Dennis Ritchie -- An Appreciation

[Kaz Kylheku]

You didn't have a choice.


How odd.

Not really. Keeping the base API in C means that these functions can be used
from C programs, and also are easier to use from other languages.

 

[Ian Collins]

Not really. Keeping the base API in C means that these functions can be used
from C programs, and also are easier to use from other languages.

They can be declared as C, but still written in C++.

 

[Kaz Kylheku]

They can be declared as C, but still written in C++.

Then people need a C++ compiler to build it, and also typically drags in
dependencies on C++ libraries (unless special steps are taken to scrub those
out).

 

[jacob navia]

Le 02/12/11 00:20, Joe keane a écrit :
I think operator overloading is a gain of about zero.

But then.... he proposes using operator overloading and
wrotes this code:

...

[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; }]
...
};

Why is he against operator overloading in C?

This is kind of completely schizophrenic.

 

[JohnF]

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

Sure, as a practical issue, some particular application may be
way, way better programmed in one language than in another.
But "practical" wasn't the issue. Even a walking person can >>think<<
how much better a train (or any faster-moving travel) might be.
As far as programming is concerned, in my own case I programmed
in Fortran (and a few assemblers) for my first 10 years, but
then >>immediately<< recognized the superiority of C (for almost
all purposes) as soon as I read the first few chapters of K&R.
Again, it's not a "practical" question. It's whether or not
your mind becomes so conditioned by using one programming language,
more-or-less exclusively, that your semantic/algorithmic thinking
becomes constrained to that language's syntax. That's what Sapir-Whorf
would say interpreted in a programming context. And I'd say "no",
at least not in my case. Although, of course, there's quite a learning
curve to become fluent in any language, natural or artificial.

 

[JohnF]

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.


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.

Sure, even postscript is Turing complete (my favorite example
being http://pcal.sourceforge.net/ that does all its calendar
calculations, including moon phases, right in the postscript
sent to the printer). But, see my followup to Willem,
convenience/practicality just isn't the issue.

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.

Yeah, that's true, that a Turing complete language
without some features will condition your mind to solve
problems without those features. And that can be a great
practical disadvantage. But the class of problems
(e.g., writing a Lisp compiler in Cobol, or using iteration
rather than recursion in old Basic) you'll deem solvable is
the same. That is, your >>thinking<< about what algorithms
you can program will be the same, as long as you're ingenious
enough to express those algorithms in an inconvenient language.
But any "thought" -- any program that can be written -- is
still expressible in that language, even if inconveniently.
Sapir-Whorf, vis-a-vis natural language, suggests some
languages don't have words/phrases for certain concepts,
and then people speaking those languages never think those
thoughts. For programming languages, the semantics -- the class
of all possible "thoughts" -- is the computable functions,
and every Turing complete language has the "words" to express
them all, even if clumsily.

 

[Joe keane]

Why is he against operator overloading in C?

I'm not -against- it. I am more 'eh'. But if you can do just fine
without it, why would it be so important to add it to the language?
Especially C?

But then.... he proposes using operator overloading and
wrotes this code:

Right and i put it in brackets meaning you can include it or not
according to taste.

Note that first we define normal methods. Then the operators are
inlines in terms of those.

If we include this it's still up to the calling function which form to
use (oh and it should be obvious how to switch between the two forms,
otherwise you screwed up).

You can use the operator, or not, your choice.

 

[Kaz Kylheku]

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

Turing equivalence requires that each machine doing solving the same
task in different ways has unlimited memory. One task needing four terabytes
of RAM to complete (and then eight if the input is slightly extended!) while
antoher needs a few kilobytes does not feel like a stylistic difference.

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???

Computing something isn't the same as expressing it. Expressing means that if
you're familiar with the language, you can immediately recognize for instance,
"hey, this program is obviously computing Fibonacci numbers using
recursion".

One way in which expressivity lost is the lack of abstraction. The more
distracting, irrelevant details the program has to be concerned with, which
have to be done for /any/ task in similar ways, the less it expresses the
particular task. I.e. the less abstract it is.

Those irrelevant things that are mixed into the solution make every program
look like every other program, no matter what it computes.

E.g. if you take any sample of 500 machine language instructions out of
your computer's memory, it looks the same as any other 500. All it expresses
is "I am an amorphous block of machine language".

 

[Jorgen Grahn]

Le 30/11/11 22:42, Jorgen Grahn a écrit : ....
That is because you did not know that Fortran has operator
oerloading, C#, even Java.

I don't care about those languages. But I could have sworn that Java
didn't have it, and my googling just shows me people rationalizing the
fact ...

I have added operatr overloading
to the lcc-win compiler and it is very useful.

As an isolated feature? I'd much rather have function overloading. I
might consider operator overloading mildly useful in a future C
standard -- if it contained function overloading and references as
well.

/Jorgen

 

[Geoff]

I don't care about those languages. But I could have sworn that Java
didn't have it, and my googling just shows me people rationalizing the
fact ...


As an isolated feature? I'd much rather have function overloading. I
might consider operator overloading mildly useful in a future C
standard -- if it contained function overloading and references as
well.

If you guys keep adding these kinds of features to C, eventually you
will have C++. It's always nice to know where you're headed.