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."
Order by: Score:
true, but some libraries...
by evert on Fri 11th Jan 2013 00:01 UTC
evert
Member since:
2005-07-06

The STL and Boost are just awesome, even when not using a OO programming style a C++ programmer has some very nice libraries available. Being able to use vectors is nice. Having many good libraries is nice:

http://en.wikipedia.org/wiki/Category:C%2B%2B_libraries

But otherwise, I mostly agree with the author. C has shortcomings, but they are well documented and tools are available to deal with them.

Edited 2013-01-11 00:07 UTC

Reply Score: 5

RE: true, but some libraries...
by shmerl on Fri 11th Jan 2013 00:03 UTC in reply to "true, but some libraries..."
shmerl Member since:
2010-06-08

C++11 is also great.

Reply Score: 4

RE: true, but some libraries...
by rexstuff on Fri 11th Jan 2013 00:30 UTC in reply to "true, but some libraries..."
rexstuff Member since:
2007-04-06

What are you talking about?! The STL and Boost are bloated and ugly; and worst of all they produce the most useless, verbose, garbage compile-time errors. (Admittedly the ugliness of those errors are partly due to C++'s template implementations, and STL and Boost are far and away the best set of libraries for C++)

Reply Score: 8

RE[2]: true, but some libraries...
by kwan_e on Fri 11th Jan 2013 01:14 UTC in reply to "RE: true, but some libraries..."
kwan_e Member since:
2007-02-18

What are you talking about?! The STL and Boost are bloated and ugly; and worst of all they produce the most useless, verbose, garbage compile-time errors. (Admittedly the ugliness of those errors are partly due to C++'s template implementations, and STL and Boost are far and away the best set of libraries for C++)


The problem there is the lack of adequate tooling for C++. C++ templating should have been largely fixed by having Concepts. Too bad it didn't make it into the standard.

Reply Score: 4

dorin.lazar Member since:
2006-12-15

The STL and Boost are bloated and ugly; and worst of all they produce the most useless, verbose, garbage compile-time errors.

I see little bloat in STL, although for a while I was misguided as well, and thought that STL was too bloated. It isn't. STL is quite small and quite elegant; I would not be afraid of using it.
With Boost I can agree that it's a bloated animal, but nobody says you should use Boost. It's just too big, and sometimes you need a smart pointer.
But now, C++11 really comes in and saves the day. It does make the STL more efficient, and makes you need less features of Boost. It adds the smart pointers you need in the standard, as well as threading and timing. It's quite nice, you should try it. ;)
The errors are indeed awful; but maybe this is something that can be improved.

Reply Score: 5

Brendan Member since:
2005-11-16

Hi,

As far as I can tell, for all programming languages the majority of problems/bugs are caused by people having trouble dealing with complexity.

The C++ way of dealing with problems caused by complexity is to add more complexity.

- Brendan

Reply Score: 9

kwan_e Member since:
2007-02-18

The C++ way of dealing with problems caused by complexity is to add more complexity.


It's not, as evidenced by the C++11 process. A lot of the effort was made to simplify the language. The "complexity" if you can call it that, mostly came from increasing library features.

Reply Score: 3

ebasconp Member since:
2006-05-09

The C++ way of dealing with problems caused by complexity is to add more complexity.

- Brendan


Are you sure what are you talking about?

C++03:
------
vector<Object*> objs = get_objects();
for (vector<Object*>::const_iterator i = v.begin(); i != v.end(); ++v)
{
cout << (*i)->toString() << endl;
}
for (vector<Object*>::iterator i = v.begin(); i != v.end(); ++v)
delete *i;


C++11:
------
vector<shared_ptr<Object>> objs = get_objects();
for (auto& s : v)
{
cout << s->toString() << endl;
}

The C++11 stuff is easier to read, easier to program, does not need to deal with memory manually and is exception-safe.

Introducing range-based for loops, static type deduction, move semantics, shared pointers and a lot of interesting stuff, they simplified the language, made the libraries more efficient and they kept backwards compatibility.

Edited 2013-01-11 19:48 UTC

Reply Score: 2

Luminair Member since:
2007-03-30

Did you just make code smaller than it needs to be just to make a point, as if lines matter

Reply Score: 2

ebasconp Member since:
2006-05-09

Not at all.

1. I replaced the classical "for loop" for the range based for loop, that hides complexity and improves reading a lot.

2. I used shared_ptr<Object> instead of Object*, so I do not need to iterate through all the vector elements to release them; the shared_ptr does the job.

3. Since the shared_ptr<Object> is a value type (storing a pointer), if an exception occurs, the vector will invoke the Object destructors automatically, making my code exception-safe.

All of that and my code is smaller ;)

Reply Score: 3

tylerdurden Member since:
2009-03-17

Am I missing something? Why didn't you use the range for look in the original code as well, to compare apples to apples.

Reply Score: 2

RE: true, but some libraries...
by Vanders on Fri 11th Jan 2013 11:25 UTC in reply to "true, but some libraries..."
Vanders Member since:
2005-07-06

The STL and Boost are just awesome, even when not using a OO programming style a C++ programmer has some very nice libraries available. Being able to use vectors is nice.


Vectors are nice (as are Lists) but those alone aren't good enough reasons to use C++.

One thing that's always confused me is the odd separation between the STL and language features. For example, why are Iterators an STL class rather than being a language construct, along with some syntactic sugar like a foreach statement?

Reply Score: 3

RE[2]: true, but some libraries...
by kwan_e on Fri 11th Jan 2013 11:51 UTC in reply to "RE: true, but some libraries..."
kwan_e Member since:
2007-02-18

One thing that's always confused me is the odd separation between the STL and language features. For example, why are Iterators an STL class rather than being a language construct, along with some syntactic sugar like a foreach statement?


One of the biggest reasons why C++ is the complicated language it is is due to the design principle they used that most of the heavy lifting be done in libraries.

The STL and TR/Boost libraries serve as a demonstration of C++ language features.

There's also the other principle of "you don't pay for what you don't use". Having library features as part of the language features could result in unwanted features being pulled into low level code. Having a separate library is a very strong signal that the inclusion of heavy weight stuff is intentional when it's in code.

Reply Score: 4

Vanders Member since:
2005-07-06

One of the biggest reasons why C++ is the complicated language it is is due to the design principle they used that most of the heavy lifting be done in libraries.


That explains my question regarding Iterators, but I still find the split rather odd and slightly arbitrary.

Of course my complaint is technically invalid since C++11 added syntactic sugar for foreach loops, so at least the syntax isn't as ugly now.

Reply Score: 3

Carewolf Member since:
2005-09-08

It is because C++ is a library programing language. If you don't need a specialized library, you probably shouldn't be using C++. This is also the reason STL doesn't matter, if you need STL you are using C++ wrong.

Reply Score: 2

tylerdurden Member since:
2009-03-17

So the main reason for using C++ are libraries, except when you use them, in which case you're using C++ wrong... ;-)

Edited 2013-01-12 21:07 UTC

Reply Score: 2

kwan_e Member since:
2007-02-18

This is also the reason STL doesn't matter, if you need STL you are using C++ wrong.


Needing containers (and now threads, with C++11) is wrong?

Reply Score: 2

Objective-C
by saso on Fri 11th Jan 2013 00:39 UTC
saso
Member since:
2007-04-18

I really liked Smalltalk, but it was just too darn slow and unusable in the real world. Then, 10 years ago, I tried coding in Objective-C on Linux (with GNUstep) and I haven't changed back ever again. Since it's a pure extension on top of C, I can still write all of my low-level algorithms in C and the higher level constructs in Objective-C. And GNUstep (and OpenStep on which it's based) is really a freakin' great library. Even for non-graphical work it's super simple:

1) There are two classes implementing collections (NSArray, NSDictionary), not a bajillion.

2) The garbage collector is extremely predictable (ref counts).

3) The class hierarchy is very shallow (at most 1-2 superclasses for 95% of the entire library), so it's easy to memorize.

4) I can intermingle low-level concepts (e.g. sockets) with GNUstep constructs (NSFileHandle) and it works just fine.

5) The loose typing and built-in dynamic reflection makes many tasks super simple (e.g. -[NSArray makeObjectsPerformSelector:]).

All in all, the idea mix of high-level abstraction and low-level grunt for my taste.

Reply Score: 7

RE: Objective-C
by Hypnos on Fri 11th Jan 2013 04:06 UTC in reply to "Objective-C"
Hypnos Member since:
2008-11-19

All in all, the idea mix of high-level abstraction and low-level grunt for my taste.

Indeed, C with an elegant Smalltalk-like OO extension -- you could do much worse.

Reply Score: 2

RE: Objective-C
by dorin.lazar on Sat 12th Jan 2013 13:00 UTC in reply to "Objective-C"
dorin.lazar Member since:
2006-12-15

1) There are two classes implementing collections (NSArray, NSDictionary), not a bajillion.

And are you sure you don't need other data structures? Like, you know, trees & such? Bitmaps?

2) The garbage collector is extremely predictable (ref counts).

You can write C++ code without ever using delete, using things like smart pointers (ref counted).

3) The class hierarchy is very shallow (at most 1-2 superclasses for 95% of the entire library), so it's easy to memorize.

The point of a framework is to offer you features, not to be small. You don't need to memorize it. You should always be able to access the documentation. Qt is this sort of framework that is elegant and can help you write clean code.

When did lack of features became such a great thing?

Reply Score: 2

spot on
by bram on Fri 11th Jan 2013 00:40 UTC
bram
Member since:
2009-04-03

The author is spot on.
It is a well written article.

C++ does not force you to go OO, but it encourages it.
In large systems, OO will hurt you.

The older I get, the more I like C, and detest C++.
Read Scott Meyers on how you can get yourself in trouble with C++. There are hundreds of different pitfalls waiting to trap you.

Reply Score: 2

RE: spot on
by tylerdurden on Fri 11th Jan 2013 01:00 UTC in reply to "spot on"
tylerdurden Member since:
2009-03-17

In my experience it is the opposite; C++ deters people from proper object orientation. IMO, C++ is such a syntactical kludge that plenty of programmers I have worked with revert to procedural thinking inadvertently when coding in it.

I don't think the object orientation is what makes large C++ projects hard to maintain.

Reply Score: 5

RE[2]: spot on
by kwan_e on Fri 11th Jan 2013 01:10 UTC in reply to "RE: spot on"
kwan_e Member since:
2007-02-18

IMO, C++ is such a syntactical kludge that plenty of programmers I have worked with revert to procedural thinking inadvertently when coding in it.


Despite my C++ apologetics, I have to agree with the part about reverting to procedural thinking. However, this kind of thing is implied in Bjarne Stroustrup's book.

Some things are just not suited to an OO style. I find OO best suited for defining ADTs. Frameworks should be a mixture of procedures and ADTs, not large object systems.

Reply Score: 2

RE[2]: spot on
by phoudoin on Fri 11th Jan 2013 13:03 UTC in reply to "RE: spot on"
phoudoin Member since:
2006-06-09

I don't think the object orientation is what makes large C++ projects hard to maintain.


Nope.
It's simply their size.

Reply Score: 5

RE: spot on
by dorin.lazar on Fri 11th Jan 2013 01:30 UTC in reply to "spot on"
dorin.lazar Member since:
2006-12-15

C++ does not force you to go OO, but it encourages it.

And this is a good thing ;)
In large systems, OO will hurt you.

Uhm. I dare to disagree. Depends on what you call 'large system'. It may be the feeling that OO causes bloat because it's easy to get bloaty when you're using OOP. But that doesn't mean that it will happen.
At the core of OOP we have the association of data and the methods that work with that data, through encapsulation. I see nothing wrong with that. It does help you to be more productive, it makes more sense for larger systems to go OOP. OOP systems are simply easier to handle and to extend.

Reply Score: 4

