HHKB spotted on desk of another famous programmer

[ch_123]

We all know Richard Stallman, resident tin-foil-hat GNU founder is a fan of the HHKB. It would also seem that Bjarne Stroustrup, original designer of the C++ language is another Happy Hacker.



No Unix beard. Ho-hum.

[keyboardlover]

Even Unix beards likely shave AFTER hockey playoffs are over.

[woody]

This is seriously disturbing.

[xwhatsit]

OMG I hate that *******.

I write C++ every day. I learned it from his book. He wrote the language -- and wrote a book about it. I don't think that's a good idea when it comes to language designers. As a programmer, I shouldn't be writing user manuals for the software I produce -- and this is about a thousand times worse.

That said the K&R C book is very lucid and doesn't have the same superior smirk embedded in the text the same way at all.

Put me off Topres, man!

[Findecanor]

At least, Bjarne Strostrup used to have a beard. Now he just looks like a goof.

I learned C++ from the manual to Turbo C++ back in '92-'93 or so. The language has evolved a lot since then. I am not sure it even had templates back then. It took a great while before different compilers were up-to-par with the latest spec. For a long time, it was not unusual that a program that could be compiled by one compiler did not compile by another.

[Soarer]

'That *******' has earnt any 'superior smirk' you may perceive!

Books about languages (and libraries) are for programmers and should be written by programmers - even better if it's the actual designer (once the reader is past beginner level, anyway). His D&E book is far more interesting than the reference manual, and was a great help to me trying to master the language.

[ch_123]

I'm half-reading his book at the minute, it's pretty alright. Then again, I already have learned C++ in the past, I just wanted to refresh my memory of it.

[xwhatsit]

'That *******' has earnt any 'superior smirk' you may perceive!

Books about languages (and libraries) are for programmers and should be written by programmers - even better if it's the actual designer (once the reader is past beginner level, anyway). His D&E book is far more interesting than the reference manual, and was a great help to me trying to master the language.

I dunno -- Knuth, who deserves far more accolades IMHO (let's face it, C++ was nothing new or particularly inventive at the time), seems to be able to write about his work very well without coming across that way. I think Stroustrup is just particularly full of himself.

I studied CS, didn't necessarily want to end up code monkeying with C++ every day. It serves its purpose, but it's by no means beautiful or elegant and when you look at what else was available at the time (Jesus man, Smalltalk?), he could've done much better. I love the benefits that come with objected-oriented programming but something very important and beautiful was lost when we left C.

We need an object-oriented LISP... oh, wait!

[keyboardlover]

Who cares about pointers anyway? Hardware is cheaper than software so I say use a modern app framework with garbage collection and scale up or scale out if needed. You might just even ship on time with fewer bugs. Fuggedaboutit!

[xwhatsit]

Who cares about pointers anyway? Hardware is cheaper than software so I say use a modern app framework with garbage collection and scale up or scale out if needed. You might just even ship on time with fewer bugs. Fuggedaboutit!

Not when you're programming a machine control running on a real-time OS. Need to have pretty stable and predictable responses.

Plus I'm somewhat dubious about the benefits of GC. Pointers and manual memory management isn't that hard -- if you can't understand it you probably shouldn't be in the line of work. I spent that much time trying to track down memory leaks in a (garbage collected) Adobe Flex app (yikes), and they're rather insidious things. Not freeing a block of memory in C/C++ because you forgot to call free/delete is a relatively easy thing to find. But having to use a profiler to track down where in a bunch of black-box code a reference is being retained is far more of a hassle and seems to happen almost as much.

[Soarer]

So you both think there are better alternatives to C++ ... fine ... use them then! For many applications they might be more suitable, but the fact remains that C++ does what it was supposed to do, which wasn't to replace Smalltalk or anything else, rather it deliberately remains close to the hardware. That happens to suit what I do, pointers and all.

BTW, I know someone who met Knuth - he found him pretty obnoxious!

[keyboardlover]

Not when you're programming a machine control running on a real-time OS. Need to have pretty stable and predictable responses.

Plus I'm somewhat dubious about the benefits of GC. Pointers and manual memory management isn't that hard -- if you can't understand it you probably shouldn't be in the line of work. I spent that much time trying to track down memory leaks in a (garbage collected) Adobe Flex app (yikes), and they're rather insidious things. Not freeing a block of memory in C/C++ because you forgot to call free/delete is a relatively easy thing to find. But having to use a profiler to track down where in a bunch of black-box code a reference is being retained is far more of a hassle and seems to happen almost as much.

I worked on a huge commercial Federally-regulated C++ software for 3 years, and have been working only in .NET for the past 3 years. I understand memory management...it's just not important to me. Memory leaks are not avoidable in a large C++ app, doesn't matter how good a coder you are. I never get them in .NET. And the amount of features my team adds in a week is greater than my old team would add in 3 months. Much fewer bugs and better quality too.

To give a Ripster-ish analogy, .NET, Java, Rails, etc. are to C++ what USB is to PS/2. =)

