Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Interview with Dennis Ritchie

sengan posted more than 15 years ago | from the geek-history dept.

Unix 60

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.

cancel ×

60 comments

Sorry! There are no comments related to the filter you selected.

Ouch!!! brain burn... (0)

Anonymous Coward | more than 15 years ago | (#2009898)

My brain hurts after reading that one......wheres that dictonary???? I remember SVR3 on those old 3Bs and PDPs, man has UNIX come a long way.

C vs. C++ speed (0)

Anonymous Coward | more than 15 years ago | (#2009899)

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

(btw. sorry for my spelling)

Wha's Inferno.. (0)

Anonymous Coward | more than 15 years ago | (#2009900)

Inferno is Unix with the addition of IFP, the
Internet Flaming Protocol. With that, a new
user can easily post flames away on Slashdot or a
newsgroup. There is another variation coming
up for spammers called Hormel.

I wish Inferno were free. (0)

Anonymous Coward | more than 15 years ago | (#2009901)

The Inferno environment is really elegant. And the language (Limbo) knows how to get out of your way and let you do your work. The aspect of simplicity in the design makes sensible but subtle choices easier to swallow. For example, the floating point semantics are well-reasoned, as opposed to Java's fp semantics. The whole environment benefits from core simplicity and pragmatism, carrying Unix-esque flexibility to new realms.

It's a true pity that Inferno is not free. It's available gratis, but that's of no help to anyone who wants to play with the internals. And many aspects of the environment could be abstracted out and used in other free software. sigh... This just makes it another wheel to re-invent.

Jason, ejr@cs.berkeley.edu

the word (0)

Anonymous Coward | more than 15 years ago | (#2009902)

how do we react in the face of the word of god?

Listen to this guy (0)

Anonymous Coward | more than 15 years ago | (#2009903)

I am sure that it gives D.Ritchie lot of sadness
to think that instead of fusing their energy
together to evaporate Winblows, freenix-ers
are fragmenting themselves into myriad
incompatible Unix-variants, the same mistake
commercial Unices did. Even within Linux community,
a dozen incompatible distributions are weakening
Linux due to the diffusion of energy. Consider
this ridiculous thing: KDE has to release 1.1
rpm packages _separately_ for RedHat, Caldera and
SuSE (even though they are all rpm-based) because
they are not compatible! What a waste of developer
time, bandwidth and disk space! Can we have
LSB sooner than some unforseeable future?

Anyway, interestingly, I used to look at this
guy (Ritchie) with reverence when I used to see
him in the Bell Labs cafetria but I never spoke with him.
I was a research intern for a year at Bell Labs
(in 1993) and my room was close to his. His and
Ken Thompson's office are right in front of each other separated only
by the corridor. Both were involved with Plan 9
at that time.

Freedom is all that matters (0)

Anonymous Coward | more than 15 years ago | (#2009904)

Personally, I've yet to hear much serious
mention of this "Inferno" thing, and unless it
is freely available, in spite of its quality
(almost assured, given the caliber of people
working on it), will probably go no where being
non-free. 8-|

BH
---
Join Altima [altima.org]
the free online, multiplayer RPG development project!

Learn your Lessons from History (proprietary==bad) (0)

Anonymous Coward | more than 15 years ago | (#2009905)

Yeah, the lesson is do NOT get locked into proprietary systems. The "free" Unices are free (as in "speech"), and that is exactly why the situation is different than the vendor supplied Unix fragmentation. FreeBSD helps Linux, and vice versa (simply because they can rip off each other's drivers :-). The commercial world gave us termcap/termlib fragmentation, signal fragmentation, Motif/OpenView + X/NeWS fragmentation, etc. And that's all just for starters. The free unices still suffer from the past injustices, but the availability of source is Mega-powerful! Back in the old days, Joe Developer needed eleventy-seven billion Makefiles and #ifdef's simply because he *couldn't* fix vendor supplied incompatibilities, or add BSD functionality (if needed), etc.

We are less locked into any specific track of free Unix, and frankly, an evolutionary process now seems to rule (ie. Slackware decides not to move to glibc2, so people who want it either change distributions, or, mother of pearl, add it themselves!) Imagine if AT&T added all kinds of hotshit features to their C lib (threading, locales, extra hidden bugs) and the source was only available to licensees. You're screwed if you need the features, but your vendor doesn't supply the lib. (Assuming a non-free alternative world)

Anyway, I don't see the "fragmentation" as anywhere near the liability that it was for the commercial world. As a developer, I still worry much less about multiple Linux distribution issues, or Linux/*BSD porting issues, than I do about SunOs 4/Solaris 2/Irix/HP-UX variances.

Chad Netzer
chadn@2xtreme.net

C vs. C++ speed (0)

Anonymous Coward | more than 15 years ago | (#2009906)

will this give better performance. Particulary I'm using GCC and I heard it was faster than G++.

You're asking the wrong question. Don't concern yourself with speed unless you're sure the proper solution won't run on your hardware. You should be saying "will C++ make my code neater, easier to add features, more maintanable, more robust". Such questions are infinitely more important than how fast the majority of code in any practical application will run.

If you don't understand design issues, then I don't recommend programming in C++. You should start with C and read some books which discuss data structures and different styles of programming (functional, procedural, object orientated). You can practice all these styles in C. Once you feel comfortable with the concepts, only then should you move on towards more complex languages like C++. Doing so too early just leads to crappy code because you don't understand the implications of what you write, and C++ assumes that you do understand what you're writing.

Good code is hard to write. This is something that a lot of people don't understand. Using the latest new beaut language doesn't make things easier for the novice, rather it just gives the novice more rope with which to tie a noose. Complex languages may make things easier for the experienced coder, but even that isn't necessarily a given.

Learn how to code in a simple language like C first. Don't concern yourself with speed because it truly isn't important for 95% of the code in 95% of the applications. You'll find that a deeper understanding of data structures and computing algorithms will assist you in writing faster code anyway.

There is no silver bullet. Learn programming first. Pick language advocacy last.

Dennis' comments on Micro vs Mono kernels (0)

Anonymous Coward | more than 15 years ago | (#2009907)

Ooooh Andy Tanenbaum must be having a fit! Looks like Dennis is in the same boat as Linus!

(No disrespect to either side...Tanenbaum is awesome, but that little flame war between him and Linus was really stupid).

MEEPT!! (0)

Anonymous Coward | more than 15 years ago | (#2009908)

Actuall, MEEPT helps to keep things on sort of a light note, and in his/her own way, addresses issues sometimes that most of us don't think to.

VB is popular because it was once easy, and in its own way, elegant. It's only with the past few years' marketing lock-in from Microsoft that most of the products from Redmond have turned to fragile, interdependent, boondoggles.

Pitty.. (0)

Anonymous Coward | more than 15 years ago | (#2009909)

Did it seem like he was a little irritated in his answers? I think he was a little miffed that the interviewer failed to follow up on his leading comments.

Re: Shallow interview (0)

Anonymous Coward | more than 15 years ago | (#2009910)

You might find _The_Practice_Of_Programming_
by Brian Kernighan and Rob Pike of interest then.

It has just been released and covers much of
what you are looking for. I just got my
copy from Amazon yesterday. Much good stuff
here. I've been waiting for an update to
Kernighan and Plaugers's
_Elements_of_Programming_Style_ for ages now,
and this appears to be of the same quality IMHO.

Kernighan has info on his home page if you are
interested,

http://cm.bell-labs.com/who/bwk/

cheers

-amcl

offtopic: Fragmentation is good. (0)

Anonymous Coward | more than 15 years ago | (#2009911)

I don't see why either KDE or GNOME should kill each other. I expect we'll just see evolution: either they keep up (like emacs and vi have done) or they get replaced by other things. As long as people want to develop them they will prosper.

C vs. C++ speed (0)

Anonymous Coward | more than 15 years ago | (#2009912)

"Don't concern yourself with speed unless you're sure the proper solution won't run on your hardware."

If this is a valid argument for C++ over C then it
is a (much stronger) valid argument for Python over . . . well, almost anything.

Mozart Oz is also worth looking at. It combines
functional programming, logic programming, and
concurrent programming with dataflow threads.

My real point is that once you realize that the
greatest performance increase is between not having written something and having it work, there
are many languages better than C or C++ -- at
least for development. And do look at Python. sr

Listen to this guy (0)

Anonymous Coward | more than 15 years ago | (#2009913)

What's the problem,

As long as Redhat/Linux have the bigest free-nix market share, there's nothing that will draw "the lamers" attention. The rest of us can use what we think is best, I use debian, some other guy might use FreeBSD.

shutup (0)

Anonymous Coward | more than 15 years ago | (#2009914)

shut up asshole!!!

Try Dylan to start... (0)

Anonymous Coward | more than 15 years ago | (#2009915)

Program execution speed is heavily influenced by the quality of design of your program and by the use of appropriate data structures, in addition to being influenced by the programming language that you choose. Program performance is usually constrained by one small segment of code. Profiling is a very valuable tool in figuring out where your program is spending its time.

The quality of design of your program and what data structures you use is not independent of what programming language that you use.

In a more productive language, you have more time to focus on performance where it counts.

IMHO, C++ is one of the poorer object-oriented languages out there. It really is a terrible mess. You would be better off with something else. Dylan is my favorite programming language, and you will undoubtedly be many more times productive in Dylan than in C++ once you learn it. If you are developing for Windows, Harlequin Dylan is a very viable option. If you are developing for some other platform, then Dylan is less viable.

I still have to use C++ for some of my programming, but hopefully that will change.

MEEPT!! (0)

Anonymous Coward | more than 15 years ago | (#2009916)

Dork, why don't you go haunt ZDNET's talkbacks if you have nothing of substance to say? You winblows lovers would be scrubbing floors if not for people like Ritchie.

You're not very clever, are you?
Anyway, I thought it was pretty funny. :)

Learn your Lessons from History. (0)

Anonymous Coward | more than 15 years ago | (#2009917)

Tell me how evolution has been disproved. Evolution is hardly a theory, it's just common sense. How do you explain the existence of mankind? God created mankind? Bullocks. Mankind evolved naturally from primitive life forms. I agree this is a miracle, but it is a miracle of nature. And don't forget it has taken billions of years.

Interestingly enough, in this century mankind has outgrown evolution. What I mean is that a very small group of people can now decide to make an end to all life on earth. Evolution is based on the fact that acts of individuals don't really matter, since the strongest will survive. This is not longer the case.

Try Java to start... (0)

Anonymous Coward | more than 15 years ago | (#2009918)

"java *forces* you to a very peculiar style of design"? Not necessarily. Take a look at Felleisen and Friedman's elegant _A Little Java, A Few Patterns_ for something, perhaps, a little different.

C vs. C++ speed (0)

Anonymous Coward | more than 15 years ago | (#2009919)

Agreed, (all other things being equal) if you need some fundamental feature (polymorphism, multimethods, runtime linking, regexps, whatever) it's best to use a language that supports it directly, since rolling your own and doing it better is a lot more work (and a lot harder to understand) if not impossible.

I'd never heard about machine code in vtbls, thanks. I've also been hearing good things about plain old

if (typeid obj == type1) obj.type1::method();
else if (typeid obj == type2) obj.type2::method();

which sounds awful (would be utterly unmaintainable if it weren't machine-generated) but is supposedly more superscalar and cache-friendly, especially if you JIT-compile and check for common cases first.

Re: Shallow interview (0)

Anonymous Coward | more than 15 years ago | (#2009920)

Damn! I didn't know that this book was coming out. Pretty interesting since I've always loved his work.

Ron Rangel

Learn your Lessons from History. (1)

Analog (564) | more than 15 years ago | (#2009921)

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

fragmentation thoughts (1)

pohl (872) | more than 15 years ago | (#2009922)

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. :-)

Evolution from Diversity? Yes (1)

pohl (872) | more than 15 years ago | (#2009923)

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 (1)

TedC (967) | more than 15 years ago | (#2009924)

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

TedC

Ritchie and parenthesis (1)

heroine (1220) | more than 15 years ago | (#2009925)

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.

Freedom Considered Helpful (1)

Stu Charlton (1311) | more than 15 years ago | (#2009926)

...except that it would probably take 10 years.

the word (1)

dylan_- (1661) | more than 15 years ago | (#2009927)


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_-


--

Learn your Lessons from History. (1)

BadlandZ (1725) | more than 15 years ago | (#2009928)

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

Evolution from Diversity? Not. (1)

BadlandZ (1725) | more than 15 years ago | (#2009929)

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.

Fragmentation IN WHAT WAY?! (1)

BadlandZ (1725) | more than 15 years ago | (#2009930)

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

Learn your Lessons from History. (1)

Tim Moore (1808) | more than 15 years ago | (#2009931)

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?

C vs. C++ speed (1)

Tim Moore (1808) | more than 15 years ago | (#2009932)

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!

offtopic: Fragmentation is good. (1)

Tim Moore (1808) | more than 15 years ago | (#2009933)

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.

offtopic: Fragmentation is good. (1)

Robert Bowles (2733) | more than 15 years ago | (#2009934)

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

Arguing over different things (1)

Digital Commando (2881) | more than 15 years ago | (#2009935)

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. :-)

C vs. C++ speed (1)

Oestergaard (3005) | more than 15 years ago | (#2009936)

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.

Good one on Y2K (1)

dattaway (3088) | more than 15 years ago | (#2009937)

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!

C vs. C++ speed (1)

stripes (3681) | more than 15 years ago | (#2009938)

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.

Can this run without Win/Linux/Alt OS? (1)

displague (4438) | more than 15 years ago | (#2009939)

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]

Can this run without Win/Linux/Alt OS? (1)

displague (4438) | more than 15 years ago | (#2009940)

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

No more Pizza ? (1)

Taco Cowboy (5327) | more than 15 years ago | (#2009941)

Why is there no more development for Pizza?

Umm, yes... (1)

Geoff NoNick (7623) | more than 15 years ago | (#2009942)

I think *somebody*'s read one too many Chick Tracts...

Unix-Linux common steps... (1)

Rotten (8785) | more than 15 years ago | (#2009943)

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

Sounds likes sensible advice. (1)

Midnight Coder (8953) | more than 15 years ago | (#2009944)

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

Wow.... how nice (1)

Grell (9450) | more than 15 years ago | (#2009945)

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.

I disagree again (1)

orabidoo (9806) | more than 15 years ago | (#2009946)

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.

Ritchie and parenthesis (1)

orabidoo (9806) | more than 15 years ago | (#2009947)

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

Wha's Inferno.. (1)

Axe (11122) | more than 15 years ago | (#2009948)

..and how can I try it on x86 machine..

Try Java to start... (1)

Axe (11122) | more than 15 years ago | (#2009949)

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

Anothewr one regarding personal issues (1)

F2F (11474) | more than 15 years ago | (#2009950)

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! :-)

Not that it matters, but... (1)

TheMeld (13880) | more than 15 years ago | (#2009951)

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.

MEEPT!! (1)

The Glorious Meept!! (17395) | more than 15 years ago | (#2009952)

If meept had one question to ask him it would be:

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


MEEPT!!

Flame wars are good (1)

akintayo (17599) | more than 15 years ago | (#2009953)

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.

MEEPT!! (1)

roseman (17656) | more than 15 years ago | (#2009954)

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.

Shallow interview (1)

ChipMunk (18521) | more than 15 years ago | (#2009955)

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

Learn your Lessons from History. (1)

ribozyme (18526) | more than 15 years ago | (#2009956)

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

Evolution (was: Learn your Lessons from History) (1)

ribozyme (18526) | more than 15 years ago | (#2009957)

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


Check for New Comments
Slashdot Login

Need an Account?

Forgot your password?

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>