RE[2]: spot on
by bram on Fri 11th Jan 2013 05:13 UTC in reply to "RE: spot on"
bram Member since:
2009-04-03

I have found Noel Llopis' Data-oriented design paper to be an eye opener. http://gamesfromwithin.com/data-oriented-design

With OO, it is easy to end up with a menagerie of objects all referring to each other with deep complexities. With data oriented design you tend to end up with flatter architectures and fewer dependencies.

I'm a game programmer, and I like his advice on how you could code most of your game engine subsystems as you would code your particle system.

With C, I feel more easily guided to data oriented, structures-of-arrays, instead of the OO and arrays of structures/objects.

Reply Score: 4

RE[3]: spot on
by Alfman on Fri 11th Jan 2013 06:30 UTC in reply to "RE[2]: spot on"
Alfman Member since:
2011-01-28

bram,

That's an interesting link. From a technical standpoint I don't think anything is inherently bad with C++ features. However there's no doubt that it encourages rather different approaches to software design.

C programs often use no abstractions whatsoever and will directly call the external libraries and kernel.

C++ facilitates rich levels of abstraction, which is generally a selling point for developers to choose it over C, and yet these very abstractions can be responsible for adding many more inefficient layers than we typically find in C programs.


OOP interfaces significantly help with contract-oriented programming in teams and help make problems much more manageable. I think a good OOP programmer will know where to draw the line without going crazy about everything needing to be a proper object.

There's no reason a high performance game should not be written in C++, just be mindful of too much indirection in critical loops.

Edited 2013-01-11 06:37 UTC

Reply Score: 4

Highly productive?
by dorin.lazar on Fri 11th Jan 2013 01:35 UTC
dorin.lazar
Member since:
2006-12-15

I think that the author's enthusiasm in the productivity arena is somewhat misguided. I love C but I don't find it as productive as C++ (especially when compared with C++11). It may be a personal feeling, but the OOP support that C++ offers makes you more productive, makes it easier to build higher scale applications.
And when you go into the C# development, comparing C with C# in the area of productivity is just mean towards C. I'm glad the author didn't insist much on the productivity part, because that would've been wrong. C is less productive, but it has all the other things that the author highlights.

Reply Score: 6

Sorry, C++ is a PITA.
by sergio on Fri 11th Jan 2013 02:37 UTC
sergio
Member since:
2005-07-06

C++ is too big for low level stuff and too complicated for higher level stuff. It's almost impossible to master the language... really really hard (at least for stupid people like me... and We're the 99% xD).

I think the smart way to go is plain old C for system level stuff and Java or C# for user level stuff.

Android is the perfect example of this kind of mixture. Profit.

Reply Score: 3

RE: Sorry, C++ is a PITA.
by kwan_e on Fri 11th Jan 2013 02:54 UTC in reply to "Sorry, C++ is a PITA."
kwan_e Member since:
2007-02-18

C++ is too big for low level stuff


Why are you using all the bells and whistles of C++ for the low level stuff?

and too complicated for higher level stuff.


Qt seems to be doing all right.

It's almost impossible to master the language... really really hard (at least for stupid people like me... and We're the 99% xD).


Mastering the entire language is only really necessary if you're creating libraries for wide consumption. The difficult C++ features are there to achieve generalization while still retaining static pre-compile type checking.

Reply Score: 6

RE[2]: Sorry, C++ is a PITA.
by radix on Fri 11th Jan 2013 10:54 UTC in reply to "RE: Sorry, C++ is a PITA."
radix Member since:
2012-02-07

Mastering the entire language is also necessary when working in teams or dealing with code somebody else wrote (so this affects perhaps 90% of programmers). Some people think it's necessary to use every feature language provides.

Reply Score: 2

RE[3]: Sorry, C++ is a PITA.
by sergio on Fri 11th Jan 2013 19:50 UTC in reply to "RE[2]: Sorry, C++ is a PITA."
sergio Member since:
2005-07-06

But 99% of the time you work with code created by another people!

C++ is so big that you are always learning the language, wasting precious time that can be used solving the actual problem.

Reply Score: 2

RE[4]: Sorry, C++ is a PITA.
by ebasconp on Fri 11th Jan 2013 20:30 UTC in reply to "RE[3]: Sorry, C++ is a PITA."
ebasconp Member since:
2006-05-09

Don't you consider precious the time you are learning something new?

Reply Score: 3

RE[4]: Sorry, C++ is a PITA.
by kwan_e on Sat 12th Jan 2013 00:14 UTC in reply to "RE[3]: Sorry, C++ is a PITA."
kwan_e Member since:
2007-02-18

But 99% of the time you work with code created by another people!

C++ is so big that you are always learning the language, wasting precious time that can be used solving the actual problem.


I don't think that's true. I've dived through the code of C++ libraries like Qt, Boost, STL, scene graphs and game engines, and they haven't really used language features that aren't in common use.

Reply Score: 3

RE: Sorry, C++ is a PITA.
by Soulbender on Fri 11th Jan 2013 04:59 UTC in reply to "Sorry, C++ is a PITA."
Soulbender Member since:
2005-08-18

Because Java never results in over-engineering and complexity....

Reply Score: 5

RE[2]: Sorry, C++ is a PITA.
by lucas_maximus on Fri 11th Jan 2013 13:28 UTC in reply to "RE: Sorry, C++ is a PITA."
lucas_maximus Member since:
2009-08-18

It depends whether it has the word "Enterprise" attached to it.

Reply Score: 5

RE[3]: Sorry, C++ is a PITA.
by Soulbender on Sat 12th Jan 2013 01:46 UTC in reply to "RE[2]: Sorry, C++ is a PITA."
Soulbender Member since:
2005-08-18

Ah yes, truer words has seldom been spoken. The magic word for immense Java suckiness: "Enterprise".
Heck, it carries the same magic in any programming language.

Reply Score: 3

RE[4]: Sorry, C++ is a PITA.
by moondevil on Sat 12th Jan 2013 17:10 UTC in reply to "RE[3]: Sorry, C++ is a PITA."
moondevil Member since:
2005-07-08

Yes.

I have seen examples of J2EE in C, Perl, C++, Java, C#.

You just need to let a few enterprise architects free reign.

Reply Score: 2

RE[5]: Sorry, C++ is a PITA.
by lucas_maximus on Sat 12th Jan 2013 18:44 UTC in reply to "RE[4]: Sorry, C++ is a PITA."
lucas_maximus Member since:
2009-08-18

Normally it comes about by mandated a particular technique should be used throughout the system regardless to it relevancy.

Reply Score: 2

RE[2]: Sorry, C++ is a PITA.
by sergio on Fri 11th Jan 2013 19:55 UTC in reply to "RE: Sorry, C++ is a PITA."
sergio Member since:
2005-07-06

Even the stupidest people, like myself, can read Java code and get a general idea of what it does. It's a very simple and beautiful language to read.

Over engineering is not a language problem. You can over-engenier in assembler if you want.

The problem with C++ is the language complexity itself, It's difficult with or without over engineering.

Reply Score: 2

RE[3]: Sorry, C++ is a PITA.
by ebasconp on Fri 11th Jan 2013 21:22 UTC in reply to "RE[2]: Sorry, C++ is a PITA."
ebasconp Member since:
2006-05-09

I understand written English but I do not understand German at all.

<sarcasm>
Let's blame the "German language designers" for creating a language that not all people can understand.
</sarcasm>

Reply Score: 3

RE[4]: Sorry, C++ is a PITA.
by Delgarde on Sun 13th Jan 2013 22:14 UTC in reply to "RE[3]: Sorry, C++ is a PITA."
Delgarde Member since:
2008-08-19

I understand written English but I do not understand German at all.

Let's blame the "German language designers" for creating a language that not all people can understand.


It's easy to mock, but his point was not unreasonable - Java is a much simpler language than C++, without templates, pointers, etc. A non-Java programmer looking to read Java code is going to have a much easier job understanding what he sees, than a non-C++ programmer looking to read C++ code.

Reply Score: 2

RE[5]: Sorry, C++ is a PITA.
by kwan_e on Mon 14th Jan 2013 01:17 UTC in reply to "RE[4]: Sorry, C++ is a PITA."
kwan_e Member since:
2007-02-18

Java is a much simpler language than C++, without templates, pointers, etc.


Java has generics. It even looks like C++ template syntax. Except with Java generics, you lose type information so you can't write:

if( obj instanceof HashMap<String, String> )

You have to write:

if( obj instanceof HashMap<?, ?> )

A non-Java programmer looking to read Java code is going to have a much easier job understanding what he sees, than a non-C++ programmer looking to read C++ code.


In my experience, Java's over reliance on inheritance makes the behaviour of Java code very hard to figure out just by looking at it. In general I find dependence on a debugger to contribute more to unreadable design than anything else.

Reply Score: 2

RE: Sorry, C++ is a PITA.
by moondevil on Fri 11th Jan 2013 07:44 UTC in reply to "Sorry, C++ is a PITA."
moondevil Member since:
2005-07-08

I am more than happy to never touched C again since 2001.

Even clang and gcc are now done in C++.

Reply Score: 3

RE[2]: Sorry, C++ is a PITA.
by ebasconp on Fri 11th Jan 2013 21:24 UTC in reply to "RE: Sorry, C++ is a PITA."
ebasconp Member since:
2006-05-09

Maybe you did not put a .c extension to your code; but C++ is an extension of C; so, you need to know C concepts (pointers, arrays, etc, pointers to functions, struts, mallocs, etc.)
.

Reply Score: 2

RE[3]: Sorry, C++ is a PITA.
by moondevil on Sat 12th Jan 2013 17:12 UTC in reply to "RE[2]: Sorry, C++ is a PITA."
moondevil Member since:
2005-07-08

When I code in C++ I take advantage of what C++ offers.

Even the C like code takes advantage of C++ improvements over plain old C.

Reply Score: 3

RE: Sorry, C++ is a PITA.
by l3v1 on Fri 11th Jan 2013 13:43 UTC in reply to "Sorry, C++ is a PITA."
l3v1 Member since:
2005-07-06

C++ is too big for low level stuff and too complicated for higher level stuff.


Uhmm, no. It's just a language. Bloatness and overcomplication is caused by the coder doing all the wrong things.

All in all, while I'm not old myself, I still I'm fairly "weird" in not trusting coders who don't know c and/or c++. If they know, but choose to use something else for a specific task/project, and they have an explainable reason why, that's OK with me. Not knowing it, or not using it for reasons like the quote, is a no-go.

Reply Score: 5

RE[2]: Sorry, C++ is a PITA.
by lucas_maximus on Mon 14th Jan 2013 11:12 UTC in reply to "RE: Sorry, C++ is a PITA."
lucas_maximus Member since:
2009-08-18

I don't know C++ or C. I always find it infuriating that this attitude still exists that you must know C/C++ to be "good".

Reply Score: 2

To each their own ...
by cade on Fri 11th Jan 2013 05:54 UTC
cade
Member since:
2009-02-28

If someone values designing code using the object oriented paradigm (OOP) then it would be expected this same person would use a language that has explicit/stronger support for OOP features (e.g. C++) rather than spending time with a language having weaker support for these features (e.g. ad-hoc simulation of OOP features in C that are rigidly implemented in C++). The issues are if OOP is applicable to a project and if the coder(s) have decent design/knowledge skills to realise any relevance of OOP for the respective coding project.

I find OOP-based design, at the application level, to be a natural stance for dealing with software-coding challenges. I suppose kernel/embedded-level code is another scenario for which my stances may not necessarity be applicable.

C++ does not force a specific form of OOP.
It provides a platform for the production of OOP code according to a style/complexity paradigm maintained/enforced by the coder.

