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)
BWK is teh most amazing people of our times.
Read his book on programming practices that he did with Rob Pike. Its best book evar.
Huh, I consider gets to be a minor (!) snafu compared to the vile mind poison of:
int foo, *bar;
And the way that C interprets type modifiers as right to left except that any modifiers on the far left to the first type. Gnnn.
If I had a penny for every time I'd seen developers failing to completely understand C types because of this, I'd be handing my wet towels to Bill Gates.
If you were blocking sigs, you wouldn't have to read this.
int foo, *bar; creates an integer named foo, and a pointer to an int named bar. Right? Or am I wrong?
So you have one declaration line which created variables of two totally disinct types. Fine for the opriginal creator, lousy for the maintainer, who sees a line declaring ints and had to do a serious double take to find that some of them are actually pointers. Abuse further as
int foo, *bar, flash, *bang, up, *down, left, *right;
Without reading the line again, what was the type of "up"?
And as for the other, 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.
The mistake I would junk is allowing enum {fred=36, bill=19, joe=333} ; Which confuses predefined constants with the classic enumeration. The cost saving of a lookup table to convert the 0, 1, 2 sequence is tiny, and the knock on effects are horrible.
Consciousness is an illusion caused by an excess of self consciousness.
Like many people, I have mixed feelings about Microsoft. They have done much good for the world, producing a common environment that has enabled a lot of creative people to build new software and hardware and sell it at reasonable prices. Microsoft's work has made computing accessible to a huge population who would otherwise not be able to use computers.
listen folks: Microsoft did not bring computers to the masses. Computers were well on their way to the masses through the fine works of the many many other people in the computer industry.
Microsoft has held computers back from the masses. Monopolies charge unreasonably high prices. High prices stop people from buying things. A grindingly competitive software industry would have delivered many more computers to many more people and businesses.
Microsoft has harmed us all, and the world economy, immeasureably, by much more than the money they've pocketed for themselves.
stick to CS, Brian, it's something you're good at.
You can write badly obfuscated code by abusing visual association in just about every language, but this particular gotcha should have tipped off Stroustrup VERY early on that his style was agegeously misleading, and a good technical editor should never have let him publish a book with such incomprehensible gibberish.
That very thing is one of the primary reasons I didn't use C++ for years (not to mention that I regretted it when I did). My thinking was that if the creator of the language didn't see how damaging it was to introduce confusion in his published writing, then he wasn't likely to avoid such in a programming language. I think ANSI C++ stands as a monument to the correctness of my thinking on that point!
I'm not disagreeing with your point, but the acceptable (if not great) solution is to choose your variable names more wisely.
To ensure perfect aim, shoot first and call whatever you hit the target
Awk and those three books were the basis of my early career and I would think had the most impact on my thoughts and programming style. Not quite the philosophy of programming, but darned close. I'm still advocating the use of small, interoperable tools in my current work, even though I no longer do the programming.
Some ideas are just right.
Forth.
After years of basic, fortran, 6502 assembler, pascal, and probably something else that I've forgotten, forth was magical. Still is.
"People who do stupid things with hazardous materials often die." -- Jim Davidson on alt.folklore.urban
The mistake I would junk is allowing enum {fred=36, bill=19, joe=333} ; Which confuses predefined constants with the classic enumeration. The cost saving of a lookup table to convert the 0, 1, 2 sequence is tiny, and the knock on effects are horrible.
The advantage of enums over constants is type checking by the compiler (warnings are issued if you try to assign a constant to a variable declared as an enum) and also warnings issued when you do a switch on an enum (as in switch(enum varBlah)). This might not be true in C, but it is in C++ and I find it useful. It's merely a convenience. It has no effect on code output.
I've found that enums in other languages which enforce the sequential order and must start at 0 are pretty much useless in most cases.
if(!cool) exit(-1);
bla
My aunt used to work with these guys at the Labs here in NJ quite often. Shes dieing now and we sit for hours and talk about how she used to program in C and how much she loved unix. Hours on end of stories about these guys and different projects. I work with a guy now who worked with her, lots of stories from him as well. Awesome stuff, true geniuses. Gotta thank these guys for changing the world.
-- chris
http://elusive.filetap.com
And what about this, then:
int pFoo, *Bar;
Which falsely labels pFoo as a pointer and Bar as not a pointer, when the opposite is true? How's THAT for confusing. The problem with encoding type name with the variable is that it now means there are two seperate ways where you "define" the type - the one for the compiler's benefit and the one for the human reader's benefit. Since they are totally independant of each other, they can disagree - leading to no end of confusion. I much prefer coming up with a solution where the human-readable version and the compiler-readable version are guaranteed to actually agree. If that cannot be done, then you are better off forcing the human reader to look at the same thing the compiler looks at, rather than inventing a fake mnemonic that has no guarantee of being correct after several hands have been involved mantaining the code.
The only such naming mnemonic I use is ones that label the storage scope, as in g_foo means "global foo", and s_foo means "local stack foo", and h_foo means "heap foo". This mnemonic just helps the reader figure out where to look for the declaration of the variable, without telling him what that declaration actually is.
Don't label something "offtopic" unless you know the topic well enough to tell what's on topic.
I'm sure most programmers, deep down inside, feel the same way. Windows is the undisputed king of the desktops. It is just easier to use Windows than most other OSes. No one can deny its role in popularizing computers.
All True.
What's more, I make a decent living off of Microsoft's products -- and like a good parasite, I don't actually harm my host.
-kgj
But if you don't leave some audio clues *out* of the literal meaning of the language, it is actually less expressive since you can't communicate any 'tone' to what you say. (For example, how do you express "this thing I am saying is sarcastic" or "This thing I am saying makes me happy" in a language where you cannot change the tone of your voice without having it end up being a totally different word?)
Don't label something "offtopic" unless you know the topic well enough to tell what's on topic.
In the interview KR said:
There are only two real problems in computing: computers are too hard to use and too hard to program.
Does everyone buy this? What about issues of availability and maintainability? How about:
There are three real problems in computing: computers are too hard to use, too hard to program and too hard to administer.
In the Turing sense, all languages have equivalent expressiveness.
In the Kolmogorov sense, the "complexity" of a program differs between two languages by at most a bounded constant (the length of the interpreter of one language in the other).
But in the real world, I think K (http://kx.com) beats any other language in terseness (and is speedwise competitive with C as well). Rebol is also amazingly terse, even if not as fast.
If you mean the "FreeBSD" userspace, then maybe, but I've yet to see anybody argue convincingly that MacOS X is actually "freebsd with stuff on top". It has a different kernel, different IO layer, the FreeBSD de-facto graphics layer is X11 not Quartz, and so on. Calling MacOS FreeBSD is like calling Windows with Cygwin Linux. I think this guy knows the difference ;)
I would argue administer==use
Or perhaps more accurately:
If it was easy to use, we wouldn't have to administer it. My microwave has a 'puter in it. It's easy to use, and I don't have to administer it.
This post is licensed under the Creative Commons Attribution-Noncommercial-No Derivative Works 3.0 License.
While MS is overpriced and abusive today, historically they did lower the bar for entrance into the computer realm. Befor MS-DOS and Windows, every brand of computer used its own OS (if you want to consider ROM-BASIC an OS) and software had to be rewritten for each platform.
With MS having the forsight and balls to reserve the ownership of MS-DOS and grant IBM a license they opened the doot to one OS running on machines manufactured by multiple venders.
Consider that when your average PC cost $4,000.00 (US) (not the high-end systems, average desktop systems), MS-DOS was only around $120.00 - $150.00 a copy. Compaired to the multi-thousand dollar cost of even the cheapest Unix systems of the day DOS was a bargain! Sure, it lacked a lot of what makes Unix so great, but it had enough to let people run their entire businesses on their desktops.
Remember, before Linux came into being, Unix (and it's clones, dirivatives, etc...) was an expensive and very closed environment.
Boobies never hurt anyone. - Sherry Glaser.
I'd like to agree that Python would be better, since I'm partial to the language myself, but I really don't know enough about VB to say.
...
But
It's boneheaded design that will turn the toddler off biking completely.
The reaction of the people taking the course seemed to be, "hey, this programming stuff isn't so bad after all." They only did the simplest of tasks (can't quite remember what any more), and VB ended up being quite sufficient. Of course, you're be correct in thinking that very, very few of them will go on to be programmers. But I'm don't think you can blame that on either the language or the course: none of them were inclined that way to begin with.
So, yes, VB may not lay the best foundation for learning other languages, and it may not be a good tool for serious development, but it seems to get non-techie types past their fear of programming just fine.
I'd suspect that Kernighan considered other languages for the course. He probably even considered Python. It would be interesting to hear what, specifically, his reasons for choosing VB over (languages x, y, z) were.