Fog Creek Software
Discussion Board

Computer Languages

  I noticed in one of your answers that if you went to College today, you would not leave without a course in 'C' or assembler.  In the process you said not Java, not Pascal.

I learned on Pascal, and to this day I still find the simple and direct syntax for doing references to be much less error prone than 'C's syntax for Pointers.  I'm not allowed to USE Pascal anywhere, unless I can be welded to a Borland product.  Even then, I must know enough 'C' to interface to Linux or Windows.

I've learned 'C', and use it in many different dialects, from 'pure' K&R to C++ extensions.  No matter what I do, it still seems 'klunky' to me.  Finding the 1980's copies of Thomas Plum's at least explained the rational behind the original Unix 'Standard Library' approach.

Anyway, I wanted a more long-winded explanation as to why the Software Engineer of tomorrow should learn 'C'.  Note that I don't disagree with you that it is important.

Tuesday, February 24, 2004

You don't have to use C, you just have to learn it.

See for the reasoning behind this.

Joel Spolsky
Fog Creek Software
Tuesday, February 24, 2004

I always found (Turbo) Pascal very very powerful.  Except for better string handling, it was basically C (with nestable functions, the with keyword, etc yummy).

Turbo Pascal let you do direct memory access (the absolute keyword), and I went happily building interrupt handlers and direct screen writes and everything (more yummy).

Pascal taught me how my 286 actually worked, and I didn't tire of typing words instead of symbols (which on my international keyboard requires some Alt-Gr arm bending).

i like i
Wednesday, February 25, 2004

Wow, OK.  As I understand it, from reading the article and about half the commentaries, your main point is:

"The point is that very low-level details can and do affect very high-level strategic software decisions, and in order to build quality software we must have a solid understanding of the basics."

Agreed.  What I am concerned about is your assertion that 'merely' learning 'C' will accomplish this. 

I feel that I was hampered for years in software engineering because 'C' is so poorly taught.  You can take several courses in 'C' at Johns Hopkins, and program it for 10 years on 68000 VME platforms, MS-DOS platforms, PIC platforms, even Sun Solaris platforms, and NEVER see the internals of malloc(), for instance.  As far as I know, the code for malloc() isn't even available except on the Sun, and even then they are 'hidden' somewhere in the Unix source tree.  That's my experience, anyway.

Yet looking at the internals of malloc() and some of the string handling library calls, and even understanding the rational behind WHY they were written that way, is what needs to happen to gain the necessary insights.

I absolutely agree with you that this insight is necessary, and using it can lead to much higher quality programs.  (Faster, cleaner, less thrashing of data, less crash prone). 

Where can you get this insight today, though?  With all these 'closed' libraries, 'just trust me', 'just use it' is the order of the day.

Wednesday, February 25, 2004

This is exactly why I urges everyone to read "Code" by Charles Petzold.

EXCELLENT book that is considered by some to be the best intro to computer engineering book.


Wednesday, February 25, 2004

"Where can you get this insight today, though?  With all these 'closed' libraries, 'just trust me', 'just use it' is the order of the day."

Wouldn't Linux include an open-sourced version of malloc (along with a lot of other things)?

Wednesday, February 25, 2004

Where can you get the source code to malloc() and other C runtime library calls?

- At least the MS compilers always have an option to install the C runtime source code.  I would have guessed that most compilers would come with runtime library source, since it is an invaluable debugging aid.

- The book 'The Standard C Library' by P.J. Plaugher is basically an implementation of the library with lots of annotations about the various design decisions the implementor has to make.  It probably isn't the best implementation of the standard, but it certainly explains it well.  He released another book on the standard C++ library, but it was an unfortunate victim of the last-minute addition of STL to the standard.

I have programmed professionally in C and C++, but generally I use higher level languages.  I still firmly believe that the initial time spent learning and working with C makes me much more effective with any programming language because I thoroughly understand the concepts that form the underpinnings of virtually all procedural (as opposed to declarative) programming.

Thursday, February 26, 2004

*  Recent Topics

*  Fog Creek Home