The existence of any deleterious level of "type complexity" and "interface interdependency" would more reflect a poor code design and issues with the associated human software designers/implementers. Sure, the C++ language contains the facilities to produce "deleterious" code but the language itself does not force a person to code in a deleterious fashion. Inadequate design/knowledge skills, in the context of the project, are to blame for this. Sometimes coders get out of their depth (e.g. impatient, temporal-based deadlines, etc.) and create badly designed/implemented code.

The author imparts a "scary" scenario for the existence of "complex types". We should not forget that these "complex" types (i.e. C++ classes,which should not be designed as being difficult to use) manage the complexity of the code base through OOP-related mechanisms such as encapsulation, polymorphism, interface visibility, etc. Instances of C++ classes (i.e. C++ objects) are "fun" to use.

It's about the design.
If "bloated" frameworks/libraries exist and are deemed a "bad" idea, it is not the fault of the language but the fault of the software designer(s).

Sure C++ is not perfect, but I never think about going back to C for my application-level libraries/executables. Minimally, C++ can be used as a "better" C in those procedural-type non-OOP programs.

Anyway, if someone chooses to stick with C ... that's fine.

If someone chooses to stick with C++ ... that's also fine.

At the end of the day we all have differently wired minds that handle complexity in their own special way and it is up to the individual to select a software language they are comfortable with in order to solve the respective software coding challenges.

That's all folks.

Reply Score: 9

C == Security Exploits by design
by moondevil on Fri 11th Jan 2013 08:12 UTC
moondevil
Member since:
2005-07-08

The author is no doubt enthusiastic about C, but there are quite a few things he gets wrong.

At the time C was developed, even during the 80's, there were languages which had better compilation speeds like Turbo Pascal and Modula-2.

The UNIX guys also decided to ignore the languages of their time, which provided already better type checking than C does.

C main weakness:

- no modules
- no way to namespace identifiers besides 70's like hacks
- null terminated strings are a open door to security exploits
- the way arrays decay into pointers ditto
- weak type checking
- pointer aliasing forbids certain types of optimizations

C developers used to complain about Pascal type safety in the 80, but if you security conscious:

- Read MISRA C
- Enable all warnings as errors
- Use static analyzers as part of the build process

Funny enough with those steps C gets to be almost as safe as the Pascal family of languages.

C needs to get replaced for us to get better security, as well as its Objective-C and C++ descendants.

The latter do offer more secure language constructs, but they are undermined by the C constructs they also support.

Even Ritchie did recognize that C has a few issues:
http://cm.bell-labs.com/who/dmr/chist.html

If UNIX did not get copied in all universities all over the world in the early 80's, C would just be another language in history books.

Reply Score: 4

RE: C == Security Exploits by design
by renox on Fri 11th Jan 2013 09:21 UTC in reply to "C == Security Exploits by design"
renox Member since:
2005-07-06

There are more weaknesses: very poor standard library which doesn't even contain a hash map or safe string handling..

Reply Score: 6

RE: C == Security Exploits by design
by saso on Fri 11th Jan 2013 12:13 UTC in reply to "C == Security Exploits by design"
saso Member since:
2007-04-18

At the time C was developed, even during the 80's, there were languages which had better compilation speeds like Turbo Pascal and Modula-2.

Oh cry me a river.

The UNIX guys also decided to ignore the languages of their time, which provided already better type checking than C does.

And there is no way you could possibly be wrong about that!

no modules

Sure it has them, though presuming you didn't know about them, you have no idea what "static" on globals and functions means.

no way to namespace identifiers besides 70's like hacks

Namespaces are a mixed bag. Sometimes they might seem useful, but more often than not I've seen them abused and make simple problems a lot more complex. Also, they are a nightmare to debug, especially when combining code from various sources (e.g. library linking) - name mangling is a linker's nightmare. It seems that huge projects, like the Linux kernel for instance, seem to work just fine without them.

null terminated strings are a open door to security exploits
the way arrays decay into pointers ditto

I think you're more complaining about a lack of automatic range checking. Sometimes it's useful, sometimes it isn't (mainly by introducing invisible glue code that can mess up some assumptions, e.g. atomicity).

weak type checking

Compared to what? For my tastes the type checking in C is pretty strong.

pointer aliasing forbids certain types of optimizations

"restrict" has been in C since 1999. Your complaint is 13 years out of date.

Read MISRA C

They ask for money, no thanks. (NASA coding guidelines are an interesting read though.)

Enable all warnings as errors

Not all warnings are errors and while it helps in development, it's very bad for e.g. libraries to ship code with -Werror enabled, since a change in compiler versions can introduce new/different checks or obsolete build options and thus make break your build.

Use static analyzers as part of the build process

lint has been in Unix since V7 (1979).

Funny enough with those steps C gets to be almost as safe as the Pascal family of languages.

Something stinks with the notable stench of "smug".

[Objective-C, C++] do offer more secure language constructs, but they are undermined by the C constructs they also support.

It is true that C gives you greater freedom in certain things and that includes shooting yourself in the foot. No question about it. On the other hand, certain things are much easier and better done in C (low-level data crunching routines).

Even Ritchie did recognize that C has a few issues:
http://cm.bell-labs.com/who/dmr/chist.html

And there he claims, among other things, that C type specifications are richer than Pascal's, directly contradicting your earlier statement. Be careful who you cite to support your case.

If UNIX did not get copied in all universities all over the world in the early 80's, C would just be another language in history books.

Looks like somebody's got an axe to grind.

Reply Score: 1

moondevil Member since:
2005-07-08

"The UNIX guys also decided to ignore the languages of their time, which provided already better type checking than C does.

And there is no way you could possibly be wrong about that!
"

Then why did they not use Algol 60 or PL/I, which were the system programming languages of the time?


"no modules

Sure it has them, though presuming you didn't know about them, you have no idea what "static" on globals and functions means.
"

It is has not.

Separate compilation is a primitive form of modules, but it is not the same.


"no way to namespace identifiers besides 70's like hacks

Namespaces are a mixed bag. Sometimes they might seem useful, but more often than not I've seen them abused and make simple problems a lot more complex. Also, they are a nightmare to debug, especially when combining code from various sources (e.g. library linking) - name mangling is a linker's nightmare. It seems that huge projects, like the Linux kernel for instance, seem to work just fine without them.
"

Sure we could also keep on using the original UNIX, why care about progress?


"null terminated strings are a open door to security exploits
the way arrays decay into pointers ditto

I think you're more complaining about a lack of automatic range checking. Sometimes it's useful, sometimes it isn't (mainly by introducing invisible glue code that can mess up some assumptions, e.g. atomicity).
"

Forget about the NULL character, boom!

Arrays should not be manipulated as pointers.

As for the usual C argument about arrays bound checking, all modern languages that compile to native code allow for selective disable of bounds checking if required.

"weak type checking

Compared to what? For my tastes the type checking in C is pretty strong.
"

Almost every other static type language out there?


"pointer aliasing forbids certain types of optimizations

"restrict" has been in C since 1999. Your complaint is 13 years out of date.
"

Except, like register, the compiler is free to ignore it and besides gcc and clang many C vendors still don't fully implement C99.

"Read MISRA C

They ask for money, no thanks. (NASA coding guidelines are an interesting read though.)
"

In our society people tend to get money for their work.

"Enable all warnings as errors

Not all warnings are errors and while it helps in development, it's very bad for e.g. libraries to ship code with -Werror enabled, since a change in compiler versions can introduce new/different checks or obsolete build options and thus make break your build.
"

You can always turn off false positives.

"Use static analyzers as part of the build process

lint has been in Unix since V7 (1979).
"

Sure, but:

- UNIX is just one OS among many
- Being available does not mean developers use it

"[Objective-C, C++] do offer more secure language constructs, but they are undermined by the C constructs they also support.

It is true that C gives you greater freedom in certain things and that includes shooting yourself in the foot. No question about it. On the other hand, certain things are much easier and better done in C (low-level data crunching routines).
"

Like in many other languages.

"Even Ritchie did recognize that C has a few issues:
http://cm.bell-labs.com/who/dmr/chist.html

And there he claims, among other things, that C type specifications are richer than Pascal's, directly contradicting your earlier statement. Be careful who you cite to support your case.
"

Sure, when compared with the original ISO Pascal. The ISO Extended Pascal as any other Pascal dialects are more expressive than C.

"If UNIX did not get copied in all universities all over the world in the early 80's, C would just be another language in history books.

Looks like somebody's got an axe to grind.
"

UNIX is a good operating system, but it is not the god of operating systems.

Reply Score: 5

saso Member since:
2007-04-18

Then why did they not use Algol 60 or PL/I, which were the system programming languages of the time?

Because, if you had even read the few Wikipedia pages on C, you'd know that C derives from Algol 60. The line is roughly this: Algol -> CPL -> BCPL -> B -> C. Each of those steps had its reasons and I'm not going to list them here. Your attempt to portrait the designers of C as conceited merely shows that you carry a personal grudge that *your* language of choice didn't become ubiquitous (I presume it's Pascal, since you mentioned it so fondly - I've met a few FreePascal enthusiasts and they are argue quite similarly to you).
As for PL/I - it was first published in 1964 when the predecessors of C were already fairly underway in their own life, and it was a proprietary product of IBM (whereas C was designed at Bell Labs). Your romantic view of the wide availability of quality computer languages in the 60s is totally missing the reality of development back then.

Separate compilation is a primitive form of modules, but it is not the same.

Either they are modules (albeit in primitive form), or they aren't. You've managed to contradict yourself in a single sentence - good job. It's also sweet that you try to declare your definition of a module as authoritative. Have you ever considered that perhaps not everybody agrees with your definition?

Sure we could also keep on using the original UNIX, why care about progress?

Wow, FreePascal on Windows user, I presume. The aura of your smugness makes my screen damp. Simply because something is old doesn't mean it's bad.
Why do you think that "more features" = "progress"? Natural languages, for instance, often times simplify their grammar through more use (e.g. the regularization of the past-tense form of verbs in English).

Forget about the NULL character, boom!

NULL is actually a macro typically defined to ((void*)0), but I understand if your case-insensitive eyes don't see the difference.
Offhand remarks get offhand responses.

Arrays should not be manipulated as pointers.

Yes, your personal opinion on the matter is really insightful.

As for the usual C argument about arrays bound checking, all modern languages that compile to native code allow for selective disable of bounds checking if required.

This would be easy enough to introduce into C as well, say, by introducing an "array" keyword in variable definitions (which would turn on dynamic range checks). No need to redesign the language from the ground up. Might be nice to have, no dispute there.

Almost every other static type language out there?

This is a pretty slimy tactic to try and shift the burden of proof onto me. I'd now have to provide an extensive list to show that other static type checking languages out there have more relaxed rules, never mind even how one would qualify what "weak" and "strong" static type checking means. I don't play this way. You claimed C type checking is weak, it's yours to prove, not mine to disprove.

Except, like register, the compiler is free to ignore it and besides gcc and clang many C vendors still don't fully implement C99.

Oh my, is support really that bad?! Oh wait, you just pulled that one straight out of your behind:
https://en.wikipedia.org/wiki/C99#Implementations
Mind you, GCC still isn't fully C99 compatible: http://gcc.gnu.org/gcc-4.7/c99status.html so even your "GCC and clang" statement is false. Do you even google before you assert something?

In our society people tend to get money for their work.

That's not what I meant. I mean is that some random dude on the Internet isn't going to persuade me to spend money on a product that he insinuates will "fix" my coding practices.

You can always turn off false positives.

Obviously you've never built any bigger product somebody else coded from source, have you? I don't have the time to comb through somebody else's build tools to find which options fail and how to disable them.

UNIX is just one OS among many

Other platforms have other static analyzers. But UNIX has been the platform of birth for C, so I just wanted to show you that what you say here is not news to native C coders.

Being available does not mean developers use it

So you think forcing people is the proper approach? Have you ever considered that some people might not like that? Of course not, you are beyond error (see "arrays shouldn't be treated as pointers" comment above).

