Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > Dennis Ritchie -- An Appreciation

Reply
Thread Tools

Dennis Ritchie -- An Appreciation

 
 
JohnF
Guest
Posts: n/a
 
      12-01-2011
Nick Keighley <(E-Mail Removed)> wrote:
>
> read up on "blub" or the The Sapir-Whorf Hypothesis


Very interesting. I've been aware of Sapir-Whorf for
a long time regarding linguistics, but hadn't been
aware of its interpretation with respect to programming
languages. Googling blub and sapir-whorf, and then reading
http://en.wikipedia.org/wiki/Linguistic_relativity
brings the following question to mind:
Doesn't Church's thesis and Turing completeness
kind of take the steam out of any "linguistic relativity"
idea applied to programming languages? At best, there's
maybe some "stylistic relativity", depending on how you
prefer designing/writing code. But regarding what's
computable, and what computable functions a given language
can express, that's pretty much a done deal. No???
--
John Forkosh ( mailto: http://www.velocityreviews.com/forums/(E-Mail Removed) where j=john and f=forkosh )
 
Reply With Quote
 
 
 
 
Malcolm McLean
Guest
Posts: n/a
 
      12-01-2011
On Dec 1, 1:35*am, James Kuyper <(E-Mail Removed)> wrote:
>
> The expression a + b gives the result of adding a to b; if the meaning
> of that phrase is not crystal clear for the relevant type(s), WITHOUT
> having to read the code or documentation for the operator overload, then
> operator+() should never have been overloaded for that(those) type(s).
>

mytype x = 1,
mytype y;

x = sqrt(-x);
y = 0 * x;

What should y be? You can't always be crystal clear.


 
Reply With Quote
 
 
 
 
James Kuyper
Guest
Posts: n/a
 
      12-01-2011
On 12/01/2011 05:53 AM, Malcolm McLean wrote:
> On Dec 1, 1:35�am, James Kuyper <(E-Mail Removed)> wrote:
>>
>> The expression a + b gives the result of adding a to b; if the meaning
>> of that phrase is not crystal clear for the relevant type(s), WITHOUT
>> having to read the code or documentation for the operator overload, then
>> operator+() should never have been overloaded for that(those) type(s).
>>

> mytype x = 1,
> mytype y;
>
> x = sqrt(-x);
> y = 0 * x;
>
> What should y be? You can't always be crystal clear.


If the overloaded operator (or function) can't be crystal clear, don't
overload it. That's my point.

Offhand, I can't think of any type for which it would be reasonable to
overload all of the operators used above, and sqrt(), unless the value
of 'y' came out as (mytype)0 in the end - but I wouldn't be surprised if
you could come up with a reasonable counter-example (it's trivial, of
course, to come up with an unreasonable counter-example).

Your example is NOT clear solely because the name 'mytype' conveys no
special meaning. Good design is not just about the interface of a type,
but also involves the name of the type. The only thing that particular
type name conveys is information about the ownership of the type. If the
name of the type doesn't convey the information the user needs to know
in order to understand what the above code means, then it wasn't
properly named, or the user doesn't know enough about the meaning of the
type to justify using it.
--
James Kuyper
 
Reply With Quote
 
James Kuyper
Guest
Posts: n/a
 
      12-01-2011
On 12/01/2011 05:05 AM, Nick Keighley wrote:
> On Nov 30, 11:37�pm, James Kuyper <(E-Mail Removed)> wrote:

....
>> C's scalar types represent characters, numbers, or pointers. It also has
>> derived types that are arrays, and functions. Operator overloads can
>> make a class type look like one of those kinds of types, and they can be
>> a very useful, reasonable thing to define, if the class represents an
>> extension to the idea of characters, numbers, pointers, arrays or
>> functions.

>
> operator overloading in C++ can also be used for conversion operators
> as well.


Yes, and that's something that's essential for implementation of smart
pointer types, for instance.
--
James Kuyper
 
Reply With Quote
 
Nick Keighley
Guest
Posts: n/a
 
      12-01-2011
On Dec 1, 10:18*am, JohnF <(E-Mail Removed)> wrote:
> Nick Keighley <(E-Mail Removed)> wrote:


> > read up on "blub" or the The Sapir-Whorf Hypothesis

>
> Very interesting. I've been aware of Sapir-Whorf for
> a long time regarding linguistics, but hadn't been
> aware of its interpretation with respect to programming
> languages.


my own application. Though doubtless plenty of other people thought of
it first. I think there's a good reason SW is still a hypothesis; that
is that not all linguists believe it. People seem to be pretty
flexible at stretching their language to cover new situtations.

> Googling blub and sapir-whorf, and then reading
> * *http://en.wikipedia.org/wiki/Linguistic_relativity
> brings the following question to mind:
> * *Doesn't Church's thesis and Turing completeness
> kind of take the steam out of any "linguistic relativity"
> idea applied to programming languages? At best, there's
> maybe some "stylistic relativity", depending on how you
> prefer designing/writing code. But regarding what's
> computable, and what computable functions a given language
> can express, that's pretty much a done deal. No???


yes you can compute anything in any reasonable programming language
(all well known programmign languages are "reasonable" from this point
of view), but the set of computations that can be computed easily and
conventiently is much smaller.

I /could/ write a Lisp compiler in COBOL but I suspect I wouldn't
enjoy it.

If I'm using an old dialect of Basic I won't automatically think of
recursion as a way to solve a problem.

I'm deliberatly learning languages outside the imperitive/OO camp. It /
does/ change the way you look at things.



 
Reply With Quote
 
Willem
Guest
Posts: n/a
 
      12-01-2011
JohnF wrote:
) Doesn't Church's thesis and Turing completeness
) kind of take the steam out of any "linguistic relativity"
) idea applied to programming languages? At best, there's
) maybe some "stylistic relativity", depending on how you
) prefer designing/writing code. But regarding what's
) computable, and what computable functions a given language
) can express, that's pretty much a done deal. No???

