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."

333 comments

  1. Correct AMPL link by JohnGrahamCumming · · Score: 4, Informative

    The story has a link to ampl.org, the correct link is ampl.com.

    John.

  2. It's official by Anonymous Coward · · Score: 0

    K&R is no more. Now we just have R. ;)

    1. Re:It's official by Lazar+Dobrescu · · Score: 5, Informative
      It is well known that Kernigham had nothing to do with the creation of C. The K&R you are referring too are the authors of the BOOK, "The C Programming Language", that Kernigham wrote with Dennis Ritchie(which is the main inventor of C).

      So, we still have K&R, just as before. Only now, maybe some readers understand better that K&R is not the names of the C inventors, but the name of the people who wrote the book about how to use C ;)

    2. Re:It's official by iabervon · · Score: 1, Funny

      Well, he does claim responsibility for getting a book written. Without him, we'd still have C, but nobody would know how to use it.

    3. Re:It's official by no+reason+to+be+here · · Score: 2, Funny

      wrote with Dennis Ritchie(which is the main inventor of C).

      <nazi class="grammar">
      First off, which is in the wrong case. which is the objective case. It should be the nominative form, that.
      Second, that/which is the wrong word. Dennis Ritchis is a person, and therefore should be substituted by the pronoun who (not whom, as that would cause that same nominative/objective problem again).
      </nazi>

    4. Re:It's official by Anonymous Coward · · Score: 0, Funny

      but nobody would know how to use it.

      Looking at the quality of code from some of the students I study with, perhaps we haven't come that far.

    5. Re:It's official by quigonn · · Score: 1

      The Soup^WGrammar Nazi!

      --
      A monkey is doing the real work for me.
    6. Re:It's official by rekkanoryo · · Score: 1
      <nazi class="grammar">
      First off, which is in the wrong case. which is the objective case. It should be the nominative form, that. Second, that/which is the wrong word. Dennis Ritchis is a person, and therefore should be substituted by the pronoun who (not whom, as that would cause that same nominative/objective problem again).
      </nazi>
      <nazi class="spelling">
      You have a spelling error. The name is Dennis Ritchie.
      </nazi>
    7. Re:It's official by rekkanoryo · · Score: 1

      Looking at the quality of code from some of my friends, I KNOW we haven't come that far yet.

    8. Re:It's official by connsmythe96 · · Score: 2, Insightful

      I've found that most people in my classes who can't program have never even heard of the K&R book, and would probably be hard-pressed to tell you who K&R are. I guess the book can only help if people read it. ;)

      --
      if(!cool) exit(-1);
    9. Re:It's official by dirkx · · Score: 1

      Of course - at that time there was a fair range of budding programming languages - and one of the prime reasons that C took such a leading position was that Kernigham wrote a most excelent tutorial on 'programming in general' and in C specifically - and, in his own words, twisted 'Ritchie his arm into writing a book with him'.

      Dw

    10. Re:It's official by no+reason+to+be+here · · Score: 1

      touche'!

    11. Re:It's official by coolfrood · · Score: 1

      Ummm... touché

    12. Re:It's official by Anonymous Coward · · Score: 0

      s/nazi/fascist/g

  3. Woah by Sir+Haxalot · · Score: 5, Funny

    '...and how he had nothing to do with the creation of C'
    That's something to be proud of!

    --
    I have over 70 freaks, do you?
    1. Re:Woah by jmt9581 · · Score: 3, Funny

      I'd be more proud of having nothing to do with C++. :)

      --

      My blog

    2. Re:Woah by Anonymous Coward · · Score: 0

      fucketh you!

      -C++ Troll

    3. Re:Woah by Anonymous Coward · · Score: 0

      Technically, there was a good chance that the language would have been called P. Originally, the language C was derived off of the language B, which was similar to BCPL. Therefore, there was actually some debate over whether to call the sucessor of C C++ or P, as P is obviously the next letter in BCPL.

    4. Re:Woah by BrokenHalo · · Score: 1
      That's something to be proud of!

      No, he's very clearly giving credit exactly where it's due: to Dennis Ritchie. He says he just twisted DR's arm into getting the latter to write "The Book" with him.

    5. Re:Woah by Mr+Z · · Score: 1

      They were saving P and L for Larry Wall, who subsequently used those letters to denote Perl source files.

    6. Re:Woah by jdeking1 · · Score: 1

      I must say that C is still my favorite, and most portable, programming language.

      --
      "A generation which ignores history has no past and no future." -- Robert Heinlein
  4. Hey, we have something in common! by Anonymous Coward · · Score: 5, Funny

    I had nothing to do with the creation of C either!

    1. Re:Hey, we have something in common! by 91degrees · · Score: 1

      Wuss!

      I had nothing to do with the creation of C, and didn't have an influence on Pascal, Perl, or the Linux Kernel. I was also not the first man to climb Everest.

    2. Re:Hey, we have something in common! by Anonymous Coward · · Score: 0

      I had nothing to do with the creation of your moms' mom!!!

      WooHoo!!
      PARTY!!!

  5. BWK by Anonymous Coward · · Score: 0, Interesting

    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.

    1. Re:BWK by JohnGrahamCumming · · Score: 4, Informative

      The book you are referring to:

      The Practice of Programming
      Kerningham and Pike
      Addison-Wesley, 1999

      is a classic text and it's very clearly written. The front cover sums up in three words the core philosophy of the entire book:

      Simplicity
      Clarity
      Generality

      It is a delight to read although it uses C/C++ as the example language everywhere and tends, therefore, to be a little C oriented, although there are examples in other languages.

      Much of the material will be familiar to people who've done a CS degree (e.g. trees, O-notation, etc.) but the section on testing is very worthwhile if you are planning to write code that will last a long time.

      John.

  6. If I were Brian... by stevens · · Score: 5, Funny

    ...and someone asked me about the wisdom of gets(), I'd also be pointing at Dennis Ritchie and yelling, "It was him! Burrrn him!"

    1. Re:If I were Brian... by Rogerborg · · Score: 2, Interesting

      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.
    2. Re:If I were Brian... by IamTheRealMike · · Score: 1
      Can you explain that?

      int foo, *bar; creates an integer named foo, and a pointer to an int named bar. Right? Or am I wrong?

      What do you mean by the order of type modifiers? Can you give an example?

      What I like is the way you can declare a variable const (ie, it's not constant and should not change) yet still assign to it and get away with merely a compiler warning.

    3. Re:If I were Brian... by syle · · Score: 1
      I give up, what does that do? I would assume at a glance that it's equivalent to:

      int foo;
      int *bar;

      But I guess that's not right. What is it?

      --

      /syle

    4. Re:If I were Brian... by thogard · · Score: 3, Informative

      The 1st gets was based on a
      while(*buf++=getchar())
      type of loop
      Once the preprocessor got more goodies, and STDIO was cleaned up, it became:
      #define gets(x) fgets(x,BUFSIZ,stdin)
      So in the days when there were only 100 or so Unix sites you could declare strings with
      char buf[BUFSIZ];
      and you couldn't overflow it.

    5. Re:If I were Brian... by Anonymous Coward · · Score: 0

      int foo, *bar;

      foo is an integer, *bar is an integer. Therefore bar is of type int *.

      I'll occasionally do that in C++ just to scare people.

    6. Re:If I were Brian... by AlecC · · Score: 4, Interesting

      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.
    7. Re:If I were Brian... by ajs · · Score: 4, Interesting
      You are exactly correct, and I have no idea what the original poster's problem with it was.
      [ajs@put /tmp]$ cat > /tmp/c.c
      #include <stdio.h>
      void
      main(int argc, char *argv[]) {
      int i, *j;
      i = 1;
      *j = 2;
      printf("i=%d, j=%d\n", i, *j);
      exit(0);
      }
      [ajs@put /tmp]$ gcc -o /tmp/c-test /tmp/c.c
      /tmp/c.c: In function `main':
      /tmp/c.c:3: warning: return type of `main' is not `int'
      [ajs@put /tmp]$ /tmp/c-test
      i=1, j=2
      Perhaps he was thinking of "int *i, j" which isn't all that bad in terms of confusion until you started seeing stroustrup's style, which I *hated* from day one of, "int* i" which of course lead to people using, "int* i, j".

      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!
    8. Re:If I were Brian... by Anonymous Coward · · Score: 0

      Whats wrong with that? An integer foo and a pointer to an integer, bar. If you must, pronounce * "pointer" and you have no problem, "int foo, int pointer bar"

      Your argument may have been better served with the example

      int *bar, foo;

      Or the evil

      int * bar, foo;

      Anyone doing that last one should have their fingernails removed with a pair of redhot needlenosed pliars.

    9. Re:If I were Brian... by rot26 · · Score: 2, Interesting
      int foo, *bar, flash, *bang, up, *down, left, *right; Without reading the line again, what was the type of "up"?


      I'm not disagreeing with your point, but the acceptable (if not great) solution is to choose your variable names more wisely.
      int Foo, *pBar, Flash, *pBang, Up, *pDown, etc;
      --



      To ensure perfect aim, shoot first and call whatever you hit the target
    10. Re:If I were Brian... by Anonymous Coward · · Score: 0

      Don't blame the old sages for "enum". That's a modern ANSI-ism.

    11. Re:If I were Brian... by parc · · Score: 2, Insightful

      So yeah, where'd that 2 come from? I'm amused that it actually worked, since you define a pointer, then assign to the dereference of it, which is god-only-knows where.

      And void main is deprecated. Don't use it. gcc is nice enough to warn you.

    12. Re:If I were Brian... by syle · · Score: 1
      I really don't see the problem with that. Maybe it's just because I've been using C long enough that reading it is second nature, but I don't recall it ever being confusing to me.

      If you were talking about int* a, b then you may have a point.

      If that sort of thing is really a problem for you, you could use hungarian notation (or some variation on it). For me, it's more of a hassle for me than a help, though.

      --

      /syle

    13. Re:If I were Brian... by mccalli · · Score: 1
      I find even worse the C++ idiom of:

      char* x, y

      This style is explicitly encouraged in the Stroustrup book. Now, what type is y? Easy because you're looking out for something, but in the middle of maintaining strange code it's easy to miss.

      Cheers,
      Ian

    14. Re:If I were Brian... by edwdig · · Score: 2, Troll

      The problem isn't:

      int foo, *bar;

      The problem is when the C++ people come and insist you put the * by the type instead of by the variable.

      int* foo, bar;

      That line confuses the hell out of people learning the language. foo is a pointer, bar isn't. That's the big reason I always insist on putting the * by the variable name rather than by the type.

    15. Re:If I were Brian... by connsmythe96 · · Score: 2, Interesting

      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);
    16. Re:If I were Brian... by BlueWonder · · Score: 2, Informative
      Huh, I consider gets to be a minor (!) snafu compared to the vile mind poison of:
      int foo, *bar;

      Why? It is perfectly possible to write a C program that contains int foo, *bar; and performs correctly for all inputs. The same is not true for a C program that calls gets.

    17. Re:If I were Brian... by connsmythe96 · · Score: 1

      Oh, and you can always just declare an enum without values. It'll default to 0,1,2,...

      --
      if(!cool) exit(-1);
    18. Re:If I were Brian... by muffel · · Score: 3, Interesting
      int Foo, *pBar, Flash, *pBang, Up, *pDown, etc;
      yuk. I can only agree with what Linux says in "CodingStyle":
      C is a Spartan language, and so should your naming be. Unlike Modula-2 and Pascal programmers, C programmers do not use cute names like ThisVariableIsATemporaryCounter. A C programmer would call that variable "tmp", which is much easier to write, and not the least more difficult to understand.
      [...]
      Encoding the type of a function into the name (so-called Hungarian notation) is brain damaged - the compiler knows the types anyway and can check those, and it only confuses the programmer. No wonder MicroSoft makes buggy programs.
      --

      bla
    19. Re:If I were Brian... by muffel · · Score: 1

      That was of course Linus, not Linux.

      --

      bla
    20. Re:If I were Brian... by fitten · · Score: 1

      The example you are probably looking for is:

      Given:

      int* i,j;

      Question: What are the types of i and j?

      Answer: i is a pointer to an integer and j is an integer;

    21. Re:If I were Brian... by smittyoneeach · · Score: 3, Insightful

      Yeah, but the variable is just a label. The actual type in question is either int or int*.
      However, you example clearly shows where 'the C++ way' (and I'm one of these who got into coding after C++ was fairly standardized, and so never have done any 'real' C) is not the preferred answer.
      The preferred answer is: knowledge.

      --
      Get thee glass eyes, and, like a scurvy politician, seem to see things thou dost not.--King Lear
    22. Re:If I were Brian... by Anonymous Coward · · Score: 0

      Question: What are the types of i and j?

      Rookie: j is a pointer..no wait, an integeraaaagghhhh!

    23. Re:If I were Brian... by Chad+Page · · Score: 1

      The other thing about C++ is that most of the sensible concepts in it can be done in regular C anyway. And are - look at the Linux kernel a bit - there are some OO-in-C concepts in there.

      Probably even some of the stuff that makes my brain hurt, but it would probably make for ugly code anyway ;)

    24. Re:If I were Brian... by curtoid · · Score: 0, Redundant

      int foo, *bar; creates an integer named foo, and a pointer to an int named bar. Right? Or am I wrong?

      Wrong. :-8

      foo is an int.

      *bar is an int.

    25. Re:If I were Brian... by Anonymous Coward · · Score: 0
      C is a Spartan language, and so should your naming be. Unlike Modula-2 and Pascal programmers, C programmers do not use cute names like ThisVariableIsATemporaryCounter. A C programmer would call that variable "tmp", which is much easier to write, and not the least more difficult to understand.
      Sadly, a C programmer would also call "NotionalAtIntroductionIssueCurrency" nic, which is much harder to understand, and then wonder why his software was producing the wrong profit/loss. And, with a decent editor, "ThisVariableIsATemporaryCounter" takes 4 keystrokes (T - h - CTRL-SPACE - TAB), so you save 1 keystroke by using silly short names.

      Hungarian notation comes into its own with autocomplete...type "cmb CTRL-SPACE" and all your ComboBoxes are there.

      Not using these modern features of editors is brain damaged - they're there to help, this isn't 1960 any more. Using overcontracted variable names only confuses the maintainer. No wonder OSS turns out so much buggy code...
    26. Re:If I were Brian... by notfancy · · Score: 1

      int foo, *bar, flash, *bang, up, *down, left, *right;

      Without reading the line again, what was the type of "up"?

      From a linguistic point of view, the problem is that type modifiers are adverbs that modify nouns (the variable declarators) instead of adjectives (the type name) as in every spoken language of the Indoeuropean family. It's a bit like saying "I've bought big oranges and very bananas". C declarators are not intuitive from a natural-language point of view.

    27. Re:If I were Brian... by Zathrus · · Score: 1

      troustrup's style, which I *hated* from day one of, "int* i" which of course lead to people using, "int* i, j".

      Only because those people were idiots, they didn't actually understand what the hell they were declaring, and they were using bad style to perpetuate the previous two issues.

      Not bad style as in "int* i", but bad style as in declaring multiple variables on one line. It's a complete non-issue if you declare each variable on it's own line. It also makes the code far more readable, and makes types much more obvious (esp. if you use Stroustrup's style -- since the type of the variable is not "int", it's "int*" -- the two are different and you intermix them at your own peril). I think a lot of people would like to do away with the godawful C syntax of type var1, var2, var3; -- because of reasons you mention. It just leads to obfusication and bad practices. It was retained in C++ only because of backwards compatibility.

      BTW, your code is bugged since you assign a value to *j without allocating memory to it. That will crash you on some platforms or in some compile modes. As well it should.

    28. Re:If I were Brian... by Zan+Zu+from+Eridu · · Score: 5, Insightful
      So what is wrong with:

      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.

    29. Re:If I were Brian... by notfancy · · Score: 1

      Argh... Linux is evil. It should bus error with that program. Also, gcc is evil. It doesn't complain even when using -O3 -Wall.

      Hint: there is an uninitialized variable.

    30. Re:If I were Brian... by Anonymous Coward · · Score: 0

      typedef int* intptr;
      intptr i,j;

    31. Re:If I were Brian... by Geekboy(Wizard) · · Score: 1

      main is int, not void.

    32. Re:If I were Brian... by Urkki · · Score: 1
      Gets is a function which you can never use in a real program, because you can never use it safely, and you call it minor snafu?

      And then you say that C allowing stupid syntax is worse than a function like that?

      And besides, that's not a bad syntax... Try this one:
      int* bar,foo;

      And, like with everything like that, you don't do it. Unless you want to be mean to anybody who'll be looking at your code later, when you know you won't be. And if you want to be mean, you can certainly do a lot more obscure things to your code...

    33. Re:If I were Brian... by DunbarTheInept · · Score: 1

      His example doesn't properly illustrate the problem. the problem is when the first parameter is the pointer, as follows:
      int * foo, bar
      To the typical novice C programmer, that looks like it means "foo and bar are both of type 'int *', when in fact it means "foo is int *, while bar is just int" That is confusing. One thing I would have liked to have seen done differently is to use actual words for the different numerical formats. I'd rather see something like: hex$ff80 rather than 0xff80. This is especially annoying with octal. It is VERY counter-intuative that:
      010 == 8
      when it looks like "ten' with an irrelevant preceeding zero. This is bad because it conflicts with the mathematical meaning of prepending a zero, which is that it means nothing.

      And if they invented types for octal, and hex, why didn't they do binary while they were at it? that would have been quite useful and make some things a lot more legible.

      As far as assigning to const being just a warning, that sounds like something compiler-dependant. It really should be enforced more strongly than that.

      --

      Don't label something "offtopic" unless you know the topic well enough to tell what's on topic.

    34. Re:If I were Brian... by Urkki · · Score: 1

      Eh? Even -O is enough to get that warning about j (see below). And I don't see how Linux not giving a bus error (which, btw, is specific to non-intel processors, so if you're running it on intel machine you won't get one for badly aligned pointer) or segmentation fault. Contents of stack, where j is, is rather undefined, it could very well end up pointing to some positon where the program has write permission by luck...

      $ gcc -Wall -O c.c
      c.c:3: warning: return type of `main' is not `int'
      c.c: In function `main':
      c.c:4: warning: `j' might be used uninitialized in this function

    35. Re:If I were Brian... by DunbarTheInept · · Score: 2, Interesting

      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.

    36. Re:If I were Brian... by leviramsey · · Score: 1

      Note that Linus only refers to Hungarian notation in functions, not variables. I've seen people bash Hungarian function notation (where it's beyond stupid) and then use pVar and so forth all over their code.

    37. Re:If I were Brian... by PD · · Score: 2, Insightful

      Hungarian notation is evil, essentially because it doesn't help the compiler, and it hinders the human programmer. The chunks of letters between two spaces are called words, and if they correspond to words we already know, we recognise them faster. In so many places we've discovered that overloading meanings into a single coded word is a bad idea (think databases). It's no fun trying to decipher a database field that looks like "A45T9923OT" into a thing called "department A4 (paper size) palate T, 99th stack, page 23, Out of the warehouse, on the Truck. Similarly, the type and the name of a variable should be kept completely separate.

    38. Re:If I were Brian... by DunbarTheInept · · Score: 1

      Uhh. Sorry, no. VERY VERY bad. where is "*j"???
      It's at an address pointed to by random trash on the stack where the j variable was allocated.

      the line:
      *j = 2;
      Is going to sometimes segfault, sometimes not segfault, depending on what random trash was on the stack when 'j' was made.

      --

      Don't label something "offtopic" unless you know the topic well enough to tell what's on topic.

    39. Re:If I were Brian... by lars_stefan_axelsson · · Score: 1
      Perhaps he was thinking of "int *i, j" which isn't all that bad in terms of confusion until you started seeing stroustrup's style, which I *hated* from day one of, "int* i" which of course lead to people using, "int* i, j".

      Yeah, I never figured out why some people can't get it into their heads that variable declarations in C is an equivalence construct. "int *i" is supposed to be read as "typeof(int) == typeof(*i)". The type on the left is equal to the type of the expression to the right. Since '*' is a pointer deference and '*i' should be of type int, then 'i' can only be a pointer to said int.

      To write it "int* i" completely misses the point. That's akin to reading it "int pointer i", which won't work at all when more complex types are involved. Just plain wrong.

      It may be argued that this is a back asswards way of specifying types of variables (or typedefs) but that's the way it is. There is actually some method to the madness.

      --
      Stefan Axelsson
    40. Re:If I were Brian... by vsprintf · · Score: 0

      So yeah, where'd that 2 come from? I'm amused that it actually worked, since you define a pointer, then assign to the dereference of it, which is god-only-knows where.

      Say what? *j = 2; (In English, "the contents of j equals 2"). You could also look at it like the pointer j is being assigned the address where the literal 2 is stored. Where's the confusion?

    41. Re:If I were Brian... by IamTheRealMike · · Score: 1
      That's fine as far as it goes, but once you start using hungarian notation it's a slipperly slope and you end up with stuff like LPVOID in an attempt to remain consistant.

      Alternatively, how about parameter prototypes like "LPUNKOUTER ppv" - which is what, exactly? Well, I can tell you that's it's a pointer to an outer unknown - oh but wait, an Unknown is also just a pointer, hence the "ppv" bit - pointer to pointer to void, geddit? But what is the parameter actually for? Not a clue ;)

    42. Re:If I were Brian... by ajs · · Score: 1

      Heehee, kind of cool, as someone pointed out, that gcc just cleaned up my mess for me, there.

      Dumb me, I forgot to malloc.

      Still and all, you get the idea, and there's no flaw in the part of the code that I was attempting to test, so much as the use of the pointer (always my weak point in C, which is why I use high level languages now).

    43. Re:If I were Brian... by Anonymous Coward · · Score: 0

      I always comment the purpose of the variable at the top of the function, like:

      int nic; /* Notional At Introduction Issue Currency */

      then if someone wants to find out what nic means, they can just look it up.

    44. Re:If I were Brian... by Anonymous Coward · · Score: 1, Insightful

      The point was the code has a bug. Following fixes the bug.

      void
      main(int argc, char *argv[]) {
      int i, *j, k;
      i = 1;
      j = & k;
      *j = 2;
      printf("i=%d, j=%d\n", i, *j);
      exit(0);
      }

    45. Re:If I were Brian... by ajs · · Score: 2, Informative

      He was pointing out (rightly so) my lack of malloc. I was assigning to empty space.

    46. Re:If I were Brian... by James+Lanfear · · Score: 2, Insightful

      You could also look at it like the pointer j is being assigned the address where the literal 2 is stored.

      No, you couldn't. *j dereferences an uninitialized pointer, which plunges the program into the dark realm of undefined behavior. If j accidentally happened to hold a valid value, and if the compiler saw fit to actually store a 2 somewhere that could be pointed to, then maybe it would appear to work, but you may as well be relying of cosmic rays to flip bits for you.

      Do youself a favor a pick up a copy of the standard, or a book, or anything.

    47. Re:If I were Brian... by jericho4.0 · · Score: 1

      Yes, Hungarian sucks, but using a 'p' prefix to indicate a pointer is not Hungarian, but good practice. It will save you much effort when writing C.

      --
      "A language that doesn't affect the way you think about programming, is not worth knowing" - Alan Perlis
    48. Re:If I were Brian... by Ed+Avis · · Score: 1
      int foo, *bar;

      It does make some sense, in a warped kind of way.

      foo is an int.

      *bar is an int. Therefore, bar must be a pointer to int.

      You have to kind of work backwards from the type of *bar to the type of bar. This was considered a feature because the type declaration mirrors the use, however it gets really unwieldy once you start having more complex types like function pointers.

      Bjarne Stroustrup has said he considers the C++ declarator syntax an experiment that failed. Of course, in C++ it's even worse since you have the extra & modifier to indicate a reference, which doesn't really fit (since 'char &c' might be read by a C programmer as 'the address of c is a char' - WTF?).
      --
      -- Ed Avis ed@membled.com
    49. Re:If I were Brian... by AJWM · · Score: 1

      and a pointer to an int named bar.

      Well, for one thing, that's not a pointer to an int named bar, that's a pointer named bar to an (as yet unspecified) int.

      (And on that pedantic note, /me exits hastily.)

      --
      -- Alastair
    50. Re:If I were Brian... by Anonymous Coward · · Score: 0

      Or maybe we could have the compiler make any variable that starts with a 'p' be a pointer, so you don't need two characters to specify it.

    51. Re:If I were Brian... by clem.dickey · · Score: 1

      My favorite change to C would be to make "variables" const by default. This implies that any declaration which did not include an initializer would have to be tagged as "var".

      int foo = g(); /* OK */
      int bar; /* useless */
      var int baz; /* OK, we can assign to this */

    52. Re:If I were Brian... by Ed+Avis · · Score: 2, Insightful

      The C++ people have some justification for putting the * next to the type name, because of C++'s references.

      string &x;

      &x is a string? Huh? How can the address of x be a string? Of course & does not really mean address-of in the above line, it means a reference to the type.

      string& x;
      string* x;

      Not great, and pretty bad when you have multiple declarations on the same line, but probably better. Stroustrup gives his reasons for preferring this second style.

      --
      -- Ed Avis ed@membled.com
    53. Re:If I were Brian... by Anonymous Coward · · Score: 0

      The variable j stores a memory location. The stupid programming example above says to take whatever memory address j is storing, and assign a value of 2 to it.

      So, you're wrong, and the programming example is bad.

    54. Re:If I were Brian... by ajs · · Score: 1

      Yes, as you note there's a bug in the example. Rushed slashdot posts, go figure.

      Still, I disagree with this notion that you present (and every Strostrup appologist I've ever heard tackle this one has presented). Think back, and imagine that these are the days when no one had heard of C++ yet, and C was it.

      Back then, there was no ambiguity. Every book ever written was of the form: int i, *j, k[200]; and everyone got exactly what that meant and why. It was good, common and expected programming practice to declare a set of variables of similar basic type that way as long as declaring them together wasn't semantically misleading to someone who would read the code.

      Only in the face of Dr. Bjorn's evil char* s did people start to think that declaring multiple variables on a line was somehow evil (circa 1990 is when I first heard that claim).

      So, it was in fact horrible form for an author to write code like that. There was nothing wrong with the way C worked, nor the way C++ would have worked, had he not conventionalized that broken usage.

      When I program in C++, I keep the asterisk with the variable name, because that's how the compiler sees it, and any other usage would be misleading.

    55. Re:If I were Brian... by jericho4.0 · · Score: 1

      Hmmm. Good point, but the solution is to have the comiler impose a naming convention, which no C porgrammer is going to swallow.

      --
      "A language that doesn't affect the way you think about programming, is not worth knowing" - Alan Perlis
    56. Re:If I were Brian... by vsprintf · · Score: 1

      Never mind, I finally got it. I was thinking of something like:

      char *msg = "default message\n";

    57. Re:If I were Brian... by AJWM · · Score: 1

      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.

      Sounds like you're using enum where you should be using const, in that case. In a true enumeration (think Pascal or Ada) you should neither know nor care what the internal representation is. Consider something like typdef enum {red, yellow, green, blue} color; why do you give a rat's ass whether 'yellow' was stored internally as 1, 2, 27 or even "yellow" ?

      If you want to use symbolic constants that the compiler recognizes and can typecheck (instead of #defines in the preprocesser), then use them: const int fred=36; and so on. And pay attention to the compiler warning (which really ought to be an error).

      --
      -- Alastair
    58. Re:If I were Brian... by Anonymous Coward · · Score: 1

      however, I consider

      int*

      as a type and the variable name say, "foo" as just that, a name. putting some functionality in the name is rediculous to me.

      saying "int *pFoo" could be interpreted (to a human) as saying misleading things about the type of variable. the variable isn't of a type "int" is is of a type "pointer to int". Consider int* as a return type. you surely don't say int as a return type when you want ant int*

      but in any case, you are right in saying that something like

      int* foo, bar, *bla, merf;

      is misleading altogether. even if you stick to all of the same type on the line, in this case int*.

      int* foo, *bar, *bla, *merf;

      i consider bad style. just make it easy and place them all on separate lines.

    59. Re:If I were Brian... by notfancy · · Score: 1

      You're absolutely right about the bus error. Twelve years of Macintosh-centrism (first 680x0's, then PowerPC's) have conditioned me to align, align, align.

      However, look at this:

      [puma:~/Desktop] mgiovann% gcc -Wall -O c.c
      c.c:4: warning: return type of `main' is not `int'
      c.c: In function `main':
      c.c:9: warning: implicit declaration of function `exit'
      [puma:~/Desktop] mgiovann% gcc --version
      gcc (GCC) 3.1 20020420 (prerelease)
      Copyright (C) 2002 Free Software Foundation, Inc.
      This is free software; see the source for copying conditions. There is NO
      warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

      What am I missing?

    60. Re:If I were Brian... by Arandir · · Score: 1

      This is why I ALWAYS put the type modifier next to the variable name. I do this for pointers and references.

      And yet another reason I prefer string types as opposed to char arrays. When people see a "char*" they think "string", when they should always think "pointer to character". If I can help I never use char* for strings, but use STL string or something else, instead.

      --
      A Government Is a Body of People, Usually Notably Ungoverned
    61. Re:If I were Brian... by Urkki · · Score: 1

      Well, the gcc I used was trusty old 2.95 something. Maybe your gcc installation is botched, or maybe that particular 3.1 prerelease is just buggy... Or doesn't implement -O ;)

    62. Re:If I were Brian... by serial+frame · · Score: 1

      Under Mac OS X, you need to include stdlib.h in order for the preprocessor to see exit(3).

      --

      -
      And the Angel said unto me, "These are the cries of the carrots! The cries of the carrots!"
    63. Re:If I were Brian... by connsmythe96 · · Score: 1

      Yes, but if you use the following:
      typedef blah int; const blah VAL_1=1; const blah VAL_2=2; blah val; val=3; the compiler probably won't tell you a thing (at least the ones I've used haven't). val is an int, and 3 is an int, so it's valid. However, with a modern C++ compiler (not sure about C, but maybe so with that too) this code will generate at least a warning: enum blah {VAL_1=1, VAL_2}; blah val; val=3;
      That code works the same in the output program as defining constants would have, but it's easier to write, easier to read (you can clearly see that those values belong to the blah type and are valid only for variables of that type), and it has the added benefit of compile-time type-checking.

      If you want strictly enforced enums you could always implement a class for that with the same overhead you talked about before. It would take a few minutes at most. Of course you couldn't do that very easily in C, so I can see how it might annoy you that there's no easy way to use strictly-enforced enums in that language. But I do like the implementation in C++.

      --
      if(!cool) exit(-1);
    64. Re:If I were Brian... by Anonymous Coward · · Score: 0

      Some warnings require that you use optimization.
      (control flow analysis... see gcc documentation for further info).

      K.R

    65. Re:If I were Brian... by connsmythe96 · · Score: 1

      Damnit, it stripped out my code tags...sorry about that...apparently i was supposed to use ecode...should've rtfm (right below the post comment form...)

      --
      if(!cool) exit(-1);
    66. Re:If I were Brian... by swillden · · Score: 1

      I was assigning to empty space.

      If only that were true...

      --
      Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
    67. Re:If I were Brian... by Anonymous Coward · · Score: 0

      So is it int* bar, or int *bar? Where does the * go, next to the type or next to the variable?

      Hmmmm....

    68. Re:If I were Brian... by ajs · · Score: 1

      Sorry, I meant "empty" in the sense of "undefined".

      As you can see, I've sent too much time in high-level languages like Perl, where the two states can be distinguished, but are interchangable without error.

    69. Re:If I were Brian... by iabervon · · Score: 1

      What tends to bother me is that, to add another variable of the same type to a line declaring a number of variables which are the same type, you need to add the right number of *s before the new name.

      The standard syntax states that you're declaring two integers, "a" and "*b" (which implies that "b" is a pointer to a int). Of course, you're not actually declaring the int that b points to, so the syntax is misleading, and leads to people failing to initialize their pointers correctly, because a line that starts "struct foo" may or may not create a struct foo, depending on whether the variable has a star. Personally, I'd prefer:

      &int b;

      That is, declare b to be the address of an int, which is a somewhat more accurate description of what's going on.

      In any case, it's far too late to correct this.

    70. Re:If I were Brian... by fucksl4shd0t · · Score: 1

      int Foo, *pBar, Flash, *pBang, Up, *pDown, etc;

      yuk. I can only agree with what Linux says in "CodingStyle":

      I have to say that I agree/disagree with you. :) I like having certain basic types, in some languages, as part of the variable name. VBScript, for example, and javascript. Languages that have no firm type. Also, with C/C++, if I know I'm going to extern a variable, I stick the type on the name just so I don't have to keep opening source files to find out. But only basic types, and pointers. I disagree completely with doing this for functions, simply because (in C++ anyway) it totally fucks up as soon as you start overloading functions. Now it's not the same type anymore, but does the same thing, with the same name, with different args. For short-term temporary variables, I tend to either revert to the old single-letter names of the old school, or I prepend tmp to the variable name.

      Other than that, I figure if the block of code is really long, I'm doing something wrong. But you should have to browse back to the variable declaration from time to time to check things because it gives you an opportunity to look at the other variables used and will raise questions, especially when you're having problems. I've found numerous problems just because I was scanning the variable declarations trying to figure out what type the variable I was working with was, but noticing other variables and saying "What the fuck is that one there for?", tracking it down, and finding the bug.

      On the other hand, it's extremely readable to look at an if() statement and see what the basic types are, and see if you're using pointers in there.

      --
      Like what I said? You might like my music
    71. Re:If I were Brian... by swillden · · Score: 1

      It was good, common and expected programming practice to declare a set of variables of similar basic type that way as long as declaring them together wasn't semantically misleading to someone who would read the code.

      "Semantically misleading" depends on whether you view the '*' as part of the type or part of the variable. Personally I think "foo is a pointer-to-int" is more meaningful, easier to think about and clearer than "foo-pointer is an int". Or should that be "pointer foo is an int"? There's really not a good way to say it.

      Of course, you can think about it and say it one way and still write code that states it the other way, but I greatly prefer the syntax that reads more naturally, even though it means that I need a few more lines for variable declarations.

      Also, I think you're giving Stroustrup too much credit. His book may have been the first place you saw this declaration style, but it was common well before he published his text. IIRC, there were several debates around this issue on comp.lang.c as early as the mid 80s.

      While I'm disagreeing with you, I might as well point out that I like C++. In fact, it's by far my favorite mainstream programming language, giving me the expressiveness of a very high-level OO language *and* close-to-the-metal control. It's a large, complex language, true, but that doesn't really matter since I've already learned it quite thoroughly. It's not a good choice for a project that has a lot of novice developers, but given a good team, C++ really rocks for a really wide range of applications and systems programming tasks. I got away from C++ for a couple of years and thought I was reconsidering my position on the language, but I recently had an opportunity to spend a few solid months writing C++ code and within a couple of weeks I realized that I felt like I had been freed from the straightjacket of C's limited expressiveness and the constant low-level irritations and poor performance of Java.

      --
      Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
    72. Re:If I were Brian... by swillden · · Score: 1

      GPL uses "free" the same way Iraq used democracy. You are fee to use the code as long as you do it "our" way.

      Only if every Iraqi chose to live in Iraq and was allowed to leave at any time.

      --
      Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
    73. Re:If I were Brian... by Darby · · Score: 1

      you may as well be relying of cosmic rays to flip bits for you.

      You mean there's another way?

    74. Re:If I were Brian... by Ruds · · Score: 1

      mmm, how Fortran-ish. What about variable names like "paintColor" or "prefs"?

      Matt

    75. Re:If I were Brian... by pyrrho · · Score: 1

      up in an int.

      "*down" is also an int.

      I'm sure you are aware that there are trivial habits to avoid this sort of confusion... so I assume you think a software engineer needs to be forced from swimming in a swamp.

      Personally I never tried to do that even when I first learned C, I always did:

      int this,that, other;

      int *pThis, *pThat, *pOther;

      Why on earth I would need the compiler/language to force me into this habit is beyond me, especially when C allows other ways to avoid this. It's like people want a paint brush designed such that it won't allow me to paint my house neon gree. I think I can handle that on my own thank you... and I just might want to do it!

      --

      -pyrrho

    76. Re:If I were Brian... by pyrrho · · Score: 1

      >Just because a language allows a construct doesn't mean you have to use it.

      excellent point. In fact, it's The Point. C and espc. C++ are toolboxes. "But this box has a hammer and I want to screw something in? Why is there a hammer in there?" Or worse, I will screw this in by placing the screwdriver in the screw head, and banging the screwdriver with the hammer! Why doesn't this work?"

      ug. I very much enjoyed your phrasing about C not being about bondage and discipline.

      --

      -pyrrho

    77. Re:If I were Brian... by pfafrich · · Score: 1

      Hang on, this program might crash. j is a pointer, but it has not been initalised. You should assume that its going to take a random value. Hence *j = 2; is setting some random memory location to 2. Bang!

      I've no real problem with the pointer syntax. Yes pointers can fry your head, but thats not the syntax's fault, its just what you get with a language which lets you work close to the memory.

      Enums with constant, non sequential values. A good feature, with useful applications. Consider this example from a maths parser.

      enum ops { add = '+', sub='-', mul='*', div='/' }
      or maybe an enum to handle ascii character input.
      --
      There are four sorts of people in the world: fools, lunatics, idiots and morons. - Umberto Eco, Foucaut's pendulum.
    78. Re:If I were Brian... by AJWM · · Score: 1

      the compiler probably won't tell you a thing

      Well, you can't blame the compiler for not catching what you meant if that's not what you wrote.

      GCC 3.2 (what I'm currently running) will give you a warning for assigning to a const, and an error for assigning to an enum literal. G++ gives an error for both.

      Need to upgrade your compiler?

      --
      -- Alastair
    79. Re:If I were Brian... by Xtifr · · Score: 1
      Yeah, but the variable is just a label. The actual type in question is either int or int*.

      True, but you can look at it another way (and I prefer to, because it makes things more consistent). If you have:
      int *foo, bar;
      then you've declared "*foo" is an int, which implies that "foo" is a pointer to int.

      I also always use "int const" rather than "const int", because I think it's more consistent. So, obviously I'm a bit obsessive about some of this stuff. :)
    80. Re:If I were Brian... by pyrrho · · Score: 1

      hungarian notation is overkill... but pWhatever is quite a good idea.

      --

      -pyrrho

    81. Re:If I were Brian... by connsmythe96 · · Score: 1

      I think you misunderstood the code. Maybe it was the formatting screwup that confused you. I didn't assign to a const. I assigned a const literal to a value that was of type "blah", which was defined as an int. The compiler will not say anything about that because it's completely valid code. But in that case what I wanted to do was use blah as a type that holds only one of those values I defined (VAL_1 or VAL_2). So instead of using a typedef and some consts, I use an enum. If you try to assign a const literal to a value that's been declared as of type "enum blah" then the compiler should issue a warning.

      --
      if(!cool) exit(-1);
    82. Re:If I were Brian... by jidar · · Score: 1

      blah, you're just arguing things that are preference based. That has nothing to do with the screw up that is gets() AKA overflows-R-us

      --
      Sigs are awesome huh?
    83. Re:If I were Brian... by vsprintf · · Score: 1

      Hah. And you couldn't spot it for the clever C troll it was. (I wish. :) I'll just go don my hair shirt and wait for the tar, feathers, and the lynch mob to arrive. I hope K&R aren't in it, although they would have good reason.

    84. Re:If I were Brian... by Zan+Zu+from+Eridu · · Score: 1
      I very much enjoyed your phrasing about C not being about bondage and discipline.

      I can't take the credit for that, it's hacker slang. If you don't know the jargon file yet, click the Home link on that page and enjoy. There are lots of awesome and/or funny annectotes in it too, like the story of Mel.

    85. Re:If I were Brian... by miu · · Score: 1
      g_foo means "global foo", and s_foo means "local stack foo", and h_foo means "heap foo"

      In my experience s_foo more commonly is used to indicate 'static' than stack. g_foo is probably not enough label for a global in programs with more than 2 or 3 source files.

      The case where I find a type descriptive name to be important is if I have to use a reinterpret_cast to treat a chunk of raw memory as a pointer to a non-opaque type. I think most uses of 'hungarian style' conventions that encode type information are worthless or misleading.

      --

      [Set Cain on fire and steal his lute.]
    86. Re:If I were Brian... by Punto · · Score: 1
      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.

      No you don't. "foo" is an int, and "*bar" is also an int. The difference is that you can also use 'bar', but if you pretend that's the same as *bar, you're just not paying attention to the declaration.. There would be no difference in complaining about &foo, or even worse, &bar.

      --

      --
      Stay tuned for some shock and awe coming right up after this messages!

    87. Re:If I were Brian... by MrResistor · · Score: 1

      "Semantically misleading" depends on whether you view the '*' as part of the type or part of the variable. Personally I think "foo is a pointer-to-int" is more meaningful, easier to think about and clearer than "foo-pointer is an int". Or should that be "pointer foo is an int"? There's really not a good way to say it.

      "foo points to an int" works well for me.

      The * is NOT part of the type. If it was, int* i, j; would give you 2 pointers, not a pointer and an int. Since it only applies to one of the variables it has to be part of the variable.

      That said, I like C++ also, although I can't say that I know any language well enough to really have a preference.

      --
      Under capitalism man exploits man. Under communism it's the other way around.
    88. Re:If I were Brian... by scotch · · Score: 1

      You haven't declared "' "*foo" is an int'; that would imply you're declaring the space/name for an int but you're not - you're only declaring a pointer variable. But if it helps you keep things straight, it's probably a mostly-harmless way to think about it.

      --
      XML causes global warming.
    89. Re:If I were Brian... by scotch · · Score: 1
      This is a wrong interpretation, imo:

      foo declares/defines the storage for an int. "*bar" does not define/declare storage for an int. The storage you have defined is for a variable of type "int*".

      --
      XML causes global warming.
    90. Re:If I were Brian... by scotch · · Score: 1

      I think what is meant (and correct) is "that's a (pointer to an int) named bar", which is equivalent to the way you wrote it.

      --
      XML causes global warming.
    91. Re:If I were Brian... by scotch · · Score: 1
      Not true. "*bar" is not necessarily an int. It could point to non-int garbage (if uninitialized) or if bar is 0, then obviouly "*bar" can't possibly be an int. This second problem most clearly shows why this line of thinking ("*bar is an int") is wrong. C/C++ are still low level languagues. Variable definitions reserve space: "int *bar" does not reserve space for "*bar", it reserves space for the pointer bar, which the compiler does type checking on to make sure you use it to point to int storage.

      As far as the "char & c" being misread, the C programmer and others should know that & and other operators are overloaded both in C and C++. Knowlege solves the problem.

      --
      XML causes global warming.
    92. Re:If I were Brian... by smittyoneeach · · Score: 1

      Some serious hedz agree with you here
      Won't kill you with detail here, but on pg.4 they demonstrate that int const turns out to be a cleaner approach in the presence of typedef.

      --
      Get thee glass eyes, and, like a scurvy politician, seem to see things thou dost not.--King Lear
    93. Re:If I were Brian... by swillden · · Score: 1

      If it was, int* i, j; would give you 2 pointers, not a pointer and an int. Since it only applies to one of the variables it has to be part of the variable.

      Yes, C's declaration syntax gives you the choice between:

      • Thinking about i and j as the same "type", but one of them a pointer and one of them a value, which is confusing, not least because it's *not* how the compiler really sees it (potentially different storage sizes, not necessarily safely assignable, very different semantics).
      • Error-prone declarations.

      Since the latter is easy to avoid (don't use multiple declarations), I see it as the lesser of two evils. Some people prefer to use typedefs and avoid the whole issue, but that leads to abominations like LPVOID... <shudder>

      I can't say that I know any language well enough to really have a preference.

      You're kidding, right? This is SLASHDOT, man! Here you're qualified to have a preference, nay, a considered expert opinion, about *anything*!

      --
      Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
    94. Re:If I were Brian... by Bush+Pig · · Score: 1

      Just because you _can_ do somehting like:
      int foo, *bar;
      doesn't mean you _should_. You only need a little bit of self-discipline to produce this instead:
      int foo; /* holds the value of foo */
      int *bar; /* pointer to bar */
      And yes, the comments are fatuous in this instance, but in a real bit of code they'd mean something.

      --
      What a long, strange trip it's been.
    95. Re:If I were Brian... by Bush+Pig · · Score: 1

      main is only int if:
      a. you specify int main(); or
      b. you don't specify anything.
      IIRC, it's quite ok to use:
      void main()

      --
      What a long, strange trip it's been.
    96. Re:If I were Brian... by Rogerborg · · Score: 1

      int const isn't obsessive, it's correct. const int is training wheels. I have worked with engineers who never took the wheels off, and who have real trouble understanding:

      int const * const

      or who don't realise that it's the same as:

      const int * const

      simply because they're never learned to read (or write) right to left. That said, it would have made more sense to have the typing apply left to right, but it doesn't, and we're stuck with that, so it makes little sense to pretend otherwise.

      --
      If you were blocking sigs, you wouldn't have to read this.
    97. Re:If I were Brian... by Rogerborg · · Score: 1

      > This is why I ALWAYS put the type modifier next to the variable name. I do this for pointers and references.

      Shame you can't declare a constant pointer then.

      --
      If you were blocking sigs, you wouldn't have to read this.
    98. Re:If I were Brian... by Rogerborg · · Score: 1

      >What do you mean by the order of type modifiers? Can you give an example?

      If you read right to left when translating an English description into a declaration, you won't go far wrong.

      Examples: pointer to constant int. Just read right to left. int, constant, pointer, so "int const *". The trick is that the compiler will associate any leading (left hand) modifier with the first type encountered, so you can also write "const int *". It's pure syntactic sugar, but it causes confusion with complex types.

      Try it yourself. Pointer to constant pointer to int? Constant pointer to pointer to constant int? Constant pointer to constant pointer to constant int? Throw some volatile, unsigned, or C++ references in there as well for extra fun.

      It's not that hard, really, but it's usually so badly learned that it takes an effort to persuade C coders to use const enough. Everything should be const unless there's a reason otherwise.

      Type modifiers are also the reason why * or & modifiers belong with neither the variable name or the basic type. If you rely on syntactic sugar, you can usually get away with putting them with the basic type, but if you insist on, e.g. "int *foo;", then how are you going to make that a constant pointer?

      --
      If you were blocking sigs, you wouldn't have to read this.
    99. Re:If I were Brian... by Rogerborg · · Score: 1

      So what is wrong with:
      int *bar;

      Make that a constant pointer. Let the hand waving commence.

      --
      If you were blocking sigs, you wouldn't have to read this.
    100. Re:If I were Brian... by Rogerborg · · Score: 1

      That's the big reason I always insist on putting the * by the variable name rather than by the type.

      What have you got against declaring constant pointers? Is it so very hard to just use "int * foo;" and not introduce conventions that discourage writing robust code?

      --
      If you were blocking sigs, you wouldn't have to read this.
    101. Re:If I were Brian... by Rogerborg · · Score: 1

      Actually, I've just noticed that you're not at all obsessive. If you use "int *foo;", then you preclude using constant pointers. Obsessing over which particular brand of unnecessary syntactic sugar to use isn't helpful if it discourages you from writing robust code.

      --
      If you were blocking sigs, you wouldn't have to read this.
    102. Re:If I were Brian... by Rogerborg · · Score: 1
      Grandparent is correct, two distinct types are "created."

      struct { int member1; int member2; } foo, *bar;

      How many structs are "created" by this declaration?

      --
      If you were blocking sigs, you wouldn't have to read this.
    103. Re:If I were Brian... by Rogerborg · · Score: 1

      Don't go slagging off C++ syntax until you first learn to program robustly in C, which involves using const, which precludes using "*bar" although (unfortunately) not "int*" because of syntactic sugar.

      The correct declaration in either language is, and always has been:

      int foo;
      int * bar;

      No? Make bar a constant pointer using "*bar" then get back to me.

      --
      If you were blocking sigs, you wouldn't have to read this.
    104. Re:If I were Brian... by Zan+Zu+from+Eridu · · Score: 1
      int * const bar; I think I don't understand what you're trying to say here.

      Is it about declaring pointers to constants? Then you've got two options: const int *bar; or int const *bar; These declarations are completely equivalent, so which one you use comes down to personal preference or your employer's coding style guidelines. Starting discussions about which one is better is a rathole.

      As long as you keep one variable declaration per line, nothing will go wrong. But again, I think I don't understand the point you're trying to make.

    105. Re:If I were Brian... by Rogerborg · · Score: 1

      You asked what's wrong with "int *bar;". What's wrong with it is simply that getting into the habit of using "*bar" discourages the use of const. Just that, and no more. It's easy to get into good habits if you don't pick up bad ones to begin with.

      --
      If you were blocking sigs, you wouldn't have to read this.
    106. Re:If I were Brian... by Zan+Zu+from+Eridu · · Score: 1

      Ah, ok. It's my policy to not argue about coding styles, so I won't ;) I've lost way too much time going down that rathole.

    107. Re:If I were Brian... by Ed+Avis · · Score: 1

      Sorry, what I meant was that the type of the expression *bar is int.

      --
      -- Ed Avis ed@membled.com
    108. Re:If I were Brian... by Ed+Avis · · Score: 1

      I am not slagging off C++ syntax, I am explaining the rationale for C's declarator syntax. But the original rationale doesn't work so well once you add C++'s reference to the mix, or 'const' as you point out. K&R C did not have either (AFAIK) so the declarator syntax back then still had some logic to it.

      The question of where to put spaces is not really an issue of language syntax.

      --
      -- Ed Avis ed@membled.com
    109. Re:If I were Brian... by Geekboy(Wizard) · · Score: 1

      The OS* expects main to be int. If you don't want any command line arguments, then you use `int main(void)`.

      [*] I mean POSIX/Unix-like OSs.

    110. Re:If I were Brian... by Punto · · Score: 1
      Grandparent is correct, two distinct types are "created."

      struct { int member1; int member2; } foo, *bar;

      How many structs are "created" by this declaration?

      Of course, but we are not talking about memory allocation.. We're talking about a visual asociation with the declaration.. The complaint was that 'int foo, *bar;' is confusing because 'bar' is not an int, but from a visual standpoint '*bar' is the int.

      Of course you can't just use *bar uninitialized right after the declaration, but the problem was looking at the code, not memory.

      --

      --
      Stay tuned for some shock and awe coming right up after this messages!

    111. Re:If I were Brian... by jdeking1 · · Score: 1

      That's just bad programming practice. You should never, ever declare multiple types in a single statement.

      Personally, I don't like to declare multiple variables in a single statement, even if they are all the same type. It makes the source code hard to read.

      But then I also compulsively comment my code, so I can read through it 10 years later and still understand everything.

      --
      "A generation which ignores history has no past and no future." -- Robert Heinlein
    112. Re:If I were Brian... by jdeking1 · · Score: 1

      VBscript drives me nuts. I want my variables to know what they should be; if you don't know what your variables are going to be (integer, float, string, etc.) how can you write a solid, reliable program?

      When I'm required to write in VB, "Option Explicit" is the first statement. It comes before the comments that describe the program. That's how important explicit declarations are to a *real* program, IMHO.

      I despise VB in all its forms (especially VBscript), but I have to use it - some of the software I have to interface with only understands VB. Believe you me, this is a constant issue when software upgrades come around: "can we get another option for scripting with this tool?" I am relentless in this area.

      --
      "A generation which ignores history has no past and no future." -- Robert Heinlein
    113. Re:If I were Brian... by fucksl4shd0t · · Score: 1

      When I'm required to write in VB, "Option Explicit" is the first statement. It comes before the comments that describe the program. That's how important explicit declarations are to a *real* program, IMHO.

      Dude, I hear you. I do the same thing, actually. I'm in much the same boat. My problem is that I learned ASP because the company I was working for used ASP. Now I'm free to use PHP, but I don't have the time to learn it.

      VBScript sucks ass for real programming, but I must admit that I enjoy it as a web programming language. On the server, it kicks the ass out of Javascript on the client (NOT a fair comparison). But I've definitely found that OPTION EXPLICIT really helps a lot with managing variables. It still doesn't straighten out type problems. As a hack, though, I find that initializing the variables with null versions of what I intend to store in them works really well. There is a type structure buried in their, and it screws up newbie vbscript programmers who haven't learned type and probably never will, but if you initialize your variables you'll invoke this type structure and effectively type your variables. :) Happy day!

      --
      Like what I said? You might like my music
    114. Re:If I were Brian... by WNight · · Score: 1

      Declaring identical variables on a single line is imho, clearer than a line for each. It's not really any easier to read

      int a;
      int b;
      int c;

      than

      int a, b, c;

      and the second syntax lets you look at one type (int) and see that everything declared on the line is the same.

      But, for this to be a valid style, you need to break out the different declarations.

      int a, b = 0, *c, d, e, *f;

      should really be

      int a, d, e;
      int *c, *f;
      int b=0;

      Moving d, e, and *f, onto their own lines just makes the program longer without making it clearer.

      Even with large monitors and 80+ line screens, vertical space is still at a premium. It's a lot easier to write or debug a function if it fits onto the screen. There's no need to jump back and forth, losing your place, to see what the declarations were, or what exactly it returns.

      Just like, while

      if (foo == bar) {
      code;
      }
      if (foo == baz) {
      code2;
      }

      is a better style than what follows

      if (foo == bar) { code; }
      if (foo == baz) { code2; }

      if you're writing twenty of those, ala a switch type statement, and 'code;' is short it makes sense to put them on one line. It's a deviation from "proper" style, but you make the program more readable to having all the conditions right in line with each other, and all the actions in line with each other, without anything in the way.

      Rules are made to be broken, but you should learn the rules (and the reasoning behind them) before breaking them.

    115. Re:If I were Brian... by WNight · · Score: 1

      The problem isn't multiple declarations on one line. The problem is that there are multiple types of declarations on one line.

      int a, b, c;

      saves time, and makes it clear at first glance that all three variables are the same. (Or it would, if people didn't try to break this.)

      int a, *b;

      I agree, is stupid. It's like putting a float and an int on one line, differing only in some piece of punctuation. Like 'num a, .b;' or something.

      So break out all different declarations (pointers, declarations with assignments, etc) onto different line, and keep all identical declarations on a single line.

      Or, broken up by functionality...

      int i, j, k;
      int Cats, Dogs;
      int *PetPointer;
      int ErrorCode;

  7. SCO sueing Brian Kernighan by Anonymous Coward · · Score: 5, Funny

    Isn't SCO already suing Brian, both for being involved in a Linux OS, and because "C" happens to be found in the middle of SCO's trademark name?

  8. Riiiiight. by LooseChanj · · Score: 1
    "...and how he had nothing to do with the creation of C."


    A likely story. Uh huh. Sure. No, I believe him. :-)

    --
    Mix the failings of Usenet with the shortcomings of the World Wide Web and the result is slashdot.
  9. Points in article: by Creepy+Crawler · · Score: 1, Flamebait

    1: but the graphical interfaces are more responsive on Windows than through an X interface.

    Isnt that what we've been saying all this time?

    2: Yes, long ago. Multics was an acronym for something like Multiplexed Information and Computing Service, and it was big and complicated because it had many of everything.

    Are there still any usable capibility systems out there? My friend found an old PrimeOS box with everything. Yet to get it running, as damn near every port is the same (spitz n sparken if you're wrong).

    3: C is perhaps the best balance of expressiveness and efficiency that has ever been seen in programming languages.

    If anything, LISP is better. If you want 3d virtual worlds which events trigger other events on a time scale, it's HELL to do in C. Lisp allows that kind of control, with the inclusion of CPU hits (in respect to C).

    4: And modern systems are so messy and complicated that they are more frustrating than rewarding most of the time.

    After reading that statement, Why'd they interview him? The whole idea of programming is to reduce or STOP that result. Programmers make it easier on users (well, supposed to)...

    --
    1. Re:Points in article: by DogIsMyCoprocessor · · Score: 4, Informative
      Why'd they interview him?

      Let's see ...

      • He invented Awk, a spiritual godfather to Perl
      • He co-authored The C Programming Language
      • He co-authored The UNIX Programming Environment
      • He co-authored Software Tools, an early manifesto of the "Unix Way" of using small, interoperable tools.

      If you had done as much important work, I think you would be worthy of an interview, too. That's no guarantee that you'd have much to say, of course.

      --

      "And this is my boy, Sherman. Speak, Sherman." "Hello." "Good boy."

    2. Re:Points in article: by Urkki · · Score: 2, Insightful
      Well, some of your points:

      1. He says the graphical interfaces for running java are more responsive on Windows than X, not that everything is. You take that out of context, and in the process invite flame war Win vs X...

      3. You are inviting a flame war Lisp vs C. They are very different languages to start with, and both have "loyal followers", one of the best recipes for flame war.

      That's why your first post comes through as flamebait, and 2nd post comes through as a troll trying to draw more attention to your first flamebait.

      (And btw, I didn't moderate it, this is just my impression.)

    3. Re:Points in article: by tommasz · · Score: 2, Interesting

      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.

    4. Re:Points in article: by sdowney · · Score: 3, Insightful
      He also co-authored The Elements of Programming Style with P.J.Plauger, and early classic on how, and how not, to program.

      The fact that the language under critque was FORTRAN, unfortunately today, obscures the underlying truths they were discussing.

    5. Re:Points in article: by AvantLegion · · Score: 1
      He invented Awk, a spiritual godfather to Perl
      He co-authored The C Programming Language
      He co-authored The UNIX Programming Environment
      He co-authored Software Tools, an early manifesto of the "Unix Way" of using small, interoperable tools.

      I wrote a paint program in OpenGL.

      Where's my interview?

    6. Re:Points in article: by steveha · · Score: 1

      The fact that the language under critque was FORTRAN, unfortunately today, obscures the underlying truths they were discussing.

      I disagree. That book rocks; every software geek should read it. Yes, some of the examples are non-interesting because they are too FORTRAN-related. But lots of the other examples are timeless classics. The discussion of floating-point math is a gem. "Floating point math is like moving piles of sand around; every time you do it you lose a little sand and pick up a little dirt." (Quote from memory so it might not be exact)

      And by the way, about half the examples are in PL/1, not FORTRAN.

      steveha

      --
      lf(1): it's like ls(1) but sorts filenames by extension, tersely
    7. Re:Points in article: by AvantLegion · · Score: 1
      And you are a moron that doesn't understand sarcasm. Pity.

    8. Re:Points in article: by Anonymous Coward · · Score: 0
      And you are a moron that doesn't understand sarcasm. Pity.

      Is that pity that he's a moron or pity that he doesn't understand sarcasm?

      So Mr. Legion, can you tell me about your work in OpenGL? I've read here that you've written a paint program.

      -cmh

    9. Re:Points in article: by AvantLegion · · Score: 1

      Well, glad you asked. It runs like shit and has a limited color palette!

    10. Re:Points in article: by Anonymous Coward · · Score: 0
      I see. So was the low performance or the limited color palette your primary objective? How well did you accomplish that?

      -cmh

    11. Re:Points in article: by sdowney · · Score: 1
      We're in violent agreement here. Even though the book is about 30 years old, it still applies today.

      But, when someone picks it up, they see FORTRAN and PL/1, no C, no Java, and assume that it's obsolete. The languages, although in common use when the book was written, now obscure, rather than reveal.

    12. Re:Points in article: by AvantLegion · · Score: 1
      Well, our main objective was being cross-platform, and we achieved that. The other two just came naturally with it.

    13. Re:Points in article: by Anonymous Coward · · Score: 0

      Avant, thank you very much for your time and good luck.

      Anonymous Coward is a poster to the slashdot.org site who perfers not to be known.

      -cmh

    14. Re:Points in article: by AvantLegion · · Score: 1
      LOL.

      This was quite humerous and probably nobody else read it.

    15. Re:Points in article: by Anonymous Coward · · Score: 0

      That's alright, I'll settle for that audience of one.

      Thanks for the complement.

      -cmh

      P.S. Is it true that you had nothing to do with the design and the development of OpenGL graphics engine?

    16. Re:Points in article: by AvantLegion · · Score: 1
      That is true. Everyone always asks me that question, just because I made the paint program! Let's set the record straight: Silicon Graphics created OpenGL. I just utilized it to create the paint program. All the credit really belongs to them, but I am flattered over the attention.

  10. FreeBSD on his Mac? by CoolVibe · · Score: 1
    From the article: "I use Solaris at Princeton, Irix when I visit Bell Labs, and FreeBSD on my Mac; I also have Cygwin on several PCs so that standard tools are readily available."

    That's odd... How useable is the FreeBSD PPC port nowadays? Last I heard it only booted and nothing much more. Isn't he confusing FreeBSD and NetBSD? Or is he referring to the FreeBSD userland in OS X/Darwin?

    I love FreeBSD though, I'd love to run it on my iMac instead of OS/X.

    1. Re:FreeBSD on his Mac? by pohl · · Score: 2, Informative

      Can't speak for Mr. Ritchie, of course, but it could be that he was refering to the FreeBSD 4.4 built into MacOS X

      --

      The "cue the foo posts in 3, 2, 1..." posts will commence with no subsequent foo posts in 3, 2, 1...

    2. Re:FreeBSD on his Mac? by DunbarTheInept · · Score: 1

      I love FreeBSD though, I'd love to run it on my iMac instead of OS/X.
      OS/X *IS* FreeBSD - with lots of other stuff on top.

      --

      Don't label something "offtopic" unless you know the topic well enough to tell what's on topic.

    3. Re:FreeBSD on his Mac? by IamTheRealMike · · Score: 2, Interesting

      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 ;)

    4. Re:FreeBSD on his Mac? by CoolVibe · · Score: 1
      No.

      OS X/Darwin is _NOT_ FreeBSD. It is a Mach/BSD hybrid kernel with a FreeBSD userland. The architecture of FreeBSD and Darwin differ tremendously. The "lots of other stuff on top" is Aqua, which uses some Mach threading stuff.

      Also, another thing where Darwin differs is package management. Darwin uses apt and .deb files. FreeBSD uses it's ports and it's pkg_* tools.

      Saying that OS X is FreeBSD is like saying that a chopper is an airoplane. Sure, they both fly, but they aren't the same.

    5. Re:FreeBSD on his Mac? by pohl · · Score: 2, Informative

      It's true that there is the Mach kernel involved (here's a simplified cake-layer diagram), but from the context that Ritchie provides ("The way I use them, which is as a casual programmer, it doesn't matter--they are all the same...") none of that is really relevant. The APIs that he expects from a unix are there in the FreeBSD 4.4 code layer. (X11 is there too, by the way). He would have to be using the word "FreeBSD" very pedantically to mean that it's FreeBSD/PPC and not the FreeBSD 4.4 in OSX. It doesn't sound like he's being pedantic in this interview.

      --

      The "cue the foo posts in 3, 2, 1..." posts will commence with no subsequent foo posts in 3, 2, 1...

    6. Re:FreeBSD on his Mac? by Durin_Deathless · · Score: 1

      Technically, Mac OS X has some FreeBSD in it, as elements of FreeBSD have been used to update Darwin.

      --
      You should use AdiumX on your Mac.
    7. Re:FreeBSD on his Mac? by DunbarTheInept · · Score: 1

      OS X/Darwin is _NOT_ FreeBSD. It is a Mach/BSD hybrid kernel with a FreeBSD userland.

      Which is exactly what *any* freeBSD port to a new archetecture is - a freeBSD userland with a newly built kernel for that new archetecture. The only difference here is who built it.

      --

      Don't label something "offtopic" unless you know the topic well enough to tell what's on topic.

    8. Re:FreeBSD on his Mac? by Anonymous Coward · · Score: 0

      No, the FreeBSD kernel itself has been ported to several architectures.

      The Darwin/OS X kernel is something quite different, and is actually based on the NeXTSTEP kernel with some parts of the BSD subsystem updated from FreeBSD.

      MacOS X as a whole very much evolved from NeXTSTEP, with FreeBSD components thrown in as more up-to-date replacements for the 4.3 BSD subsystems it used to have.

    9. Re:FreeBSD on his Mac? by DunbarTheInept · · Score: 1

      Nothing you said contradicts what I said. The kernel is a teeny tiny part of what makes BSD be BSD. Replace it and you still have BSD.

      --

      Don't label something "offtopic" unless you know the topic well enough to tell what's on topic.

  11. expressive by rnd() · · Score: 3, Insightful

    He mentions that he considers C to be the best combination of expressiveness and efficiency. I wonder, fellow Slashdotters, what you think the most expressive language is (efficiency aside)?

    --

    Amazing magic tricks

    1. Re:expressive by Anonymous Coward · · Score: 0

      That all whitespace language slashdot mentioned a few months back is surely the most expressive language I've seen.

    2. Re:expressive by Madoc · · Score: 1

      Haskell.

      --
      Anonymous Cowards: Proving daily that human beings are innately jerks.
    3. Re:expressive by garcia · · Score: 3, Funny

      vuglar language.

      Flash video of Monty Python's famous skit ;)

    4. Re:expressive by ryants · · Score: 4, Funny
      what you think the most expressive language is (efficiency aside)?
      Chinese. In no other language can one syllable mean anything from "chicken" to "the interlocking fates of all beings in the celestial orb".

      And let's not forget crisitunity.

      --

      Ryan T. Sammartino
      "Ancora imparo"

    5. Re:expressive by GnuVince · · Score: 2, Insightful

      Lisp and Smalltalk are two VERY good languages at being very expressive. And both are old enough to have had enough research that they are now as fast as C++.

    6. Re:expressive by leoboiko · · Score: 3, Insightful
      --
      Prescriptive grammar:linguistics :: alchemy:chemistry. Stop being a nazi and learn some science.
    7. Re:expressive by IamTheRealMike · · Score: 2, Insightful

      Well, define "expressive" first, then maybe people will be able to give better answers....

    8. Re:expressive by wFruitbat · · Score: 1

      I don't mind what he says. For me K&R are the authors of the C language. About expresivness you all know that it is always a tradeff between speed/size/expresivness/etc... We are toying with the idea here to use K or APL for some financial mumbo-jumbo. In practice it seems that often the best solutions are cocktails - get some C, some C++, some Java, SOAP some Java, call the SOAP from Perl, generate XML and convert with a stylesheet. That's fun.

    9. Re:expressive by nat5an · · Score: 2, Informative

      I'd have to agree. I was taking a grad level course on programming language foundations, and the prof did the famous sieve of erasthones in one line (well two lines, since you have to call the sieve function from somewhere) in Haskell:

      f (h:t) = h : f [ x | x <- t, x 'mod' h /= 0]
      main = f [2..]

      The only reason it's possible is due to Haskell's lazy evaluation, so you can have infinite recursion defining a list, and it's not really a problem, unless you try to grab every member of the infinite list and use its value.

      Well, I was impressed. You all may be jaded.

      --
      Head down, go to sleep to the rhythm of the war drums...
    10. Re:expressive by rot26 · · Score: 1

      I wonder, fellow Slashdotters, what you think the most expressive language is

      Algol

      --



      To ensure perfect aim, shoot first and call whatever you hit the target
    11. Re:expressive by swordgeek · · Score: 3, Interesting

      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
    12. Re:expressive by turgid · · Score: 2, Insightful

      And both are old enough to have had enough research that they are now as fast as C++.
      I suppose that all depends of the compilers and interpreters involved.

    13. Re:expressive by eglamkowski · · Score: 1

      There was a news item a month ago about how speaking Chinese requires the use of both sides of the brain, whereas english only use one side.

      I'm actually trying to learn chinese and I'm having a rather difficult time of it. Damn intonation....

      --
      Government IS the problem.
    14. Re:expressive by X · · Score: 1

      C++ can get pretty damn these days, but yeah, I'd throw Lisp, Smalltalk, and for totally different reasons, APL into the pool.

      --
      sigs are a waste of space
    15. Re:expressive by X · · Score: 1

      "C++ can get pretty damn these days"

      I of course meant "pretty damn expressive", although many would argue the original version was correct. ;-)

      --
      sigs are a waste of space
    16. Re:expressive by jfengel · · Score: 5, Insightful

      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".

    17. Re:expressive by Requiem · · Score: 1

      Prolog.

    18. Re:expressive by Anonymous Coward · · Score: 0

      Intercal... or BRAK.

    19. Re:expressive by axxackall · · Score: 1

      Mozart and Curry.

      --

      Less is more !
    20. Re:expressive by Usquebaugh · · Score: 1

      The perfect dining experience!

    21. Re:expressive by DunbarTheInept · · Score: 2, Interesting

      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.

    22. Re:expressive by Lugor · · Score: 1

      intonation is different from tone. intonation is emphasis on certain letters or parts of syllables. Tone is what you are used to in expressing emotion. And Chinese is very contextual, because accents will affect intonation, so you have to understand the context of the spoken language. And in Chinese some words can have the same pronounciation and same intonation yet have different meanings.. context!

    23. Re:expressive by Circuit+Breaker · · Score: 2, Interesting

      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.

    24. Re:expressive by homebru · · Score: 1
      In no other language can one syllable mean anything from ...

      You never heard my Mother say "Well?" as one of us tried to sneak in the back door at one in the morning.

    25. Re:expressive by blair1q · · Score: 1

      Superseded by "Pith Empowers."

    26. Re:expressive by awol · · Score: 1

      Prolog (but I will trade with most any FP language as well). It blew my mind once I got my first success with it. I mean it just blew my mind that the particitioning problem could be 30 odd lines of code and then the N partitioning problem became 31 lines.

      --
      "The first thing to do when you find yourself in a hole is stop digging."
    27. Re:expressive by DunbarTheInept · · Score: 1

      Doesn't alter my argument at all, since I only gave tone as one example, not the be-all-end-all. Regardless of which audio features you are referring to, be they tone or intonation or whatever, limiting what is available for the user's discretion *limits* rather than increases expressability. (And, no, it is not true that tone is the only audio clue English speakers use to express non-literal meanings. Intonation is also used, as is pacing (where to pause, and for how long).)

      --

      Don't label something "offtopic" unless you know the topic well enough to tell what's on topic.

    28. Re:expressive by GlassHeart · · Score: 1
      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.

      I think the "expressiveness" of a language can be defined as how many appropriate native expressions it has for all thoughts that needs expressing. For example, the Fukien dialect of Chinese has a single word describing the sensation of irritating a wound (perhaps by sprinkling some salt on it). In this sense, it is more expressive than Mandarin Chinese or English, which lacks such a succinct expression.

      Using this definition then, generally a bigger language is more expressive. C has a hard time expressing the concept of objects, and no real way to express messages. C++ and Java are more expressive than C in terms of objects, and Objective C is more expressive than C in terms of messages. On the other hand, C is probably more expressive than Java and Pascal for low level programming.

      Note also that this quality is not infinitely beneficial. A very expressive language is also likely to be harder to master, because there are more expressions to learn before you can express yourself appropriately in the language.

    29. Re:expressive by Bananenrepublik · · Score: 1

      This works because the tones in Chinese are not absolute (otherwise you would already have problems with differently pitched voices), but instead it actually works like this (in Mandarin, other non-standard dialects have more complex schemes):
      Every syllable starts at some pitch A and ends at a pitch B, monotonously increasing or decreasing the pitch along the way. Only the intervall between A nd B counts.

      IIRC the four tones of Mandarin are:
      1. B = A
      2. B = A + 1 semitone
      3. B = A + 2 semitones
      4. B = A - 1 semitone

      So if you were to express a sentiment by changing the pitch of your voice you would change both A and B by the same amount, and you would therefore have no problem keeping your words comprehensible, because you would get
      A -> A' = A + shift
      B -> B' = B + shift = A + some semitones + shift
      and thus: B'-A' = B-A

    30. Re:expressive by Anonymous Coward · · Score: 0

      Assembly is extremely unexpressive and extremely efficient, whereas perl is the opposite. That is what he meant, dimwad.

    31. Re:expressive by Anonymous Coward · · Score: 0

      Chinese has more hominems because it has fewer sounds. But incorrect intonation comes across like speaking with an accent. Do you have trouble understanding people from the the American South, or from England?

    32. Re:expressive by tesmako · · Score: 1

      Prolog. Insanely expressive. Especially GNU Prolog which has a numerical constraint facility bolted on too. Largely all programs end up dead slow but an insanely large class of problems kind of solve themselves in prolog. Plus that writing a solution in prolog the simplest solution tends to become extremely general.

      If one could find a technique to efficiently compile Prolog-code into efficient machine-code you can bet you would hear a lot more about it.

      Other languages that deserve mention are;
      * Lazy functional languages - so sweeeeet, incredibly many problems can be solved by building an inifinite data-structure and walking it in the right way. Not terribly inefficient either.
      * Lisp - Powerful macro-facility and otherwise nicely expressive language. Has nice compilers to get decent performance too.
      * Smalltalk, Forth, Ruby etc. All languages that are powerful enough to be able to define classic control-structures in the base language should be mentioned when discussing expressive languages.

    33. Re:expressive by cpeterso · · Score: 1


      untyped garbage-collecting language like Lisp or Perl

      btw, Lisp is not an untyped language. It is a strongly but dynamically typed language.

    34. Re:expressive by nihilogos · · Score: 1

      Smalltalk has been around longer than C++. It is still far slower than C++.

      If you have any benchmarks to the contrary please provide them. Otherwise comments like

      "are old enough to have had enough research that they are now as fast as C++."

      should be dismissed like the rubbish they are.

      --
      :wq
    35. Re:expressive by RealAlaskan · · Score: 1
      Every syllable starts at some pitch A and ends at a pitch B, monotonously increasing or decreasing the pitch along the way. Only the intervall between A nd B counts.

      That's OK except for the monotonic part. It goes like this:

      First tone: B=A
      Second tone: B>A
      Third tone: your tone falls from A, but then rises so that B>A
      Fourth tone: B<A.

      All this A and B stuff is confusing. Second tone sounds like a question, third tone sounds like a drawled question, and fourth tone sounds as if you're angry. If you always spoke in the first tone, folks would think that your voice was a tiny bit higher than it is.

      Believe me, native speakers have no difficulty conveying emotion by the tone of their voices.

    36. Re:expressive by jfengel · · Score: 1

      True enough. The various Lisp variants have all sorts of typing, up to the Meta-Object stuff which is really amazing. I was thinking of it in its basic "everything is a symbol or a list" mode (really more Scheme than Lisp).

  12. He teaches VB! by Anonymous Coward · · Score: 2, Informative

    Brian K is a really nice guy, it seemed to me. Another gift of the city of Toronto and the University of Toronto to humanity! I heard him talk at UofT a year or two ago. It seems he teaches Visual Basic in his programming course at Princeton. I'm a C nut so that came as a shock to me. Still, I really admire the guy.

    1. Re:He teaches VB! by Sri+Ramkrishna · · Score: 1

      He's teaching it to people who don't know how to program I would imagine. Can you imagine trying to explain C for the first time to non-cs people? Gads...he must have done it for
      his sanity!

      sri

    2. Re:He teaches VB! by $rtbl_this · · Score: 4, Funny

      I'm a C nut...

      Just be glad you're not dyslexic as well. :)

      --
      "Are you being weird, or sarcastic?" said Emma. I said I didn't know because I get the two feelings mixed up.
    3. Re:He teaches VB! by __past__ · · Score: 3, Funny
      It seems he teaches Visual Basic in his programming course at Princeton. I'm a C nut so that came as a shock to me.
      Well, he certainly is in good company.
    4. Re:He teaches VB! by Tet · · Score: 1
      Just be glad you're not dyslexic as well. :)

      Oh how I wish I had some mod points for this...

      --
      "The invisible and the non-existent look very much alike." -- Delos B. McKown
  13. Rob doesn't get enough credit by DrSkwid · · Score: 1

    If you liked the book you might love the operating system

    --
    There are places where the networks are not touching,and there are places where they are-Boeing's Lori Gunter
  14. Great people are so humble! by civilengineer · · Score: 5, Insightful

    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
    1. Re:Great people are so humble! by Anonymous Coward · · Score: 0

      Actually, before they had affirmative action quotas it was easy if you were a white male and wanted to do as much as you could.

  15. Mac OS X, Solaris, IRIX by green+pizza · · Score: 1

    Isn't he confusing FreeBSD and NetBSD? Or is he referring to the FreeBSD userland in OS X/Darwin?

    As he metioned that most of the free unices these days are alike, I'm guessing that he's referring to the FreeBSD userland.

    I love FreeBSD though, I'd love to run it on my iMac instead of OS/X.

    Mac OS X runs pretty well on the G4 iMac that I use. Apple's flavor of X11 runs well enough for me, and there's plenty of OSS goodies, links, and documentation to keep most folks happy.

    It is kinda interesting that he mentions using SGI IRIX at Bell Labs... they don't seem to be the sort of shop that needs gobs of graphics pipes, hundreds of CPUs, or mountains of IO. Though I guess there are plenty of people that like IRIX simply for all of the performance tools that are part of the development environment. (An environment that's too anal to easily compile most open source software... but that's another rant for another time......)

    1. Re:Mac OS X, Solaris, IRIX by arth1 · · Score: 1

      It's not only all the performance tools of the SGI development environment that makes it attractive, but the very fact that it's quite strict.
      Many a time I have had to run PD/OS programs through SGI's compiler first in order to get it debugged enough to run under newer versions of Linux or Solaris. It won't allow stupid mistakes like assuming uninitialized variables are zero, typecasting a pointer to an integer, using the high bit of signed variables, or linking external variables that's constant in one module and volatile in another.
      gcc lets too much slip through, even with -Wall, and this often lends to bad coding habits that may work at present, but not in the next version of an OS or compiler suite. Thus I find SGI's compiler and linker to be invaluable to clean up source.

      On the other hand, gcc barfs on things it shouldn't barf at too, like:

      int main(void) {
      return 0
      }

      Strictly speaking, there should be no semicolon after 0 (because of the "}"), but gcc demands it. Ask Ritchie if Kernighan doesn't agree :-)

      Regards,
      --
      *Art

  16. he's dead wrong about MS by Anonymous Coward · · Score: 2, Interesting
    I hate it when somebody smart that i respect in one domain, says something stupid about another domain:

    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.

    1. Re:he's dead wrong about MS by SDPlaya · · Score: 3, Insightful

      While your argument may be beginning to hold some weight now, I find your position wrong for most of the history of computers. Historical Microsoft has been on the low-end of the price scale. In fact this is why they are scrambling against Linux, because they've usually been able to beat competitors by undercutting them in price (often destroying markets at the same time). I think you can argue that Microsoft has stifled innovation, but I don't think you can argue that they charge unreasonably high prices. Furthermore, outside of the OS, most other pieces of software are easy to migrate away from. If Microsoft's prices were "unreasonably" high, don't you think someone else would have taken over the Office Suite market by now?

    2. Re:he's dead wrong about MS by CdnYoda · · Score: 2, Funny

      Hmmm...sounds like someone from the Dark Side. Of course MS prices are outrageous! They don't even include the source! :-)

      --
      -- "May the Source be with you!"
    3. Re:he's dead wrong about MS by Anonymous Coward · · Score: 0
      huh? talk to an economist, you just said nothing. Monopolists use low prices to drive competitors out of businiess, it's classic. They also use bundling deals and exclusivity and FUD. Read any history of MS, they used all these techniques throughout the 80s. DOS was a monopoly (annointed by IBM) and the profits from that were used to take over the other markets for Windows and office tools.

      that Microsoft used low prices (because they could afford to) to defeat rivals is evidence that they are a monopolist. Hardware prices over the last 20 years have dropped and dropped and dropped, even as we have gotten higher and higher tech. And, software is even cheaper to mass produce than hardware is... how come OSes and office suites from Microsoft cost more than they ever have?

    4. Re:he's dead wrong about MS by Anonymous Coward · · Score: 0
      Furthermore, outside of the OS, most other pieces of software are easy to migrate away from. If Microsoft's prices were "unreasonably" high, don't you think someone else would have taken over the Office Suite market by now?

      hasn't anybody ever emailed you a powerpoint, word, or excel document? have you ever set foot in a large corporation? everybody needs to use the same office suite because they are not compatible with one another. MS, who Kernighan is praising for creating standards, could create a standard document format to create a competitive market for suites, but they won't do this. I wish Kernighan could see that.

    5. Re:he's dead wrong about MS by crucini · · Score: 1

      This is a good point, and should not have been modded down. The creativity and energy of the computer industry were very high in the 80s. The rate of progress has definitely slowed since Microsoft settled its gray bulk over the industry, blotting out the sunlight. They have crushed many innovators through FUD, buyouts, and underhanded tactics. Computer users would be much better off today if Microsoft had never existed.

      Although, as Linus Torvalds pointed out, the existence of Microsoft led to the standardized PC platform which enabled the birth of Linux.

    6. Re:he's dead wrong about MS by DunbarTheInept · · Score: 3, Insightful

      Microsoft didn't bring computing to the masses, nor did it hinder it, the HARDWARE platform it was lucky enough to be attached to brought computing to the masses. The openness of the PC hardware made it more affordable than alternatives, and made the hobbiests like it for tinkering, giving the best of both worlds, attracting people BOTH from the 'I want to tinker' camp, and from the 'I want it cheap and don't care about the details' camp. Remember the 80's? The Mac was universally hated by the very same people who today talk about how cool OS/X is for being BSD based. That's because in the '80s the marketplace was driven by people who were willing to learn new software and new languages without even blinking an eye, and so the computer buying decision was driven more by the hardware than the OS that sits on top of it.

      Think about when PC's were becoming popular in the '80s with thousands of titles available for Microsoft DOS. The fact that the OS was DOS was largely irrelevant to those packages. They took over the whole machine when they ran and the OS's job was over once the program was running. So people didn't care that DOS was crap. What mattered is that at a time when the hardware wasn't fast enough to make a real OS feel "snappy", DOS could be shoved aside so your program had the whole CPU and memory to itself. It worked because at the time you couldn't spare the memory and time for a "real" OS.

      DOS was a success because it was attached to PC's, not because of any features of DOS itself.

      --

      Don't label something "offtopic" unless you know the topic well enough to tell what's on topic.

    7. Re:he's dead wrong about MS by Junks+Jerzey · · Score: 1

      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.

      No offense, but that's just silly. The price of the *hardware* is still the main expense of a PC. Now you could argue that IBM PC clones were a total mistake, and that we all should have been using something else, like Amigas or whatnot. But that's not Microsoft's fault. MS-DOS sucked, back in the day. I mean really, really sucked. And at the time there *were* alternatives to buying a generic PC running MS-DOS. But people bought them anyway, even when they were super overpriced and horrifically unusable.

      Fast forward to today. Windows is generic. OS X is generic. Linux and BSD are generic. In all honestly, there's little difference between them. They're all bloated, they're all old tech. They're all not as usable as they should be. Again, you can't blame Microsoft for this.

    8. Re:he's dead wrong about MS by orim · · Score: 1

      "Computer users would be much better off today"

      Computer users? No. Due to the standard set by Msoft (one desktop to rule them all), hardware design/sales really exploded. Think about it; all you have to do when putting out a new PCI card/some other piece of hardware is to write one set of drivers, not 5. Think about that... Think about how supported Linux is these days.

      However, just as I believe we've gained in the home user arena (yes, even usability - what does it tell you when Apple is copying parts of Windows GUI these days?), I think programmers were damaged by MSoft throwing in their weight into the language design arena. Working to kill Java, pushing C++, all 6-7 iterations of it, then ASP, now .Net... One of my CS professors was absolutely right when he said that any language whose primer is 1000+ pages shouldn't be around.

      So it was the best of times, it was also the worst of times...

      --
      "If you could only see what I've seen with your eyes..." - Roy Batty
    9. Re:he's dead wrong about MS by RevMike · · Score: 1
      Microsoft didn't bring computing to the masses, nor did it hinder it, the HARDWARE platform it was lucky enough to be attached to brought computing to the masses.

      I don't agree, but on a very fine point. Inexpensive hardware was available to the masses before MS. CP/M and its hardware was widely available, had lots of apps, and didn't cost too much. Remember Osbourne, Kaypro, TRS-80?

      Adding the three letters IBM to a slightly scaled up CP/M clone, however, had the effect of pushing the whole package to broader acceptance. IBM's label made the PC a tool for medium ande large businesses that were already running mini and mainframe computers. Once IBM created that (huge) market, the Compaqs and other clone makers drove the prices down, creating the commodity prices we have today.

    10. Re:he's dead wrong about MS by Anonymous Coward · · Score: 0
      it is true that having a monopoly sometimes brings a standard, and there are sometimes benefits to standards. But there are also significant negatives to standards (NTSC and gasoline internal combustion engines might have run their courses by now?) and significant negatives to monopolies and you are ignoring them and that's what makes you so stunningly wrong.

      that, and your history is 100% wrong: it was the IBM hardware standard that spawned the clone industry. Microsoft's official strategy was actually to support all sorts of different platforms with p-code for the tools and ports of DOS to the early Intel platform variants (DEC and ATT and NCR...). That strategy hurt Microsoft and enable companies like Lotus to produce much better products, products tuned exactly to the IBM platform.

    11. Re:he's dead wrong about MS by Anonymous Coward · · Score: 0
      jesus, you are dead wrong, yet you call me silly.

      The price of the *hardware* is still the main expense of a PC. Now you could argue that IBM PC clones were a total mistake, and that we all should have been using something else

      that's not the argument i would make. Hardware is stuff. It costs to make. It is wrong to do as you are doing and look at price. You need to look at profit margin. The profit margins on hardware are low. Software costs nothing to duplicate. Its margins are very high.

      Microsoft earns the lion's share of profit on a new system, and they have no variable cost component beyond duplicating a disk. It's a great business. But, they are a monopolist and the

  17. Oh yeah by Anonymous Coward · · Score: 0

    Python.

    Oh, you meant that joke whitespace language? That isn't Python? Oh right.

  18. Yes and no by smittyoneeach · · Score: 1
    ...computers are too hard to use and too hard to program.
    Sure, hiding the details is a Good Thing.
    I think there is a counterargument, though; y'all just can't express differential calculus easily in arithmetic terms.
    The genius of MS is in targeting the lowest common denominator. Why does Joe User care about the difference between physical and logical partitions? Redmond has the a:\ b:\ c:\ market firmly in hand.
    The utopian vision of 'source code for all my people' will never occur; they can't be bothered (as a whole) to vote, much less think. And we love the sheep nonetheless.
    --
    Get thee glass eyes, and, like a scurvy politician, seem to see things thou dost not.--King Lear
    1. Re:Yes and no by Dun+Malg · · Score: 1
      The genius of MS is in targeting the lowest common denominator.

      yeah, but that denominator keeps going lower. To what are they going to change "My Network Places" (shudder) that's dumber-down than THAT?

      --
      If a job's not worth doing, it's not worth doing right.
    2. Re:Yes and no by Anonymous Coward · · Score: 0

      Clearly, knowledge of potentially non-Microsoft possibilities is DANGEROUS.
      Future versions will blur reality further by just making things appear to be one continuous desktop.
      If you experience performance degradations while we automagically do extensive configuration work, buy more RAM. If that doesn't help, an entirely new computer may do the job.
      If you are still beat down, complain to your sysadmin, who may not be the swiftest fellow around, but he does have a shiny MSCE diploma, which can also be yours for a nominal fee. No knowledge required.

    3. Re:Yes and no by Anonymous Coward · · Score: 0

      Partitions are a bad example. I can't think of any other easy to understand concept that microsoft has succeeded so well in making a mess of. Joe user will care about logical partitions when he has a couple of hard-drives partitioned and has to figure out what the hell those letters mean. The concept of hda1, hdd5, fd0 etc. is very much easier to understand

  19. Re:SCO sueing Brian Kernighan by gwydi0n · · Score: 1

    Not to mention that Unix was written in C, and since SCO own's everything Unix, they own everything C, which was helped in its propagation by Brian's book with Dennis, both of whom will be the next victims of "ze vicious leetigashun" for illegally spreading word of SCO's property, and allowing people to come up with the idea of derivative works, since C is now owned by SCO, so is everything written in said language...

    Somebody shoot me. Please.

  20. Simplicity by devphil · · Score: 5, Funny


    One of my favorite Kernighan quotes of all time:

    Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it.
    --
    You cannot apply a technological solution to a sociological problem. (Edwards' Law)
  21. Atleast Windows is safe. by Niadh · · Score: 5, Funny

    ... since C is now owned by SCO, so is everything written in said language

    That explains why SCO isn't going after Microsoft.
    Windows being written in VB and all.

    1. Re:Atleast Windows is safe. by CdnYoda · · Score: 1

      Not so fast...ever hear of a company called InterTrust? :-)

      --
      -- "May the Source be with you!"
    2. Re:Atleast Windows is safe. by Zenki · · Score: 1

      Yeah, but Microsoft just bought stake in Immersion technologies after paying them off and licensing force feedback technology used in the Xbox controller. Immersion currently has a suit against Sony.

      http://www.gamespot.com/pc/news/news_6072673.htm l

      I think what's going to happen is that both Immersion/Microsoft and InterTrust/Sony are going to end up crosslicensing their respective technologies and dropping both suits.

    3. Re:Atleast Windows is safe. by mibus · · Score: 1

      The scary thing is, a very good friend of mine explained how one of his teachers in high school (only a few years ago) claimed time and time again that MS Office was written in VB...

      My guess on the timeline was that this was when VBA was introduced into Excel, so he got all muddled. Poor guy ;-)

      *sigh*

    4. Re:Atleast Windows is safe. by MrResistor · · Score: 1

      I had VB crash on me once while it was loading, and it threw up a window asking if I wanted to debug the process that had just crashed. Being curious, I answered "Yes", and it proceeded to open up...

      VC++!!!

      --
      Under capitalism man exploits man. Under communism it's the other way around.
  22. overthrow the style oppressor by smarthippy · · Score: 3, Funny
    nothing to do with the creation of C? then why am i supposed to be using his coding style?! hrmph. i'll put my {}'s where i damn well please, now that the ugly truth has come to light.
    main() {
    for(;;) {
    printf("suck it!"); } }
    1. Re:overthrow the style oppressor by Anonymous Coward · · Score: 0

      I hate reading through code like

      int main(){
      for(;;){
      printf("suck it");
      }
      return 0;
      }

      That is the ugliest, hardest thing to read through, especially when there are hundreds or even thousands of lines like that.
      Why can't people put the open and close brackets on seperate lines to keep clean looking code?

      I once saw a line of code similar to:
      int main(){while(1){printf("test");}return 0;}

      I shit you not, I wanted to murder someone after seeing that.

    2. Re:overthrow the style oppressor by Anonymous Coward · · Score: 0

      You think the first example is hard to read? Wuss.
      If it's such a big deal, run the code through a pretty-printer. (code formatting program)

    3. Re:overthrow the style oppressor by eidechse · · Score: 1

      ***That is the ugliest, hardest thing to read through, especially when there are hundreds or even thousands of lines like that.
      Why can't people put the open and close brackets on seperate lines to keep clean looking code?***

      I used to say the same thing myself. I also said on many occasions "I think I see what those K&R brace style people are getting at, bet they still suck."...then I got converted. I think it was after reading 'Code Complete'. I don't think the book actually went so far as a hard sell on the style, it advocated a standard approach across a code base above all, but it did make two points I found compelling: the declaration/condition/loop is really the beginning of the construct, not the opening brace, while the closing brace is always the end. And, that it's easier (visually) for constructs to appear as blocks. A good example is a function with a lot of parameters placed on separate lines:

      "vertical" style:

      void Ack ( int p1,
      int p2,
      int p3,
      int p4 )
      {
      //code
      //code
      //code
      }

      K&R style:

      void Ack ( int p1,
      int p2,
      int p3,
      int p4 ) {

      //code
      //code
      //code
      }

      The "vertical" style leaves a '{' dangling in a big blob of whitespace by itself. It's not a huge deal but after 5-10kloc I find the "block" (that runs vertically from the 'v' in 'void' to the '}' to be better looking and easier to "scan".

      That's the reason that I changed styles, but I agree (with 'Code Complete' and others) that consistency and clean formatting all around is more important.

  23. Holy shit, batman, where's your flame-proof suit?? by Rinikusu · · Score: 5, Funny

    Let's see:
    1) He mentions he writes interfaces for.. Visual Basic
    2) He mentions he writes code in Java
    3) He mentions Microsoft in a positive light
    4) He admits to owning a Mac

    Fuck, man, the only thing he didn't do is say "vi" or "emacs".

    Does this mean that, in reality, all of the contention regarding languages, operating systems, and idealogies is completely artificial and that we should really just use what we like instead of jumping on a particular bandwagon and denying the legitimacy of anything else?

    Man, I think I want to go back to bed.

    --
    If you were me, you'd be good lookin'. - six string samurai
  24. Why Pascal is Not My Favorite Programming Language by NearlyHeadless · · Score: 5, Informative

    Here's an HTML version of Why Pascal is Not My Favorite Programming Language. There's a Postscript version on Kernighan's website

  25. totally. I like this guy. by rebelcool · · Score: 5, Insightful

    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.

    --

    -

    1. Re:totally. I like this guy. by asciiRider · · Score: 2, Insightful

      It seems to me that alot of "propaganda" and silly things like win32 vs. unix vs. whatever really aren't about the tools themselves, or what the tools can acomplish.

      Sometimes the debates are about the design of the tools.

      I'm pretty sure the Slashdot crowd, given 2 hammers that work well, can argue on and on about which one is "better." Once they've convinced you that one is designed better than the other, they will go on to say "By the way, your poorly designed hammer will do a fine job for you."

      Design and Function are two different things, yet when the debates happen, they often get all mixed up together. Pretty neat to see some of the debates play out anyway though...

    2. Re:totally. I like this guy. by nathanh · · Score: 1
      I'm pretty sure the Slashdot crowd, given 2 hammers that work well, can argue on and on about which one is "better."

      You're damn right. I've got 4 hammers and they all have different purposes. My 20lb sledge is good for gardening work. My claw hammer does the job for most woodwork. I also have a wooden mallet and a tiny hammer for cabinet work. For particular tasks, one hammer is better than another. That's not debatable.

      Even within the same genre of hammers there are clearly "better" hammers and "worse" hammers. Consider the material for the shaft (wood vs iron vs fibreglass) and the grip (rubber vs cotton vs tape). There are inferior decisions you can make when building a hammer.

      You're damn right I can argue on and on about which hammer is "better". Pick up a woodworking magazine and you'll see that amateur carpenters argue over hammers in exactly the same way that Slashdotters argue over technology. Slashdot isn't "special" in this regard. We're all human. Arguing seems to be our second nature.

  26. VB??? by Merk · · Score: 1

    Ugh!

    Is there a more vile language you can teach to newbies? I guess it must be meant to weed out the people who don't really want to program.

    There are so many better choices than VB for teaching, if you really want to show people a GUI, try Java. If you just want something that is clean and easy to get started with, try Ruby or even Python. But VB? It has awful namespace problems, an absurd mishmash of methods vs. functions vs. subroutines, etc. Yuck.

    Isn't it odd that I'd recommend to people who want to become programmers to avoid taking Brian Kerningham's class?

  27. Yup by Anonymous Coward · · Score: 0

    Like, for example, calling exit() with the non-ANSI argument -1, instead of EXIT_FAILURE

    I am only half joking :)

    1. Re:Yup by Mr+Z · · Score: 1

      Besides, aren't exit() return codes supposed to be non-negative? I guess it doesn't matter, because the value of the status ANDed with 0xFF is what the invoking program will see. -1 just comes out as 0xFF. (255 in decimal.)

      --Joe
  28. Sueing for use of letters... by BlueWonder · · Score: 1

    Never assume such things cannot happen. Actually, Deutsche Telekom (Germany's telecommunications monopolist) is sueing a small company (not even a competitor) for usage of the letter T.

    They have been unsuccessful in sueing companies for usage of the color magenta in the past, though.

  29. Re:Mac running Linux problems by j0l · · Score: 2

    Umm just one quick question you say that you're running Linux on a Mac; there is no version of BBedit that runs on Linux. Unless you are doing something strange like running it through MOL

  30. Re:Holy shit, batman, where's your flame-proof sui by machine+of+god · · Score: 5, Funny

    You read the article didn't you. DIDN'T YOU. Never do that again.

    (It led you to assume that the rest of slashdot will.)

  31. these guys by Anonymous Coward · · Score: 5, Interesting

    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

  32. Unix Guy Who Doesn't Hate Windows by handy_vandal · · Score: 1

    BK: "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. At the same time, I am unhappy with some of their products. An operating system should not crash very often, if at all, and the sheer complexity of both using and programming the Windows environment is daunting."

    --
    -kgj
  33. VB for beginners by mykepredko · · Score: 1

    I think you're missing the point that VB is very simple to create simple input -> processing -> output applications. BASIC is also quite tolerant of of syntax and declaration errors which avoids heavy groans when something upchucks because a variable isn't properly declared. Not to mention that it also has the same syntax (which is probably the root of the problems that you have mentioned) as GW-BASIC that has been available for 20+ Years.

    With the Visual Studio front end, learning to create (and debug) simple applications is probably most efficiently done with VB. The color coding of statements is nice. When the student moves on to more complex tasks (say data base access and hashing), then something like C or Java would be preferable.

    I'm not a MS proponent in any way, I just agree with Brian's choice of tools for introducing computers to students. As they get more experienced and knowledgeable, I would expect they would move on.

    myke

  34. C enums by crucini · · Score: 1
    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 cost of the lookup table is not necessarily trivial. It depends how often it's used. The C enum is good at adapting to arbitrary numbering schemes, especially if they have gaps. enum{fred=36, bill, joe};

    My only complaint is that the enum values enter the same namespace as variables. They should only show up as symbols when comparing or assigning a variable of that enum type. Then there should be a qualifying mechanism to reach them from the outside, like x = person::bill;
    1. Re:C enums by Mr+Z · · Score: 1

      I believe, in C++, you can plop enums inside a class, thereby putting them in a better namespace. Doesn't help you much in C, I grant you, but it's something.

      I don't know why people are so against enums. Enums do not require storage, do not require pointer generation and indirection in order to resolve, can be optimized by the compiler (unlike a lookup table), and so on.

      And if you use enum-typed variables, it can even catch when you forget one of the cases when you use the enum variable to fire off a switch! (Assuming you don't use default: cases.) The debugger will even show you your variable's values in terms of the enum names.

      --Joe
  35. VB and Kernighan's course by Serf · · Score: 4, Informative

    Isn't it odd that I'd recommend to people who want to become programmers to avoid taking Brian Kerningham's class?

    I know people who have taken his classes. I live with one of them (a CS type), and used to live with another (a non-CS type). All of them have nothing but good things to say about Kernighan's classes.

    The class in which he teaches VB is oriented towards non-CS types, and, from what I saw of my former roommate's coursework, I can't imagine a better course to give people who are basically computer illiterate SOME idea of just what goes on inside the magic box, and some familiarity with all the issues surrounding information technology (legal, ethical, etc. ... like what you see on Slashdot every day). It's not just a programming course -- it covers pretty much every aspect of the field of computing and its related subjects, though in somewhat limited depth.

    Complaining about VB's namespace problems in this context is like bitching about giving a toddler a tricycle because he'll never win the Tour de France on anything with three wheels. My former roommate had no problems with his programming assignments that he wouldn't have had in any other language, and, judging from what I've seen of people trying to pick up C and Java for the first time, VB is a far better choice of language for a course that aims to give people a flavor of what computers are all about.

    1. Re:VB and Kernighan's course by Merk · · Score: 1

      I think it's more like bitching about how the tricycle's back wheels don't turn so the toddler has to drag the thing around. It's boneheaded design that will turn the toddler off biking completely. The biggest problem I had when I tried to write VB programs is that there were thousands of functions/subroutines/methods arranged in no particular way. If I wanted something that gave me the absolute value of a number I couldn't look in the Math namespace, I had to go through the entire list, bit by bit, until I spotted the one I wanted (luckily in this case it started with an a). That sort of problem is probably more important for beginning programmers than it is for experienced ones who at least know some typical names of functions that do "X".

      I definitely don't think people should start programming with C either, and Java is too complicated too. But what about Ruby or Python? Both of these make simple "hello world" type programs, and simple input/output programs super easy. In addition, they both have interpreters. I think having an interpreter when you're just starting out is a great idea. Python's GUI interpreter even does syntax highliting as you go! The only thing that the VB environment has going for it over that sort of thing is the ease with which you can make new GUI components.

      For every 1 thing that VB does to make it an easy language for a complete beginner to learn, it has 3 that make it either difficult in another way or hard to move on to better languages later.

    2. Re:VB and Kernighan's course by Serf · · Score: 2, Interesting

      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.

    3. Re:VB and Kernighan's course by Merk · · Score: 1

      If the course is designed well, and they don't push the limits of VB, then people probably won't think programming is too hard -- I just think that by choosing something other than VB they could go from "hey, this programming stuff isn't so bad after all." to "Wow, this is so cool, and it's really easy!"

      I'd like to hear the other languages he considered too, and to see what made VB a better choice than Python (and hey, maybe the Python developers could use that feedback to make it better).

    4. Re:VB and Kernighan's course by Anonymous Coward · · Score: 0
      I can't imagine a better course to give people who are basically computer illiterate SOME idea of just what goes on inside the magic box, and some familiarity with all the issues surrounding information technology (legal, ethical, etc. ... like what you see on Slashdot every day)

      Our next trick will be getting members of Congress and perhaps a few lobbyists into his course...

      -cmh

  36. Slashdot should retitle the article by Comatose51 · · Score: 4, Insightful

    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 /.
    1. Re:Slashdot should retitle the article by AvantLegion · · Score: 1
      EXACTLY.

      I do a lot more work in C++ than I do in C. That said, there's no programming book that I hold in a higher regard than Kernighan & Ritchie's C language book.

      It maintains the impossible balance of being both brief and complete. The book is that way because every individual description of something is also both brief and complete.

      I wish Stroustrup's C++ book was equally well-written.

  37. Re:AMPL Link by waitigetit · · Score: 0

    Yes, that's slashdot. Someone corrects a mistake by the editors, but because someone else did the same a couple of seconds earlier, he's redundant.

    --
    I could care less, but not without a lobotomy
  38. not quite by Anonymous Coward · · Score: 0

    Monopolists use low prices to drive competitors out of businiess,

    Yes. So does pretty much any successful business. If you provide better value than your competitors, you'll eventually drive them out of business if they don't adapt. If you don't provide better value, you'll eventually be driven out of business. You don't have to be a monopoly.

    how come OSes and office suites from Microsoft cost more than they ever have?

    Um ... because they have to pay their programmers? Just a wild guess there.

    But back to the original point -- of course Microsoft brought computing to the masses. The evidence is all around you, on your friends' computers, on your co-workers' computers, on the vast majority of the PCs in the world. Would it have been possible for another company to accomplish the same task? Maybe, but (and here's what matters) -- that didn't happen. It was Microsoft that brought computing to the people, and that's the way it is.

    1. Re:not quite by Anonymous Coward · · Score: 0
      If you provide better value than your competitors, you'll eventually drive them out of business if they don't adapt. If you don't provide better value, you'll eventually be driven out of business. You don't have to be a monopoly.

      what you are saying sounds nice, but it's not true because they do adapt. Look at fast food, look at automobiles, look at oil, look at the many industries that are not monopolized: what you are saying does not happen. It only happens when one competitor takes undo advantage of temporary conditions (DOS's dominance) and uses unfair practices (tying, bundling, predatory pricing, etc.) to extend dominance.

      But back to the original point -- of course Microsoft brought computing to the masses.

      no, you didn't go back to the original point. Kernighan said,

      Microsoft's work has made computing accessible to a huge population who would otherwise not be able to use computers.

      Not otherwise able to use computers? Do you seriously think that Microsoft was a necessary piece to this puzzle? You are a fool. The mistake that Kernighan made was that from the point of view of 70's unix hacker, he saw that Microsoft did something that Kernighan couldn't do. But Apple comes to mind as a company that was already doing a fine job bringing computing to the masses. DOS was no more user friendly than CP/M, and Microsoft's office tools and Windows were all copies and ripoffs of competitor's ideas and innovations. What I said when seen in context is accurate: computers were already coming inexorably to the masses. Don't confuse Microsoft's success with innovation.

    2. Re:not quite by Anonymous Coward · · Score: 0

      But Apple comes to mind as a company that was already doing a fine job bringing computing to the masses.

      If they were the 95% and not the 5%, you'd be bitching about them just as much as you bitch about Microsoft.

      And I like Apple.

    3. Re:not quite by Anonymous Coward · · Score: 0
      If they were the 95% and not the 5%, you'd be bitching about them just as much as you bitch about Microsoft.

      um... yes?

      If I always bitch about the 95% market share monopolist, i'd be guilty of horrors! being completely consistent, and consistent with standard economic theory.

      you can't see that because you are guilty of being completely, consistently stupid.

  39. It's a shared feeling... by Comatose51 · · Score: 2

    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. What drove some of us nuts is that it crashed a lot and some of the practices of MS. With Windows 2000, the first complain really quiet down a lot.

    --
    EvilCON - Made Famous by /.
    1. Re:It's a shared feeling... by Arandir · · Score: 2, Insightful

      It is just easier to use Windows than most other OSes.

      Correction. It is just easier to use Windows software under Windows than most other OSes. But beyond that it's actually pretty mediocre.

      Compare the individual components of Windows to their counterparts in the UNIX world. Compare *just* the window manager part (not the desktop) to Blackbox. Blackbox is easier to use. You can easily control the z-order of windows, snap to window or screen borders, etc., making it very easy to organize your windows on the screen. Now compare *just* the desktop part (not the window manager) to the KDesktop. Under KDE you can use any damn image you want as the wallpaper, and scale it smoothly. You can align you icons to a grid. Multiple desktops are a given. Etc. Now look at task bars. Kicker and Panel kick butt over the Windows taskbar.

      People who have never used any other system always say that Windows is easier than anything else they've tried. And there are so many of them, that people who HAVE used other systems tend to believe them. But it's just not true. It just seems that way because it's what you're used to. Spend a couple of week using something other than Windows, then go back. You'll be surprised.

      p.s. I've never used XP, so it may be a different story, but even CDE seems usable compared to Win9x/NT/2K.

      --
      A Government Is a Body of People, Usually Notably Ungoverned
  40. I, Parasite by handy_vandal · · Score: 2, Interesting

    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
  41. favorite quote by LMCBoy · · Score: 1

    There are only two real problems in computing: computers are too hard to use and too hard to program. We've made enormous progress on both of these over the past fifty years, but they are still the real problems. And I predict they still will be problems 50 years from now.

    Interesting. So in 50 years, we won't have a Star-Trek like voice interface for our computers? Damn.

    80-year-old LMCBoy: "computer, make me a ham sandwich"

    Mycroft 2: "Poof! You are a ham sandwich." (mechanical laughter)

    80yoL: "In my day, computers were obedient! They had respect for users. You mechs today with your AI and your hoodahey, I tell ya..." (types 'rmmod ai_humor.o')

    --
    Liberal (adj.): Free from bigotry; open to progress; tolerant of others.
  42. Only two real problems in computing? by kbeer · · Score: 3, Interesting

    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.

    1. Re:Only two real problems in computing? by Sivaram_Velauthapill · · Score: 2, Interesting

      Maybe he considers maintenance and administration under the "too hard to use" category...

      --
      Sivaram Velauthapillai
      Seeking the meaning of life... @slashdot of all places ;)
    2. Re:Only two real problems in computing? by Angst+Badger · · Score: 1

      What about issues of availability and maintainability?

      I think it's fair to say that a machine that is unavailable and unmaintainable is hard to use.

      --
      Proud member of the Weirdo-American community.
    3. Re:Only two real problems in computing? by 1in10 · · Score: 1

      Administration is just a special case of use.

  43. i don't get it :( by Anonymous Coward · · Score: 0

    what does that mean?

    1. Re:i don't get it :( by Anonymous Coward · · Score: 0

      Rearrange some letters.

      See you Auntie.

  44. Confusing function pointers by ucblockhead · · Score: 1
    I can never define any sort of function pointer in one line

    Yeah, me too, and I've been doing C/C++ since 1985.

    All the style manuals say to limit yourself to one decl per line, and many say to prefer "int* foo" to "int *foo". Sometimes I think we'd be better off if the language enforced both.

    --
    The cake is a pie
  45. Re:AMPL Link by Anonymous Coward · · Score: 0

    Not only "Redundant", but also "Overrated". The latter from a really chickenshit moderator. And where were the subscribers on this? Twenty minutes of advance notice, and no one even tried the links? What a useless bunch of zombies (either the subscribers or the editors who ignored them). "Improve the stories by letting subscribers see them early" - another "great" plan bites it.

  46. Re:Why Pascal is Not My Favorite Programming Langu by IamTheRealMike · · Score: 1, Informative
    I should note here that the Borland Object Pascal language has dealt with nearly all of the problems presented in the paper, and in many respects is a wonderful language to work in. I know I certainly prefer most parts of it to their C equivalents. The syntax is clear and readable, typecast scoping is clearer, it has powerful built in types (nobody uses arrays of chars for strings and hasn't for years, there is a builtin string type).

    Pascal may be dead, but in Windows-land at any rate its child, Object Pascal lives on. And if you compare how Object Pascal evolved from Pascal to how C++ evolved from C, Pascal wins every time.

    The other neat thing (from one perspective, bad from another) is that Pascal was essentially abandoned to Borland. Lacking the need to standardise it, they added many many useful abilities into the language that make it an ideal Win32 workhorse. Unlike MSVC++, when it would have led to better integration with Windows Borland extended it, for instance IDispatch is integrated into the language seamlessly, so you can do:

    var WordDocument :OleVariant; begin WordDocument := CreateOleObject("Word.Document"); WordDocument.SomeMethod(); end;

    ie in order to support COM instead of messy cludges that make you do things manually support for late bound object methods were added to the language.

    Of course that means you were essentially tied to one companies compiler, but nonetheless that doesn't make the language any less nice.

  47. Kernighan says a mouthful: by Tokerat · · Score: 1

    LJ: Could you say that you love computers (IT)?

    BK: No. There was a time when they were incredible fun to work with, and I really enjoyed programming and getting the machine to do things, but it was never my whole life. And modern systems are so messy and complicated that they are more frustrating than rewarding most of the time. It's still pretty easy to get completely wrapped up in trying to write a program, though; that will always be fun.
    That's why I'm not a programmer anymore. That and the schoolyard drama that goes on in the industry now. (And no, I'm not talking about in /. posts!)
    --
    CAn'T CompreHend SARcaSm?
  48. Re:Holy shit, batman, where's your flame-proof sui by leonardop · · Score: 1

    For an interview where Mr. Kernighan did mention emacs, see here...

    Actually, quite an interesting read too.

  49. The third problem by lscotte · · Score: 2, Interesting

    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.
  50. not an expert in anything now by tungwaiyip · · Score: 1
    I'm not an expert in anything now, though. There are too many things to know, and it gets easier to forget as one gets older.

    He is also very humble to admit that he is not an expert in anything now. Think of how much anxiety today's geeks have when encountered with new things they don't understand.

  51. Actually, he is right. by RatBastard · · Score: 2, Interesting

    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.
  52. Re:Why Pascal is Not My Favorite Programming Langu by hysterion · · Score: 1
    Wow there is a wonderful quote in there (for wicked truth-twisters like me ;-):
    I found relatively little use for pointers. -- Brian Kernighan, 1981.
  53. What an embarrassing interview by afabbro · · Score: 2
    "What were the AWK and AMPL languages designed for?"

    "Brian, what do you think of UNIX? Is it a good and reliable platform for development?"

    "Is it true that you suggested the name "UNIX" for the long ago OS, Multics? What does that word mean?"

    "What are your hobbies? Reading? Sports?"

    "Could you say that you love computers (IT)?"


    Etc. What a waste of a good man's time.

    Nearly all the interview questions are either (a) things widely available in the literature (as in FAQs, not digging research - did the interviewer really not know what AWK stood for? If so, shame on him), or (b) idiotic questions that I might ask if I was interviewing a 6th grader.

    If you can't think of anything interesting to ask your subject, don't bother with the interview!

    --
    Advice: on VPS providers
    1. Re:What an embarrassing interview by AvantLegion · · Score: 1
      Nearly all the interview questions are either (a) things widely available in the literature (as in FAQs, not digging research - did the interviewer really not know what AWK stood for? If so, shame on him), or (b) idiotic questions that I might ask if I was interviewing a 6th grader.

      All he left out was "who do you like?"

  54. pascal ? by andy666 · · Score: 0, Troll

    LJ: You called C "the best balance of expressiveness and efficiency". What about Pascal? There are legions of Pascal programmers in the world. Is it less expressive or less efficient than C?

    i don't get this. is the interviewer from mars ? who programs in pascal anymore ?

  55. Re:Why Pascal is Not My Favorite Programming Langu by marhar · · Score: 2, Informative
    I should note here that the Borland Object Pascal language has dealt with nearly all of the problems presented in the paper...

    Pascal's main problem is that nearly every "real world" implementation of Pascal has dealt with the problems presented in the paper, Unfortunately in different and incompatible ways.
  56. Re:Mac running Linux problems by MobyTurbo · · Score: 1
    Umm just one quick question you say that you're running Linux on a Mac; there is no version of BBedit that runs on Linux.
    The answer is that this is a cut-and-paste troll that originally was flaming another operating system, and got poorly re-edited (at least twice according to my vague recollection of what the original flame was targeted at) to make a new flame. The trolls here are getting dumber and dumber.
  57. Smalltalk's performance by X · · Score: 1

    High performance implementations of Smalltalk yield comperable performance to C++. Sometimes they are slower, sometimes they are faster. Certainly there are some things where it's going to be hard to beat C++, but Smalltalk is not far behind.

    --
    sigs are a waste of space
  58. thanks by pyrrho · · Score: 1

    I have long been familiar with the jargon file, but I've certainly not read it all and wasn't familiar with the B&D entry. Thanks.

    I have read The Story of Mel, before, however... although it was a pleasure to be directed to it and read it again.

    cheers.

    --

    -pyrrho

  59. Re:Holy shit, batman, where's your flame-proof sui by babbage · · Score: 3, Insightful
    In The Power of Myth, Joseph Campbell talks about how among pretty much all religions, the laity & clergy get caught up in how their religion is better than all the others (the classical religious wars). However, most of these religions have a mystical wing -- monks, yogis, etc -- and in general the members of these groups are much more willing to reach out to the other groups and not try to paint things in terms of "us vs. them".

    Kernighan sounds like he applies this kind of perspective to computers. From what I've read, for all the flame wars about Perl vs. Python, Vi vs. Emacs, *NIX vs. Windows, etc, the "monks" in these groups seem to be much more focused on the commonalities among systems rather than the differences between one and another. Kernighan talks about all the languages and operating systems he uses; Larry Wall gleefully puts the best of every language he can get his paws on into Perl; Guido van Rossum doesn't seem to object to letting a future version of Python run on top of Perl6's Parrot runtime engine; Craig Mundie has no fear preaching the Microsoft word at the Open Source Conference; and Tim O'Reilly tells people that he gets along well with all the people he has met at Microsoft.

    I think that's wisdom.

  60. C++ is a much bigger language by Goonie · · Score: 1

    Whilst K&R is a masterpiece of prose, and Stroustrup, well, isn't, the real reason why K&R is small and Strstroup is both large and incomplete is that C is a clean, small language, where C++, well, isn't.

    --

    Any sufficiently advanced technology is indistinguishable from a rigged demo
    --Andy Finkel (J. Klass?)
  61. Re:Why Pascal is Not My Favorite Programming Langu by Anonymous Coward · · Score: 0

    For very early Pascal that was true. As a practical matter most Pascal implementations fall into 4 camps: original pascal, UCSD pascal, Turbo Pascal, and Apple Object Pascal (TurboPascal 5.5,delphi). This is not too different from C: K&R C, ANSI C, Objective C, C++, ANSI C++.

    Today, pretty much every Pascal compiler I see implements Borland's Pascal extensions which are the original Turbo pascal set, and the Object Pascal set used by Borland but which was developed by Apple.

  62. Re:AMPL Link by waitigetit · · Score: 0

    "Improve the stories by letting subscribers see them early"

    Yeah, let your paying customers fix your mistakes, so the freeloaders get a better product. That's a great plan.

    --
    I could care less, but not without a lobotomy
  63. Re:overthrow the style oppressor NOT by threadsafe_r · · Score: 1

    I love reading through code like that! I have encouraged many junior coders to adopt K&R... for me, this is clean looking code.

    But consistent application of style should override any urge to inject your own preferred thang. Its a religious for sure but also now is a habit I can't break!

    cheers /.

  64. Re:AMPL Link by Anonymous Coward · · Score: 0

    Just out of curiosity, is your sig "Nuke the unborn gay baby whales" for Jesus, or Nuke the "unborn gay baby whales for Jesus"? Enquiring minds want to know. :-)

  65. Re:AMPL Link by waitigetit · · Score: 0

    the former

    --
    I could care less, but not without a lobotomy