Still worth it to learn C?

[Daniel Duffy]

Maybe this will convince to write in C (it's bad and good)

 

[Yike Lu]

lol... "PL1 is 80s" but C is 70s.

 

[Daniel Duffy]

lol... "PL1 is 80s" but C is 70s.

I wrote my first ever program in PL/I in 1971 , it is (0.25*Fortran + 0.75*Cobol) :D

Yike Lu,
He does not like Lisp either

 

[Daniel Duffy]

Here's a radical idea: in addition to learning C++, how about learning D (a programming language which much of the structure of C++, native code generation, range checking and garbage collection).

Why?

 

[Ian Kaplan]

Here's a radical idea: in addition to learning C++, how about learning D (a programming language which much of the structure of C++, native code generation, range checking and garbage collection).

Why?

That paragraph should have covered it.

I'll observe that no one designs languages like C/C++ anymore. For example, the Go Language has both garbage collection and range checking.

The reliability of C/C++ software is terrible. A lot of financial software can be categorized as "critical systems". To build systems like this we should use the best tools available. And C++ simply is not the best tool available. The reliability of C++ software is much worse than software written in Java, exactly because C++ does not have range checking and garbage collection.

The advantage of D is that it has many of the advantage of Java, but it compiles to native code. You can write "close to the iron" or time critical code in D, where you could not do this in Java. As I've noted before, because of the structure of D, the compiler can also do a better job optimizing the code.

The only way to develop reliable C++ software is to use data structures like "smart pointers" that clean up after themselves. And to overload the [] operator so that you don't over index data structures. All of this introduces overhead that does not exist in a language like D (or Java for that matter).

There's no doubt that learning C++ is important. There's a lot of legacy code out there and it's a skill that is needed for the job market.

But I can assure you that if I were running a software group at a hedge fund, where I had the opportunity to develop a lot of new software, I would not develop this software in C++. Again, I want to use the best tools available. It's just not worth arguing about whether C++ is the best tool available. It simply isn't. Anyone who has developed large systems in C++ should have many stark reminders of this, as they constantly chase system crashes and hard to find memory errors. Developing large complex software systems is difficult. Why make it more difficult than it needs to be?

Ian

 

[Daniel Duffy]

The reliability of C/C++ software is terrible. A lot of financial software can be categorized as "critical systems". To build systems like this we should use the best tools available. And C++ simply is not the best tool available. The reliability of C++ software is much worse than software written in Java, exactly because C++ does not have range checking and garbage collection.

I agree that C++ is more of a challenge for some developers than Java or C#. In that case it is better not to use C++ if you can get away with it. Personally, I like C# for trading and QF applications.

Many critical real-time systems are in C++, so developer discipline _is_ possible.

One issue is that many systems have not done the up-front software design nor documented the code.

And there is a right way and a wrong way to write in C++ (bad/good habits). I don't always blame the language alone.

[q]C++ does not have range checking[...][/q]
This is a scary remark; this is a non-issue if code is designed and implemented properly. Can you give an example? I am very curious.

BTW you can get memory leaks in Java and C# as well (unreachable objects).

 

[cgorac]

The reliability of C/C++ software is terrible. A lot of financial software can be categorized as "critical systems". To build systems like this we should use the best tools available. And C++ simply is not the best tool available. The reliability of C++ software is much worse than software written in Java, exactly because C++ does not have range checking and garbage collection.

I find that these lengthy rants about which programming language is good, and which is not, are typically pointless (and also typically mostly written by people without too much actual practical experience, thus useless). Namely, in real world these things work in very simple manner: either you as a programmer cannot influence the programming language choice, in which case you either don't accept the job if you really can't live with the choice imposed, or you just shut your mouth up and get to the work; or you can choose the implementation language, in which case you choose the language you're most comfortable with, exactly because this way you know you're going to produce best results in quickest time.

Thus, while everything you write above is mostly valid for example for some sort of academic discussion on which programming language novices should be taught as first programming language in high school or college, so that they could acquire sound programming practices along the way, it is not relevant at all for any decently experienced programmer. For example - everything you say about that C/C++ are more prone to pointer handling errors is true in principle but, as you're already pointed to previously by some other posters here, any C/C++ programmer with 1+ years (or even less) of experience will know how not to fall into this sort of traps, and which tools (and these days there exist loads of these) to use to check for them.

(Also, some of your claims are just factually wrong: for example, you said that D has an advantage over Java as it could be compiled to native code, while Java cannot - well, check under "gcj".)

 

[Ian Kaplan]

I find that these lengthy rants about which programming language is good, and which is not, are typically pointless (and also typically mostly written by people without too much actual practical experience, thus useless). Namely, in real world these things work in very simple manner: either you as a programmer cannot influence the programming language choice, in which case you either don't accept the job if you really can't live with the choice imposed, or you just shut your mouth up and get to the work; or you can choose the implementation language, in which case you choose the language you're most comfortable with, exactly because this way you know you're going to produce best results in quickest time.

Thus, while everything you write above is mostly valid for example for some sort of academic discussion on which programming language novices should be taught as first programming language in high school or college, so that they could acquire sound programming practices along the way, it is not relevant at all for any decently experienced programmer. For example - everything you say about that C/C++ are more prone to pointer handling errors is true in principle but, as you're already pointed to previously by some other posters here, any C/C++ programmer with 1+ years (or even less) of experience will know how not to fall into this sort of traps, and which tools (and these days there exist loads of these) to use to check for them.

(Also, some of your claims are just factually wrong: for example, you said that D has an advantage over Java as it could be compiled to native code, while Java cannot - well, check under "gcj".)

I decline the opportunity to engage in a flame war. This post is so obnoxious that it deserves no response.

 

[Ian Kaplan]

[q]C++ does not have range checking[...][/q]
This is a scary remark; this is a non-issue if code is designed and implemented properly. Can you give an example? I am very curious.

BTW you can get memory leaks in Java and C# as well (unreachable objects).[/quote]

I should note that I tend to use range checking and bounds checking interchangeably and this probably makes my point confusing. To a compiler developer they are the same thing, but in an application they are, at least conceptually, different (e.g., range checking is where one makes sure an argument is in range and bounds checking is what I have been referring to).

I've worked on several image processing applications where there were multiple, large buffer that were used for the images. In some cases the National Institute of Standards libraries for C++ multidimensional arrays were used. These array objects have bounds checking. However, there was other code where these was no bounds checking. It took us a while to track down some of the buffer allocation errors.

This application is multi-threaded C++ code. The structure is pretty good, but it has evolved over time, with multiple programmers working on it. Especially when devices are shut down and threads terminate or restart, there have been object allocation problems.

Even good programmers, using good design, make mistakes. Or don't fully understand the structure of the code when they join the project and modify it. This code is probably about 100K lines. It has improved greatly in the last year, but there are still crashes and the problems have been extremely difficult to track down and fix. This software system controls an image processing instrument on an airplane. I've flown with it. It's pretty irritating when you're flying and the software crashes and you have to restart. So I've eaten my own dog food, as they say.

When I develop software I am constantly reminded of the fact that I make mistakes. The problem with C++ is that is that it is very unforgiving for any errors and the errors are difficult to find. There are now only three tools to help debug memory errors that I know of: Valgrind, a tool from Parasoft, and Purify from IBM. The output of Valgrind is pretty horrible and it is difficult to use with class libraries like Qt (which, by the way, has a very nice set of core classes). Parasoft and Purify are a pain to use because they have node locked licenses and I'm constantly working on new systems and shipping them "out the door".

You can definitely build C++ data structures that do their own range checking. However, a compiler that does range checking (bounds checking) can do a better job, because it can optimize the range checking. So in this case the code generated by the D compiler will be more efficient. Also, the source code in D will be simpler since you don't have to do things like overload the [].

I absolutely agree that in many cases one must use C++. I have spent many years developing large applications in C++. In addition to the imaging code above, I have, among other things, developed a compiler for the Verilog hardware design language. I've spent a lot of time chasing memory error and bad pointer references. For multi-year software projects, when engineers are leaving and joining and the software is growing "organically" my experience is that design and documentation alone are the answer to errors in C++.

If I have the opportunity to use a better tool, then I'm going to use it. That tool may be Java or C#, or Python (I use R a lot these days and Python looks like an attractive platform to deploy an algorithm prototyped in R). If I need native code performance and I can use D, then I'm going to use D.

By the way, I agree that there are memory leaks in Java. I've worked on a project that was plagued by such a leak and we finally tracked it down with Yourkit. So there's no panacea. All I'm saying is that developing large complex software systems, over multiple year periods, is difficult. If you can, you should use the best tools available. Some times your hands are tied. But if I could choose the tool and I needed native code performance, I'd use D.

Ian

 

[Daniel Duffy]

For multi-year software projects, when engineers are leaving and joining and the software is growing "organically" my experience is that design and documentation alone are the answer to errors in C++.

Ah, it's called 'organic' these days? I do agree that such undisciplined development can lead to spaghetti code.

I would hardly blame C++. As with more mature domains, blueprints are needed.

 

[aravind sivam]

yes,it was worth to learn c,because c is the basic program of computer....with out c u didn't study any programming language.c++ is used in software language like PHP,.NET,etc...c is used in hardware language like embedded c......to get more details and training in c refer this webpage: lastbenchindia.com/

 

[ExSan]

yes,it was worth to learn c,because c is the basic program of computer....with out c u didn't study any programming language.c++ is used in software language like PHP,.NET,etc...c is used in hardware language like embedded c......to get more details and training in c refer this webpage: lastbenchindia.com/

try edX

 

[ExSan]

In the words of Linus Torvalds:

"...
C++ is a horrible language. It's made more horrible by the fact that a lot
of substandard programmers use it, to the point where it's much much
easier to generate total and utter crap with it. Quite frankly, even if
the choice of C were to do *nothing* but keep the C++ programmers out,
that in itself would be a huge reason to use C.
...
In other words, the only way to do good, efficient, and system-level and
portable C++ ends up to limit yourself to all the things that are
basically available in C. And limiting your project to C means that people
don't screw that up, and also means that you get a lot of programmers that
do actually understand low-level issues and don't screw things up with any
idiotic "object model" crap.
...
"
http://thread.gmane.org/gmane.comp.version-control.git/57643/focus=57918

Read the whole exchange. It will open your eyes.

no pain, no gain

 

[Daniel Duffy]

Linus Torvalds shudda taken the Quantnet/Baruch C++ courses.

 

[Daniel Duffy]

You can bypass C. In C++ concentrate on things like (ordinary) pointers and function pointers. And memory management.

Looking back, I am very glad that the QN C++ course has 2 modules on C (you really learn what a compiler is). Of course, there's a lot of deprecated C code not to use but

1. you learn necessary structure
2. get close to the hardware.
3. C++ _is_ a better C

Jumping into C++ w/o C foundations (just pointers and malloc is not enough).

Compare learning Italian with some Latin savvy helps a lot.

 

[Daniel Duffy]

The big jump from {Java, Python, Matlab, <whatever>} to C++ immersion is huge. Do some C first. Believe me, otherwise 2 steps forward and 1 step backwards.

Someone on QN once wrote that they learned more from QN C++ than 4-year CS degree programme.

Saw this random observation...

If you do not know any lower-level programming, this means you do not know how to get your codes speak to machines.
Then I am afraid you should not claim yourself a computer scientist!
The new computer science education appears to be garbage. Majority of graduate know only front-end stuff and think they know CS.
The CS edu-system was way better decades ago!!!

 

[longgamma]

C is a fun language to play around with. I doubt most of us would need it at work unlike hardware engineers or high performance computing people. The limited scope and freshing lack of OOP means you can focus on solving problems and creative thinking rather than spending thirty minutes on documentation. I really enjoy python but sometimes its too abstract, working in C just forces you to solve every step of the problem, which is great for learning new concepts like data structures.

 

[Daniel Duffy]

C is like a Bear Grylls survival weekend, Python a cruise in the Bahamas.

 

[longgamma]

C is like a Bear Grylls survival weekend, Python a cruise in the Bahamas.

Hehe, the simplicity of C is charming. Heres the source code of Quake 3 Arena - a multiplayer shooter game written entirely in C. Its amazing how far a simple language without OOP can go.

GitHub - id-Software/Quake-III-Arena: Quake III Arena GPL Source Release

Quake III Arena GPL Source Release. Contribute to id-Software/Quake-III-Arena development by creating an account on GitHub.

github.com