No.

What Turing is saying, in a sense, is that you can always emulate the
features of language A in language B, and therefore you can compute the
same things. However, you have to be familiar with language A to be able
to emulate its features in language B.

The upside to this is: if you learn a very different language, such as lisp
or haskell or prolog, or even ruby, you can then go back to C and implement
the new features that make programming so much easier, but which you never
knew existed before you learned those languages.


Claiming that it is only "stylistic relativity" is like claiming that the
invention of the train really wasn't that important, because people could
get where they wanted already simply by walking.


SaSW, Willem
--
Disclaimer: I am in no way responsible for any of the statements
made in the above text. For all I know I might be
drugged or something..
No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT
 
Reply With Quote
 
Joel C. Salomon
Guest
Posts: n/a
 
      12-01-2011
On 11/30/2011 06:29 PM, in reference to lcc's operator overloading
extension, jacob navia wrote:
> Le 01/12/11 00:21, Ian Collins a écrit :
>> Do you use pass by value, or do you pass by reference under the hood?

>
> Of course by reference... qfloats are 120 bytes long...
> For a function of 2 arguments you would have to push 240 bytes
> each time... impossible.


When I first read about lcc's operator overloading, these two aspects
struck me as not in the "spirit of C": function names with operator
symbols inside them and the invention of reference parameters.

[As an aside, to Jacob: How much complexity is added to the grammar to
accommodate things like "operator+"? Is this as intrusive as it seems
on first blush?]

That said, operator overloading is a handy idea. Before he left Bell
Labs, Ken Thompson added operator overloading to the Plan 9 C compiler.
I believe this extension is still available in the 8c/6c C compilers
distributed with Google Go. It's... different than Jacob's C++-inspired
idea. See Jim McKie's quoting Ken's documentation at
<http://9fans.net/archive/2001/05/482>.

I think operator overloading is a nice feature (in either form); YMMV as
to which (if any) is a better fit to C.

--Joel
 
Reply With Quote
 
88888 Dihedral
Guest
Posts: n/a
 
      12-01-2011
On Thursday, December 1, 2011 9:38:31 PM UTC+8, Willem wrote:
> JohnF wrote:
> ) Doesn't Church's thesis and Turing completeness
> ) kind of take the steam out of any "linguistic relativity"
> ) idea applied to programming languages? At best, there's
> ) maybe some "stylistic relativity", depending on how you
> ) prefer designing/writing code. But regarding what's
> ) computable, and what computable functions a given language
> ) can express, that's pretty much a done deal. No???
>


