Linked by MOS6510 on Thu 10th Jan 2013 23:25 UTC
General Development "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."
Thread beginning with comment 548488
To view parent comment, click here.
To read all comments associated with this story, please click here.
moondevil
Member since:
2005-07-08

"I didn't say they [Algol 60, PL/I] were top quality, only better than C.


And here we go with the blanket statements again, asserted without proof.
"

Sure asserted without proof.

It is based on my understanding what a better language is, by looking at the epoch documentation that I had access to, during my degree.

For me, a languages that allow the developer to focus on the task at hand are always better than those that require them to manipulate every little detail.

Usually that detail manipulation is only required in a very small percentage of the code base.

In the end I guess it is a matter of discussing ice cream brands.

If you can't support your claims, don't make them. But before you dig into it, take a look at: https://en.wikipedia.org/wiki/Strong_typing#Variation_across_program.....

So any statements you present will most likely just express your personal opinions on the matter. Oh and I have an MS in CS, so I've heard them before (including "C sux", "C rocks" and "Let's code everything in Prolog").


And I one with focus in compiler design and distributed computing.

Usually static languages with strong typing don't allow for implicit conversion among types, forcing the developers to cast in such cases.

Overflow and underflow are also considered errors, instead of being undefined like in C.

Pointers and arrays are also not compatible, unless you take the base address of the array.

Enumerations are their own type and do not convert implicitly to numeric values, like in C.


Since 1989 C has had rigorous support for this kind of compartmentalization (.h interface files, .c implementation files) and virtually every single project I've ever laid eyes on has used it. Of course it's rudimentary, but there are higher constructs on top which provide most, if not all of the features you would expect.


Well let me quote another section of the article.

Languages that formally support the module concept include Ada, Algol, BlitzMax, COBOL, Component Pascal, D, Erlang, F, Fortran, Haskell, IBM/360 Assembler, IBM RPG, Java (packages are considered modules in the JLS), MATLAB, ML, Modula-2, Modula-3, Morpho, Oberon, NEWP, OCaml, Pascal, Perl, PL/I, Python, and Ruby.[citation needed] The IBM System i also uses Modules in CL, COBOL, and RPG when programming in the Integrated Language Environment (ILE). Modular programming can be performed even where the programming language lacks explicit syntactic features to support named modules.


Somehow I don't see C listed as a language that supports modules.

Sure you can do modular programming by separate compilation, but that is not the same as having language support for it. I have done it for years.

For example, in some languages that support modules, the compiler has builtin linker and is also able to check dependencies automatically and only compile required modules.

The types are also cross-checked across modules. In C,
some linkers don't complain if the extern definition and the real one don't match.

If your hands our bound by your customer, then I suspect you have other problems in your project, not just with the language.


In the Fortune 500 corporate world, usually there isn't too much developer freedom.

"To expert C coders, you mean.

Agree, it's probably news to you. GCC, for instance, supports -W and -Wall, both of which together activate lots of helpful static code analysis in GCC (unused variables, weird casts, automatic sign extensions, etc.).
"

I am aware of it.

As I answered in another thread, I have done C programming between 1992 and 2001, with multiple compilers and operating systems.

Since then, most of the projects I work on rely on another languages.

"Just stating my opinion.

No problem there - when you clearly state something as personal opinion, I have no problem. It's only the assertions and blanket statements that make my blood boil. We could probably understand each other over a beer much better than over the Intertubes.
" [/q]

Yeah, it would be surely a better way to discuss this.

Reply Parent Score: 3

saso Member since:
2007-04-18

For me, a languages that allow the developer to focus on the task at hand are always better than those that require them to manipulate every little detail.

Usually that detail manipulation is only required in a very small percentage of the code base.

Essentially what you're describing is limiting freedom in what you can do in a certain language, so that a programmer has no chance of running into trouble. Sometimes it's a good thing, sometimes it's slowing you down. The lack of pointers in Java, for instance, has frequently tied my hands down, e.g. I can't pass a subarray as a zero-cost pointer to a subroutine to work on. Instead, I either have to change the interface to include an offset index, or create a copy (potentially a huge performance penalty if the operation is trivial). If I want to make sure that the callee doesn't modify it, I must copy it. In C, I'd simply make it a pointer to const.

In the end I guess it is a matter of discussing ice cream brands.

Sure is.

Usually static languages with strong typing don't allow for implicit conversion among types, forcing the developers to cast in such cases.
Overflow and underflow are also considered errors, instead of being undefined like in C.
Pointers and arrays are also not compatible, unless you take the base address of the array.
Enumerations are their own type and do not convert implicitly to numeric values, like in C.

All of what you describe are limits on what a developer can do. At times it's sensible to limit them, sometimes it's simply throwing hurdles his or her way. For a CRM system, or a web app, fine, it's sensible not to manipulate pointers - that isn't performance critical code. But not everywhere. I have no problem with you saying 'sometimes/most often these are not necessary'. The problem is when you assert that C is essentially a stupid, pointless language and that everything else that you like is better. I know it's tough to swallow, but there are painfully few OS kernels written in Pascal, and probably for good reason.

Somehow I don't see C listed as a language that supports modules.

That's merely because the author didn't follow his/her own definition. The logical structure of such an argument is:
1) If language X has feature Y, then has support for modular programming
2) Here are the languages I know of that meet criterion 1
All the author did was miss another language that clearly meets their own criteria for modular programming.

For example, in some languages that support modules, the compiler has builtin linker and is also able to check dependencies automatically and only compile required modules.

This is a compiler/build infrastructure feature, not a language feature. For instance, Sun's javac doesn't do that (just tested it), yet Java clearly fits the definition. So for all matters, this is a pointless criterion.

The types are also cross-checked across modules. In C,
some linkers don't complain if the extern definition and the real one don't match.

While it is possible to have poorly written code where interface declarations are completely torn away from their own implementations, the correct practice is to #include your own interface files when making the implementation, exactly to provide this check. Again, your complaint is at least 20 years out of date (this was true in K&R C and other pre-C89 dialects which lacked proper interface declarations).

Reply Parent Score: 3