Slashdot Mirror
Google Engineer Decries Complexity of Java, C++
snydeq writes "Google distinguished engineer Rob Pike ripped the use of Java and C++ during his keynote at OSCON, saying that these 'industrial programming languages' are way too complex and not adequately suited for today's computing environments. 'I think these languages are too hard to use, too subtle, too intricate. They're far too verbose and their subtlety, intricacy and verbosity seem to be increasing over time. They're oversold, and used far too broadly,' Pike said. 'How do we have stuff like this [get to be] the standard way of computing that is taught in schools and is used in industry? [This sort of programming] is very bureaucratic. Every step must be justified to the compiler.' Pike also spoke out against the performance of interpreted languages and dynamic typing."
doWhatIWant()
and
doItFaster(doWhatIWant)
- None can love freedom heartily, but good men; the rest love not freedom, but license. -- John Milton
Segmentation Fault
"Efficient" languages are too complex. "Simple" languages are too inefficient.
Normally I'd write this off as "duh" but this is Rob Pike.
Oh wait, he's pushing something new that somehow manages to be easy and efficient? OK...
Pike detailed the shortcomings of such languages as a way of describing the goals that he and other Google engineers have for a new programming language they developed, called Go.
Oh, so he's pushing a competing product and denigrating his competition? Nothing to see here, I think.
I'd like to hear what he thinks about Perl.
0 = 1 + e^(Alt something)
English estas too malmola! Paroli en Esperanto!
And where is the news here?
Picking the right tool for the job doesn't just cut down half the work time, but can help offset what sloppy workers do to destroy quality.
C++, Java, perl, C, forth, and sh are all different languages, and well suited to different jobs. But when all you have is a nailgun (i.e. all you are fluent in is a single language), every project starts looking like nailgun job, including your own foot.
Google Engineer promotes Google language Go and claims it addresses weaknesses of existing languages, including Java and C++.
Democracy Now! - your daily, uncensored, corporate-free
This guy has a lot of nerve telling other folks what programming language to use.
You should bash Java, and C++ devs will agree. You should bash C++, and Java devs will agree.
Now you bashed both languages that has probably the most devs. Except some dynamic languages, of course (PHP and JS comes to mind).
Oh, you insulted them, too.
OMG...
How about "Rob Pike Decries Complexity of Java, C++" instead?
|Rob Pike| >> |Google Engineer|
Shorter Rob Pike: all those other languages suck, but the one I invented rocks. It's elegant and simple just like Lisp was back in the sixties!
I'm reminded of this blog post I read, where the author described it as "The Hurricane Lantern Effect". You look at someone else performing a task, and you think "geez, what an idiot! I can do it better in ten different ways!".
Then they hand the task off to you, and you slowly realize that each of your ten improvements isn't actually any better.
I bet you that if it's still around in ten years, someone else will decry Go 10.0 as being a "bureaucratic programming language".
These sorts of languages (and the underlying religious cults they bring with them) are probably appropriate for some uses. But what I see done in my life-critical real-time processor applications borders on criminal. Data hiding? How the f'ing hell do I check what is going on to the bit level is some twit determined to "hide the data". This is particularly apt right now, because we are adding a feature to our code that was almost trivial to add to our FORTRAN simulations, and because of the "cult of classes" C++ programming it's damn near impossible in the final product, and completely impossible to look at and tell what the heck it's doing. Trying to test it like a black box is never going to get to the level we need.
We started having peer reviews of the code, and my colleagues and I are the designers of the system, so we would hypothetically need to sign off on it. We went for two hours to get 10 lines into it, no one could explain how it was working but that we should just "trust the compiler". That didn't fly with us, so the solution was to *not have us present at the peer reviews* since we were "disruptive"
What we need is someone that can write straightforward procedural code, but no one seem to be willing or able to do it any more. It has all the features of a cult or a secret society, even when you get someone to understand and agree, they won't deviate from their dogma.
See, I'm already thinking about extentions.
doWhatIWantEvenThoughImTellingYouToDoSomethingElse()
Nostalgia isn't what it used to be.
slowDownAndCrashSoICanSellAnUpgrade();
The ______ Agenda
Slashdot previously interviewed Rob Pike.
Ceci n'est pas une signature.
Go has the same problems. They try to make it 'simpler' but along the way they actually make it more complex.
For example, try-catch-finally idiom is an easy and standard way to deal with exceptions. But no, they had to invent their own half-assed implementation just to be 'minimal'.
Also, they insist on using fucking _return_ _codes_ to indicate errors. WTF? It only makes code more complex because of tons of stupid 'if error' statements.
Personally, I like Rust's ( http://wiki.github.com/graydon/rust/project-faq ) design more. At least, it has some new features.
What do you expect? To me it appeared to be little more than stumping for the programming language he wrote - Google Go. Which has yet to impress me. They say that it's flexible like an interpreted language but fast like a compiled one. To me, it seems like it's missing all the cool shit that makes me USE an interpreted language, but doesn't provide the same low-level access that makes me use a compiled one! All languages have their niche, I suppose, and I guess I'm just not the target demographic for Google Go
If I had a nickel for every time I had a nickel, I'd be richcursive!
You could at least mention that Rob Pike had a large part in designing Plan 9, a programming language called Limbo, and oh, UTF-8, and that by "he and other Google engineers", TFA means Ken Thompson, who created B (a predecessor to C) and had a part in creating an operating system called Unix.
These two people are the closest thing to a "computer scientist" there probably is, and I'd wager they know quite a lot about programming language design. Pike is known about his feelings towards programming languages like C++.
Rob Pike made a talk about Go and programming language design and makes some interesting points. It's available on youtube.
It's like the old saw about asking a Christian, "Is it okay to smoke while praying?" versus "Is it okay to pray while smoking?"
Of course competent programmers should handle C and all that. The point is, however, that the new ground to be discovered will be done by having non-programmers be able to quickly, easily, and accurately practice their craft with the aid of numerical analysis and data processing. It's the difference between doing something in an afternoon and needing to incorporate a company; pitch ideas; apply for grants/labs; &c.
The cynical programmer will say that the easy languages will inevitably allow fuckups. Well, that's true I guess (although isn't it an interesting project to reduce these?), but in any real project there are already several categories of fuckups (often methodological/statistical) which the programmer is, usually, blissfully unaware of, and will screw the data/results on a much grander and more subtle scale.
Here is a great example of an "empowering" language: http://processing.org/ Yeah, a `true programmer' may call it inefficient, but if it allows someone to do what they previously could not even conceive of, isn't this an infinite gain in efficiency?
"They were pure niggers." – Noam Chomsky
I actually think that perl is the best programming language every designed.
(Waits for storms of laughter to subside)
No, really, I'm completely serious. perl is the English of programming languages. It takes the most useful parts of everything and mixes them all together into a useful conglomerate.
Much the same way you can use English to write a scientific dissertation, a sonnet (in full Billy S mode), or O RLY? perl can be as descriptive and formal or as loose and unbounded as the programmer chooses and it all JUST WORKS!
I **lothe** "bondage and discipline" languages that force me to think and write a certain way just because some would-be language guru thinks HIS way is the One True Path to enlightenment. perl gives me an expressive, more-than-one-way-to-do-it language that lets me think and work the way that best fits the problem at hand.
I have written enterprise-level perl code optimised for long-term maintainability and reliability (an LDAP server replication program that did schema translation). And I have written 5-second hacks that solved an immediate problem quickly and efficiently. perl lets me do this. No other language I've used matches perl's sheer versitility.
I love perl!
And I'm not at all ashamed to admit it.
DG
Want to learn about race cars? Read my Book
How many words are in english? A lot. (According to the OED folks, "The Second Edition of the 20-volume Oxford English Dictionary contains full entries for 171,476 words in current use, and 47,156 obsolete words. To this may be added around 9,500 derivative words included as subentries.") How many words does the average native english speaker know? According to this random website, 12,000-20,000 words. So English is complex, yet just 10% of the language meets a native speakers needs (less than that as we don't use all the words we know in normal conversation...except my wife when she's mad at me, then I hear every word she knows, many repeatedly)
So Java is complex. C++ is complex. I program in Java for my daily bread and I certainly don't use the entire language. It's only as complex as I need it to be. The complexity of my code is driven by what I'm trying to do, not by the language itself. And for code maintainability, I try to keep things as simple as possible.
This same rant has apeared generation after generation, and often from peope smart nough to know better. It's why COBOL was invented, with syntax like.
I kid you not, Adm Hopper actually thought that would make programming easier, and she was no moron.
Guess what guys? The reason programming is hard is because you must clearly and unambiguously state what you want to have happen. Yes, the languages could surely be better - the syntax and intricacies of C++ are pretty nightmarish, and Java only fixes some of those issues while introducing others. There's surely a better way to do resource management, and multi-threading, that are less error prone without making you give up needed control. But it's still going to be hard to solve hard problems, and you're still going to need to be very precise and detailed in describing how to solve a problem.
Irreducible complexity is irreducible.
Socialism: a lie told by totalitarians and believed by fools.
I kinda miss those days--easy to learn and embedded 6502 machine code subroutines to make things move faster.
"The only legitimate use of a computer is to play games." - Eugene Jarvis
The summary makes him sound like a winer with no solution. If you read TFA, you see he's pimping Google's new language, Go. That's perfectly understandable since they pay him; but TFA also points out that languages accumulate cruft over time, and Go is a baby.
For all intensive purposes, "whom" is no longer a word. That begs the question, "who cares"?
You obviously aren't paid by the hour to write java code, or else you'd have come up with something like:
ThreadFactory.getInstance().setExecutionTarget(new Runnable(){ public void run (doWhatIWant() }).addExecutionObserver(ExcecutionItemObserverFactory.getInstance()).start()
Which is much more "enterprise ready" than yours.
UTF-8 was one moment of genius insight ("make sure the escape sequences cant be confused with notmal characters"), and the rest was trivial. The details weren't even very well thought through beyond that one clever idea: real standards deal mostly with error handling, and UTF-8 totally dropped the ball on that, leaving RFC 3629 to pick up the slack. If anything, co-inventing UTF-8 is an argument that he doesn't know much about real-world programming (Ken has of course proven himself elsewhere). Being the author of RFC 3629 (F. Yergeau) and cleaning up the mess would make one's opinions much more interesting!
Socialism: a lie told by totalitarians and believed by fools.
workItHarder makeItBetter doItFaster makesUsStronger moreThanEverHourAfterHour workIsNeverOver
The idea of programming as a semiskilled task, practiced by people with a few months' training, is dangerous. We wouldn't tolerate plumbers or accountants that poorly educated. We don't have as an aim that architecture (of buildings) and engineering (of bridges and trains) should become more accessible to people with progressively less training. Indeed, one serious problem is that currently, too many software developers are undereducated and undertrained.
Obviously, we don't want our tools--including our programming languages--to be more complex than necessary. But one aim should be to make tools that will serve skilled professionals--not to lower the level of expressiveness to serve people who can hardly understand the problems, let alone express solutions.
We can and do build tools that make simple tasks simple for more people, but let's not let most people loose on the infrastructure of our technical civilization or force the professionals to use only tools designed for amateurs.
- Bjarne Stroustrup
No sig today...
Should have RTFA I guess, I now realize Mr Pike just talks in circles and really didn't have anything of value to say other than 'programming is hard'.
No, he doesn't. TFA-writer Joab Jackson talks in circles and doesn't have anything of value to say. Mr. Pike, on the other hand, appears to be saying that Google Go fixes a lot of unnecessary complexity in Java and C++.
His keynote isn't linked from either the Slashdot summary or TFA, but can be seen here: http://www.youtube.com/watch?v=5kj5ApnhPAE
Want a high quality FOSS RTS game? Try Warzone 2100!
Big != evil. While M$ uses their clout to squish the competition, bribe the government(s), and get away with plenty other unlawful stuff, Google grows mostly by providing a superior product. There is a long way before (if) they become the new M$.
We have a FoobarFactoryFactory class in the project I'm currently assigned to... yes, it's a factory that creates factories (which in turn create foobars). And the foobars are themselves generic-ish objects which can contain any number of different types of data.
And they have the nerve to tell me one of the qualities of higher-level devs is that "they tend to make things simpler than entry-level devs".
Even though for most people that's the first hurdle (and one that they fail), I'm not sure that this is the main reason programming is hard. I know plenty of people who've mastered the basic mechanics of doing that, and yet still don't program too well because they can't make their problem-solving ability scale to larger, more complex problems. You can understand at a fairly low level every single step that will be carried out to execute your program, yet be completely unable to write a large, modular and maintainable software system.
Are you adequate?
One of C's great advantages is not only that it is simple and very fast, it is also very close to the hardware -- when you make local variables, structures, assignments, etc... you have a good idea what the compiler needs to do. Likewise control structures, statements and so on.
The reason it is used is -- frankly -- because it kicks the ass of every other language out there (except machine and assembly) when it comes to both size and performance. This is because a C fragment turns into something very efficient and "close to the metal" if the compiler is even half-good, and that in turn is because what C does is very close to what the CPU does. Spend a couple weeks writing a C compiler -- just a C to ASM one for any CPU -- you'll see what I mean.
The only sense in which C is "harder" is that it takes more statements - because they tend to do simple things - than a higher level language to do many things. A little writing, a little building your own library... you'll have a nice resource for lists, memory management, graphics, in whatever area(s) your interest(s) lie(s.) And at that point, it's not harder -- it's easy, and it's fast as hell to write, and it *will* kick the butt of most other languages, as long as the understanding of the problem to be solved by the programmers is reasonably similar.
Also... I'm a huge fan of Python, use it all the time. Great language, totally wiped Perl out of my life (and for that, I am eternally grateful.) And as an interpreted language, it's not all that slow -- especially on a modern machine. But compared to C... no, I'd *never* use Python as a language for anything that required serious computation. You don't even need to go to C++ for some pretty cool OO - it's not only easy to do, it's educational and you'll actually understand what OO is doing, and why. If you need crazy OO, C++ is right there, and can remain efficient if you're really careful. Me, I rarely go there, but YMMV.
That whole too complex thing... what, was he hired by Google as a janitor? Or a janitor's helper? Seriously, too complex? For whom? Is he trying to teach a German Shepherd to program? Twit. If you came to my company for a job, and you told me C was "too complex" or "too hard", I'd just show you the door.
Have our standards really dropped that far?
I've fallen off your lawn, and I can't get up.
What we have here is feature creep.
Usage: km/h for speed (kilometers per hour); kph for very slow impulses (kilopond hours).
C++ done right with scoped classes doesn't need garbage collection. No, really it doesn't, most people have just never worked with scoped classes, and it's mind-boggling that they don't show up in C++0x (other than the half-useless auto_ptr we've always had). I have a real problem with garbage collection in production code, because it's freaking hard to find and plug resource leaks. If you forget to close a file in a garbage collected language, it will probably get closed eventually when the garbage collector cleans up, but the program likely has some bug anyhow, and the GC has made it a horrible intermittant bug that changes behavior in a lab environment!
C++ has two key abilities that any good language needs, but few have: scoped resoruces (but only in that it allows you to add them yourself!), and const references. Why are people still making high level languages where references aren't const by default?!? In C# I can't (usually) tell from the function signature whether changing an argument will change the caller's copy, nor can I be sure from an interface that a given function won't alter what I pass to it - what insanity is that? (And Java is only slightly better.)
Socialism: a lie told by totalitarians and believed by fools.
It's why COBOL was invented, with syntax like.
SUBTRACT DEBIT FROM BALANCE GIVING NEWBALANCE.
I kid you not, Adm Hopper actually thought that would make programming easier, and she was no moron.
COBOL was designed like this so it could be read and understood by corporate auditors and accountants - and for the recruitment and training of accountants as COBOL programmers.
It makes perfect sense when you remember that modern bookkeeping rules are the product of hundreds of years of law and practical experience which the neolithic geek did not have.
Stroustrup (inventor of C++) is hardly a source of unbiased opinion on this topic. His elitist argument comes off sounding like "Calculators are bad because anyone can use them, engineers should use slide rules. Would you want someone designing a bridge who was too stupid to use a slide rule?" Professional programmers can be more productive if they are able to spend more time creating and less time fighting with their tools, and denying amateurs access to those tools sounds more like job-protectionism than professionalism.
Support Right To Repair Legislation.
Nearly everything I was unhappy about in C++ is better in D.
I suppose it's worth expanding my polymorphism comment slightly. People who think that objecitve C's Messaging concept is just semantic sugar are not understanding it clearly.
In objective C you don't "call an object method" but rather you pass a message to the object. THe object, if it chooses to reply, does not "return" a value but instead sends back a reply message.
What's the difference? Well in implementation very often nothing. The message that is sent is a message name and a list of calling args and their names. 99.9% of the time the object chooses to resolve this message by finding a method that corresponds to that prototype. So that looks just like C++. But the thing is, it does not have to do that. It could choose to re-interpret the message. And in particular it might use some other recently method added later than "linking" time to the object. Thus how the method calls are bound does not happen at link time. They often are prebound then for efficiency, but they do not have to be. The same is true of the return values.
THis makes it more like java in a way.
But the nice thing is that the overall syntax is just a thin layer on basic C.
Another reason that Objective C is so nice now is that it had a chance to mature and modernize out of the spotlight. Having lived mainly in the apple ecosystem it has a lot of standard libs now with dictionaries and core data tied to persistent storage, MVCs, and so forth that are all (mostly) self consistent and not the tower of babble on finds in java. THings like get-set commands can be handled by decorators rather than explicit coding. That's cool because by letting the compiler pre-processor define what is in a get set you can inherit all sorts of things like listeners binding to your variables that you did not explicitly encode. Just recomoile your code and poof you inherit all the new features.
Some drink at the fountain of knowledge. Others just gargle.
What about an environment where you can eathily hide complexity and meta-information? Or, possibly, add new literalth? Where the bathe of the language is shifted to the Abthtract Thyntax Tree, not tho much the thyntax.
Fixed that for you. Programming with abstract syntax trees has been possible since Common Lisp if not earlier.
I'm aware of who he is, what he does now and what he's done in the past. I've now seen his keynote.
My opinion hasn't changed. He has nothing to say and talks himself in circles, I'm guess you just don't see it due to lack of understanding, of course maybe I'm the one that doesn't understand.
Who knows, but I'm going to stick with my original assessment that he's just a blow hard spewing about his latest creation and how everyone elses sucks because his creation some how mysteriously fixes the problem that no one else has.
You go listen to what he has to say, I'll continue getting things done while you go play with a new language because its 'better' until you realize that its exactly the same as all the others.
When you start telling me that the language is the problem I realize instantly that you aren't that great of a programmer. My one exception to this is Visual Basic (not BASIC, VB specifically). It is a shitty environment because of the shit support library MS made for it.
Persistent Volume manager for Kubernetes - https://github.com/dwimsey/openshift-pvmanager
Sorry, but if you can't "think like a programmer does", you won't be able to create anything but the most trivial program, ever. The difficulty of programming isn't learning language and syntax, it's "thinking like a programmer does". That's precisely the thing that must be accomplished to write complex software, and that's precisely the thing that is difficult to do for most of the population.
Sorry to disappoint.
Karma: Poor (Mostly affected by lame karma-joke sigs)
I think you'd be amazed at how much some of the world's companies rely on Excel macros.
Every time I start to have faith in humanity, I ruin it by driving to work between 7 and 8 am.
Objective-C is definitely simpler than C++. A little complexity is creeping in now, especially with Blocks. But overall it adds very little to C.
September 2011: Looking for Cocoa/iOS work in Boston area Cocoa Programmer Quincy, MA
Even [XYZ]-modem used a similar setup.
Not quite. Xmodem and Ymodem use SOH and STX to denote start of sectors and ACK/NAK, but after that it's just a raw 8-bit file dump to the checksum/crc bytes with no concern for character set encoding. Zmodem uses DLE and escapes out most of the C0 bytes (XON/XOFF and CAN must be escaped regardless of session flags), but doesn't use the rest of the codes for anything.
Most of C0/C1 codes mixed right in with the text for formatting/presentation, e.g. embedding backspaces followed by underscores to get underlined text. Some of the others did link-level too. It was a mess, so much so that parsers for ANSI X3.64 / ECMA-48 style escape sequences take a LOT of work to get right (passing 'vttest' is not trivial).
UTF-8 isn't bad. It specifies that character decoding be done before any other processing including C0/C1 and ANSI escape sequences, which makes it very easy to integrate on the reading side. Harder is dealing with wide chars on the screen and user I/O. Compared to Avatar's repeat character and ANSI fallback features, it's much more bang for the buck. And let's not talk about "ANSI Music" and it's use of SO (Ctrl-N) because it's the "music symbol" in CP437!
(Disclaimer: I've written a console-based terminal emulator that does a decent VT102/220, UTF-8, X/Y/Zmodem/Kermit, and lots of other things.)
We need a new OS too. There hasn't been a decent OS since CP/M.
There's Emacs.
I must say I rarely find a comment on /. that I agree as much as I do with yours.
C and Python march hand in hand, one is for machine performance, the other is for programmer performance. If someone thinks C is too complex or too hard to learn then he shouldn't be working with programming computers, he's likely to cause great damage sooner or later.
However, there's one point where C will need a new approach: multiprocessing is coming. Since it seems like Moore's law has hit the ceiling at 3 GHz CPU speeds, all progress in performance for the foreseeable future will come from increasing the number of CPUs and cores working together.
I have done a lot of programming in multithreads using the pthread library lately and I feel that something better is needed, pthread is not close enough to the metal. I think some new fundamental elements may be needed in the language.
C is so great for programming because it mirrors the hardware closely. For instance, pointers work so well because they represent memory addresses. Before I learned C I had worked with Fortran, I still have some programs I wrote over 25 years ago. Today I look at those old Fortran programs and I wonder why I did some things the way I did. I see some convoluted loops and wonder why I did that because, with a quarter century hindsight on using pointers, I create almost instinctively the most efficient set of pointers to handle a data structure.
What programmers often don't realize is that the correct data structure may get orders of magnitude improvement in performance. To give one example, years ago, when I studied artificial neural networks, I read an article in the Doctor Dobb's magazine (January 1989, page 32, "Neural Networks and Noise Filtering" by Casey Klimasaukas). It was a good article, but the source code in C that came with it sucked. There was a struct _pe representing a processing element and each struct _pe had an array of struct _conn representing the connections to that element.
The problem is that in an artificial neural network what each neuron is doing is, basically, a convolution of two arrays. To do that efficiently in hardware you need to have the array elements contiguous in memory. When you put the connection weight in a structure together with other data you will not have that value contiguous with the weights of the other connections.
From an "object oriented" point of view that program was perfect. But if you want to use your multi-core CPU with that, the program sucks. That's the benefit you can get from programming in C that you won't get with other languages.
And don't tell me that raw performance does not matter because you can always get faster hardware. CPU clock speed has stopped at 3 GHz, we must learn to use our multicores if we want to evolve from now on.
As far as I'm concerned COBOL is the perfect programming language. I'm a little biased as I worked as a COBOL programmer for a time, but you have to admit the syntax is very easy to read.
A well written COBOL program is like reading a little battle plan. It tells you, in plain English, what it intends to do and the ruthlessness of a COBOL compiler forces you to create readable, structured code.
Every COBOL programmer knows where the period is supposed to be. C programmers still haven't figured out where the braces should be. It says a lot about a language when you have decades-long debates about punctuation in your code. It encourages a lack of programming discipline which I feel is the leading reason why software is so buggy today.
Bibo Ergo Sum.
Very hard to find a main stream game that isn't written in C++. What with Ms pushing XNA and some other stuff like that there may start being a few more written in managed languages, but C++ still reigns supreme. Why? Speed. You can write some real efficient (from the processor's point of view) code if needed, but it still has higher level functions like being OO and the boost libraries to make thing easier.
Even on games made to be extensible, C++ is usually at the core. Civ 4 is mostly XML and Python. Pretty much all data is stored in XML, and the interactions of that stored in Python. However, the game engine is written in C++, as is the AI's DLL. The game core maybe you argue that is because they didn't want people messing with it but the AI they released the source code for. It is C++ because speed is essential.
Some programmers love to whine about C and C++, but they endure for many reasons. I'd also point out they form the core of most OSes. Linux is written in C. The Windows kernel is written in C, the higher level API/ABI stuff in C++ and only some of the user stuff in .NET. OS-X is again C and C++ at the low level, and Objective-C higher up. All of this is not coincidence.
The main problems of the major languages are known, but not widely recognized by many programmers.
The killer problems with C today mostly involve lying to the language. "int read(int fd, char* buf, size_t bufl);" is a lie; you're telling the compiler that the function accepts the address of a pointer, while in fact it accepts a reference to an array of char of length "bufl". This lie is the root cause of most buffer overflows. The other big problems with C involve the fact that you have to obsess on who owns what, both for allocation and concurrency locking purposes, yet the language provides no help whatsoever in dealing with those issues.
And that's where we are today.
The language it was written in was Algol 68. What contributed to my success was an expressive static type system, and garbage collection. Unless you specifically turned run-time checking off, you could not break the run-time system.
Oh, and did I mention that the compiler generated low-level efficient code as well?
But there are few Algol 68 compilers around these days.
Looking to what *is* available nowadays, have a look at Modula 3. It's not my favourite style of syntax, but programs written in it tend to run fast and be easy to debug. Again, most of the bugproofing lies in the static checking and garbage collection. And it's a systems language. It has been used for implementing OS kernels and the like, as well as application programs. It's my language of choice at the moment. Get the CM3 implementation. Follow the link in the Wikipedia article.
Another attractive language is OCAML. I haven't much experience with it, but it seems to share the behaviour I've grown to love with Algol 68 and Modula 3. If anything, though, OCAML does too much automatic type inference. This leads lazy programmers to forget to mention types at many strategic code locations. making the code unnecessarily obscure.
Do you know who you are dissing? Did you read the article? No, and no. He never said anything against C, he said C++ was too complex not C. So you echo him and slag him off over your misreading at the same time? One of the founders of your profession? Standards dropped? Yep, sure. But whose?
And I was thinking something a little more classy:
neverGiveThisUp(You);
neverLetThisDown(You);
Common Sense