Like in many other languages.

What I was talking about is the contrast between highly abstract languages (Objective-C's OO part, Java, etc.) and lower abstraction languages (C). Of course you can write data crunching in other low-level languages (even Assembly for that matter).

Sure, when compared with the original ISO Pascal. The ISO Extended Pascal as any other Pascal dialects are more expressive than C.

Except that ISO Extended Pascal didn't exist when Kernighan and Ritchie designed C, so your citation of Ritchie to support your case misses the chronological order in which these languages appeared. According to Wikipedia, the first Pascal compiler in the US was written for the PDP-11, much later than UNIX appeared and probably even after C.

UNIX is a good operating system, but it is not the god of operating systems.

I never said so, but it's history is intertwined with C, so knowing about UNIX gives you a good idea how C developed.

Reply Score: 4

moondevil Member since:
2005-07-08

"Then why did they not use Algol 60 or PL/I, which were the system programming languages of the time?

Because, if you had even read the few Wikipedia pages on C, you'd know that C derives from Algol 60. The line is roughly this: Algol -> CPL -> BCPL -> B -> C. Each of those steps had its reasons and I'm not going to list them here. Your attempt to portrait the designers of C as conceited merely shows that you carry a personal grudge that *your* language of choice didn't become ubiquitous (I presume it's Pascal, since you mentioned it so fondly - I've met a few FreePascal enthusiasts and they are argue quite similarly to you).
"

Well yes.

I never used FreePascal though.

I am old enough to have used C and Pascal when the first compilers were being made available in ZX Spectrums.

As for PL/I - it was first published in 1964 when the predecessors of C were already fairly underway in their own life, and it was a proprietary product of IBM (whereas C was designed at Bell Labs). Your romantic view of the wide availability of quality computer languages in the 60s is totally missing the reality of development back then.


I didn't say they were top quality, only better than C.

According to epoch documentation many companies did license languages on those days.

"Separate compilation is a primitive form of modules, but it is not the same.

Either they are modules (albeit in primitive form), or they aren't. You've managed to contradict yourself in a single sentence - good job. It's also sweet that you try to declare your definition of a module as authoritative. Have you ever considered that perhaps not everybody agrees with your definition?
"

I only care about the Computer Science definition and C does not offer that.

http://en.wikipedia.org/wiki/Modular_programming

"Sure we could also keep on using the original UNIX, why care about progress?

Wow, FreePascal on Windows user, I presume.
"


Never used Free Pascal.

Windows is just another operating system among many.

The aura of your smugness makes my screen damp. Simply because something is old doesn't mean it's bad.
Why do you think that "more features" = "progress"?


Usually more features tend to improve programmer's productivity.

Natural languages, for instance, often times simplify their grammar through more use (e.g. the regularization of the past-tense form of verbs in English).


Well, actually English grammar was originally simplified thanks to the Normand occupation:

http://geoffboxell.tripod.com/words.htm

"Forget about the NULL character, boom!

NULL is actually a macro typically defined to ((void*)0), but I understand if your case-insensitive eyes don't see the difference.
Offhand remarks get offhand responses.
"

I have seen enough code like str[index] = NULL to make that statement.

Not everyone writes str[index] = '\0', specially the ones that like to turn off warnings.

Too many scars of off-shoring projects.

"Arrays should not be manipulated as pointers.

Yes, your personal opinion on the matter is really insightful.
"

I imagine any security expert would agree, but I might be wrong.

"Almost every other static type language out there?

This is a pretty slimy tactic to try and shift the burden of proof onto me. I'd now have to provide an extensive list to show that other static type checking languages out there have more relaxed rules, never mind even how one would qualify what "weak" and "strong" static type checking means. I don't play this way. You claimed C type checking is weak, it's yours to prove, not mine to disprove.
"

Should I now give a CS lecture about classes of static typing?

"Except, like register, the compiler is free to ignore it and besides gcc and clang many C vendors still don't fully implement C99.

Oh my, is support really that bad?! Oh wait, you just pulled that one straight out of your behind:
https://en.wikipedia.org/wiki/C99#Implementations
"

I am well aware of that Wikipedia page.

There many more C vendors than what Wikipedia lists and many customers don't let you choose the compiler to use.

Mind you, GCC still isn't fully C99 compatible: http://gcc.gnu.org/gcc-4.7/c99status.html so even your "GCC and clang" statement is false. Do you even google before you assert something?


That assertion was because many think that gcc and clang are the only compilers that matter.

"You can always turn off false positives.

Obviously you've never built any bigger product somebody else coded from source, have you?
"

Well, have you ever done a 300+ developers multi-site project?

"UNIX is just one OS among many

Other platforms have other static analyzers. But UNIX has been the platform of birth for C, so I just wanted to show you that what you say here is not news to native C coders.
"

To expert C coders, you mean.

"Being available does not mean developers use it

So you think forcing people is the proper approach? Have you ever considered that some people might not like that? Of course not, you are beyond error (see "arrays shouldn't be treated as pointers" comment above).
"

No, I am just a meaningless person in this world.

Just stating my opinion.

"Sure, when compared with the original ISO Pascal. The ISO Extended Pascal as any other Pascal dialects are more expressive than C.

Except that ISO Extended Pascal didn't exist when Kernighan and Ritchie designed C, so your citation of Ritchie to support your case misses the chronological order in which these languages appeared. According to Wikipedia, the first Pascal compiler in the US was written for the PDP-11, much later than UNIX appeared and probably even after C.
"

Point taken.

"UNIX is a good operating system, but it is not the god of operating systems.

I never said so, but it's history is intertwined with C, so knowing about UNIX gives you a good idea how C developed.
"

Agreed.

Reply Score: 2

saso Member since:
2007-04-18

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.

According to epoch documentation many companies did license languages on those days.

Yep, they did, but Bell Labs obviously didn't feel the needed to.

I only care about the Computer Science definition and C does not offer that.

http://en.wikipedia.org/wiki/Modular_programming

Oh really? Then I quote from the linked Wikipedia page you linked:
Modules are typically incorporated into the program through interfaces. A module interface expresses the elements that are provided and required by the module. The elements defined in the interface are detectable by other modules. The implementation contains the working code that corresponds to the elements declared in the interface.

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.

Usually more features tend to improve programmer's productivity.

By that logic, more controls on a car means better/safer/more productive driving. In actuality, Einstein's famous (possibly apocryphal) quote captures reality much better: "Everything should be made as simple as possible, but not simpler."

Well, actually English grammar was originally simplified thanks to the Normand occupation:
http://geoffboxell.tripod.com/words.htm

I said 'often times', not 'always'. Obviously at times languages expand in complexity to incorporate new necessary concepts and there's nothing wrong with that.

I have seen enough code like str[index] = NULL to make that statement. Not everyone writes str[index] = '\0', specially the ones that like to turn off warnings.

These programmers deserve a kick in the nuts for the above construct. This will produce warnings (implicit cast of void * to char) and is indicative of the fact that the author doesn't actually understand how computers work. I personally prefer str[index] = 0; Same meaning, less text, clearer.

Too many scars of off-shoring projects.

Ah well, if you buy cheap product, don't be surprised when it turns out to be shoddy. I have the same experience with offshore. Having a "safer" language means they will just provide you with dumber code monkeys.

I imagine any security expert would agree, but I might be wrong.

Security is not a simple yes/no game - the most secure computer is one that is off. It's all about finding middle ground. Some code warrants your approach, some doesn't. Making blanket statements, however, will guarantee that at times you will throw the baby out with the bathwater.

Should I now give a CS lecture about classes of static typing?

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...
Note that some of these definitions are contradictory, others are merely orthogonal, and still others are special cases (with additional constraints) of other, more "liberal" (less strong) definitions. Because of the wide divergence among these definitions, it is possible to defend claims about most programming languages that they are either strongly or weakly typed.

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").

I am well aware of that Wikipedia page.
There many more C vendors than what Wikipedia lists and many customers don't let you choose the compiler to use.

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

Well, have you ever done a 300+ developers multi-site project?

I was talking about things like X.org, KDE, the Linux kernel, Illumos, etc. These are humongous code bases with tons of external dependencies and when doing a project that uses them, I don't have the time to go through each and every piece and fix a maintainer's bad assumptions about build environments, often times just to test a solution. That's why I said -Werror is good for development, bad for distribution.

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.).

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.

Reply Score: 4

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 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 Score: 3

znby Member since:
2012-02-03

"Then why did they not use Algol 60 or PL/I, which were the system programming languages of the time?

...
As for PL/I - it was first published in 1964 when the predecessors of C were already fairly underway in their own life, and it was a proprietary product of IBM (whereas C was designed at Bell Labs). Your romantic view of the wide availability of quality computer languages in the 60s is totally missing the reality of development back then.
"

Interestingly enough, Multics, whose developers included Ritchie and Thompson, was written in PL/1 and used one of the first non-IBM compilers for the language. PL/1 was by all accounts a product of 'design by committee' and compilers for it which supported the entire language were difficult to implement and required high end computers at the time.

Reply Score: 1

Point by point
by ingraham on Fri 11th Jan 2013 08:53 UTC
ingraham
Member since:
2006-05-20

"Simple and Expressive"

In what way is C simple? Take someone who's got a good background and mind for programming and show them C. See how long it takes them to actually understand how to define a function to pass to qsort() and bsearch() and then get the syntax right for function pointers. Versus .sort() and .find() in any object language, or the array-style dictionaries in Smalltalk or Lua. No way is C more expressive, much less 'simple.'

"Simpler Code, Simpler Types"

Okay, that I sort of agree with. I was bouncing through the JavaFX API docs yesterday, and there sure were a lot of bizarro return types that don't make sense off hand. However, there are entire books written about how to figure out what a damn variable definition means in C. const * char is a pointer to const... I think. Right? Very simple.

"Speed King"

Okay.

"Faster Build-Run-Debug Cycles"

In what universe? I grant you, C++ takes longer to compile than straight C, normally because it has to compile anything having to do with templates all the way back up the line. But my Java compiles are every bit as fast as C compiles. Maybe faster, since Java often does a better job of figuring out what needs to recompile, vs. 'hmm, maybe I should 'make clean' just to be sure.' And the Build-Run-Debug cycle of ANY scripting language is about a hundred times faster than C. gcc --help takes longer than no compile step at all.

"Ubiquitous Debuggers and Useful Crash Dumps"

Again, I can't argue with that one. Well, C crash dumps aren't always useful, but they're there when you really need them.

"Callable from Anywhere"

Okay. Although I'm not sure there's any real advantage over C++ in this regard.

"Yes. It has Flaws"

Indeed. Of course, every language does. But some of the crap you put up with in C is really just awful. Strings may be a simple, dumb example, but damn it just about every program has to deal with strings constantly. It may be a small grain of sand, but it chafes after a while. And sure, I can get an internationalization library for C. (Or ten of them, and who knows which one is actually the good one.) But in Java it's just there.

A final thought. Would Couchbase have been written at all if it hadn't started in Erlang? Sure, when it got big and successful and they needed speed improvements they re-coded in C. But could they have gotten that far without a higher level language to start with? The whole idea of "rapid prototyping" isn't just good because it makes programmers' lives easier, but also because get up and running with something functional quickly. You have to prove a business case or convince people to join your team, and that point is a lot harder to get to in C.

Reply Score: 9

RE: Point by point
by moltonel on Fri 11th Jan 2013 10:06 UTC in reply to "Point by point"
moltonel Member since:
2006-02-24

In what way is C simple? Take someone who's got a good background and mind for programming and show them C. See how long it takes them to actually understand how to (...)


C is much simpler to understand fully than most other languages, in the sense that you understand exactly what a given line of code does. You pretty much know what (unoptimized) assembly will be generated by reading C. Try that with python, java, or even C++.

Of course C is harder to understand when you start with the language, but that's not what the author is talking about. He's talking about very experienced programmers (which he is).