[xwhatsit]

So you both think there are better alternatives to C++ ... fine ... use them then! For many applications they might be more suitable, but the fact remains that C++ does what it was supposed to do, which wasn't to replace Smalltalk or anything else, rather it deliberately remains close to the hardware. That happens to suit what I do, pointers and all.

Problem is, it's so popular, everybody uses it, commercial libraries are written in it, the entire industry has standardised on it. Which means as a programmer, one inevitably has to deal with it. So it pisses me off because it could've been so much better. C++0x is getting there but it's not enough.

I worked on a huge commercial Federally-regulated C++ software for 3 years, and have been working only in .NET for the past 3 years. I understand memory management...it's just not important to me. Memory leaks are not avoidable in a large C++ app, doesn't matter how good a coder you are. I never get them in .NET. And the amount of features my team adds in a week is greater than my old team would add in 3 months. Much fewer bugs and better quality too.

To give a Ripster-ish analogy, .NET, Java, Rails, etc. are to C++ what USB is to PS/2. =)

Firstly, the `you' in my post wasn't you per se -- it was a general `one'. I'm sure you can manage memory.

However, horse**** on the `Memory leaks are not avoidable in a large C++ app'. All it takes is discipline. Throwing a few tools at it like valgrind to check you're crossed your Is and dotted your Ts doesn't hurt either.

.NET has its place. But there's some things it will never replace. Controlling real-time machinery is one of them. Sure, Beckhoff and the like are bringing out tools to deal with .NET, but that's only one piece of the pie and eventually you're twiddling bits on a bus at a hardware level. To do that reliably you need C/C++.

Imagine you've got microsecond timing requirements and the .NET virtual machine decides to collect the garbage right in the middle of an execution loop. Game over!

And there's one fact that makes this all moot anyway -- for the new projects started today that should be written in .NET/Java/Ruby (Rails? eww ), most of them get written in C/C++ anyway because of momentum and general stubbornness (note that that link is of total lines of code -- I saw another paper a year or two ago where it reckoned C of all things topped the list by far of new projects started, but can't find it). So unfortunately while I'd certainly rather be doing GUI apps in .NET (if I used Windows, most of my work is on embedded Linux), chances are in most companies I'll end up using C/C++ because the architect said so.

[Findecanor]

I studied CS, didn't necessarily want to end up code monkeying with C++ every day. It serves its purpose, but it's by no means beautiful or elegant and when you look at what else was available at the time (Jesus man, Smalltalk?), he could've done much better. I love the benefits that come with objected-oriented programming but something very important and beautiful was lost when we left C.

There was already Objective-C -- a C with some Smalltalk thrown in ...

Many languages that have evolved have done so as a reaction to the shortcomings of C++. One of them is Java. It would not be as it is, if it hadn't been for C++.

However, horse**** on the `Memory leaks are not avoidable in a large C++ app'. All it takes is discipline. Throwing a few tools at it like valgrind to check you're crossed your Is and dotted your Ts doesn't hurt either.

