"The Unreasonable Effectiveness of C"

[Lynn McGuire]

"The Unreasonable Effectiveness of C"
http://damienkatz.net/2013/01/the_unreasonable_effectiveness_of_c.html

"For years I've tried my damnedest to get away from
C. Too simple, too many details to manage, too old
and crufty, too low level. I've had intense and
torrid love affairs with Java, C++, and Erlang. I've
built things I'm proud of with all of them, and yet
each has broken my heart. They've made promises they
couldn't keep, created cultures that focus on the
wrong things, and made devastating tradeoffs that
eventually make you suffer painfully. And I keep
crawling back to C."

Nice article from 2013.

Lynn

 

[Johann Klammer]

"The Unreasonable Effectiveness of C"
http://damienkatz.net/2013/01/the_unreasonable_effectiveness_of_c.html

"For years I've tried my damnedest to get away from
C. Too simple, too many details to manage, too old
and crufty, too low level. I've had intense and
torrid love affairs with Java, C++, and Erlang. I've
built things I'm proud of with all of them, and yet
each has broken my heart. They've made promises they
couldn't keep, created cultures that focus on the
wrong things, and made devastating tradeoffs that
eventually make you suffer painfully. And I keep
crawling back to C."

Nice article from 2013.

Lynn

Again?

https://groups.google.com/forum/#!original/comp.lang.c/A63MoF55v4U/YuHyU1AcvpcJ

(not criticising, just wondering..)

 

[Lynn McGuire]

Again?

https://groups.google.com/forum/#!original/comp.lang.c/A63MoF55v4U/YuHyU1AcvpcJ

(not criticising, just wondering..)

Ah, a tribute to my own incompetence.

Sorry about that.

Lynn

 

[rescattered]

Ah, a tribute to my own incompetence.



Sorry about that.



Lynn

Still -- not a bad post for the author of the "Newbie at Programming" thread from earlier today to see.

 

[BartC]

"The Unreasonable Effectiveness of C"
http://damienkatz.net/2013/01/the_unreasonable_effectiveness_of_c.html

"For years I've tried my damnedest to get away from
C.

I've tried for years to go the other way!

Too simple, too many details to manage, too old

and crufty, too low level. I've had intense and
torrid love affairs with Java, C++, and Erlang. I've
built things I'm proud of with all of them, and yet
each has broken my heart. They've made promises they
couldn't keep, created cultures that focus on the
wrong things, and made devastating tradeoffs that
eventually make you suffer painfully. And I keep
crawling back to C."

Nice article from 2013.

Quite a bit of misinformation:

"C has a standardized application binary interface (ABI) that is supported
by every OS, language and platform in existence."

No it hasn't (that I have heard of). In fact it can take quite a bit of
effort to find out even how big a 'long' is, presented only with an
interface spec in a header file.

"If you want to write something once and have it usable from the most
environments and use cases possible, C is the only sane choice."

My experience is you write something once, then /even on the same platform/,
every compiler you try will find something different to complain about.
Unless you write code in such a rigid way that you might as well get into
Ada.

"C has the fastest development interactivity of any mainstream statically
typed language."

Well here he might be right! By virtue of narrowing it down a little
('mainstream' so that the only competitors are C++ and friends, and
'statically typed' so that most rapid development languages are eliminated).