"Faster Build-Run-Debug Cycles"

In what universe?


In the universe where java is not a "comparable language" I suppose, but I admit I wonder about this one too.

Reply Score: 6

RE[2]: Point by point
by moondevil on Fri 11th Jan 2013 10:24 UTC in reply to "RE: Point by point"
moondevil Member since:
2005-07-08

He's talking about very experienced programmers (which he is).


On my world such type of developers should have no problems understanding languages more complex than C.

Reply Score: 2

RE[3]: Point by point
by moltonel on Fri 11th Jan 2013 12:24 UTC in reply to "RE[2]: Point by point"
moltonel Member since:
2006-02-24

"He's talking about very experienced programmers (which he is).
On my world such type of developers should have no problems understanding languages more complex than C. "

No. Not when there's a VM or an interpreter involved, not to the point of knowing what assembly (not just bytecode !) gets generated. Even with a language deeply rooted in C like C++, there are so many parts of it that keeping them all in your mind while you code casually is not possible.

Again, we're not talking about just understanding the language you code in, but understanding what will actually get executed on the CPU.

I know my chosen languages very well, better than I know C. But I still have a better understanding of what C does to my machine than I do with any other language.

Reply Score: 3

RE: Point by point
by saso on Fri 11th Jan 2013 12:30 UTC in reply to "Point by point"
saso Member since:
2007-04-18

In what way is C simple? Take someone who's got a good background and mind for programming and show them C.

This is a flawed premise. You are positing a hypothetical question and drawing conclusions without any data to show for it. In other words, what you're doing here is blind speculation.

const * char is a pointer to const... I think. Right? Very simple.

"const *char" isn't a valid C construct. I think you meant 'const char *' which is the traditional form to write the more proper 'char const *'. That is a "character constant"-pointer, i.e. a pointer to a character-constant. Contrast with 'char * const' which is a "character"-pointer constant. This is one of the more luxurious features in C, having the ability to keep a close eye on object mutability. How do I pass a constant array in, say, Java? I can't, there's no way to do it.

The rest of your comment, I have no problem with. C is not a one-size-fits-all solution.

Reply Score: 4

RE[2]: Point by point
by telns on Fri 11th Jan 2013 17:36 UTC in reply to "RE: Point by point"
telns Member since:
2009-06-18

'Collections.unmodifiableList()' will sometimes answer the need. But you are absolutely right; C has a lot more control.

Reply Score: 1

RE[2]: Point by point
by ingraham on Fri 11th Jan 2013 22:22 UTC in reply to "RE: Point by point"
ingraham Member since:
2006-05-20

You are positing a hypothetical question and drawing conclusions without any data to show for it.


Fair enough. I stand by the basic premise, however. Using function pointers to pass a compare function to a sort function is more complicated than blah.sort(). Particularly if your collection has a natural sort order, like strings.

"const *char" isn't a valid C construct.


Ha! Okay, it was 4 in the morning when I wrote that, but the fact that I screwed up my example kinda proves the point.

Reply Score: 2

RE[3]: Point by point
by kwan_e on Sat 12th Jan 2013 00:20 UTC in reply to "RE[2]: Point by point"
kwan_e Member since:
2007-02-18

Using function pointers to pass a compare function to a sort function is more complicated than blah.sort(). Particularly if your collection has a natural sort order, like strings.


The point of passing a compare function to a sort function is for when you want to sort things into a different order than the natural one.

Reply Score: 2

RE[4]: Point by point
by ingraham on Sat 12th Jan 2013 04:44 UTC in reply to "RE[3]: Point by point"
ingraham Member since:
2006-05-20

The point of passing a compare function to a sort function is for when you want to sort things into a different order than the natural one.


Except in C, there is no way to sort anything without passing a compare function to qsort. Even an array of ints needs a hand-coded, if trivial, compare function passed to it.

Reply Score: 2

RE[5]: Point by point
by saso on Sat 12th Jan 2013 10:19 UTC in reply to "RE[4]: Point by point"
saso Member since:
2007-04-18

Except in C, there is no way to sort anything without passing a compare function to qsort. Even an array of ints needs a hand-coded, if trivial, compare function passed to it.

Actually, the fact that qsort takes a comparator function means that it is much better than a simple sort() method on an array object. It allows you much more freedom in comparing compound and complex objects, not just primitive values. How, for instance, do you sort an array of structures/objects sensibly? The language doesn't know how, so you have to provide a comparator. This is one of the less problematic features of the standard C library - providing generic interfaces for everything. If you need your ultra-fast ultra-optimized sorter, you can always code it yourself.

Reply Score: 2

RE[6]: Point by point
by ingraham on Sun 13th Jan 2013 05:23 UTC in reply to "RE[5]: Point by point"
ingraham Member since:
2006-05-20

In Java, your class extends Comparable, then provides a definition of comparesTo(). You can now use your class with anything that wants to sort or search. You could argue the difference is just semantics or syntactic sugar. Still, the concept and syntax of function pointers is considerably more difficult to understand, and results in code that isn't as checkable by the compiler and can cause really wacky things to happen if you mess it up. In C, if I accidentally pass my string compare function to qsort while I'm trying to sort an array of ints, the program will compile and run, and then screw up badly at runtime.

Reply Score: 2

RE[7]: Point by point
by kwan_e on Sun 13th Jan 2013 06:27 UTC in reply to "RE[6]: Point by point"
kwan_e Member since:
2007-02-18

In C, if I accidentally pass my string compare function to qsort while I'm trying to sort an array of ints, the program will compile and run, and then screw up badly at runtime.


That's not so much a problem with using function pointers as it is with weak typing. qsort has to be able to sort any types, so the arguments passed to the sorting function are void*, making the function signature similarly unhelpful.

However, if you write a thin wrapper on top of qsort that takes in a function pointer with more specific argument types, then the compiler will complain reliably.

Reply Score: 3

RE[7]: Point by point
by saso on Sun 13th Jan 2013 11:09 UTC in reply to "RE[6]: Point by point"
saso Member since:
2007-04-18

I think you just consider it simpler because it's what you're used to. For instance, it would take me a good while to figure out what you said about comparesTo(), simply because I'm not used to it. Also, your example covers custom sorting of objects, but not of first class types - how do I do a custom sort on strings, or ints, or something else atomic? Sure, you could wrap the primitive types in custom object classes and incur a significant performance penalty (an array of 10000 int's is going to need 10000 malloc's and subsequent free's), in addition to adding tons of lines of code (plus a few new extra classes/files), whereas in C the problem could have been solved efficiently in about half a dozen lines of code with no extra allocation needed.

Reply Score: 2

v RE: Point by point
by Wafflez on Fri 11th Jan 2013 12:57 UTC in reply to "Point by point"
RE[2]: Point by point
by saso on Fri 11th Jan 2013 14:35 UTC in reply to "RE: Point by point"
saso Member since:
2007-04-18

And as for debuggers... Visual Studio blows C out of water

C is a language, Visual Studio is an IDE. You're comparing two different things.

pause any time, IntelliSense to go back in steps, check variables, call stacks. Aaaand Paralel Tasks windows debugging threaded application.

Correct me if I'm wrong, but VS supports all of the above on C++ (among other things), which is almost entirely a superset of C, i.e. it supports them on C as well. You're arguing against gdb, not C. And as for gdb, except for "Intellisense to go back in steps" (isn't Intellisense a code completion feature?), all that you mention can be done in gdb as well. Perhaps you mean some specific feature and/or problem?

Reply Score: 6

RE[3]: Point by point
by tanzam75 on Fri 11th Jan 2013 19:00 UTC in reply to "RE[2]: Point by point"
tanzam75 Member since:
2011-05-19

He probably meant IntelliTrace, which is the historical debugging tool bundled with Visual Studio Ultimate. IntelliTrace is implemented by using IL metadata, and thus it does not work on native C++ code.

Parallel Tasks/Stacks was designed primarily to debug task-parallel applications -- though you can also use it on threads. gdb would need an extension for whatever task-parallel library you're using. The Visual Studio debugger has it because the compiler, runtime, and IDE are all bundled together in one package -- and so the debugger can be tightly-coupled to the bundled libraries.

It's not so much C# vs C++, as the "everything bundled together" model vs. the individual-tools model. If you select components individually, then you'd just install a whole bunch of addons to get what you need in the IDE -- Eclipse being a primary example.

Edited 2013-01-11 19:02 UTC

Reply Score: 2

RE: Point by point
by Valhalla on Sat 12th Jan 2013 14:23 UTC in reply to "Point by point"
Valhalla Member since:
2006-01-24

Would Couchbase have been written at all if it hadn't started in Erlang? Sure, when it got big and successful and they needed speed improvements they re-coded in C. But could they have gotten that far without a higher level language to start with? The whole idea of "rapid prototyping" isn't just good because it makes programmers' lives easier, but also because get up and running with something functional quickly.

Hmm... I don't see your point. Prototyping in a higher-level language doesn't take away the usefulness of C. Judging by this thread I'm hardly the only one combining C and Python in my daily work, and yes I pretty much always write new code in Python first and then translate performance hotspots to C.

That said I'm certain Couchbase could have been written directly in C without prototyping in a higher level language, I think the initial thought was to have it running in Erlang but the performance was found lacking which prompted a rewrite in C.

The Linux kernel devs wrote git straight off in C during a very fast development phase and it's been a huge success in no small part due to it's much-lauded performance, but also it's stability.

Reply Score: 3

tails92
Member since:
2007-10-07

Unlike the other common programming languages of our days, C is the only one expressive enough to do everything you want to do with the machine.
For some it is a strength, for some it is a weakness, but to use C well you need to know how CPUs execute code.
If you know that, aside from syntactical quirks, using C is easy and results in small and fast programs, even in userspace.
Nowadays it is fashionable to criticize C and to say it is not good for userspace applications, but a fact remains and it is that most of the applications which make the computing world run, they are in C. Pure C.
Despite some people thinking otherwise, OOP oriented programming is much more confusing for newbies, and newbies should start learning to programming in assembly. Yes, in assembly. The only way they will understand what the language is doing when they go on to higher level languages. Theory means nothing without practice and understanding. Once you know how assembly languages work and the memory model of machines pointers are just natural.
Substandard programmers can flock to languages like C# or Java. Not that I find Java, the language, wrong in itself, it's just that it is often used by programmers who do not understand what's happening and that want to be cool by saying stuff like "it's secure, it's run by a VM, it's sandbox, it doesn't have pointers!!", well it is does have references. Which, internally, are just like pointers! It's hidden to the eye, but they are still there. Proof is the argument passing to methods in Java, if I pass a reference to an object in an argument, and if I change the value of the reference inside the function at a later moment, the value of the reference I passed to the function externally doesn't change. Just like C. It's still passing argument by copying. Most other things are just things the Java Compiler enforces for you and the JVM sets up automatically for you (like garbage collection, interfaces, etc.).
You can compile C for a virtual machine, and it will be as "safe" as Java run in a virtual machine, and also the MMU already tries to "isolate" user code from system code in order to make things safer. Most times it is sufficient, at times not.
Not type checking adds to the expressiveness of C, it doesn't make it "unsafe" if you know what you are doing. That you can copy things elsewhere without being stopped is a very useful side feature, especially in system code.
Also, C strings are not necessarily too tied to the language. You could modify a C compiler in order to output Pascal-style strings for string constants, and you could make custom string functions that handled Pascal strings if you really wanted to..

Edited 2013-01-11 09:06 UTC

Reply Score: 7

renox Member since:
2005-07-06

You can, you can: what matters is how C is used currently not how it could be used.
And C isn't used *at all* like how you're suggesting it could be.

Reply Score: 2

moondevil Member since:
2005-07-08

Unlike the other common programming languages of our days, C is the only one expressive enough to do everything you want to do with the machine.


Really?!

And I though Ada, Modula-2, Modula-3 and Turbo/Free Pascal, Oberon(-2) already provided everything C does and more, just to name a few comparable languages.

Not type checking adds to the expressiveness of C, it doesn't make it "unsafe" if you know what you are doing. That you can copy things elsewhere without being stopped is a very useful side feature, especially in system code.


Security exploits everywhere, since not everyone is a top developer.

Also, C strings are not necessarily too tied to the language. You could modify a C compiler in order to output Pascal-style strings for string constants, and you could make custom string functions that handled Pascal strings if you really wanted to..


Then you throw C performance out of the window, because all C libraries assume null terminated strings and you end up converting between string types all the time.

Edited 2013-01-11 10:30 UTC

Reply Score: 4

Tractor Member since:
2006-08-18

Then you throw C performance out of the window, because all C libraries assume null terminated strings and you end up converting between string types all the time.


Since when is C performance depending on null-terminated string ? God, have you already programmed in C ?

Whenever i'm looking for performance, i never handle strings, but blocks of bytes.
Strings are for "higher-layers", such as sending a file name as a parameter. This kind of usage has zero impact on critical loop performance.

Reply Score: 1

moondevil Member since:
2005-07-08

Since when is C performance depending on null-terminated string ?


The performance lost is the string conversion.

As long as you keep using the same type of strings, there is no issue.

God, have you already programmed in C ?


1992 - 2001

Reply Score: 2

C will not disappear any time soon
by rom508 on Fri 11th Jan 2013 11:54 UTC
rom508
Member since:
2007-04-20

I am a system software developer and I have been using C for for about a decade now. The reason why I got into C was simple: Unix is developed in C and this is what you tend to use for Unix system software development.

Some people look down on C because it's old and uncool, but just because something is old does not mean it's crap. Many people avoid C because it's not an object oriented programming language, however I think you can use object oriented programming paradigm with C, as long as you are willing to fully understand how it works at the low level. With a bit of effort and discipline, I have been able to use plain C to achieve single inheritance, polymorphism and generics. It takes a bit longer to develop your code compared to Java or C++, but I would argue it makes you a better programmer when you understand the low level implementation.

So despite its age, C is a very flexible and powerful programming language, although I would prefer for Ada to be more ubiquitous.

Reply Score: 2

saso Member since:
2007-04-18

Some people look down on C because it's old and uncool, but just because something is old does not mean it's crap. Many people avoid C because it's not an object oriented programming language, however I think you can use object oriented programming paradigm with C, as long as you are willing to fully understand how it works at the low level. With a bit of effort and discipline, I have been able to use plain C to achieve single inheritance, polymorphism and generics. It takes a bit longer to develop your code compared to Java or C++, but I would argue it makes you a better programmer when you understand the low level implementation.

Exactly my experience as well. But when I break it to the modern wannabe-hipster script kiddies here on OSNews, I get modded down ;) "C doesn't do feature X the cool way, so it's stupid" is the premise here.