If you have enough discipline, you could perhaps find all memory leaks and plug them, but it can sometimes be hard to do .. or even to see that you have a leak in your program.

Another aspect of manual memory mgmt vs. GC is that in many cases you don't just manage memory objects, but many other types of resources as well: most often they are operating system objects of which you can only have at most N at once. If you manage resources manually, then you can often manage both memory and other resources the same way, but with GC you can't -- you still need to manage some resource manually. (sticking the deallocator in finalize() won't work, because you can not tell when it will be called)

Valgrind works only on a low level and will only detect leaks of memory. I have worked with code that lacked a pthread_destroy_xx() call. The bug did not incur any memory leak, and there were no resource leakss under Linux, but resource leaks were (eventually) found when the program was ported to Windows, because the pthread implementation is different there.

Imagine you've got microsecond timing requirements and the .NET virtual machine decides to collect the garbage right in the middle of an execution loop. Game over!

You can not have microsecond timing requirements on Windows. I have tried that. It is not a real-time OS. Forget about it.
For embedded systems, there are GC algorithms in the literature that are deterministic enough for hard realtime apps, but I don't know if they are available anywhere, or used for anything. They do have much overhead though.

[xwhatsit]

There was already Objective-C -- a C with some Smalltalk thrown in ...

Many languages that have evolved have done so as a reaction to the shortcomings of C++. One of them is Java. It would not be as it is, if it hadn't been for C++.

Yes there's that The same reason we wouldn't have high performance four-stroke motorcycle engines if it weren't for Soichiro Honda being pissed off with two-strokes.

If you have enough discipline, you could perhaps find all memory leaks and plug them, but it can sometimes be hard to do .. or even to see that you have a leak in your program.

The easiest thing to do is not to create them in the first place -- sticking to rules like RAII helps here.

Another aspect of manual memory mgmt vs. GC is that in many cases you don't just manage memory objects, but many other types of resources as well: most often they are operating system objects of which you can only have at most N at once. If you manage resources manually, then you can often manage both memory and other resources the same way, but with GC you can't -- you still need to manage some resource manually. (sticking the deallocator in finalize() won't work, because you can not tell when it will be called)

Quite -- I've found GC helps with the easy stuff, but often you still need to have a pretty good understanding of what's going on underneath. And having resource locking and management further obfuscated and hidden definitely doesn't help.

Valgrind works only on a low level and will only detect leaks of memory. I have worked with code that lacked a pthread_destroy_xx() call. The bug did not incur any memory leak, and there were no resource leakss under Linux, but resource leaks were (eventually) found when the program was ported to Windows, because the pthread implementation is different there.

I get nervous when people say things like `oh well, it's POSIX, should be able to port it in a week or two' for those kinds of reasons You're right. Our fancy tools don't always save us -- that goes for both valgrind and GC

You can not have microsecond timing requirements on Windows. I have tried that. It is not a real-time OS. Forget about it.
For embedded systems, there are GC algorithms in the literature that are deterministic enough for hard realtime apps, but I don't know if they are available anywhere, or used for anything. They do have much overhead though.

Yes I've heard Windows isn't too flash for that. We use RT Linux for that reason. 50KHz square wave out of a GPIO pin into a scope -- rock solid, no jitter, even when loading the thing up with all kinds of CPU and I/O bound other processes. That's only 20us of course but it's good enough.

[HaveANiceDay]

Oh god, you mentioned C++0x. The last thing C++ needs is more features T_T.

[dracaXL]

This thread is an interesting read, despite not being a programmer!

[keyboardlover]

Damn...that girl likes her java!

[xwhatsit]

Would be more interesting if more programmers had boobs.

I know programmers with boobs.

Doesn't mean they're female.

[keyboardlover]

There are five female developers on my current team.

[xwhatsit]

I remember some stunners in my CS classes when I was at uni -- sadly, they're probably all now earning far more than me

[quadibloc]

You can not have microsecond timing requirements on Windows. I have tried that. It is not a real-time OS. Forget about it.

So? Should people writing programs not intended to run under Windows have to use assembler language?

It's true enough that most Windows applications could be written in languages with garbage collection and other nice features. For the typical user, there's only one kind of program that actually takes the hardware's raw performance to its limit.

Programs like Duke Nukem.

[Findecanor]

It's true enough that most Windows applications could be written in languages with garbage collection and other nice features. For the typical user, there's only one kind of program that actually takes the hardware's raw performance to its limit.

Programs like Duke Nukem.

We are not talking about raw performance. Realtime is about latency: being able to respond to input in a timely manner.
PCs are used for controlling all kinds of industrial processes, assembly lines, robots, etc. where there might not be very much computation but where timing is important.

In my case, it was not even about an industrial setting. It was a desktop user interface gizmo that provided 3D pointing and force feedback: something very useful for artists and designers. The hardware was big and strong enough to poke an eye out ... if programmed that way. Therefore, the software, (written in C++, running under Windows) had a built-in fail-safe at the low level: If the cumulated movement vector for a time slice became too large, it shut off. This happened, of course, every now and then, when you least expected it. On a proper real-time OS, it wouldn't have.

[Wibox]

Bjarne Stroustrup is about as anti-UNIX as it gets. At least Ken Thompson still uses something POSIX...

   Being really good at C++ is like being really good at using rocks to sharpen sticks. -- Thant Tessman
    Arguing that Java is better than C++ is like arguing that grasshoppers taste better than tree bark. -- Thant Tessman
    There are only two things wrong with C++: The initial concept and the implementation. -- Bertrand Meyer
    C++ has its place in the history of programming languages. Just as Caligula has his place in the history of the Roman Empire. -- Robert Firth
    C++ is history repeated as tragedy. Java is history repeated as farce. -- Scott McKay
    C++ is like jamming a helicopter inside a Miata and expecting some sort of improvement. -- Drew Olbrich
    C++ is the only current language making COBOL look good. -- Bertrand Meyer
    C makes it easy to shoot yourself in the foot; C++ makes it harder, but when you do, it blows away your whole leg. -- Bjarne Stroustrup
    C++: Simula in wolf's clothing. -- Bjarne Stroustrup
    C++ will do for C what Algol-68 did for Algol. -- David L Jones
    Historically, languages designed for other people to use have been bad: Cobol, PL/I, Pascal, Ada, C++. The good languages have been those that were designed for their own creators: C, Perl, Smalltalk, Lisp. -- Paul Graham
    I consider C++ the most significant technical hazard to the survival of your project and do so without apologies. -- Alistair Cockburn
    If C++ has taught me one thing, it's this: Just because the system is consistent doesn't mean it's not the work of Satan. -- Andrew Plotkin
    If you think C++ is not overly complicated, just what is a protected abstract virtual base pure virtual private destructor and when was the last time you needed one? -- Tom Cargill
    I invented the term Object-Oriented, and I can tell you I did not have C++ in mind. -- Alan Kay
    It has been discovered that C++ provides a remarkable facility for concealing the trival details of a program -- such as where its bugs are. -- David Keppel
    Java is, in many ways, C++--. -- Michael Feldman
    Java, the best argument for Smalltalk since C++. -- Frank Winkler
    PL/I and Ada started out with all the bloat, were very daunting languages, and got bad reputations (deservedly). C++ has shown that if you slowly bloat up a language over a period of years, people don't seem to mind as much. -- James Hague
    The last good thing written in C++ was the Pachelbel Canon. -- Jerry Olson
    To me C++ seems to be a language that has sacrificed orthogonality and elegance for random expediency. -- Meilir Page-Jones
    Whenever the C++ language designers had two competing ideas as to how they should solve some problem, they said, "OK, we'll do them both". So the language is too baroque for my taste. -- Donald E Knuth
    Within C++, there is a much smaller and cleaner language struggling to get out. -- Bjarne Stroustrup
    {Major-Willard} C++ damages the brain ... -- EWD
    C++ is the best example of second-system effect since OS/360. -- Henry Spencer
    C++ is an insult to the human brain -- Niklaus Wirth
    All new features added to C++ are intended to fix previously new features added to C++ -- David Jameson
    C++: glacial compiles, insane complexity, impenetrable errors, laughable cross-platform compat, basically useless tools. -- Aaron Boodman
    Life is too long to know C++ well. -- Erik Naggum
    If you like C++, you don't know C++. There's a mutual exclusion going on here, and I've yet to see a counter-example other than possibly a few of the members of the standards committee. -- ssylvan in reddit.
    *Oh, definitely. C++ may not be the worst programming language ever created, but without a doubt it's the worst ever to be taken seriously. -- Mason Wheeler
    C++ is to C as Lung Cancer is to Lung.
    I think maybe the guy who invented C++ doesn't know the difference between increment and excrement. -- smcameron
    C++ is more of a rube-goldberg type thing full of high-voltages, large chain-driven gears, sharp edges, exploding widgets, and spots to get your fingers crushed. And because of it's complexity many (if not most) of it's users don't know how it works, and can't tell ahead of time what's going to cause them to loose an arm. -- Grant Edwards
    C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor
    I believe C++ instills fear in programmers, fear that the interaction of some details causes unpredictable results. Its unmanageable complexity has spawned more fear-preventing tools than any other language, but the solution should have been to create and use a language that does not overload the whole goddamn human. -- Erik Naggum
    I may be biased, but I tend to find a much lower tendency among female programmers to be dishonest about their skills, and thus do not say they know C++ when they are smart enough to realize that that would be a lie for all but perhaps 5 people on this planet. -- Erik Naggum
    C++ is a language strongly optimized for liars and people who go by guesswork and ignorance. -- Erik Naggum
    c++ is a pile of crap. -- Theo de Raadt
    With C++, it's possible to make code that isn't understandable by anyone, with C, this is very hard. -- Mike Abrash
    Whenever I solve a difficult problem with C++, I feel like I've won a bar fight. -- Michael Fogus
    C is C++ without the BS. -- SocialPhatology
    [keeping somebody] from using C++ makes me feel like I saved a life -- aiju
    C++ is probably the only language where the error [message] can be longer than the program -- aiju

[TacticalCoder]

Wibox, I think you forgot one of the best quote about C++:

I made up the term 'object-oriented', and I can tell you I didn't have C++ in mind

-- Alan Kay, OOPSLA '97

[vun]

Wibox, I think you forgot one of the best quote about C++:

I made up the term 'object-oriented', and I can tell you I didn't have C++ in mind

-- Alan Kay, OOPSLA '97

That quote is in there as well.

That being said; this thread is very entertaining even though I don't really know much about coding.

[TacticalCoder]

That quote is in there as well.

That being said; this thread is very entertaining even though I don't really know much about coding.

: )   good catch!   There were so many I missed it : )

[binarypie]

Problem is, it's so popular, everybody uses it, commercial libraries are written in it, the entire industry has standardised on it. Which means as a programmer, one inevitably has to deal with it. So it pisses me off because it could've been so much better. C++0x is getting there but it's not enough.

 
Firstly, the `you' in my post wasn't you per se -- it was a general `one'. I'm sure you can manage memory.

However, horse**** on the `Memory leaks are not avoidable in a large C++ app'. All it takes is discipline. Throwing a few tools at it like valgrind to check you're crossed your Is and dotted your Ts doesn't hurt either.

.NET has its place. But there's some things it will never replace. Controlling real-time machinery is one of them. Sure, Beckhoff and the like are bringing out tools to deal with .NET, but that's only one piece of the pie and eventually you're twiddling bits on a bus at a hardware level. To do that reliably you need C/C++.

Imagine you've got microsecond timing requirements and the .NET virtual machine decides to collect the garbage right in the middle of an execution loop. Game over!

And there's one fact that makes this all moot anyway -- for the new projects started today that should be written in .NET/Java/Ruby (Rails? eww ), most of them get written in C/C++ anyway because of momentum and general stubbornness (note that that link is of total lines of code -- I saw another paper a year or two ago where it reckoned C of all things topped the list by far of new projects started, but can't find it). So unfortunately while I'd certainly rather be doing GUI apps in .NET (if I used Windows, most of my work is on embedded Linux), chances are in most companies I'll end up using C/C++ because the architect said so.

Despite being slightly off topic.

Bring a computer programmer of many talents I feel the need to respond to this.

It really depends what you are building as to what tools you will need.
I think the blanket statement of php/ruby/python/java/wtvever will eventually be rewritten in c/++ at some point for performance is off-base.
If one is trying to solve a problem that is very CPU bound or perhaps very memory bound then maybe c/++ might be the right option.
If your problem is IO bound or connection bound then it really doesn't matter what language you write your software in. The problem is somewhere else.

What it really comes down to is performance versus productivity.
Being productive at the same level in c/++ as say python is a much harder task for most programmers.
Although, not all.

If I was building a new project I would also choose a language that I know will be easier scale up staff wise over scaling up performance wise.
If I need to I can break parts out and write them in languages that make sense for the job. Scala and Erlang seem to be a big deal lately over c/++.
Premature optimization can, and almost always does, doom a project.

P.S if any javascript-type programmers want a job in San Francisco. PM me. I am hiring.

[xwhatsit]

I think you misundestood me. What I wrote is not that many programs written in Python/Ruby/Java get rewritten in C/C++ (that would be a strange thing to do unless there were serious issues with the original program in the original language). What I wrote was that although many new programs written today would be very well served by being written in .NET or Ruby/Tk, precisely because performance isn't an issue for many (most?) desktop-type programs. However, a good chunk of them don't, and get needlessly written in C/C++ because of momentum and in many software houses `that's the way things are done here'.

As for your quote `Being productive at the same level in c/++ as say python is a much harder task for most programmers', that's a bit of a WTF. Unless one is a web-developer type, in which case programmer isn't quite the right word.

[ch_123]

I can't remember who said it, but -

"If programming in Pascal is like being locked up in a straitjacket, and programming in C like playing with knives, then programming in C++ is like juggling with chainsaws."

[woody]

Programming is evil, anyway. Especially nowadays.

[HaveANiceDay]

The real question is what keyboard does IBM's Watson use?  THAT is the future of programming.

Show Image

Us programmers are a very dumb breed, constantly working towards making ourselves unemployed. Unless you are one of those programmers that write terrible convoluted code and thus securing your job, you are doing it right :P

[zmurf]

When talking middle level languages I prefer standard C or Objective-C. Objective-C is really nice... and the Openstep framework is quite up to date when compared to Apples Nextstep framework.

If we go up a nudge to the high level languages I really like C#. Microsoft has really made some good effort in making it fast and easy to produce competent, easy readable, and advanced code. Thing like linq, event handling and lambda expressions is really awesome. For this reason most of my WIMP based linux apps is made in Mono (but since most of my Linux software isn't WIMP based I mostly code in Objective-C when creating linux software.)... and the ones I made for Android have been done in MonoDroid.

Otherwise I'm looking quite a lot into Googles Go! language... is quite interesting with some really cool features.

But my one true love when it comes to programming is mc68000 assembler.
Programming assembler for mc68000 on an classic Amiga... that's what I love doing on my spare time. Which I unfortunately haven't got enough of.