Slashdot Mirror
Linux Journal Interview With Brian Kernighan
pndiku writes "Linux Journal has an interesting interview with Brian Kernighan where he talks about AWK, AMPL and how he had nothing to do with the creation of C."
← Back to Stories (view on slashdot.org)
He says " I wound up at Princeton" and "through good luck I got a job at Project MAC at MIT" and "probably because of the MIT experience, I got a job at Bell Labs in the Computing Science Research Center". Princeton, MIT, Bell Labs?? not easy!
New year Resolution: Don't change sig this year
Very practical. He wants to use the computer as a tool. Not a propaganda platform. Windows is fine and dandy for some applications, Unix for others. It all depends on what you're trying to do.
-
You've got to be careful with your terminology here. All languages are equally expressive in the sense that anything you compute in one can be written in another. (At least in terms of computability. Access to hardware is a different matter.)
In your context, you might mean "expressive" in the sense of "saying as much in as few words as possible." Since C is a typed languge with explicit memory management, it's going to be more verbose than an untyped garbage-collecting language like Lisp or Perl. (Well, they have very limited typing, especially once you start adding constructs on top of the core language.)
Or you could mean "expressive" in exactly the opposite sense, where you have to be more "expressive" about the types of things. In this sense C is far less expressive than strongly typed languages like Haskell or even C++/Java.
Or you could simply be referring to the verbosity of the language, where COBOL holds the title of most ugly language and APL is without a doubt the shortest. (APL is indistinguishable from line noise.)
In the end the value of a "language" has less to do with the core language and much to do with the libraries for hardware access (memory, screen, disk, network) and compatibility with common features provided by the OS (clipboard, windowing, etc.)
So you pick your language for a host of reasons few of which have anything to do with a core "expressiveness".
int foo, flash, up, left;
int *bar, *bang, *down, *right;
Or even better:
int foo;
int flash;
int up;
int left;
int *bar;
int *bang;
int *down;
int *right;
Just because a language allows a construct doesn't mean you have to use it. This is a coding-style argument, which are of course all subjective.
I can never define any sort of function pointer in one line: I always have to typedef tthe function and then have a pointer to it. While I can work out, with a manual in hand, how to do it in one line, the syntax is so unintuitive that I never do it: I will just have to reach for the manual again wh en I maintain it.
This is a valid problem that has to do with operator precedence. In C the operator precedence is arranged in such a way most commonly used expressions can be written without a lot of brackets. I think this is more convenient, because normally you don't define a lot of function pointers, but you do use at least some pointer arithmetics.
The mistake I would junk is allowing enum {fred=36, bill=19, joe=333} ; Which confuses predefined constants with the classic enumeration.
A constant in C is not the same as an enum. Simply put constants are addressable, enum items are not. One could choose to introduce yet another construct for unaddressable constants, but this is far more practical.
And again, you don't have to use every feature in a language just to make your code more interesting. C was designed as a language-of-choice, not as a bondage-and-discipline language. If you don't like your freedom, don't use it, but please don't start whining you've got too much freedom.
It should read, "Conversation with God (or a God)".
Jokes aside, the names Kernighan and Ritchie are firmly planted in the minds of most CS majors. We have "celebrities" like Torvald or Stallman but at the end of the day, professors always say "Read page XXX in Kernighan and Ritchie", which we always proceeds to ignore until our code doesn't work. Then once again, we reach for the pretty little white book and thank someone or something for the well written proses. Unlike many other CS books, K&R seem to have cover most of the possible contingencies a fledgling CS major might have. I hate books that tell you how to do things only in one way, their way. K&R was written so well that I didn't have to.
EvilCON - Made Famous by