Reply Score: 2

f0dder Member since:
2009-08-05

It's fine understanding how the OO features work on a low level. I'm not sure I'd say people *need* to know this to be decent programmers, but I'm personally fond of my background in C and assembly.

But, after learning how to do things at a low level, why would you continue writing code in that tedious and painful way, when there's tools better suited for the job?

Reply Score: 3

rom508 Member since:
2007-04-20

Because it's not tedious and painful, the overhead of manually doing basic OO development in C is not very big. It would be tedious and painful to use C++ instead, because I don't have as much experience with C++.

Reply Score: 1

f0dder Member since:
2009-08-05

Hm, fair enough point wrt. the experience (you're never too old to learn something new, though! ;) ) - but I'd still say the manual work is tedious... otherwise C++ would probably not have been invented? (Keep in mind that the early versions translated to C - you're doing a compiler's job).

I personally also enjoy the higher type safety and a bunch of C++ features (RAII!) and some libc++ things. Even if not doing OOP as such, I wouldn't be using C, I'd be using C++ as a Super-C (and I'd even argue that it's not necessarily a bad idea for kernel mode work, though you definitely would be using a restricted feature set of C++ there).

Personal preference and experience are some pretty big factors. I've played around with quite a lot of features by now (nowhere near proficient in all of them!). Most of them are in the comfort zone of C-like (javascript, python, LUA, C# and Scala do offer some alternative ideas though, and even a bit of FP mindset).

But C++, for some reason, has a special place for me. Probably because (especially with C++11!) it lets me program in a lot of different styles, while still offering kick-ass performance and being relatively safe - and RAII really is nice compared to garbage collection.

Not saying it's the end-all-be-all of languages, I believe in the right tool for the right job... I just have a hard time seeing why you'd use plain C, when you could do procedural programming with C++ :-)

Reply Score: 3

rom508 Member since:
2007-04-20

It has nothing to do with being old to learn something new, but more with spare time. There is too much information out there, too many different ways of skinning a cat. I personally don't think C++ is worth the effort, I just don't like the way it's designed. I'd be more inclined to put the time and effort into Ada, I think Ada is far superior to C++, but that's just my personal opinion.

I can see why C++ and Java appeal to so many people, but there are some people like me who prefer simpler things in life. As an example, I still own an old monochrome Nokia mobile phone, it does the job, it never crashes and I would never trade it for an iPhone or any other gizmo of that sort.

Reply Score: 2

This article gets it right
by BluenoseJake on Fri 11th Jan 2013 12:26 UTC
BluenoseJake
Member since:
2005-08-11

C is unreasonable, and effective.

Reply Score: 4

v It's all about design
by gpsnoopy on Fri 11th Jan 2013 14:37 UTC
RE: It's all about design
by saso on Fri 11th Jan 2013 16:49 UTC in reply to "It's all about design"
saso Member since:
2007-04-18

C vs C++, C vs C#, C vs Java, C vs OO, etc is an old debate that is slowly dying as a newer generation of programmers is replacing the old guard. And funnily enough, the quality of software has massively improved over the years.

And yet, C is the most popular language and has been on the rise for a few years (even displaced Java as the most popular language a few years back):
http://www.tiobe.com/content/paperinfo/tpci/index.html

So, what gives?

Reply Score: 4

RE[2]: It's all about design
by gpsnoopy on Fri 11th Jan 2013 17:42 UTC in reply to "RE: It's all about design"
gpsnoopy Member since:
2007-04-17

Demand for C has increased a few years ago due to the need for developers in the embedded market.

Otherwise I would take this link with a pinch of salt: Visual Basic 6 is almost more popular than C# and on its way to surpass it.

I think that a more interesting metric would be the languages used daily on our computers and on large applications.

Edited 2013-01-11 17:42 UTC

Reply Score: 2

RE[3]: It's all about design
by saso on Fri 11th Jan 2013 18:13 UTC in reply to "RE[2]: It's all about design"
saso Member since:
2007-04-18

Demand for C has increased a few years ago due to the need for developers in the embedded market.

Otherwise I would take this link with a pinch of salt: Visual Basic 6 is almost more popular than C# and on its way to surpass it.

So what you are saying is that C isn't a good fit for *your* problem domain. No problem there, there's no silver bullet as languages go, and everybody picks their favorite language also according to personal taste.

I think that a more interesting metric would be the languages used daily on our computers and on large applications.

If you are allowed to formulate arbitrary questions, you can get arbitrary answers. That doesn't mean that they apply in the real world, though.
As for me, personally, I don't care if C is the least or most used computer language in the world. I still use the right tool for the job, be it C or something else.

Reply Score: 2

RE[4]: It's all about design
by ingraham on Fri 11th Jan 2013 22:28 UTC in reply to "RE[3]: It's all about design"
ingraham Member since:
2006-05-20

I still use the right tool for the job, be it C or something else.


Careful there, saso! That sounds absolutely reasonable, which is not allowed on teh Interwebs. :-)

Reply Score: 1

RE[3]: It's all about design
by lucas_maximus on Mon 14th Jan 2013 11:31 UTC in reply to "RE[2]: It's all about design"
lucas_maximus Member since:
2009-08-18

Visual Basic 6 just won't die. Trust me I wish it would.

Reply Score: 2

RE: It's all about design
by ebasconp on Fri 11th Jan 2013 21:36 UTC in reply to "It's all about design"
ebasconp Member since:
2006-05-09

C vs C++, C vs C#, C vs Java, C vs OO, etc is an old debate that is slowly dying as a newer generation of programmers is replacing the old guard. And funnily enough, the quality of software has massively improved over the years.


So, are you claiming that is other programming language where the future OSes are being written? Something that the new guys can use instead of the old-good-for-nothing C?

Interesting!

Reply Score: 3

Use the right tool for the job
by massysett on Fri 11th Jan 2013 15:18 UTC
massysett
Member since:
2007-12-04

I can never understand posts like this. I doubt carpenters sit around and argue about whether screwdrivers or hammers are better. I'm a writer and I don't argue about whether pens are better than pencils. In the kitchen I don't argue about whether knives are better than scissors, or whether a spoon is better than a fork.

Use the right tool for the job. OK, so maybe for your jobs C is often a better tool than Java. That doesn't mean "C is better" or "C is more effective." For my jobs Haskell is a better tool than C. That doesn't mean "C has broken my heart" or "C focuses on the wrong things." Goodness, we can have different tools that do different things; just because a tool isn't suited to a task--or to the tasks you do most often--doesn't mean that tool sucks.

Reply Score: 3

Soulbender Member since:
2005-08-18

You should have more up-mod'ing for this but since I already commented I can't.


Btw, sporks beats both spoons and forks

Edited 2013-01-12 03:06 UTC

Reply Score: 2

C++ could be bypassed
by fithisux on Fri 11th Jan 2013 15:28 UTC
fithisux
Member since:
2006-01-22

You can use ObjC/C/Asm for low level and build everything high-level with other languages. Ocaml is an example, ruby is another example and Go is yet another example. You can have a stack that does not use C++. But high-level languages are useful for large scale programming. Unfortunately there is no standard IMHO that allows to write a library in Pascal/Ocaml/C/Asm or Guile and re-use it by the others. This is unfortunate. For example it does not make sense to waste man months writing an xml library in C (it can be done optionally) when you can write it in Go. It makes no sense to write a proof system in C when you can do it in Ocaml and so on. Scripting languages are also another essential ingredient.

I believe that the main problem is the hardware and not the complexity that fostered C++. Fix the hardware in order to simplify the low level and use high level languages to build the stack. I could use C to interface to PCI and build a TCP/IP stack in Go in order to make it available to other consumers or even C. The main problem is that companies want to maintain the profit margin in HW and make bad hardware. Why should I ever need a driver for the printer if I could write it in user space with Ocaml and some C libraries via TCP/IP or a Wireless interface.

The complexity grows, the tools are there but the companies don't get it. Bad hardware costs manhours and makes life tougher.

Edited 2013-01-11 15:30 UTC

Reply Score: 3

RE: C++ could be bypassed
by saso on Fri 11th Jan 2013 16:55 UTC in reply to "C++ could be bypassed"
saso Member since:
2007-04-18

Fix the hardware in order to simplify the low level and use high level languages to build the stack.

Are you suggesting we build hardware that interprets high-level code directly? Do you realize that this makes CPU design nearly impossibly complex? Even the handful of Java processors and VLIW processors that have been built still execute relatively low-level "bytecode" instructions that are nowhere near abstract language complexity levels.

Reply Score: 2

RE: C++ could be bypassed
by tylerdurden on Fri 11th Jan 2013 19:51 UTC in reply to "C++ could be bypassed"
tylerdurden Member since:
2009-03-17

Perhaps the problem is that you may have a very poor (or lacking) understanding of computer architecture.

Reply Score: 3

RE: C++ could be bypassed
by moondevil on Fri 11th Jan 2013 19:58 UTC in reply to "C++ could be bypassed"
moondevil Member since:
2005-07-08

