Become a fan of Slashdot on Facebook

 


Forgot your password?
Close
typodupeerror
×
Unix Operating Systems Software

Interview with Dennis Ritchie 60

Posted by sengan from the geek-history dept.
LinuxFocus has conducted an interesting interview with Dennis Ritchie the co-creator of Unix. It includes some discussion about Linux, C versus C++, and his current work on Inferno/Limbo.
This discussion has been archived. No new comments can be posted.

Interview with Dennis Ritchie More

Interview with Dennis Ritchie

Comments Filter:
  • I suppose I read this differently, but I assumed he was talking about Linux and the various BSD's, not fragmentation within Linux.

    One major difference that I think is worth pointing out, however, is that (AFAIK) the commercial Unix variants were not binary compatible, while there is a fair amount of that already in the free Unix world (and even some in the commercial world). Also, by definition, it's much easier to get a piece of free software working on any given system; all it takes is one of many thousands of users to port it, and you're off and running. I think this makes a lot of the 'fragmentation' a lot less deadly.

    I think the trick here is not to let marketing forces do to free unix what they did to commercial unix, which is define the terms. IOW, don't make things any more incompatible than is absolutely necessary, and don't refer to it as 'fragmentation'; call it 'competition'.

  • The way I see it, fragmentation is equivalent to diversity, with the alternative being homogeneity. So, would I rather live with that which environmentalists want to preserve, or with that which nazis live to impose? Hmmm. :-)
  • My point is, Flame Wars != Diversity.

    You are correct. Diversity, not flames, is what equals diversity. The trolls and flamings of a vocal, idiotic minority is merely annoying. Ultimately, it's just the inconsequential cries of people who can't live with diversity, probably for not being fully upright.

    Don't let them distract you.

  • Freedom is not all that matters; good code matters. Microsoft could GPL Windows and it would still suck.

    TedC

  • Ever notice how Dennis Ritche likes to write a lot in parenthesis? He also indents paragraphs below the first line and encases them in brackets I hear.
  • ...except that it would probably take 10 years.


  • A tad grumpy this morning, eh? I assume he was trying to imply that Dennis Ritchie is God. A harmless exaggeration at worst...

    More revealing is your approach to opinions that differ from your own. You piss on them. Good to see your education was completely wasted on you.

    dylan_-


    --

  • Those that do not study history are doomed to repeat it.

    "I can't help observing, of course, the "free source" Unix-derived world seems to be suffering from exactly the same kind of fragmentation and strife that occurred and is still occurring in the commercial world."

    Reminds me a hole lot of what Jim Gettys [freshmeat.net], the guy who brought us X, had to say not to long ago.

    Linux is it's own worst enemy. Microsoft can't destroy Linux. But Linux can destroy itself. Take sometime and think about that before your next flame war over libraries, hiarchies, OSS, OSI, all this other junk...

  • KDE flames Gnome cause KDE works and is stable.

    Gnome argues KDE's licence sucks, no matter how much they change it.

    GNUstep grows quietly in the background with a better foundation, but since the other KDE and Gnome are "hot" it doesn't get as much attention, and support. Yet, the end users flock to it to avoid contriversy (seen last Window Manager poll on slashdot?). But, the developers as a whole remain cluelessly beating eachother with clubs. Gee... Yea, I can see how THAT is going to cause evolution. The "weaker ignored" ones remain while the potential "diversity" kills each other off.

    My point is, Flame Wars != Diversity. And if you must put Linux in the context of an ecosystem to understand it, then think about this. Everything has it's place on the food chain. Animals have become extinct solely from being "too good" that they over hunt thier pray, and end up starving. Does this mean the animal was not powerful? No. It means that without carefull planning, and understand the delicate balance, you can do more harm than good to yourself.

    So, who do you want to be? The Powerful Pre-Historic brutal tigers who conquer all, but then starve, or the crafty and wise squirl who stores his nuts away for winter and trys not to call too much attention to himself by not starting fights?

    Who won the race? The Hare who gloated, bragged, argued, and was cocky, OR the turtle who kept his mouth shut, didn't mock anyone, and just kept on plugging without making any enemies? Who do you think everyone wanted to actually SEE win the race? The Jerk of a Hare? Or the relyable friendly little Turtle?

    Fighting each other in the name of diversity is pointless. Diversity will grow as the natural product of many many things, the least productive of which is infighting.

    Ya know, there is more than one case of a "pack" or "tribe" or "club" or "commnuity" turning on each other and distroying itself, while the rest of the world goes without knowing or caring.

    Shake hands with your rival, compete with them, keep them in sight, work out with them, share ideas. Two runners who are friends or two body builders can push each other as friends much farther and faster than they can move on thier own. If the two start duking it out from the beginning, they will just be bloody, weak, tired messes before they leave the starting line, and they will never see the finish line or a trophy.

  • See my posts above, please :-)

    Specifically http://slashdot.org /comments.pl?sid=99/02/20/0133207&pid=67#642 [slashdot.org]

    Then, be very very very careful how you define fragmentation. Yes, it's good, IF you qualify it to exclude some critical factors (infighting).

  • Uh oh...hot button!

    Well, er, that's only if you believe in evolution on a large scale. There is plenty of "evidence" that, although there are minimal "evolutionary" changes over time, evolution has been "disproved" by a lack of evidence evidence on the large scale.

    A lack of evidence doesn't disprove a theory. It just doesn't provide support for it. The acceptence of the theory of evolution is based on a common-sense extension of the visible minor changes to the long term. Is there any reason to believe that this extension doesn't follow? Is there evidence that there are contraints on the amount that a genetic code can change?

    What kind of evidence would convince you that evolution occurs? A billion-year case study?

  • The STL will give you maps, lists, vectors etc...If you wrote the same software in C, you'd either spend days implementing the trees yourself, or use a less efficient and error-prone general tree implementation (using void pointers).

    Apparently glib (part of the GTK+ project) has a number of useful data structures implemented in C. I haven't used it, and I'm not arguing that it's better. Obviously it would have to use void* or equivalent so you miss out on static type checking. And I don't think it's as comprehensive as STL. But it is there!

    C++ can be translated to C, so the code should be equally fast.

    This doesn't necessarily follow. I wouldn't expect C++ translated to C to be any faster than C++ compiled directly, there still needs to be some overhead for the C++ features you use. In other words, you may be able to make a C implementation that is more efficient than the translated version.

    One of the design goals for C++ is that there shouldn't be any runtime cost for features of the language you don't use. So if I compile my ANSI C program with a C++ compiler, I shouldn't lose anything.

    Used wrongly, C++ can be arbitrarily slow, just like any other language.

    This is an important point. C++ arguably offers more potential for abuse than most other languages. Because it's easier and faster for an experienced developer to write in C++ than C, many people have the false impression that it is an easier or simpler language than C when quite the opposite is true.

    The only thing I hate about C++ is the time it takes to compile my code...That actually slows development.

    If you don't use "make" or equivalent, you really should. It's worth the effort!

  • Fragmentation isn't good. Choice is good. Fragmentation sometimes results in choice (and is sometimes necessary for it). But not always. And it's not really the best way to provide choice.

    Is having multiple window managers really more beneficial than having one super-configurable window manager? There's a tradeoff between efficiency and complexity on one hand and configurability on the other hand, but I think that you lose a lot more by forking the code. Red Hat used to ship with FVWM95 as the default, but switched it to FVWM2 with default configuration files that made it look like 95.

    The secret of the vi and emacs wars is that the two programs, though they purportedly do the same thing, are pretty fundamentally different in design philosophy. I would claim that they have two separate uses. I use both, depending on my task -- most of my administrative tasks (editing config files and so forth) are done in vi, and most of my development tasks (editing C, Java, HTML and other extended editing jobs) are done in emacs. There's a substantial difference between the two programs. The reason both projects continue isn't because of stubbornness, but because people need a featureful, complex, super-configurable editor and a lightweight, fast, efficiency-oriented editor. For another example, see the Netscape vs. lynx war.

    In contrast, take the GNU Emacs vs. XEmacs split. This is truly unfortunate, and there is a good deal of duplicated effort and catch-up games between the groups. There's no reason for both editors to exist -- the differences in design philosophy are minor and reconcilable (you could argue that they're more like differences in developer interest than design philosophy).

    I strongly disagree that we benefit by having two desktop environments. It does not give us more choice, but less. I can use any window manager with my apps -- neither one cares about the other. vi and emacs are functionally equivalent -- they both edit regular ASCII. I can't choose whether my apps use KDE or GNOME. If I want to use GIMP, I have to have GTK. If I want to use KMidi or KPPP, I have to use KDE. If I want KLyX and Gnumeric and have them both integrate seamlessly with each other and the rest of my desktop...well I'm out of luck. Like FSF and XEmacs, GNOME and KDE aren't different enough to warrant their coexistence.

    • At least for linux it has been. For example, fvwm forked off into fvwm2, fvwm95 and afterstep, (and more) arguably three different products. Arguments about the "duplicated effort" are ridiculous. The world is clearly a better place for having the choice.
    • As for KDE, lets not forget why many distributions refused to bundle it (it was not open-source ( this has changed 8) ) Now we do have two "divergent" OSS development efforts (KDE and Gnome).
    • Each group surely has idea of what should and should not be done, if they were forced to work together we would likely be left with one LCDDE ("lowest common denominator" desktop environment). Instead, we have two rich, (fairly) clean environments that
      • Evolve on their own.
      • "Borrow" ideas from each other.
        Because of this, both projects (and all of us) benefit.
    • As to the Gnome/KDE wars, so what? The vi/emacs wars have been going on for years with zero casualties. Though I disagree with emacs on philisophical grounds, it is a remarkable product.
    • Modern (glibc) Distributions
      No real dissent here. All of the sources come from the same places and package-format conversion utilities take care of binaries.
  • I agree totally. Ritchie knows that C has warts; it evolved from the typeless language B during a time when strongly-typed languages like Pascal were becoming the academic rage. The difference was that Ritchie could create a tiny compiler and tool chain and build tons of useful tools on top of it. It took a decade before Pascal even incorporated enough extensions to be usable; read Brian Kernighan's famous paper on Pascal. Wirth at some level despises Ritchie for his successes. :-)
  • The STL will give you maps, lists, vectors etc. using any types predefined as well as user defined. I find that very useful. You tend to use balanced trees instead of linked lists for caches etc. because it's so darn easy to use. If you wrote the same software in C, you'd either spend days implementing the trees yourself, or use a less efficient and error-prone general tree implementation (using void pointers).

    C++ can be translated to C, so the code should be equally fast. But often you write better code in C++, because you can afford the time it takes.

    Ofcourse, you can write crappy software in any language. Used wrongly, C++ can be arbitrarily slow, just like any other language.

    The only thing I hate about C++ is the time it takes to compile my code. Because the compiler has to do so much work for you (matching templates etc.) it just takes a really long time often.

    A project I'm currently working on is now around 4K lines of C++, and it takes 25 minutes to compile (using -O1) on a P133. That actually slows development. However, if I'd written the program in C, it'd been more like 40K lines, and there's no way I would have gotten as far as I am now.

    All in all, you don't get faster code (usually, there are some exceptions though) from C++, but often you write better software.

    Just my 0.02 euro.
  • I liked his reasoning about Y2K. He might be right. Who would want to be around a bunch of drunks on a thin skinned vessel traveling around 600 mph? Would you know for sure no one has slipped a few drinks in the cockpit? Hehehehe...

    Was it just me or did those interview questions have a very long word count? They reminded me of exam questions that needed to be read carefully to digest the full content. More than one question in a question too. Despite that, he gave a great interview!
  • Actually, I'm currently working on a program and use ANSI C. But it makes a lot of use of structures and functions to manipulate them, I was wondering if when I use C++ will this give better performance. Particulary I'm using GCC and I heard it was faster than G++.

    Yes.

    No.

    Maybe.

    I assume you want to know how fast your code will run, not how fast it will compile. If you are writing C code that does C++ like things (carrying around function pointers in structs, and calling through them) then the C++ won't be slower, and may well be faster (C++ virtual functions have the same effect, but they are frequently implmented somewhat diffrently*, and sometimes the compiler can determine the types ahead of time and code a dirrect jump). C++'s liberies may also help you by supplying an allready optmised data structure so you don't end up using a linked list and linear searches rather then a hash table.

    However I can almost garentee you that the first C++ program you write will probbably be slower then the C version you would write, and may well take longer. Not becasue C++ is bad, but because you will be learing both how to weild it effectavly, and efficently. It is probbably time well spent. Think of it like learning lex & yacc, your firt lex/yacc parser will probbably take longer then doing it by hand, but your second lex/yacc parser will be done far faster then doing it by hand. Of corse with lex/yacc there is little diffrence in run time speed, but that can be the case with C++ as well. If you avoid virtual functions and RTTI then your C++ code has no reason to be slower then C (or if you approximate the same features in C, then using the real thing in C++ won't slow you).

    * C++ virtual functions are commonally done by having one pointer in the struct point to a virtual function table, so you only have one table per class, not one per instance of the class. Some compilers and platforms also don't store an array of addresses to jump to, but an array of jump instructions. That frequently interacts with modernish CPU branch prediction to be far faster then simple indirect jumps.

  • Is Inferno just a Java type thing, or is it possible to boot inferno - no other OS involved?

    What about plan-9, or amoeba - can someone?

    (well i know amoeba is independent - hey look at that Tanenbaum opened up the license on Amoeba, now it is free to more than Big Universities
    http://www.cs.vu.nl/~ast/ [cs.vu.nl]
  • Is Inferno just a Java type thing, or is it possible to boot inferno - no other OS involved?

    What about plan-9, or amoeba - can someone clarify?

    (well i know amoeba is independent - hey look at that, Tanenbaum opened up the license on Amoeba, now it is free to more than Big Universities. X-Free style license.
    http://www.cs.vu.nl/~ast/ [cs.vu.nl])
  • Why is there no more development for Pizza?
  • I think *somebody*'s read one too many Chick Tracts...
  • Interesting Article, is nice to hear what this kind of people thinks, people that really made something big for all of us...
    But maybe Dennis missed a point. Unix broke in several branches of development that really hurted it's potential. But those things happened because of Big companies playing with the good 'ol Unix. Linux in the other hand, by now, is not ruled by economic interests but by excellence and the pride of the people who develops it. And it's path is free of Big Companies with marketing schedules, promises or stock prices...
    When you let people create freely, you can expect only the best...
  • Though there are exceptions (like sorting with templates) as a general rule of thumb C++ will speed up your development but not your code.

    Mind you if you have hand rolled your own linked-lists and tree data structures then you might want to have a look at C++'s standard template library (the STL). I've found myself thinking "I'm glad I've got these vectors and hashmaps templates, if I had been programming in plain C then I would of had to substitute easier to code but less efficent data structures just to get the job done in time".
  • Someone who is just as important to software in general as certain others are to free/open source development who doesn't appear petulant and who keeps his eye on the bottom line (i.e. code).

    I don't suppose anyone's ever seen Bell Labs fork a project over personality conflicts though.

    (guess that experience/maturity thing wins in the end. )

    ~Grell


    "Do not meddle in the affairs of UNIX, for it is subtle and quick to
    dump core." -- Anon.
  • to paraphrase jwz, do NOT learn C++ as your first OO language. First learn some C, which is small and easy as a language; then learn Smalltalk or Eiffel or Objective C or Java to understand what OO is about, and where it comes useful (and where it's just another idiom that just works too), *then* learn C++'s peculiar (and I'm being nice) way of doing OO.
  • yeah, they tend to do that in his home planet (even though his English is good, and without the parenthesis most people might never have figured out).
  • ..and how can I try it on x86 machine..
  • ...then convert your design into C++.
    Java will force you into sensible design, and is much easier to use.
    Though memory management would be painful after Java...
  • As it was brought over /. these days, there have been some personal issues going wrong in the top of the OS community.. (Which is sad to hear).. I know there are many people involved, and everyone is entytked to his/her opinion.. However I'd like to share this story as an example of the behaviour and closeness these two guys, who contributed enormously to the computing world...

    I remember reading in one of Ken Thompson's papers how they unintentionally made the same small ASm program.. And it happened to be that they both have produced almost exactly the same code...

    As impossible as it seems, it's a food for thought.. maybe there is that one/two/three people in the world, who think the same way we do.. and maybe close coupling with a pal will produce better code, than the egoistic all-nighters many of us pull... :)) What do you think?

    --Flame On! :-)
  • my high school principal was Dennis Ritchie's brother... kinda kewl... He had one of those cool symbolic unix/c posters in his office... He was going to have Dennis come in and talk to our programming class, but it didn't happen before I graduated. Oh well.
  • If meept had one question to ask him it would be:

    Dennis, why didn't you make it more like visual basic?


    MEEPT!!
  • With some exceptions the much reviled flamewars allow for ingenuous exchange of ideas and opinions among (an admittedly) bright collection of minds. At least /. flamewars do.

    They allow those of differing opinions to postulate about the advantages of 'their' products. While the claims may occasionally be spurious, the discord is usually beneficial.

    Unix has evolved into many different flavours each as unique as those that use them. While the incompatibility is bad the variety is good, and to be desired.
  • FYI, Brian Kernighan had a paper at the Tcl/Tk conference a couple of years ago. Among a bunch of other things, he spent a good amount of time talking about how he was using VB on some of the projects he was currently involved with.
  • Good to see an interview of the Great Man himself.

    It's a pity that the interviewer didn't take the opportunity to ask more meaningful questions. I would have loved to hear His thoughts on programming and design in general, efficiency vs "elegance" issues in programming, as well as how to construct large complex systems (since he has worked on so many).
  • Hmm..fragmentation outside the commercial realm can be a Good Thing.

    Example: look at your hand..see that opposable thumb? (You do have one, don't you?) That's there because of a fragmentation in your (Great)^10 Grandaddy's genome that occurred a few hundred thousand years ago.

    Linux needs *more* fragmentation so that it can grow its equivalent of opposable thumbs...

  • Yes, yes. That argument is all well and good and would better apply if I were actually proposing that we encourage _penguins_ to sprout opposable thumbs. By advocating that we encourage _Linux_ to grow opposable thumbs I was merely being allegorical. Given your reservations re: the ongoing theory of evolution, perhaps I should have given a nod to the concept of punctuated equilibrium.

    Anyway, the base concept of the goodness of fragmentation for Linux development is valid and has been verified by the very nature of how Linux has already "evolved" to its present state. "Locking in" and discouraging diversity at this time would cause much more harm than fragmentation. But this is obvious, isn't it?

    To get back to the original thread, I massively respect Ritchie, but I think that his correlation (and it has been made by others in the past) vis a vis the fragmentation of commercial unices relating to the present state of Linux development is unfounded. We must dance to the rhythm of the schisms... ;)

    As a postscript, when I refer to 'Linux' here, I am of course referring to the whole ball of wax: GNU/LINUX plus whatever talismans (KDE, GNOME, NetHack, XBill) you care to add to the gumbo...


Slashdot Top Deals

"In my opinion, Richard Stallman wouldn't recognise terrorism if it came up and bit him on his Internet." -- Ross M. Greenberg

Close