

30 years of C - pragmatic
http://www.dadhacker.com/blog/?p=1132

======
awolf
"Don’t leave unused code hanging around because it might be useful someday. If
it’s not being used right now, remove it, because even just sitting there it’s
costing you."

Couldn't agree more - every extra line makes the source code that much harder
to wrap your brain around.

If I glance at a section in my code and can't instantly grasp what it is doing
and how it fits into the bigger picture then I know I still have refactoring
to do.

~~~
DarkShikari
And version control keeps it around for you anyways.

I can't even count the number of times I've heard "but this code will be
useful if/when we add support for feature X" used to justify hundreds or even
thousands of lines of ifdeffed-out cruft.

~~~
sunkencity
I worked with someone who never threw old code away. It was amusingly
difficult to try to understand what his code did. Typically shitloads of php
files that didn't do anything and in the files that actually did something
stuff like

    
    
       if (false) { ... large incomprehensible code block .. }
    

was common. Why comment out stuff when you can just disable it
programmatically?

~~~
scotty79
The cause could be that inside the block there were already the /* */
comments, and editor did not have single keystroke option to add // at the
beginning of each selected line.

~~~
sunkencity
no. he used Eclipse. Apple-7 would have worked.

~~~
scotty79
Ok. So I have another theory. In place of false there was previously some ugly
condition and he wanted get rid of the things that were done on this condition
with minimal necessary effort hoping that someone in the future with more time
(maybe even himself) will clean that up since doing cleanup in such case is
not hard thing to do.

------
fogus
" When I worked for Apple a few years later I was dismayed that it was a
Pascal shop..."

I never knew this, interesting tidbit. Like many programmers I've read my
share of Apple history books, but somehow Apple Pascal eluded me.

~~~
cesare
Yep. Much of the original Mac OS was written in Pascal.

I still have a boxed copy of Symantec Think Pascal. I used it to make my first
steps in window based/event driven applications programming on the Mac (in
1990).

I remember coding my first apps invoking the system calls directly to create
windows, handling events (see where the user clicked) etc. Then I moved to
Codeworrior which had a nice c++ framework.

~~~
drewr
If my high school CS teacher had told me that Mac OS had been written in
Pascal, I would have been slightly more enthused about learning it. I had a
similar, nebulous unease with it as dadhacker and really enjoyed C when I got
to college.

~~~
cesare
I dropped out of college (CS) instead, also because of an episode related to
this.

An assignment for an exam was to make a simple library management program in
pascal (cataloging books, leading, receiving them back etc.), mainly to test
our understanding of pointers.

Even if we also had Macs at the university, we've been asked to make a command
line app. But, since I was studying the Mac OS gui programming by myself, I
made a graphical application instead.

The assistant professor that was evaluatings our assignment didn't believe
that I had made it myself. She probably couldn't understand it herself (but,
obviously, all the relevant functions were separated from the gui code). So
she asked me to rewrite everything from scratch as a command line application
in a couple of hours in front of her.

I managed to do it but I was really really pissed off. Shortly thereafter I
started working and dropped out.

~~~
barrkel
You ignored the requirements and demonstrated expertise in the wrong area,
IMO.

In a similar situation, I wrote the required command-line app, but it handled
queries, basically parsing to an expression tree predicate.

Of course, it doesn't matter now.

~~~
cesare
> You ignored the requirements and demonstrated expertise in the wrong area,
> IMO.

The assignment was about implementing the functionalities of a simple library
management app. And it was explicitly to test using pointers, linked lists
ecc.

The requirements were fully implemented. And all the queries were handled by
functions which were completely separated from the gui code.

Basically, instead of a textual menu (1 - borrow, 2 - return etc.) you had a
Mac Os menu and the results were presented inside fields in a window instead
of a textual output.

If I had to convert the program to a textual interface by editing my source
(instead of doing everything from scratch) it would have took me 5 minutes (or
less). IIRC the code was already there and simply commented out.

Keep also in mind that our lab was full of Macs (50-60 machines) with just a
PC (which, btw, has been used by a guy who had made the app with his own
advanced textual interface - something like ncurses - and who had a similar
fate as mine). So I thought it was a plus to use the native gui of the OS we
were using all the time.

> Of course, it doesn't matter now.

Of course. It happened 17 years ago :-)

~~~
nitrogen
In my experience, CS professors like automating the grading process as much as
possible. It's conceivable that your assistant professor was upset she
couldn't just run your app through the grading script.

~~~
cconstantine
We had something similar at Purdue. In fact, we were frequently given an
example 'correct' program whose output we needed to match exactly. It took me
much longer to get register assignment in my compilers' class to match the
professor's results than it took me to get it 'correct'.

This gets to interfaces though. I don't know about the gp, but if the
assignment specifies a particular interface then that becomes a part of the
spec. It doesn't matter that you made a more advanced interface, if it doesn't
match the required interface it's wrong.

------
coliveira
I like this part: "Template meta-programming is a great example of people
being clever without being responsible."

------
cturner

        can’t help but think that Sun continued to blow its
        opportunities here, for years.
    

Usually I jump on the bash-java bandwagon. However, I think the author's wrong
about this. Java is good in a team setting, and Java is the best choice for
the enterprise.

I support a cross-platform, plugin-oriented Java application with a large
install base and wouldn't want it written in anything else.

In C applications, it happens that applications will have segfaults, and
threaded log less helpfully on the way down whereas in java there's a command
that allows you to analyse threads of a running process. When there's a Java
problem I have much better odds of getting my head around the source than I
would for the sort of macro-affected C source that you'd need for an
application run in this setting. If it were to run out of memory it would be
clear about it. When you're stuck with libraries where the source and
developers are long gone it's realistic to use a decompiler. With some
preparation at dev time you can use the classpath and classloaders to hot-
patch.

C is good for programmers, but not so good for the other technical workers.
And I don't think C is as much of a big deal as it used to be due to the
advances in scripting languages. I do a fair bit of programming oriented
around unix system calls, all in python. Sometimes I find the documentation is
better in C, and mock it up there, and then carry it back to python where I
can do more with it. Also, if you're on Bigco's standard-issue Solaris host
you're far more likely to find perl than a C compiler. Computers are faster
than they used to be. Raw execution speed and memory footprint of a process
(areas where C is stronger) are much less relevant to scale issues than they
used to be.

Reply said:

    
    
        The author is comparing Java to C#, not C.
    

Er - ah - so he did. Thanks for being polite about it.

~~~
arohner
The author is comparing Java to C#, not C.

------
ivankirigin
I "know" C. But are there any good resources on learning to build real systems
in C? I don't like C++.

~~~
sunkencity
Look at successful open source projects and read the source.

~~~
ivankirigin
Like what? Memcache is written in C, right? Python itself?

Anyone actually follow this method want to chime in?

~~~
there
i think the key is to find something secure (and thus, "correct") and not
doused with tons of portability goo (ifdefs, etc.)

look at openssh, but the one in openbsd's tree and not the portable branch.
for that matter, any of the openbsd-developed daemons (openbgpd, openntpd,
etc.) at <http://www.openbsd.org/cgi-bin/cvsweb/src/usr.sbin/> or usr.bin/ssh
for openssh.

any of the openwall projects are also small and easy to work with -
<http://www.openwall.com/>

~~~
henryprecheur
Secure & correct programs don't always have a nice code.

For example qmail is probably the most secure smtp server around. But the code
is not easy to read.

Pretty much all the stuff Dan Bernstein writes is secure and correct. But his
coding style is just too weird for me and many others.

~~~
there
yes, i avoided listing djb's stuff for that very reason.