Unfortunately there is no standard IMHO that allows to write a library in Pascal/Ocaml/C/Asm or Guile and re-use it by the others


The AS/400 mainframes use bytecode (ILE) as program format with the JIT integrated into the kernel.

The code gets JITted and cached in the executable, either on the first use or on demand.

Additionally the code might be regenerated if required.

This was kind of the route Microsoft was trying with everything .NET on Vista.

Now lets see where WinRT (COM ABI) goes.

Reply Score: 3

C++ for me
by telns on Fri 11th Jan 2013 17:25 UTC
telns
Member since:
2009-06-18

C is nice, and has worn remarkably well, but if I were making the choice between those two for a new project, C++ would normally be the winner.

This may be sacrilege to some, but considered strictly as a technical book, I think Stroustrup's "The C++ Programming Language" is better than K&R's "The C Programming Language" as well.

Edited 2013-01-11 17:38 UTC

Reply Score: 1

RE: C++ for me
by tylerdurden on Fri 11th Jan 2013 19:52 UTC in reply to "C++ for me"
tylerdurden Member since:
2009-03-17

I think Stroustrup's "The C++ Programming Language" is better than K&R's "The C Programming Language" as well.


Sacrilege! Burn the witch!!!!

Reply Score: 4

Benchmark of real-life apps, someone ?
by Kochise on Fri 11th Jan 2013 20:15 UTC
Kochise
Member since:
2006-03-03

Let's open the free buffet :

http://www.hxa.name/minilight/#comparison

Kochise

Reply Score: 2

C and Python
by FunkyELF on Fri 11th Jan 2013 21:48 UTC
FunkyELF
Member since:
2006-07-26

I love C and Python.... and I love the fact that they're fairly simple to intermix.

