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

143 of 878 comments (clear)

  1. We all know the ideal language has two functions by spun · · Score: 5, Funny

    doWhatIWant()
    and
    doItFaster(doWhatIWant)

    --
    - None can love freedom heartily, but good men; the rest love not freedom, but license. -- John Milton
  2. Complex? Difficult? Since when? by Anonymous Coward · · Score: 3, Funny

    Segmentation Fault

  3. umm... by deviator · · Score: 3, Insightful

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

    1. Re:umm... by Bryansix · · Score: 3, Insightful

      Right. Basically what we call "High level programming languages" are not all that high level any longer and the compiler is getting off without doing enough work. The language should be simple and the "hard work" should be done by the compiler figuring out the most effecient way to get done what it is being told to get done.

    2. Re:umm... by owlstead · · Score: 3, Interesting

      I'm not saying that that would be it, but I would not mind a programming environment where the text files have gone the way of the dodo. With Eclipse we use a rather strong "Clean Up" where missing keywords (e.g. final) are added and statements are reformatted (etc.). Wouldn't it be easier to do without that kind of stuff? What about comparing the differences of two branches (or new code with the head) where the actual semantic changes are compared vs lines of text? What about an environment where you can easily hide complexity and meta-information? Or, possibly, add new literals? Where the base of the language is shifted to the Abstract Syntax Tree, not so much the syntax.

    3. Re:umm... by FooAtWFU · · Score: 2, Interesting

      I'm no Robert Pike, but I imagine that computer programming as we move to thousands and millions of cores will consist less of telling the computer how to do something, and more of telling the computer what you want to do and having a really smart compiler figure out the details. The more low-level you go, the less chance the compiler has of figuring out what you're trying to do and making it work effectively (and do crazy optimizations like speculative out-of-order execution, and what-have-you).

      But this means that the programming languages of the future will be less imperative and more functional. How that will ever catch on is beyond me.

      --
      The World Wide Web is dying. Soon, we shall have only the Internet.
    4. Re:umm... by ultranova · · Score: 4, Insightful

      But this means that the programming languages of the future will be less imperative and more functional.

      No, that means that the programming languages of the future will be subjective: the computer will interpret your commands in the light of whatever other data it has. This, of course, requires artificial intelligence, and slowly but surely phases away the whole job of programming as a separate skill from commanding people.

      In other words, the ultimate programming languages of future will be known as English, Chinese, etc.

      --

      Forget magic. Any technology distinguishable from divine power is insufficiently advanced.

  4. Missing context... by Akido37 · · Score: 5, Insightful

    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.

    1. Re:Missing context... by CosmeticLobotamy · · Score: 3, Informative

      "WriteLine()" makes perfect sense in the context of the Console class when paired with its newline-less counterpart, Write(), and is spelled wr[down-arrow][enter]. Four keys. Intellisense (or whatever its equivalent in your preferred IDE is). Use it. Quit inflicting functions like "wrtln" on the rest of us.

  5. If C++'s complexity has him vexed by swanzilla · · Score: 4, Funny

    I'd like to hear what he thinks about Perl.

    1. Re:If C++'s complexity has him vexed by mrogers · · Score: 5, Funny
      I'd like to hear what he thinks about Perl.

      Since his talk had no discernible structure, said the same thing in a dozen different ways and won't make any sense this time next year, I'd assume he's a fan.

  6. A new phrase for "U.N. Barbie" by Culture20 · · Score: 4, Funny

    English estas too malmola! Paroli en Esperanto!

  7. And...? by arth1 · · Score: 3, Insightful

    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.

    1. Re:And...? by arth1 · · Score: 2, Insightful

      Anything that a RPN calculator does well at, forth does even better? :-)

      Due to the nature of forth, I would say that it's well suited for applications where being modular is a plus, stack space is not at a premium, initialization time is not at a premium, but execution speed from when execution actually starts (not including initialization) is important.

      Oh, and where you can take advantage of the extra rope you're given (like with C). That people are able to hang themselves with it is no reason for a hardware store not to sell rope. But the hardware store clerk should also be able to tell you when glue would be a better choice.

    2. Re:And...? by jd · · Score: 2, Informative

      Forth is extremely good for hardware control. It seems to have lost the edge it used to have, but once upon a time Forth was dominant in radio astronomy, self-contained robots, firmware, scientific lab equipment, etc.

      --
      It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
  8. Alternative Summary by bigsexyjoe · · Score: 5, Insightful

    Google Engineer promotes Google language Go and claims it addresses weaknesses of existing languages, including Java and C++.

    1. Re:Alternative Summary by jekewa · · Score: 2, Interesting

      I'll start using Go as soon as Google makes a browser-based development environment for it, ala Google Documents meets Bespin, and it makes something I can then deploy to servers other than the one running the development environment...

      --
      End the FUD
    2. Re:Alternative Summary by slasho81 · · Score: 2, Interesting

      Rich Hickey talked about incidental complexity in his keynote talk at the JVM Languages Summit 2009: http://www.infoq.com/presentations/Are-We-There-Yet-Rich-Hickey
      It's worth watching.
      If Pike thinks the Go language solves anything, he should probably watch this talk too.

  9. 443,000 lines of Javascript?? by Black-Man · · Score: 3, Interesting

    This guy has a lot of nerve telling other folks what programming language to use.

  10. Not a good diplomatic move... by drewhk · · Score: 3, Interesting

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

    1. Re:Not a good diplomatic move... by arth1 · · Score: 3, Funny

      You should bash Java, and C++ devs will agree.

      Bad advice!

      % bash java /usr/bin/java: /usr/bin/java: cannot execute binary file

  11. "Google Engineer" ... seriously? by John+Whitley · · Score: 4, Insightful

    How about "Rob Pike Decries Complexity of Java, C++" instead?

    |Rob Pike| >> |Google Engineer|

    1. Re:"Google Engineer" ... seriously? by vbraga · · Score: 2, Informative

      You probably used UTF-8 in a way or another.

      --
      English is not my first language. Corrections and suggestions are welcome.
  12. Summary: by IICV · · Score: 4, Interesting

    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. ... Pike also spoke out against the performance of interpreted languages and dynamic typing. ... "Go is an attempt to combine the safety and performance of statically typed languages with the convenience and fun of dynamically typed interpretative languages," [Pike] said

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

    1. Re:Summary: by BitZtream · · Score: 4, Insightful

      Whats better is if you take a look at his history of 'inventions', you find one or two things that eventually, with the help of others, turned into something that other people use.

      His personal list of inventions looks like a list of 'things no one gives a shit about'.

      His list of Wikipedia quotes are golden. I think there was one on the list that didn't make him look like a total douche.

      He's one of those guys that thinks everything sucks except what he's made ... unfortunately, the entire rest of the world feels pretty much the exact opposite.

      Looking at his history, I don't think he'll ever say anything bad about Go, he'll just continue thinking it was perfect and that it failed because everyone else wasn't up to the task of using it.

      --
      Persistent Volume manager for Kubernetes - https://github.com/dwimsey/openshift-pvmanager
    2. Re:Summary: by yyxx · · Score: 2, Informative

      I think UTF-8 and his two books were pretty influential. BLIT and Plan 9 were pretty significant research systems. And as a member of the original UNIX group, I think his opinion on UNIX and C carries some weight (and is probably shared by many of the original UNIX developers).

      As a language, Go actually looks pretty nice to me. The trouble with Go is the same trouble nice new languages have always had: lack of critical mass. If Google starts using Go for Appspot, Android, and internal development, it may have a chance.

      Just out of curiosity: what have you accomplished?

    3. Re:Summary: by yyxx · · Score: 2, Interesting

      So the only people that can be critical of anyone are people that have some big publicly recognized accomplishments? That's a pretty small list.

      You went beyond critical and went to ad hominems; that makes the question legitimate.

      But merely "This guy thinks he's better and smarter than everyone else...

      He's smarter than the vast majority of programmers; his publications and resume tell you at least that much.

      but his actual accomplishments in what HE'S developed to replace those technologies in no way measure up the his fanatical criticism of them"

      He was part of the development of the technologies he criticizes. Second, his criticism really is valid: C++ and Java are objectively bad designs, and I say that as someone whose main programming languages over the last 30 years have been C, C++, and Java. Third, technically, what he has developed to replace them does measure up; it is certainly quite a bit better.

      So, if he developed better technologies, why didn't they catch on? Because better technologies frequently don't catch on. Replacing a technology with something better doesn't just require developing something better, it requires convincing the users of the old technologies that switching is worthwhile, a process complicated by the fact that most users of those old technologies know little about software or programming languages.

      And, as you noticed, Pike isn't a particularly good advocate; he comes across as a blow-hard. Pike is never going to create a successful programming language, even though he is a lot more capable than B.S. or Gosling.

  13. A man after my own heart by Brett+Buck · · Score: 5, Insightful

    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.

    1. Re:A man after my own heart by assemblyronin · · Score: 2, Insightful

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

      Unless you're writing assembly code for non-pipeline microprocessors, you're already implicitly 'trusting the compiler' because most modern compilers will re-order instructions to help prevent pipeline stalls, or improve efficiency.

    2. Re:A man after my own heart by 16K+Ram+Pack · · Score: 2, Insightful

      The "cult of classes" has really got out of hand. I spent about 4 days just looking through some C# code of a client, to try to work out exactly how it worked. No-one seemed to give a damn about making a pragmatic, easy to understand solution. Instead, it was stacks of classes inheriting from classes. In one instance, there was a "staff" class which inherited from a "person" class. But the "person" class was used in no other way than to be inherited by the staff class.

      Now, theoretically it's quite right, but it's just not pragmatic. It just adds code that makes things confusing. And things like this make maintenance of code a total bitch. I'm not against classes, but they're often overused and entirely unpragmatic.

    3. Re:A man after my own heart by ultranova · · Score: 4, Insightful

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

      You read the code of the class that the data belongs to. You can be sure that what you read is the only thing going on because no other code can do anything to the data since it's hidden from it.

      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.

      Well, high-level languages generally make it impossible to figure out what's really going on behind the scenes. That's intentional: abstracting away details is the whole idea of a programming language.

      C++ is particularly bad here because it mixes high- and lowe-level abstractions and allows you to redefine basic operations (such assignment, +, etc.). Combine that with manual memory management and lack of bounds checking and you have a rather explosive combination.

      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.

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

      If you are using a compiler, you have the choice of either trusting it, or inspecting the machine code it generates by yourself, which is harder than simply writing the damn thing in assembly to begin with, and thus defeats the whole point of using a compiler.

      If you want straightforward procedural code, use C. Using C++ for procedural code is pointless, and simply adds unneeded complications.

      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.

      It could simply be that they disagree with you. Your earlier bit about data hiding making it more difficult to figure out what's going on makes it seem that you don't understand the idea of object-oriented programming, so of course it would seem like a "cult" to you.

      It could also be that you're trolling. In that case: bravo sir, you truly have the art down.

      --

      Forget magic. Any technology distinguishable from divine power is insufficiently advanced.

  14. Re:We all know the ideal language has two function by somaTh · · Score: 4, Funny

    See, I'm already thinking about extentions.

    doWhatIWantEvenThoughImTellingYouToDoSomethingElse()

    --
    Nostalgia isn't what it used to be.
  15. News Flash by eclectro · · Score: 2, Funny

    Rob Pike likes to program in Forth in his spare time.

    --
    Take the cheese to sickbay, the doctor should see it as soon as possible - B'Elanna Torres, "Learning Curve"
  16. Re:We all know the ideal language has two function by cgenman · · Score: 3, Funny

    slowDownAndCrashSoICanSellAnUpgrade();

  17. Excessive abstraction has always annoyed me by Anonymous Coward · · Score: 2, Insightful

    Almost everyone programming computers these days seems to be too eager to forget what the computer is actually calculating. When you are writing software that has any need to perform within certain memory or time constraints, or scale to any degree at all, you need to understand your program at that level.

    For example, for high performance searching it is critical to understand pointer arithmetic to build an effective hash table. Without that, either your substitute search algorithm doesn't scale efficiently, or you're depending on a likely-less-than-optimal generic library.

    I knew a database developer who insisted that each record in a database match the block size of the disk in use. The computer then calculated the block that contained the desired record and read/wrote only that block. Developers in high-level languages just wouldn't give a shit.

    I knew a graphics developer who looked for every opportunity to use powers of two so he could use bit-masking and rotating: rotate 1 bit right to divide by two, or XOR with 0x07 to get modulus 8, etc.

    Optimization by understanding what the computer is actually calculating is fading fast, and teaching Java at the university level only accelerates that trend.

  18. Slashdot Interview by Jodka · · Score: 4, Informative

    Slashdot previously interviewed Rob Pike.

    --
    Ceci n'est pas une signature.
  19. Yes. And Go has the same problems by Cyberax · · Score: 3, Informative

    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.

    1. Re:Yes. And Go has the same problems by owlstead · · Score: 4, Interesting

      Thank you, I do agree. I was about to write to the authors of Go, but I thought better of it: simply because I cannot see Go go anywhere.

      Basically, they do really weird things:
        - no exceptions
        - half assed immutability concepts
        - focus on compile time (compile time? really? yes really!)
        - no modularization system (it's like the micro-kernel vs mono-kernel fight all over)

      It's got some good ideas that make it interesting for small, fast, secure applications, but not so many that it becomes interesting. I could see technically make some headway for small monolithic kernels. But their market placement is lacking to the point that it is non-existent.

  20. Re:Maybe because programmers like to be clear by metamechanical · · Score: 3, Insightful

    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!
  21. Understatement of the year by ThoughtMonster · · Score: 4, Informative

    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.

    1. Re:Understatement of the year by GooberToo · · Score: 2, Insightful

      Which hardly makes them immune from criticism.

      In my opinion it makes them more likely to suffer criticism. Many computer scientists, the majority I've met, seem to chronically like in a glass house and are completely disconnected from anything but theory. So if I run with the logical conclusion, in theory, made in a clean room, he's completely right. Pragmatically, almost everything he said likely to be completely wrong.

      Oddly enough, seems to more or less cover much of his and the comments and here.

    2. Re:Understatement of the year by Bright+Apollo · · Score: 5, Insightful

      Pike and Thompson are not computer scientists, they are practitioners. The difference between Thompson's contributions and Knuth's contributions, for example, illustrate this exact point.

      --#

  22. Re:If you can't code in C++ you shouldn't code. by retchdog · · Score: 3, Insightful

    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
  23. I LOVE perl! by DG · · Score: 5, Funny

    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
    1. Re:I LOVE perl! by Monkeedude1212 · · Score: 4, Insightful

      I actually think that perl is the best programming language every designed[...] perl is the English of programming languages.

      You went on to describe how Perl is great but just so you know - every one of those reasons you listed is why every multi-lingual person on the planet hates English. It's a pain in the ass to learn because there are too many exceptions to the rules or the rules aren't well defined. Look no further than pluralization. Add an S, in most cases. Oh, but if it ends in an y, make it 'ies', like skies. And for some words, that end in sh or ch or x or something, its 'es', like wrenches. Oh and for Goose, its Geese. But the plural for Moose is not meese, in fact, its just moose, not even mooses.

      We won't bother getting into Contractions or prefixes/suffixes or any of the real gritty stuff. English itself is a pain, let alone how many variants of it are across the Earth, with their own Formal, informal, and Slang terminology.

      So yeah, while the flexibility that makes Perl accessible to more programming styles is good to you, its still a a pain to learn, and one of the reasons why people are put off by it. Without a standardized way of doing things its difficult to understand exactly whats going on. Some of the most obfuscated code I've ever seen has been written in Perl.

    2. Re:I LOVE perl! by Grishnakh · · Score: 2, Insightful

      If you know German, Latin, and some French, English should be easy for you. English is basically a big mishmash of several older languages, taking parts of each, but not putting them together into anything coherent.

      The main strength of English is its versatility; it's trivially easy to adopt new words from other languages like Russian or Japanese. However, adopting words from extremely different languages means that they won't fit into those nice rules that you complain are violated too much.

      Of course, we could throw all that out, and not adopt any new words at all, and only create new words for things which can fit the rules, but that would require a special Institute, the way they do with French. That hasn't worked out too well, and people aren't exactly flocking to learn French these days. They're all trying to learn English and Mandarin.

    3. Re:I LOVE perl! by Culture20 · · Score: 3, Insightful

      English. It's a pain in the ass to learn because there are too many exceptions to the rules or the rules aren't well defined. Look no further than pluralization. Add an S, in most cases. Oh, but if it ends in an y, make it 'ies', like skies.

      Unless the word is Monkey, then the plural is Monkeys.

      The nice part about the English language is that someone can speak pigeon-English and English speakers understand them very well. All those exceptions teach native-speakers to be accepting of lingual oddities. In some other languages, incorrect verb tense can make the difference between talking about "You" or "She", or incorrect tonality can make a foreigner sound like a stroke victim.

    4. Re:I LOVE perl! by Grishnakh · · Score: 4, Interesting

      Actually, English is a very easy language to learn, to a certain degree. It's a lot like learning to play guitar. Any moron can learn to play a few chords on a guitar and make a simple song. However, only really talented people can become true virtuosos of the instrument and play like Joe Satriani or Steve Vai. English is like that: it's easy to learn it to a minimal degree and become somewhat conversant. The words are short and simple, you don't have to worry about silly things like word gender, etc. However, becoming truly fluent in it (so that you can read and write advanced literature, for instance) is difficult and time-consuming because you have to memorize so many things, and learning some Greek and Latin is very useful for understanding many larger words.

    5. Re:I LOVE perl! by A+Friendly+Troll · · Score: 2, Interesting

      You went on to describe how Perl is great but just so you know - every one of those reasons you listed is why every multi-lingual person on the planet hates English.

      I'm multi-lingual.

      English, with the exception of Esperanto, was the easiest language to learn. There are several orders of magnitude more exceptions in some other languages; they also have a lot more cases and conjugations, and actually use genders (to which English is oblivious). Even spelling words in English is incredibly easy.

    6. Re:I LOVE perl! by martin-boundary · · Score: 2, Funny
      And then there's the word police, which doesn't actually have a singular at all, and its plural doesn't end in an s anyway just to mess with criminals' minds.

      "You're surrounded by the police. Come out with your hands up."

      "Fuck, the police are here. We're toast."

      "Don't be silly, they said THE POLICE. It's singular, there can't be more than one guy out there. When you see him, just shoot him."

      ???

      "Damn you, English language!"

    7. Re:I LOVE perl! by shutdown+-p+now · · Score: 3, Informative

      The words are short and simple, you don't have to worry about silly things like word gender, etc.

      Yeah, you only have to worry about other silly things, such as learning seemingly endless tables of non-standard plural and past tense forms by rote, or understanding just what the hell perfect tense is about.

      English is certainly not the hardest language out there, but it's also not the easiest one, by far.

  24. And everyone at Google now speaks Esperanto by Call+Me+Black+Cloud · · Score: 4, Insightful

    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.

    1. Re:And everyone at Google now speaks Esperanto by msclrhd · · Score: 2, Insightful

      Exactly. You don't need to use template meta-programming to get the job done for most tasks.

      Hell, just use the better C subset and the C++ library if you want to.

      There is also no need for a Singleton of a Factory that creates Factories to create objects that you pass an Observer to that calls a function to do something when a simple parametrised free-standing function will do the same job. The maintainer of the code will thank you for it (even if that maintainer is you at some point down the road).

      Think about the data and what operations you are performing on that data.

      Also, use the right languages and structures. If you have XML that you want to visualise as HTML, XSLT is designed to do that easily and reliably. If you are using JavaScript and/or python, use JSON and the native type system. Use standard library functions over hand-written ones unless you have a clear, measurable need not to.

      Work with the languages and tools you have, not against them.

  25. C++ and Java make for good foundations by oxide7 · · Score: 2, Insightful

    It's been a long time since I've coded in a professional environment but I feel that having learned C++ you can learn any other language. It is complicated and verbose, but its extremely precise. Imagine having to learn how to manage memory with something like PHP. Actually -- because the new generation DOESNT LEARN C++ its why code is getting so sloppy now. There are easier languages sure, and using them can be fine, but if that's all you know, then you don't really know what your code is doing.

  26. Re:Maybe because programmers like to be clear by lgw · · Score: 5, Insightful

    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.

    SUBTRACT DEBIT FROM BALANCE GIVING NEWBALANCE.

    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.
  27. Programming is Hard by CSHARP123 · · Score: 2, Interesting

    I RTFA, really all he is saying is programming is Hard. Well Duh, I am sorry to hear that from Google Engineer. May be he will be better off using C# or VB.Net. Welcome to programming.

  28. So... we'll end up back at Atari BASIC? by Mad-Bassist · · Score: 3, Interesting

    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
  29. He's just pimping Go by istartedi · · Score: 4, Informative

    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"?
    1. Re:He's just pimping Go by Cro+Magnon · · Score: 3, Funny

      but TFA also points out that languages accumulate cruft over time, and Go is a baby

      Yeah, in another 10-20 years, Go will be a clunky piece of cruft, and we'll need a new language, possibly named "Stop".

      --
      Slow down, cowboy! It has been 4 hours since you last posted. You must wait another few hours.
    2. Re:He's just pimping Go by shutdown+-p+now · · Score: 2, Funny

      Yeah, in another 10-20 years, Go will be a clunky piece of cruft, and we'll need a new language, possibly named "Stop".

      You forgot to mention that, before that happens, we'll get a bunch of derived languages, such as Objective-Go, Go++, Go--, Go#, GoScript and GoXML.

  30. Re:If you can't code in C++ you shouldn't code. by AnonymousClown · · Score: 2, Interesting

    No,

    What this world needs is competent programmers. C++ too hard for you? You shouldn't be programming. It's that simple.

    Look, C++ is my programming language of choice: I like programming down to metal, having the OS load my program and run it without any intermediary like an interpreter or some sort of runtime (no I don't do CLI), and I like the ability to go down and do old school 'C' when I need to. But these days, it's like Stroustrup is adding features for the sake of adding features - trying to be "modern"? I don't know. It's making the language bulkier, adds even more chances for obfuscation, and it's getting to the point where even C++ fanboys like myself are reevaluating our relationship with the language.

    Good god, when he first added templates (a great feature just see the STL), I had to deal with programmers who made template classes for everything and used it once for one data type. Plah-ease! Just because the feature is there doesn't mean you gotta use it. There's a time and place for everything. C++ is turning into the Word of programming languages: adding esoteric features that less than 1% of users will ever use.

    C++ is turning into a bloated slow fat pig and I'm thinking of getting a divorce.

    --
    RIP America

    July 4, 1776 - September 11, 2001

  31. Re:Maybe because programmers like to be clear by MightyMartian · · Score: 2, Interesting

    Not to mention that, no matter what language you use, certain algorithms are going to be inherently complex, and in these areas the "simple" or "true" languages fall flat on their face. I've been coding in one form or another since the mid-1980s, and what I've seen from the "simple" languages is that they might be useful for teaching, but try to write a complex application or solve complex problems, and that simplicity simply makes the code even larger and more awkward.

    --
    The world's burning. Moped Jesus spotted on I50. Details at 11.
  32. Re:We all know the ideal language has two function by MikeyO · · Score: 5, Funny

    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.

  33. Re:Maybe because programmers like to be clear by lgw · · Score: 4, Insightful

    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.
  34. Re:We all know the ideal language has two function by PixieDust · · Score: 5, Funny
    I dunno, I kind of like these extensions:

    workItHarder makeItBetter doItFaster makesUsStronger moreThanEverHourAfterHour workIsNeverOver

  35. Did anybody post this yet? by Joce640k · · Score: 5, Insightful

    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...
    1. Re:Did anybody post this yet? by vbraga · · Score: 2, Informative

      Since I never met this quote before and found it quite insightful here is the link for interview where Stroustrup said it for those like me who didn't know it - it's worth reading.

      --
      English is not my first language. Corrections and suggestions are welcome.
    2. Re:Did anybody post this yet? by Slightly+Askew · · Score: 4, Insightful

      How incredibly arrogant. I would totally hire a semiskilled carpenter to put up a tool shed in the back yard. Not so much a NYC high rise. I would also gladly hire an apprentice electrician to put in a new overhead light fixture, but not to wire up my 440v industrial machinery.

      There's nothing dangerous about semiskilled programming, providing they are doing work that is appropriate for semiskilled programmers. I'm no more going to hire Thomas Knoll to write my company's Human Resources app than I'm going to personally apply for a job writing the next version of whatever the NYSE is using.

      --
      Public use of any portable music system is a virtually guaranteed indicator of sociopathic tendencies. -- Zoso
  36. Re:Maybe because programmers like to be clear by Zarel · · Score: 5, Informative

    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!
  37. Re:Maybe because programmers like to be clear by Shompol · · Score: 4, Insightful

    I'm sorry to say, Google is now officially my new Microsoft. Too big for their own good,

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

  38. He's right. Code in C. by Anonymous Coward · · Score: 2, Insightful

    C. It's just the right thing to do.

  39. Re:We all know the ideal language has two function by HeronBlademaster · · Score: 4, Insightful

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

  40. Not so sure of that... by Estanislao+Mart�nez · · Score: 5, Insightful

    Guess what guys? The reason programming is hard is because you must clearly and unambiguously state what you want to have happen.

    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.

  41. C too complex? Hilarious. by fyngyrz · · Score: 3, Insightful

    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.
    1. Re:C too complex? Hilarious. by clone53421 · · Score: 5, Insightful

      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.

      That’s exactly the point... it’s too close to the hardware. Yes, it gives you really fine-grained control over what happens, and you can tweak it to make it as fast as possible. With the speed of today’s computers, though, you shouldn’t (usually) need that amount of optimization. Plus, the compiler should be robust enough to optimize the program nearly as well as you could anyway.

      You don’t want to tell the computer every nitty-gritty detail. The computer is fast enough and powerful enough to do what you want it to do without you needing to exercise that level of control over how it actually does it. You just want to call a function that does what you want without worrying about the underlying hardware or algorithm that does it.

      As programs get more and more complex, more and more abstraction is needed between the programmer and the hardware. This is not surprising. Someday, instead of saying “that’s like coding an entire application in assembly”, we might be saying “that’s like coding an entire application in C++”.

      --
      Alexander Peter Kristopeit bought his basement from his mommy for one dollar.
    2. Re:C too complex? Hilarious. by fbjon · · Score: 4, Informative

      You seem confused. He said C++ is complex, not C, and he is entirely right. Also, if you used to do Perl, you might like Ruby. It's no faster than Python, but I find it nicer.

      --
      True confidence comes not from realising you are as good as your peers, but that your peers are as bad as you are.
    3. Re:C too complex? Hilarious. by bonch · · Score: 5, Insightful

      C's closeness to the hardware is probably why it has stayed relevant in the era of mobile computing and battery life. Some developers do need to tell the computer every nitty-gritty detail.

    4. Re:C too complex? Hilarious. by rolfwind · · Score: 5, Insightful

      "Greenspun's Tenth Rule of Programming: any sufficiently complicated C or Fortran program contains an ad hoc informally-specified bug-ridden slow implementation of half of Common Lisp."

    5. Re:C too complex? Hilarious. by bbn · · Score: 5, Insightful

      This is because a C fragment turns into something very efficient

      No it _can_ turn into something very efficient. But usually it is too much bother or the programmer is not competent enough and the program ends up being no more efficient than something coded in a different language.

      Take a look at the programming language shootout. The C programs usually win the contest, but they do it by doing crazy things like looking up the cache size of the CPU and implementing their own version of malloc to fit a page size. The run of the mill C program is not like that.

      For many or even most tasks stability and security is more important. Other languages provide those properties better than C.

    6. Re:C too complex? Hilarious. by Ex-MislTech · · Score: 3, Insightful

      You got modded flamebait because you dared question the less is more crowd that wants higher level languages that do
      most of the lower level work for them.

      The ppl that coded closer to the metal as you say mostly have grey hair now, and are looked at as legacy coders
      by the new breed that want all that lower level coding done for them by the language.

      As for it being complex, sure it is complex for most ppl, but for a college trained Comp Sci. major it should
      be bread and butter and tools of the trade.

      Ppl have declared we are giving a dumbed down education and I think this is a fair indicator of it.

      --
      google "32 trillion offshore needs IRS attention"
    7. Re:C too complex? Hilarious. by Anonymous Coward · · Score: 2, Interesting

      With the speed of today’s computers, though, you shouldn’t (usually) need that amount of optimization.

      the inefficiencies aggregate to the point where you have cd burning software that eats 200MB of ram and 300MB of hd space. binaries were getting bigger and hungrier all through the 90s, but there was a literal explosion after all the sandboxed runtimes became popular with colleges. People don't buy faster computers to run slower code written by lazier programmers. They assume they're going to get a faster experience. ...or at least more capability. what ends up happening more and more often though is that stuff just gets slower, buggier and more expensive.

    8. Re:C too complex? Hilarious. by conspirator57 · · Score: 4, Informative

      That's exactly the point... it's too close to the hardware. Yes, it gives you really fine-grained control over what happens, and you can tweak it to make it as fast as possible. With the speed of today's computers, though, you shouldn't (usually) need that amount of optimization. Plus, the compiler should be robust enough to optimize the program nearly as well as you could anyway.

      umm... did you miss the part where the guy also bitched that interpreted languages are "too slow"?

      so which is it? where on this stone are you going to squeeze the blood from? it's a tradeoff and the menu of available programming language choices is already comprehensive. this guy expresses it better and more comprehensively than i care to in a /. comment:

      http://eatthedots.blogspot.com/2008/07/why-is-c-faster-than-python.html

      and compiler research has only yielded 4% annual improvement in performance per Proebsting's law
      http://research.microsoft.com/en-us/um/people/toddpro/papers/law.htm
      http://www.cs.umd.edu/class/spring2006/cmsc430/lec18.4p.pdf

      and compiler researchers concede that a competent human will outperform a compiler for the foreseeable future. so your statement about compilers is total hand-waving away of facts inconvenient to your argument.

      --
      "If still these truths be held to be
      Self evident."
      -Edna St. Vincent Millay
    9. Re:C too complex? Hilarious. by Like2Byte · · Score: 4, Insightful

      This is exactly the reason I program in C and C++. Because it is hard. The level of knowledge required for entry into my field is higher and I am therefore surrounded by more competent engineers.

      Anyone complaining that C/C++ is too hard needs to stay in GUI application and web development. Have fun, I say.

    10. Re:C too complex? Hilarious. by 19thNervousBreakdown · · Score: 4, Insightful

      The vast bulk of your argument is dedicated to defending C, which he never mentioned and only an imbecile would call the core language rules complex.

      C++, which you barely mention, on the other hand, is extremely complex at its core, mostly due to its templating language--which, by the way, is one of the very best features of C++, and although it could be (and will be in C++0x (0x more like 2x amirite)) done better, I think the expressiveness is well worth the complexity. Again, only an imbecile would call C++ simple.

      The real question to ask when somebody chooses to bash C++, however, is "what are you selling?" In this case, he's fairly up-front about it--he's selling Go, Google's pet language. To that, I say, "I'll believe it when I see it." Right now Go is a bunch of "but just look at the groundwork we've laid down! This will be great when it's done!" As the article mentioned, that may be true, but its complexity will approach C++ as its capabilities do. It's just hard to do a lot of stuff well, and for all the complaining, C++ does do a lot of stuff, and it does most of it well, or at least ... eh, pretty good.

      Honestly, look over the C++ challengers: every one I've ever seen that's squarely aimed at taking out other languages is little more than an ego project. I have yet to see a language that actually introduces new capabilities without significant downsides compared to what they're trying to replace, so I'll keep doing what's worked for me the last 10 years I've been a C++ fanboy: wait for something that's actually better to come out. Smugly.

      --
      <xml><I><am><so><damn>Web 2.0</damn></so></am></I></xml>
    11. Re:C too complex? Hilarious. by Klinky · · Score: 4, Informative

      You know, nothing pisses me off more than people responding to a post saying only "THIS". Please, keep it to yourself if that's all you can contribute. I feel bad for thewasted bandwidth and computing power that was exhausted on that little brain fart of a post.

    12. Re:C too complex? Hilarious. by sjames · · Score: 4, Insightful

      C is very much a relevant language with a strong niche for modern use. It's very good at what it does. It is a mid-level language and it shines at that sort of use.

      Note that he was complaining specifically about C++, not C. It's not even necessarily the language itself, but the patterns and APIs that are inspired by the language that matter.

      When you need a higher level language than C, C++ is NOT a great answer. It's a series of bolt-ons for C that try to make it something it is not.

      Meanwhile, java started out badly with silly marketing claims that it never quite lived up to, still manages to perform poorly in practice and has been dogpiled with a bunch of alphabet soup such that if there is a lean and mean language in there somewhere, we'll never find it./

      So it's not at all C that is too complex, it's those horrific messes we call programs written in C++ that are too complex.

    13. Re:C too complex? Hilarious. by Foofoobar · · Score: 4, Funny

      Also, if you used to do Perl, you might like Ruby...

      Yes and if you like Jesus, you also might like Jim Jones or Charles Manson. Push your cult elesewhere!

      --
      This is my sig. There are many like it but this one is mine.
    14. Re:C too complex? Hilarious. by ducomputergeek · · Score: 3, Funny

      But you can do anything in perl. Problem is you can do anything in perl (doesn't mean you should.)

      --
      "The problem with socialism is eventually you run out of other people's money" - Thatcher.
    15. Re:C too complex? Hilarious. by DerPflanz · · Score: 2, Insightful

      With the speed of today’s computers, though, you shouldn’t (usually) need that amount of optimization.

      And that is why we have a shitload of very crappy software nowadays. Why does a printer driver needs 110MB of hard disk space? Why does a browser (yes, that's you Firefox) need 20-30 seconds to start up? Because the developers are raised with the notion that they do not need to optimize for speed or size. I, for one, would more than welcome a generation of developers that know what they are doing and think of computer-time instead of developer-time. Especially in often-run applications. And even more especially in web-apps, which are notoriously badly designed and written.

      --
      -- The Internet is a too slow way of doing things, you'd never do without it.
    16. Re:C too complex? Hilarious. by yyxx · · Score: 2, Informative

      And what do you tthink would the difference between "an ad hoc informally-specified bug-ridden slow implementation of half of Common Lisp" and an actual CommonLisp implementation be?

    17. Re:C too complex? Hilarious. by shutdown+-p+now · · Score: 2, Informative

      C++ has RTTI, but it is frequently (often?) disabled.

      RTTI is actually not disabled all that often, since doing so typically also kills dynamic_cast, and that can be very useful at time.

      But then C++ "RTTI" is a misnomer. I mean, it only lets you inspect the name of the type, and even then the precise content of that string is implementation-defined, so you're only guaranteed that it's unique among all types! There's no member reflection whatsoever, and you can't create a new instance from a type_info.

      The thing is, once you have a system running around maintaining type data on all your objects in memory, you are halfway to having a virtual machine

      No, not really. You only have a bunch of static arrays filled with data. It is completely orthogonal to the idea of VM.

      By the way, have you noticed how many C++ frameworks roll out their own RTTI using macros or preprocessors?

      Reflection is such a perf hit either you want it or you don't, and if reflection is REALLY vital to your code, you mine as well run on a fully featured VM, the rest of the VM isn't going to weigh you down too much more.

      There are very few cases where reflection is used all the time, even in a VM-based platform such as Java or .NET. More often than not, it's used once to initialize some complex object graph in a generic way (e.g. read window layout from XML), and after that you're back to good old statically typed code.

      Another case is not really run-time - rather, it's the ability of some visual designer (or other tool) to list types in the assembly, their members etc, so that it can show those neat property grids, or generate code, based on that information. COM has that kind of thing - type libraries - which are completely useless at runtime (unless a specific object implements IDispatch for dynamic invokes), but are used a lot at design-time.

    18. Re:C too complex? Hilarious. by strikethree · · Score: 2, Insightful

      "You don't want to tell the computer every nitty-gritty detail. The computer is fast enough and powerful enough to do what you want it to do without you needing to exercise that level of control over how it actually does it."

      No! No no no! Stop it! It is thinking like that which has caused my dual 2.66ghz processor to provide a less responsive interface than my 7mhz Amiga provided! Really. Seriously. STOP THINKING THAT FASTER HARDWARE RELEASES YOU FROM THE RESPONSIBILITY OF WRITING EFFICIENT CODE. Really. Just stop.

      Sincerely,
      The rest of the world who actually has to use your programs

      --
      "Someone needs to talk to the tree of liberty about its ghoulish drinking problem." by ohnocitizen
    19. Re:C too complex? Hilarious. by freakhill · · Score: 2, Funny

      THIS!

  42. Re:Complex? Difficult? Since when? by thetoadwarrior · · Score: 2, Insightful

    It's not hard to learn Java but yes, it is often a complicated mess of shit when you want to use it on the web. Anything where you *have* to generate great swathes of code to keep your sanity is probably an over engineered shit solution.

  43. Re:Maybe because programmers like to be clear by Grishnakh · · Score: 2, Interesting

    Yep, it's like different natural human languages. Some are much simpler than others, and don't have so many cases and tenses and such. However, to express more complex thoughts (such as "he would have liked to go home"), you have to be extremely wordy, whereas with a more complex language, you just use a different verb tense.

  44. Re:We all know the ideal language has two function by jsiren · · Score: 3, Funny

    What we have here is feature creep.

    --
    Usage: km/h for speed (kilometers per hour); kph for very slow impulses (kilopond hours).
  45. Re:Maybe because programmers like to be clear by Muad'Dave · · Score: 2, Informative

    ... "make sure the escape sequences cant be confused with notmal [sic] characters"...

    That was figured out _long_ before UTF-8. In fact, having been born in 1956, Rob Pike was probably exposed to the concepts of Control Codes and bisync as well as all the other framing methods that use escape characters to indicate in-band signalling.

    Have you ever wondered what all those control characters are doing wasting space down there under decimal 32? Link management, that's what. Start of Header, Start of Text, End of Text, End of Transmission, etc. They were all used to keep systems in sync across the (nasty) comm lines of the day. Even [XYZ]-modem used a similar setup.

    --
    Tiller's Rule: Never use a word in written form that you've only heard and never read. You will end up looking foolish.
  46. Re:We all know the ideal language has two function by danieltdp · · Score: 2, Funny

    I just hope, for the sake of your project, that the factory don't create foobars, but something else that you removed from the original

    --
    -- dnl
  47. Re:We all know the ideal language has two function by bennomatic · · Score: 2, Funny

    My implementation of that is doTheRightThing().

    --
    The CB App. What's your 20?
  48. Re:Maybe because programmers like to be clear by lgw · · Score: 3, Interesting

    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.
  49. Re:Maybe because programmers like to be clear by westlake · · Score: 4, Interesting

    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.

       

  50. Re:Maybe because programmers like to be clear by lgw · · Score: 2, Informative

    Yes, you can do it the sane way. But my point was that someone actually thought the verbose way was easier to understand!

    --
    Socialism: a lie told by totalitarians and believed by fools.
  51. Don't hate on VB by labnet · · Score: 2, Interesting

    Although I mainly do hardware engineering, I also have done/do lots of 8/16/32 bit embedded prorgamming in C and C++. C is a terrific language for embedded. C++ is like a samurai sword, hard to truly master without killing yourself.
    I truly loved VB6 as a RAD platform. I wrote a scientific application involving realtime data collection/control, database method and paramter control, realtime graphing, simultaneous multiple system control including sampling robots etc, that is still being used in hundreds of industrial labs around the world. It was written in around 4 months, and there is no way I could of done it in C++.
    I think C++ sucks for end user app development for most of the reasons metioned by Rob Pike, but is has its place when you are close to the metal.

    --
    46137
    1. Re:Don't hate on VB by BitZtream · · Score: 2, Interesting

      You like VB for the same reason you like Tylenol.

      It lets you play doctor without actually being one, or in this case, you get to play programmer without actually being one.

      That most certainly has its usefulness as you are well aware, but that doesn't make it a tool that programmers should be using.

      Doctors and programmers use a different set of tools than you use at home.

      I spend most of my time now converting crappy VB apps to real applications, I have a license to hate VB and shitty VB writers who think they are programmers.

      --
      Persistent Volume manager for Kubernetes - https://github.com/dwimsey/openshift-pvmanager
    2. Re:Don't hate on VB by shutdown+-p+now · · Score: 2, Interesting

      I truly loved VB6 as a RAD platform. I wrote a scientific application involving realtime data collection/control, database method and paramter control, realtime graphing, simultaneous multiple system control including sampling robots etc, that is still being used in hundreds of industrial labs around the world. It was written in around 4 months, and there is no way I could of done it in C++.

      Yes, but you could have done it in Delphi just as fast and convenient, and you'd have had code that was much more readable.

      A language in which this line of code:

      x = y

      does not certainly mean "assign value of variable y to variable x" (in VB, it might mean that, or it might not - that depends on type of x; hint: default properties), truly deserves to be fully erased from the memory of mankind.

  52. Biased much? by Comboman · · Score: 3, Insightful

    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.
  53. Re:Maybe because programmers like to be clear by lgw · · Score: 2, Interesting

    No, I think you missed the point entirely here: those escape sequences would begin with a control character, but contain normal characters. So if you were grepping for "foo" you might get a false positive because "foo" appeared in an escape sequence. UTF-8 ensures that will never happen. Any existing code that uses reasonable algorithms to search or sort ASCII text still works reliably with UTF-8 text, but didn't with earlier escape sequence schemes.

    --
    Socialism: a lie told by totalitarians and believed by fools.
  54. Re:Not everybody runs servers for a living by 0123456 · · Score: 2, Interesting

    In all my years of coding in Perl, Ruby, and Javascript, I have never encountered a single bug where somebody inserted a string into an array meant for integers, or one where someone tries to compare a float to an array.

    I've seen plenty of bugs in interpreted languages where someone meant to call procFoo() but actually wrote procFooo() and therefore the two hour script run failed at 1:58 requiring us to run it again from the start. I've seen plenty of bugs caught because the compiler realised that CustomerId is not the same type as WidgetCount, even though both are wrapped ints. I've seen plenty of bugs where someone meant to write 'f = procFoo()' but actually wrote 'g = procFoo()' and the 'smart' language created a new variable g while the program later used the value of f.

    A compiled language like C++ would catch all of those before you actually ran the code. Obviously a strongly typed interpretive language would catch the second, but a 'smart' language would probably convert it for you, leading to a bug that takes a long time to track down.

    I'm not saying that 'smart' languages are a bad idea, but there are an awful lot of things they can screw up for you if they try to be too 'smart'.

  55. Re:Maybe because programmers like to be clear by bonch · · Score: 2, Funny

    Yeah, it's not like Google is driving past your house to take pictures and index your WiFi network or anything. Sheesh!

  56. Re:We all know the ideal language has two function by ultranova · · Score: 2, Funny

    My implementation of that is doTheRightThing().

    Wouldn't that make it unfit for enterprise use?

    --

    Forget magic. Any technology distinguishable from divine power is insufficiently advanced.

  57. Re:Maybe because programmers like to be clear by ciggieposeur · · Score: 5, Interesting

    Nearly everything I was unhappy about in C++ is better in D.

  58. Re:python+ objective C by goombah99 · · Score: 3, Interesting

    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.
  59. Lisp by tepples · · Score: 5, Funny

    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.

  60. Re:Maybe because programmers like to be clear by Anonymous Coward · · Score: 2, Informative

    Good thing Google doesn't have an illegally close relationship with the government that benefits the company!

  61. Re:Maybe because programmers like to be clear by BitZtream · · Score: 3, Informative

    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
  62. Don't need to write Java to run on Java by benjto · · Score: 2, Interesting

    You don't have to write in Java to run on Java. Languages like Clojure, Scala, and Groovy have come about an an answer to the complexity and verbosity of Java's syntax and structure - all running on the Java platform.

    Java

    // HelloWorld.java
    class HelloWorld
    {
    public static void main(String args[])
    {
    System.out.println("Hello World!");
    }
    }

    Groovy

    //hello.groovy
    println "hello, world"

    Clojure

    // hello.clj
    (println "Hello World")

  63. Re:'Go' doesn't go far enough by godefroi · · Score: 3, Insightful

    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)
  64. Re:If you can't code in C++ you shouldn't code. by nschubach · · Score: 3, Informative

    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.
  65. Re:objective C by SteeldrivingJon · · Score: 4, Informative

    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
  66. Re:python+ objective C by SteeldrivingJon · · Score: 2, Insightful

    Re: method syntax

    I always liked how it was different from function syntax. Obj-C was my first OO language, and I had a conceptualization of objects as being semi-independent entities, so it felt natural to express message passing in a different syntax from 'mere' C functions.

    --
    September 2011: Looking for Cocoa/iOS work in Boston area Cocoa Programmer Quincy, MA
  67. Re:Maybe because programmers like to be clear by ciggieposeur · · Score: 3, Interesting

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

  68. Re:Maybe because programmers like to be clear by lgw · · Score: 2, Interesting

    shared_ptr solves a different problem. An example of a scoped resource is a file handle that you allocate on the heap, that automatically closes the file when you leave scope, whether by returning or by an exception flying past. With scoped resources you can just stop thinking about all the "does my resource get cleaned up if this happens" cases entirely! You should never explicitly clean up a resource, so there's no way to forget to do so in some corner case. Just like a "using" block in C#, except it's the default, so you can't forget to do it (the most malevolent bugs I've fought were people forgetting to use a using block).

    Combine this idea with shared_ptr and it works for heap resources too, not just stack resources.

    --
    Socialism: a lie told by totalitarians and believed by fools.
  69. Re:Emperor is Naked by MathiasRav · · Score: 3, Funny

    We need a new OS too. There hasn't been a decent OS since CP/M.

    There's Emacs.

  70. C and Python complement each other by mangu · · Score: 5, Informative

    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.

    1. Re:C and Python complement each other by woodsbury · · Score: 5, Informative

      In case anybody doesn't know, the new standard for C that is currently being planned includes multithreading support in the form of a threads.h header.

      http://en.wikipedia.org/wiki/C1x

      I believe the newest GCC includes some support for some of the features of that standard already (which of the features I can't remember).

  71. Re:Maybe because programmers like to be clear by Alcoholist · · Score: 3, Insightful

    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.
  72. Re:If you can't code in C++ you shouldn't code. by ciggieposeur · · Score: 2, Informative

    C++ is turning into a bloated slow fat pig and I'm thinking of getting a divorce.

    Check out D sometime, you might really like it.

  73. And video games by Sycraft-fu · · Score: 4, Insightful

    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.

  74. What's wrong with the main languages by Animats · · Score: 5, Interesting

    The main problems of the major languages are known, but not widely recognized by many programmers.

    • C Started out with only built-in types, to which a type system was retrofitted. (You have to go back to pre-K&R C documents to see this, but originally, there was just "char", "int", "float", and pointers to them. "struct" was just a set of offsets, with no type checking. You couldn't even use the same field name in two different structs.) Bolting a type system onto this took a long time, and resulted in problems ranging from "array=pointer" to cascading recompilation because "include" files contain implementation details of included modules.

      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.
    • C++ Was supposed to fix the major problems with C. A few bad design decisions in the type system made that hopeless. The underlying problems with arrays remained. An attempt was made to paper that over with the "standard template library" collection classes. Collection classes were a big step forward, but they were really just papering over the moldy type system underneath, and the mold kept coming through the wallpaper. The C++ standards committee keeps adding bells and whistles to the template system, but after ten years they still don't have anything good enough to release.
    • Java Was supposed to fix the major problems with C. Java itself isn't a bad language, but somehow it got buried under a huge pile of libraries of mediocre quality. Then a template system was bolted on top, along with ever more elaborate "packaging" systems. Java ended up as the successor to COBOL, something that surprised its creators.
    • Python Python is an elegant language held back by painfully slow implementations. Some of the implementation speed problems come from the most common implementation, which is a naive (non-optimizing) interpreter, but some of them come from bad design decisions about when to bind. Late-binding languages are not inherently slow, but Python has lookup by name built into the language specification in ways which make it almost impossible to speed up the language as defined. (The Unladen Swallow team is discovering this the hard way; they're getting only marginal speed improvements with their JIT compiler.) Python also addresses concurrency badly; everything is potentially shared and one thread can even patch the code of another. The end result is that only one thread can run at a time in most implementations.
    • JavaScript A painful language which, due to massive efforts to speed it up, is starting to take over in non-browser applications. JavaScript is the object model of Self expressed in syntax somewhat like that of C. This is ugly but adequate.

    And that's where we are today.

  75. Re:Maybe because programmers like to be clear by lgw · · Score: 2, Interesting

    Sure, if you can get the "closing them when I'm done with them" right every time, never failing due to human error, you're golden. However, one wonders why you'd need a garbage collector, or for that matter a text editor - can't you just move the bits around on disk with the power of your mind? :)

    But, yeah, any time you see weak pointers a living hell awaits. Garbage collection is much better for those corner cases (and, dammit, for a while C++0x had "opt-in" garbage collection, but lost it. It's the best of both worlds!) I'm not the biggest fan of WCF, but it does have one thing goint for it: it's not COM.

    --
    Socialism: a lie told by totalitarians and believed by fools.
  76. Re:Maybe because programmers like to be clear by lgw · · Score: 2, Funny

    the ruthlessness of a COBOL compiler forces you to create readable, structured code

    You should ALTER your views on this subject.

    --
    Socialism: a lie told by totalitarians and believed by fools.
  77. "Product" by weston · · Score: 2, Insightful

    Oh, so he's pushing a competing product and denigrating his competition?

    "Product" is a pretty poor word choice for something that's given away in the way Go is. Pike doesn't really have much more to gain than *you* do from the adoption of Go and reduced use of C++ and Java.

    Nothing to see here, I think.

    Only if the substance of his criticism doesn't hold up. My experience suggests his objections are apt, and I might add that a casual dismissal of work by Rob Pike and Ken Thompson reflects more on you than them.

  78. Re:Maybe because programmers like to be clear by bonch · · Score: 2, Insightful

    How will you fence off a satellite image?

    I know, I know, it's pointless to argue with Slashdotters who looooove Google.

  79. Re:Maybe because programmers like to be clear by bonch · · Score: 2, Insightful

    Most people don't understand WiFi networking and don't realize they're broadcasting anything. I didn't say people weren't free to take pictures of your house. I'm just pointing out that you're supporting a company whose CEO said only criminals worry about privacy. If you're okay with that, then Google loves fans like you!

  80. Re:objective C by BitZtream · · Score: 2, Insightful

    Objective-C has the absolute most fucking retarded 'memory management' model I have ever seen.

    Its got all the disadvantages of ref counting and non-ref counting allocation, and absolutely none of the advantages of either.

    Anyone who thinks Objective-C is simpler is sorely confused.

    --
    Persistent Volume manager for Kubernetes - https://github.com/dwimsey/openshift-pvmanager
  81. There are decent languages. by hendrikboom · · Score: 4, Insightful
    In the 70's, I wrote a parser generator. It was about 1000 lines long, and it took 25 tries to get it past the static checking of the compiler. After that, it ran correctly the first time I got to run it.

    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.

  82. That wasn't Pike, JavaScript ain't bad by weston · · Score: 2, Interesting

    It was actually Adam de Boor who discussed JavaScript.

    And while JavaScript has its warts, all in all, it's a pretty nice language. If gmail is 400k+ lines of code in JavaScript, it would have been well over a million (if not four million) in Java.

  83. Do you know who Rob Pike is? by Demena · · Score: 4, Insightful

    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?

  84. Umm... by deesine · · Score: 2, Insightful

    pretty well, actually.

    --
    damaged by dogma
  85. Re:Maybe because programmers like to be clear by shutdown+-p+now · · Score: 2, Interesting

    n a good programing language, the "using" block would be implicit by default when you allocated the object, and you would need to declare it "shared" or somehting for those corner cases where you want it to survive leaving scope (and done properly, "shared" would only create a problem where there was an algorithmic error, not a simple oversight).

    You've just described C++. Objects with automatic storage duration ("stack-allocated" for those not versed in standarteze) get cleaned up as their scope is gone, and to mark them "shared" you declare them using std::tr1::shared_ptr and allocate with "new".

  86. Re:We all know the ideal language has two function by bigngamer92 · · Score: 5, Funny

    And I was thinking something a little more classy:
    neverGiveThisUp(You);
    neverLetThisDown(You);

  87. New wave legacy by randomsearch · · Score: 2, Interesting

    Having spent a few years working with IBM mainframes running 30-year-old COBOL and assembly code, the problems of maintainability are always sitting at the back of my mind when debates like this come up.

    I've worked in Java and C commercially, and recently I've done a few web projects in PHP and JavaScript. I'm currently an academic researcher, and in that job I've spent some time writing Python and C++. I'm also familiar with the way we're teaching languages and programming, having been involved in the labs and lectures.

    I think we are in danger of creating a "new wave" (apologies to French cinema) of legacy software. Whilst scripting, dynamically-typed, languages can be fun and faster as tools to build code in the first place, they do not constrain or discipline the programmer as much as something like Java. Object-orientation with static typing etc. took off because it is a great way to design (some, not all) software in a structured manner to improve communication between engineers and address concerns like maintainability.

    I understand why people are using things like Ruby and Python right now, but I suspect it might be a short-termist view of the world. If you're planning to throw your website away, perhaps that's ok. Invariable though, things last much, much, longer than you expect them to.

    We've already seen how poorly sites like Facebook scale - imagine what they will be like in another 10 years. We may well look back on these years of great web development as building a legacy that a lot of us spend the rest of our lives trying to reverse-engineer, fix and replace.

    RS

  88. C has no advantages over C++. None. Nada. by Joce640k · · Score: 2, Insightful

    C++ OTOH, has many, many, many advantages over C.

    Vou can program it like C but take advantage of a few extra things like automatic memory management (no need to use free()), better strings (no strcpy or buffer overflows), etc. C++ is every bit as good as C for this.

    But ... for larger projects C++ provides proper control of resources (objects have defined lifetimes), exception handling (which combined with stack unwinding makes writing robust code much smaller/neater/easier), much better abstraction abilities (define your interfaces then worry about the details), better namespace control, etc.

    I'm sure that as a C zealot you've argued your case against the assembly language zealots, and rightly so - there's a very good reason why people switched from assembly language to C once the C compilers reached maturity.

    Well ... this is 2010 and that exact same reason is why they later switched from C to C++.

    The reason is that C simply doesn't scale. Big projects are a LOT more work in C than in C++ (just like writing 640k programs in assembler was a lot more work than in C), and for zero gain. Learn to use your tools and the "efficiency" argument vanishes like morning mist.

    --
    No sig today...