He makes a good case for the existence of such a language, not such a good
one for C itself. There is no reason for another language other than C to be
able to do all this stuff too. But the ubiquity of the language (especially
its use in OSs where it's difficult to use much else) seems to have long
stifled any competition.

 

[James Kuyper]

I've tried for years to go the other way!

Too simple, too many details to manage, too old

Quite a bit of misinformation:

"C has a standardized application binary interface (ABI) that is supported
by every OS, language and platform in existence."

That's a bizarre claim. I can't imagine what he was thinking of - it
bears no resemblance to reality.

....

"If you want to write something once and have it usable from the most
environments and use cases possible, C is the only sane choice."

My experience is you write something once, then /even on the same platform/,
every compiler you try will find something different to complain about.
Unless you write code in such a rigid way that you might as well get into
Ada.

I don't know what you mean by "rigid" - but it you're referring to
something that is in fact needed to avoid those complaints, it's almost
certainly something you should be doing. If you find that sufficiently
uncomfortable that you would prefer using Ada, go ahead. However, first
make sure that Ada is available on the desired target platform. One of
C's big advantages over just about all other languages is the wide
variety of platforms for which fully conforming implementations of C are
available.

From what I've seen of your postings on this newsgroup, you don't have
enough knowledge of C to write portable C code, and are sufficiently
unsympathetic to the design goals of C that it's very difficult for you
to assimilate the coding practices needed to write such code. I suppose
those practices my seem "rigid" from your point of view.

 

[Malcolm McLean]

"The Unreasonable Effectiveness of C"
http://damienkatz.net/2013/01/the_unreasonable_effectiveness_of_c.html
Lynn

C hits the sweet spot.
If you're doing something inherently trivial, but nevertheless complex,
like coding a mass of "business rules", then there's an temptation for
the intelligent programmer to put complexity, and therefore interest,
into the language he's using. But if you're doing something inherently
difficult and complex, then you want the complexity in the algorithm,
not in the coding constructs you're using. So most interesting code is
written in C.
You want floating point arithmetic, subroutine calls, and register
usage abstracted. You want infix expressions, and an easy way of
laying out data in memory. But that's about all you need, the rest
can be expressed in terms of arithmetical and logical operations,
copying memory, and conditional branches. Then C provides for loops,
while loops and switches over the conditional branches.

But that's pretty much it.

 

[BartC]

On 05/30/2014 02:29 PM, BartC wrote:


I don't know what you mean by "rigid" - but it you're referring to
something that is in fact needed to avoid those complaints, it's almost
certainly something you should be doing.

What, endlessly casting from unsigned char* to signed char* and back again?
Do you really want to see code full of pointless conversions like that? DMC
in particular has got such a bee in its bonnet about it, that I haven't been
able to use it at all since I refuse to add those casts (it classes them as
errors rather than warnings).

From what I've seen of your postings on this newsgroup, you don't have
enough knowledge of C to write portable C code

Leaving such aspersions on my abilities aside ...

, and are sufficiently
unsympathetic to the design goals of C that it's very difficult for you
to assimilate the coding practices needed to write such code. I suppose
those practices my seem "rigid" from your point of view.

.... let me take some code not written by me: one C source module of a Python
interpreter. And the results of compiling with the standard options of these
six compilers are:

gcc: many warnings, one error

Pelles C: many warnings (different from gcc), and two errors, one different
from gcc

Lccwin32: one warning (different from any of the above)

DMC: four errors (different from any of the above)

Clang: loads of warnings (same as most of the gcc ones), no errors

gcc/TDM: same as gcc, plus one more error thrown in

As I said, every compiler will find something different to complain about.
(The problem being that a C program isn't just specified by its source code,
you also have to specify the compiler, the version of the compiler, and the
exact collection of options that will make it all work. And this is for just
*one* platform and *one* OS! So much for portability.)

 

[James Kuyper]

What, endlessly casting from unsigned char* to signed char* and back again?

No, if you do it right the number of casts needed is quite small. I
remember you making this claim before, though I no longer remember your
reasons for thinking it was necessary, only that they didn't make sense.

Leaving such aspersions on my abilities aside ...

I'm just referring to aspersions you cast on yourself. You admitted to
having learned as little about C as possible, just enough to make
minimal use of it, because of your distaste for the language.

... let me take some code not written by me: one C source module of a Python
interpreter. And the results of compiling with the standard options of these
six compilers are:

gcc: many warnings, one error

Pelles C: many warnings (different from gcc), and two errors, one different
from gcc

Lccwin32: one warning (different from any of the above)

DMC: four errors (different from any of the above)

Clang: loads of warnings (same as most of the gcc ones), no errors

gcc/TDM: same as gcc, plus one more error thrown in

It would be much more meaningful to identify precisely the code that
you're compiling, and the compiler options you were using, along with
the actual text of the messages.

As I said, every compiler will find something different to complain about.
(The problem being that a C program isn't just specified by its source code,
you also have to specify the compiler, the version of the compiler, and the
exact collection of options that will make it all work. And this is for just
*one* platform and *one* OS! So much for portability.)

You're right, the C standard mandates that at least one diagnostic
message, contents unspecified, must by generated by the processing of a
translation unit that contains any syntax errors or constraint
violations, as well as for a couple of specific conditions. That's
really quite minimal. Everything beyond that is up to the individual
implementations.

However, while the standard permits a great deal of variation,
real-world compilers need to be useful to their users, and the actually
amount of variation between compilers is much smaller than the standard
permits it to be. I strongly suspect that a C expert looking at those
error messages and the source code would use the word "different" a lot
less frequently than you did. I suspect that many of the supposedly
"different" messages were really addressing the same problematic code
from multiple different (and equally valid) points of view.

 

[Ian Collins]

.... let me take some code not written by me: one C source module of a Python
interpreter. And the results of compiling with the standard options of these
six compilers are:

Did you invoke the compilers in what they would consider standard's
conform mode?

Alas, too many opensource projects assume the world to be Linux+gcc and
don't bother to write correct, conforming, code. As one who uses
!Linux+!gcc, this used to drive me nuts... I've started judging the
"quality" of opensource projects by their willingness to accept
standards conforming patches

 

[Kenny McCormack]

Did you invoke the compilers in what they would consider standard's
conform mode?

Alas, too many opensource projects assume the world to be Linux+gcc and
don't bother to write correct, conforming, code. As one who uses
!Linux+!gcc, this used to drive me nuts... I've started judging the
"quality" of opensource projects by their willingness to accept
standards conforming patches

I think you should carefully read and consider and accept the wisdom of
this .sig quote:
--
For instance, Standard C says that nearly all extensions to C are prohibited. How
silly! GCC implements many extensions, some of which were later adopted as part of
the standard. If you want these constructs to give an error message as
“required†by the standard, you must specify ‘--pedantic’, which was
implemented only so that we can say “GCC is a 100% implementation of the
standardâ€, not because there is any reason to actually use it.

 

[Chad]

My limited programming experience has taught it's sometimes easier to use C and other times it's easier to use Java.

 

[OldBlueBear]

Why bother with anything but C.
I am not referring to pretender ANSI C but the "real thing"; Classic C. Classic C, that is K&R (Whitebook) Cwith the mods from the Interdata 8/32 port [passing struct, unions, bitfields, enumerated type etc) . You can do anything that requires code with this stuff (Been doing it for more than 40 years) everything from hooking straight into a bare board all the way to GUI(s) . But not with gcc it cannot compile any of the original UNIX(s) source code as it was broken along time ago. Why? The Linux weenies (or gremlins!) at work again.

You cannot beat "Real UNIX" and "Classic C", they are the Ace !