I agree with you. But Turing died to young, I'll pay my regrets to the mass
not to understand his works in time. H was living like another famous artiest
who cut his own ear.
 
Reply With Quote
 
Joe keane
Guest
Posts: n/a
 
      12-01-2011
In article <(E-Mail Removed)>,
Ian Collins <(E-Mail Removed)> wrote:
>Until you you have to implement a specialised numeric type or a smart
>pointer.


I have done so several times in C, and i chose not to use overloading.

Of course i like to write in C, then make a C++ wrapper:

extern "C"
{
int qz_add(struct qz *x, struct qz *y, struct qz *res);
int qz_addw(struct qz *x, struct qz *y, struct qz *res, int w);
int qz_mul(struct qz *x, struct qz *y, struct qz *res);
...
}

class Qz
{
struct qz p;

inline int add(Qz& x, Qz& y)
{ return qz_add(&x.p, &y.p, &this->p); }
inline int addw(Qz& x, Qz& y, int w)
{ return qz_addw(&x.p, &y.p, &this->p, w); }
inline int mul(Qz& x, Qz& y);
{ return qz_mul(&x.p, &y.p, &this->p); }
...

[inline Qz operator +(Qz& x, Qz& y)
{ Qz tmp; (void) tmp.add(x, y); return tmp; }
[inline Qz operator +()(Qz& x, Qz& y, int w)
{ Qz tmp; (void) tmp.addw(x, y, w); return tmp; }
inline Qz operator *(Qz& x, Qz& y)
{ Qz tmp; (void) tmp.mul(x, y); return tmp; }]
...
};

[throw in some 'const']
 
Reply With Quote
 
Ian Collins
Guest
Posts: n/a
 
      12-01-2011
On 12/ 2/11 12:20 PM, Joe keane wrote:
> In article<(E-Mail Removed)>,
> Ian Collins<(E-Mail Removed)> wrote:
>> Until you you have to implement a specialised numeric type or a smart
>> pointer.

>
> I have done so several times in C, and i chose not to use overloading.


You didn't have a choice.

> Of course i like to write in C, then make a C++ wrapper:


How odd.

> extern "C"
> {
> int qz_add(struct qz *x, struct qz *y, struct qz *res);
> int qz_addw(struct qz *x, struct qz *y, struct qz *res, int w);
> int qz_mul(struct qz *x, struct qz *y, struct qz *res);
> ...
> }
>
> class Qz
> {
> struct qz p;
>
> inline int add(Qz& x, Qz& y)
> { return qz_add(&x.p,&y.p,&this->p); }
> inline int addw(Qz& x, Qz& y, int w)
> { return qz_addw(&x.p,&y.p,&this->p, w); }
> inline int mul(Qz& x, Qz& y);
> { return qz_mul(&x.p,&y.p,&this->p); }
> ...
>
> [inline Qz operator +(Qz& x, Qz& y)


So you avoided operator overloading by using it?

> { Qz tmp; (void) tmp.add(x, y); return tmp; }
> [inline Qz operator +()(Qz& x, Qz& y, int w)
> { Qz tmp; (void) tmp.addw(x, y, w); return tmp; }
> inline Qz operator *(Qz& x, Qz& y)
> { Qz tmp; (void) tmp.mul(x, y); return tmp; }]
> ...
> };
>
> [throw in some 'const']


I hope you C is better than your C++.

--
Ian Collins
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Re: RIP Dennis Ritchie Lynn McGuire C++ 12 10-18-2011 08:35 AM
Dennis Ritchie Has Died Bradley K. Sherman C Programming 28 10-18-2011 04:44 AM
Query from Dennis Ritchie C learner C Programming 6 04-04-2011 05:44 PM
Errata for The C Programming Language, Second Edition, by Brian Kernighanand Dennis Ritchie Ioannis Vranos C Programming 4 05-16-2009 03:48 PM
What is this noalias thing Dennis Ritchie is railing about ? Spiros Bousbouras C Programming 22 09-13-2007 09:28 AM



Advertisments