Porting C to Python and Python to C is pretty straight forward (as long as you're not doing OO programming in Python obviously).

To me... I see Python as C but with a nicer syntax and just the right amount of built in data structures.

I love being able to create a throw-away list, dictionary, or other structure right inline a statement.

See if the first two letters of a string match one of several other strings?

In Python:

if foo[:2] in ['XX', 'YY', 'AB', '!!']:
print 'woo hoo'

In C:

if ( strncmp(foo, "XX", 2) == 0 ||
strncmp(foo, "YY", 2) == 0 ||
strncmp(foo, "AB", 2) == 0 ||
strncmp(foo, "!!", 2) == 0 ){
printf("woo hoo\n");
}

... its the little things.

Is the Python going to perform faster?... hell no, but I love the readability. And if it needs to be ported to C for performance, it is straight forward.

Reply Score: 5

RE: C and Python
by tylerdurden on Fri 11th Jan 2013 22:23 UTC in reply to "C and Python"
tylerdurden Member since:
2009-03-17

I sympathize. I have found that prototyping stuff quasi interactively in python and then porting it over to C/C++ can be a very productive way of programming.

Edited 2013-01-11 22:23 UTC

Reply Score: 3

RE[2]: C and Python
by FunkyELF on Mon 14th Jan 2013 13:29 UTC in reply to "RE: C and Python"
FunkyELF Member since:
2006-07-26

I sympathize. I have found that prototyping stuff quasi interactively in python and then porting it over to C/C++ can be a very productive way of programming.


Exactly.
Previous generations might have prototyped on paper or a chalk board before "finalizing" the C code.
Thats from a time where it made sense to plan ahead because you might be using punch cards or had to wait your turn for computer time.

Python makes a great prototyping language because it has been described as executable pseudo-code. Not too low or high level.
When I prototype in Python I'm doing the same thing, I'm just using a text editor rather than pad of paper.

Reply Score: 2

C -> Go
by voidlogic on Sat 12th Jan 2013 01:26 UTC
voidlogic
Member since:
2005-09-03

I wonder if this gentlemen has tried Go? If he is a big C fan, Go might be a great choice for the stuff that doesn't need to be written in C. Great qoute: “Go is like a better C, from the guys that didn’t bring you C++” — Ikai Lan. Not only is Go a safer version of C with lots of great modern features, it integrates very well with C via cGo.

If memory usage and speed are your preeminent concerns, C is certainly a force to be reckoned with: http://benchmarksgame.alioth.debian.org/u64q/which-programs-are-bes...

Reply Score: 2

RE: C -> Go
by ebasconp on Sat 12th Jan 2013 03:58 UTC in reply to "C -> Go"
ebasconp Member since:
2006-05-09

I never tried Go, but I would give a try to D instead of Go.

Reply Score: 2

RE[2]: C -> Go
by voidlogic on Sat 12th Jan 2013 04:08 UTC in reply to "RE: C -> Go"
voidlogic Member since:
2005-09-03

I can't imagine why, unless you are doing embedded development.

Reply Score: 2

RE[3]: C -> Go
by ebasconp on Sat 12th Jan 2013 04:43 UTC in reply to "RE[2]: C -> Go"
ebasconp Member since:
2006-05-09

Could you please elaborate on your comment?

D is a systems programming language (like C or C++) but with a very high level of abstraction.

http://en.wikipedia.org/wiki/D_(programming_language)

Edited 2013-01-12 04:43 UTC

Reply Score: 2

RE[4]: C -> Go
by voidlogic on Sat 12th Jan 2013 07:11 UTC in reply to "RE[3]: C -> Go"
voidlogic Member since:
2005-09-03

http://en.wikipedia.org/wiki/Golang
http://tour.golang.org/#1

“Go is like a better C, from the guys that didn’t bring you C++” — Ikai Lan

Ken Thompson, Rob Pike & Robert Griesemer set out at Google to create a modern C. Go is an extremely simple language compared a multi-paradigm language like D. For some people this means worse, for many it means better. For me being simple, yet providing all the tools needed is perfect. IMHO sufficient simplicity is elegance, and leads to maintainable code.

If you Google D vs Go you will find many threads, take a look the discussion; It is much broader than we could hope to cover here. (Keep in mind most results are 3 years out of date)

If I had to make you a short list I would say I like Go because:

* For me personally I have never had a more productive language experience than Go. (I have mostly used C,C++,C#,Java,VB/.net with some Javascript,Perl,PHP,Haskell,Prolog)

* Go makes is easy to get concurrency right on the first pass, and has extremely powerful concurrency features built-in. In Go there is no writing a single threaded version and having come back and multithread it later.

* The entire language spec is small enough to read in one sitting and understand and know by heart in less than one month.

* The Go compiler is extremely fast, faster than C or D

* Go performs very well: http://benchmarksgame.alioth.debian.org/u64q/which-programs-are-bes...

* Language formatting is standardized (gofmt). No more newline flame wars for example.

* While D appeared in 2001 and Go in 2009 D and Go are now neck and neck on stack overflow and github. On OSnews, hacker news, slashdot etc you see many more Go stories. While this does not in and of itself make Go better, if this means Go has a stronger faster growing community, that is positive for developers that choose Go.

I'll stop here and for the sake of brevity. In short D is a better C++ and Go is a better C that believes C++ was a wrong turn.

Reply Score: 3

RE[5]: C -> Go
by Valhalla on Sat 12th Jan 2013 15:22 UTC in reply to "RE[4]: C -> Go"
Valhalla Member since:
2006-01-24


Ken Thompson, Rob Pike & Robert Griesemer set out at Google to create a modern C.

I just can't buy into the notion of Go as a 'modern C'. There are similarities in syntax, not surprising of course when considering who the authors are, but the languages are targeting different areas.

I do like Go, it's a language I am currently dabbling with and I put it somewhere between python and C. I think it has a great future, largely due to the built-in concurrency features you mentioned since the future seems to hold an ever increasing number of cores per cpu.

But in the domains where C dominate, characteristics like high performance, deterministic memory handling, small memory footprint, no runtime overhead, low-level constructs for efficient data manipulation, ease of use from other languages, etc are what makes it so popular.

Go really doesn't apply here, it will never have the same performance due to being a 'safe' language and also due to having automatic garbage collecting which has logic using up cycles even when it's not actively reclaiming memory. It does not have a comparable small memory footprint as it includes the runtime with each binary, it lacks constructs like unions, it lacks a simple bitfield type, in short it is not a replacement for C.

And when I'm talking about domains where C is dominant, I mean things like system-level code, audio/video encoding/decoding, archivers/compressors, low level frameworks, image/sound manipulation etc.

Currently Go is making it's largest splash in web development, part if this is due to some of it's characteristics, part of it likely is that the web developer space is quite prone to experiment with new languages.

However in the longer perspective I can see Go have a 'go' at replacing C++,Java,C# for application level development.

Desktop applications like for example Libre Office, Inkscape, Gimp, etc could easily have their C++ parts replaced by Go while keeping the underlying C performance critical components (like GEGL for Gimp) where it's necessary.


* The Go compiler is extremely fast, faster than C or D

Yes, but it will get slower once more optimizations are implemented. Still they chose to write their own Go compiler from scratch due to finding the LLVM and GCC backends much too slow so there's good reason to believe it will remain quite fast.


Hmmm.. are you are cherry-picking results or am I missing something? Here is the straight-up list:
http://benchmarksgame.alioth.debian.org/u64q/benchmark.php?test=all...

Go is quite a bit slower than Java 7 and much slower than C (which is the fastest overall). Still there is a slew of performance improvements in store for Go 1.1 from what I've read so it will be interesting seeing where it lands once that is released. Certainly the performance isn't bad considering it's a 1.03 release of a very young language, but again calling it a modern C is something I find to be nonsense.


* While D appeared in 2001 and Go in 2009 D and Go are now neck and neck on stack overflow and github.

Cherry-picking D as a comparison is rather pointless I think, it does not have the resources that Go enjoys through Google, also it's development history is so unlike that of Go, with community fragmentation over runtimes and standard libraries etc.

Reply Score: 2

RE[6]: C -> Go
by moondevil on Sat 12th Jan 2013 17:22 UTC in reply to "RE[5]: C -> Go"
moondevil Member since:
2005-07-08

Just a small remark, check Native Oberon and Blue Bottle OS.

Desktop operating systems used at ETHZ in Zurich, implemented in GC enabled system languages.

http://www.ocp.inf.ethz.ch/wiki/Documentation/WindowManager

Only the boot loader, and hardware bindings are fully implemented in Assembly, with the remaining parts in Oberon or Active Oberon.

Fully working desktop systems, used for operating system research and teaching.

The main reason mainstream OS are still not using GC enabled system languages is inertia, but this is already changing at least in Windows with the C++/CX extensions.

Reply Score: 3

RE[7]: C -> Go
by Valhalla on Sat 12th Jan 2013 18:25 UTC in reply to "RE[6]: C -> Go"
Valhalla Member since:
2006-01-24

Fully working desktop systems, used for operating system research and teaching.

What are you trying to prove by the existance of such OS implementations? I'm sure someone has a research OS written in a interpreted language aswell.

Show me benchmarks where these systems are evaluated under pressure and compared with native unmanaged equivalents like Linux/BSD/NT.

If something had came along that used garbage collection and memory safety and magically managed to perform as well as native unmanaged code then obviously we'd all be using it by now.

The main reason mainstream OS are still not using GC enabled system languages is inertia

No, it is because we are not ready to give up performance at the system level, the amount of optimization at this level is extreme, we are talking about the use of specific compiler extensions to manually handle such low level aspects as branch prediction and cache prefetching/clearing. You don't want garbage collection pauses in this setting.

But if you have any benchmarks which supports the notion that the reason we are not seeing garbage collected safe language based operating systems used in mainstream computing is that of inertia rather than performance, please show me.

Again, I'd love it if there was some magic silver bullet that allowed us to have full memory safety while having the same performance as in unmanaged native code. In reality it's a tradeoff, and in areas such as kernel level code where low latency is absolutely crucial, performance trumps convenience.

Native code related bugs gets squashed, it's performance remains.

Reply Score: 2

RE[6]: C -> Go
by voidlogic on Sat 12th Jan 2013 19:43 UTC in reply to "RE[5]: C -> Go"
voidlogic Member since:
2005-09-03

I just can't buy into the notion of Go as a 'modern C'. There are similarities in syntax, not surprising of course when considering who the authors are, but the languages are targeting different areas.


C might have a limited domain now, but you are forgetting when it was written is was very much a general purpose language. In the same way Go is.

But in the domains where C dominate, characteristics like...

Go might not have these qualities compared to C, but it does have many of these qualities compared to modern applications programming languages. Outside of writing a OS, Go's problem domain is a super-set of C as used in modern times.

Yes, but it will get slower once more optimizations are implemented.

I think you don't understand what makes Go fast to compile: http://golang.org/doc/go_faq.html#What_is_the_purpose_of_the_projec...

Furthermore, Go tip (1.1 in dev) has many many more optimizations than Go 1.0.3 and the compiler is 30% faster yet....

Hmmm.. are you are cherry-picking results or am I missing something? Here is the straight-up list:

You are missing something.

1. Your link does not include Go in the comparison.

2. If you do include it, you will see only very fast languages like C/C++/Java beat Go out (and Go is improving) Go beats most languages on the list (including C# Mono).

Most importantly:
3. Your link is only considering execution time, my link is a composite of execution time, memory usage and code size (weighted the same).

The is important because although Go is a little slower than Java (which is actually one of the fastest languages, BUT Java uses MUCH more memory (hence its reputation). You can play with the weights of my first link to reflect your own priorities regarding exec time vs memory usage vs code size and make your own call.

but again calling it a modern C is something I find to be nonsense.

Again, I mean modern C as in C the general purpose language of the 1970/80s, not C is the systems programing language of today. I'm not suggesting Go replaces what C is used for primaily nowadays (in some cases). The primary use cases of C has changed, I mean "modern C" in regards to C's original more general purpose nature.

Cherry-picking D as a comparison is rather pointless I think

...I was responding to someone who was comparing Go and D... I don't think D is particularly relevant to most developers.

Reply Score: 2

RE[7]: C -> Go
by Valhalla on Sat 12th Jan 2013 23:30 UTC in reply to "RE[6]: C -> Go"
Valhalla Member since:
2006-01-24


Furthermore, Go tip (1.1 in dev) has many many more optimizations than Go 1.0.3 and the compiler is 30% faster yet....

Sounds great, but it most likely means that the original compiler had lots of untapped speed improvements prior to this upcoming version. Implementing optimizations to be applied during code generation will slow the compiling down.

Oh, and both the Go compiler and the Go runtime are written in, you guessed it, C ;)


1. Your link does not include Go in the comparison.

Yes it does, it's two steps behind Java 7.


Your link is only considering execution time

That is how you measure language performance. Memory usage and code size are other metrics.


The is important because although Go is a little slower than Java (which is actually one of the fastest languages, BUT Java uses MUCH more memory

I actually don't think that matters much when it comes to the areas where Go and Java are likely to be deployed (which are unlikely memory constrained areas), obviously it's not a bad trait to use less memory though.

Still I think Go has every chance of eventually beating Java in raw performance, currently Java has what is probably the best in class garbage collector, Go's garbage collector is (as of 1.03 atleast) likely far behind.

Also in overall compiler optimizations the Go compiler sometimes loses out heavily to Gccgo on the exact same code, indicating that there is still alot of room for improvements to be made.

Again, I mean modern C as in C the general purpose language of the 1970/80s, not C is the systems programing language of today.

Well if you had framed it as such then I would have had no problem with your claim, although I would still find it odd to compare Go with C's much more widespread usage in the 70/80's as opposed to the areas it mainly occupies today.

...I was responding to someone who was comparing Go and D...

Ah, my bad, sorry.

Reply Score: 2

C99 latest ?
by Tractor on Sat 12th Jan 2013 02:39 UTC
Tractor
Member since:
2006-08-18

and yet C is indeed stuck in the past, with C99 being the latest version i know of.

I guess the culprit is C++, which is supposed to be, well, C plus other things. So probably a lot of people will answer just that : newest versions of C are "embedded" into C++ evolution.

I feel pity for C. That basically means there is no more any evolution to wait for C, all this due to a "name grabbing effort" by the C++ team. For people who want the predictability of C, there has to be another route than C++.

Reply Score: 1

C Rocks but it doesn't Rule
by benali72 on Sat 12th Jan 2013 07:33 UTC
benali72
Member since:
2008-05-03

C is low-level, idiosyncratic, difficult to maintain, and error-prone... and I love it! Always have, always will. But I'd be the first to admit that for most IT applications it's a poor choice.

For IT admin tasks I often use Perl or shell programming. I admire Python lots though I don't much use it myself. Never really learned Java and its 18 million classes. Oh well...

Reply Score: 2

RE: C Rocks but it doesn't Rule
by lucas_maximus on Mon 14th Jan 2013 12:56 UTC in reply to "C Rocks but it doesn't Rule"
lucas_maximus Member since:
2009-08-18

Never really learned Java and its 18 million classes. Oh well...


You don't have to learn the classes that is why there is a language reference ;-)

Reply Score: 2

pica
Member since:
2005-07-10

I repeat, I really do not want to miss OO when going multi-threaded.

Greetings,
pica

Reply Score: 2

Trabant
by cipri on Sat 12th Jan 2013 23:14 UTC
cipri
Member since:
2007-02-15

Why is a trabant better than a ferrari?
Simple!! If doesn't allow you to drive with 300km/h against a tree. With the "top speed" of a trabant being around 70-100 km/h, you still have chances to survive if you made an accdient. And it costs you a lot less to repair it.
Guys really, with c, there is a lot of stuff you simple can't do, and which would force you to write a lot more code instead of automatic code generation.

And would say about D programming language?

Reply Score: 1

There's no polite way to put this...
by deathshadow on Sat 12th Jan 2013 23:35 UTC
deathshadow
Member since:
2005-07-12

But after some three and half decades of programming - much of it with C and C syntax languages - C (and most every language based on it) PISSES ME OFF. Needlessly cryptic, pointlessly convoluted, and seemingly intentionally designed to make 100% certain you are going to make coding mistakes, I would rather hand assemble 8k of Z80 machine language, than deal with trying to find a bug in 100 lines of C code.

The ONLY reason I put up with it is that generally speaking it's what you are forced into using by compiler availability, support, and what's expected of you in the workplace. It's easy to blame the lemmings at the rear and front -- since most of us writing software are stuck in the middle and can't see where you're going and can't stop for fear of getting trampled.

I often think C and every language based on its syntax from C++ to Java to PHP, exists for the sole purpose of making programming hard. They are certainly a far cry from the elegance of languages like Pascal or the simplicity of assembly... To be frank, I thought there were two core reasons for higher level languages -- portability - which is a joke when you're still that close to the hardware, and being simpler than machine language - which it most certainly is NOT! It gets far worse when you look at objects in most any C derivative language since they seem to be just shoehorned in any old way!

Even sadder are all these 'newer' languages that are even more needlessly cryptic and difficult to decipher like Python, Ruby, or lord help you Rust... Rust, the language for people who think C is a bit to clean and verbose -- which is akin to saying the Puritans who went to Boston in the 17th century did so because the CoE was a little too warm and fuzzy for their tastes... or founding your own extremist terrorist group because Hezbollah was a bit too warm and fuzzy. There's this noodle-doodle idiotic concept right now that typing a bunch of symbols and abbreviations most people could never remember in a hundred years is 'simpler' than using whole words -- and the quality of code has gone down the toilet thanks to it... Such idiocy explaining why people will piss away bandwidth and code clarity on halfwit rubbish frameworks like jQuery.

It's enough to make you think the old joke... isn't a joke.
http://www-users.cs.york.ac.uk/~susan/joke/c.htm

Edited 2013-01-12 23:40 UTC

Reply Score: 2

kwan_e Member since:
2007-02-18

Even sadder are all these 'newer' languages that are even more needlessly cryptic and difficult to decipher like Python, Ruby, or lord help you Rust...


I don't know about the other two, but Python is really easy to decipher. The mandatory indents make it really easy. ;)

Reply Score: 2

deathshadow Member since:
2005-07-12

I should like Python -- I really should given what a stickler I am for clear consistent formatting...

But to be brutally frank, it's more cryptic than C in it's logic structures. Take the example up above by funkyelf -- both the C and the Python versions make me want to punch someone in the face due to their lack of clarity.

But again, I worship at the throne of all things Wirth so...

I LIKE the forced formatting of Python -- I DISLIKE the unclear control structures and lack of verbose ending elements... and the needlessly short/cryptic methodology and naming conventions. By the time you get into iterators and generators, it's a needlessly convoluted mess that honestly, I have a hard time making any sense out of.

I dunno, maybe this dog is getting too old for new tricks -- but I cry for anyone trying to use python to learn with -- which is part of why I don't get why the Pi folks and many educators have such a raging chodo for it. It's the LAST thing I'd consider using to teach people to program... It's another of those languages so complex IMHO you'd be better off just sucking it up and coding machine language directly. I really don't get these high level languages that make assembly look simple.

Edited 2013-01-13 09:37 UTC

Reply Score: 2

kwan_e Member since:
2007-02-18

By the time you get into iterators and generators, it's a needlessly convoluted mess that honestly, I have a hard time making any sense out of.


With iterators and generators, you have to understand that it's almost a different "paradigm". I think the root of your problem with Python may more be the fact that it's not a purely imperative language? I'm currently biting the Common Lisp bullet, and the Lisps have the same kind of ability.

Like C++, most programs don't need advanced Python features like iterators or generators anyway, but once you get used to a more declarative style of programming, it becomes a lot easier. That usually involves writing a few Python list comprehensions.

I dunno, maybe this dog is getting too old for new tricks -- but I cry for anyone trying to use python to learn with -- which is part of why I don't get why the Pi folks and many educators have such a raging chodo for it. It's the LAST thing I'd consider using to teach people to program... It's another of those languages so complex IMHO you'd be better off just sucking it up and coding machine language directly. I really don't get these high level languages that make assembly look simple.


The thing that makes Python a good teaching language is that the basics of programming in Python is a lot easier to understand than C and its descendants. Yes, there are complicated advanced things, but in terms of the basic stuff, Python is easier to teach.

Reply Score: 3

Comment by RareBreed
by RareBreed on Sun 13th Jan 2013 03:06 UTC
RareBreed
Member since:
2011-10-10

I too think the productivity aspect of C is overrated by the author.

I think what the author fails to consider is when your programming language of choice is "fast enough". Also, too many times, I have seen algorithms to solve problems using brute force approaches isntead of choosing smarter algorithms. I don't care if you write machine code, if you're using a dumb algorithm, your program's runtime efficiency will pay for it. I think that C's reputation as a "high-level assembly" actually makes people less likely to truly think about algorithm design, and instead rely on tricks of the compiler. In other words, C's reputation as a fast language is actually detrimental to good algorithm design.

Many people have been addressing C's lack of OO as a good thing, but I will say that C's lack of functional style programming is a bad thing. Having had to torture my brain to grok functional programming languages, I think that people just don't think easily in it. Recursion tends to hurt people's brains, and generally, people come up with iterative solutions instead. Also, the immutability of variables throws people for a loop (no pun intended from above). Unfortunately, C is horrible from a functional perspective. Start writing functions in a map-reduce style, using first class functions for filtering, having the ability to generate functions dynamically, or using to closures to encapsulate data....and you will truly miss it when you have to write things in an imperative style.

Reply Score: 2

C is useful.
by Tuishimi on Mon 14th Jan 2013 17:08 UTC
Tuishimi
Member since:
2005-07-06

But I miss using Fortran even more. ;)

Reply Score: 2