Stroustrup: Aesthetics matter, but a language has to be useful.

Discussions

News: Stroustrup: Aesthetics matter, but a language has to be useful.

  1. Bill de hÓra points out a great Bjarne Stroustrup quote, where the foremost designer of C++ says that "There are more useful systems developed in languages deemed awful than in languages praised for being beautiful." Considering how much attention is being paid to Java language features like closures, generics, and properties, Stroustrup's point is particularly appropriate. It's not about how pretty the language is, because - as he says - more useful systems have been designed in languages that look like keyboard vomit than in "beautiful languages." A language has to be appealing, but the core issue is whether people can and do use it to get things done.

    Threaded Messages (31)

  2. The core issue is not the ease of *writing* code in a language, but the ease of *maintaining* it. There are "elegant" syntaxes that coders love and maintainers cannot make head or tail of; the ternary conditional is always cited as an example of this, and I personally think closures are another. The "keyboard vomit" comment seems to be to be a well-deserved slap at Perl and its progeny--similar problem, opposite cause. Maintainable code can and should be written in any language: but how much time and trouble must be taken to do so?
  3. The core issue is not the ease of *writing* code in a language, but the ease of *maintaining* it...
    That depends. I've worked on projects covering the whole range from fast, cheap and dirty to long term maintainable. The cheap and dirty projects are typically small projects where scripting languages such as Groovy come in handy with their powerful closures, XML-builders etc. (with the positive side effect that they will have to hire you for any maintenance :) )
    IMHO they should leave Java as is and let people use a blended approach using Java and scripting (i.e. Groovy) together. Ivo Houbrechts Houbrechts IT - agile open source Java consultancy
  4. IMHO they should leave Java as is and let people use a blended approach using Java and scripting (i.e. Groovy) together.
    Amen. I've been using Jython for a little while now and it works wonderfully. Unfortunately Jython seems to be foundering at sea so I'll probably need a replacement. Groovy seems like the obvious choice only because it's being 'bone-i-fied' by Sun.
  5. closures... bad for maintainers??[ Go to top ]

    There are "elegant" syntaxes that coders love and maintainers cannot make head or tail of; the ternary conditional is always cited as an example of this, and I personally think closures are another.
    I really think closures would reduce the complexity of a lot of code. If you look at file handling in ruby, you can see why: File.open("myfile.txt").each { |line| puts line } Will print each line AND will close the file after the block has executed. No finally in which the resource is released!
  6. There are "elegant" syntaxes that coders love and maintainers cannot make head or tail of; the ternary conditional is always cited as an example of this, and I personally think closures are another.


    I really think closures would reduce the complexity of a lot of code. If you look at file handling in ruby, you can see why:

    File.open("myfile.txt").each { |line|
    puts line
    }

    Will print each line AND will close the file after the block has executed. No finally in which the resource is released!
    In this case you could do the exact same thing using function objects or anonymous inner classes.
  7. There are "elegant" syntaxes that coders love and maintainers cannot make head or tail of; the ternary conditional is always cited as an example of this, and I personally think closures are another.


    I really think closures would reduce the complexity of a lot of code. If you look at file handling in ruby, you can see why:

    File.open("myfile.txt").each { |line|
    puts line
    }

    Will print each line AND will close the file after the block has executed. No finally in which the resource is released!
    Or better yet, someone could write a class that implements Iterable that takes a filename as a parameter for it's constructor, opens the file when you begin iteration, and closes it when iteration is complete. Then the programmer could use the for loop syntax. So you could have: for (String line : new LineFile("myfile.txt")) { System.out.println(line); } I don't think that's any more complex than the Ruby example. Of course someone would have to write the LineFile class, but it would be pretty trivial.
  8. There are "elegant" syntaxes that coders love and maintainers cannot make head or tail of; the ternary conditional is always cited as an example of this, and I personally think closures are another.


    I really think closures would reduce the complexity of a lot of code. If you look at file handling in ruby, you can see why:

    File.open("myfile.txt").each { |line|
    puts line
    }

    Will print each line AND will close the file after the block has executed. No finally in which the resource is released!


    Or better yet, someone could write a class that implements Iterable that takes a filename as a parameter for it's constructor, opens the file when you begin iteration, and closes it when iteration is complete.

    Then the programmer could use the for loop syntax. So you could have:

    for (String line : new LineFile("myfile.txt")) {
    System.out.println(line);
    }

    I don't think that's any more complex than the Ruby example. Of course someone would have to write the LineFile class, but it would be pretty trivial.
    I've actually implemented a JDBC wrapper using the functional style like the .each() method given above, substituting an instance of an interface for a closure. I really your suggestion except that is has one fatal flaw (in Java). If the iteration doesn't complete successfully, the Iterable does not know that it needs to close it's resources. In C++ people use RIAA and we can use finalizers or Reference classes in Java but these still require that the Object is released and that's an unacceptable side effect, IMO. The flip side of that problem is that if I'm locked into being called N times from the each method, I can't break out if I've got everything I need. No big deal if there are 10 items but if you are talking about millions of rows of data and you find it in the 5th row, it's a serious issue. What I did is have the one method in my interface have a boolean return type, true = continue, false = break. If you could write these things as a loop, have them implemented as the functional foreach, and make it so that the foreach 'driver' could receive a break signal (using the break keyword), that to me would be the optimal solution. What do you think?
  9. I really your suggestion except that is has one fatal flaw (in Java). If the iteration doesn't complete successfully, the Iterable does not know that it needs to close it's resources. In C++ people use RIAA and we can use finalizers or Reference classes in Java but these still require that the Object is released and that's an unacceptable side effect, IMO.
    Yes, I'm always finding myself longing for C++ destructors. Resource management is so much more than memory management, and garbage collection only handles memory in a satisfactory way.
    If you could write these things as a loop, have them implemented as the functional foreach, and make it so that the foreach 'driver' could receive a break signal (using the break keyword), that to me would be the optimal solution. What do you think?
    Hmmm...have to think about that.
  10. Yes, I'm always finding myself longing for C++ destructors. Resource management is so much more than memory management, and garbage collection only handles memory in a satisfactory way.
    I don't really long for destructors because once I accepted that the functional paradigm can be used selectively in an OO language, I've found it to be superior in many cases to RIAA. Actually, I've combined the two in my JDBC wrapper. The code that does the SQL just makes a query and handles the rows. The wrapper always knows whether there is an active query. But instead of closing the PreparedStatement at that point, I associated it to the Object that represents the Query with a WeakReference. Each time the query is executed (with new parameters usually) it reuses the PreparedStatement, unless the Connection has expired, in which case a new PreparedStatement is created and associated with the Query. Once all active queries on an expired connection are complete, the connection is closed. The only way that this wrapper can not know that the query is done is if the row handler's method never returns. But this is a problem in itself that I don't think it worth worrying about at this level.
  11. I don't really long for destructors because once I accepted that the functional paradigm can be used selectively in an OO language, I've found it to be superior in many cases to RIAA.
    it's called RAII ;-)
  12. I don't really long for destructors because once I accepted that the functional paradigm can be used selectively in an OO language, I've found it to be superior in many cases to RIAA.


    it's called RAII ;-)
    Oops. Well, I think everyone knows what I meant.
  13. I don't really long for destructors because once I accepted that the functional paradigm can be used selectively in an OO language, I've found it to be superior in many cases to RIAA.
    Yes, functional programming is superior to the Recording Industry Association of America.
  14. Or better yet, someone could write a class that implements Iterable that takes a filename as a parameter for it's constructor, opens the file when you begin iteration, and closes it when iteration is complete.

    Then the programmer could use the for loop syntax. So you could have:

    for (String line : new LineFile("myfile.txt")) {
    System.out.println(line);
    }

    I don't think that's any more complex than the Ruby example. Of course someone would have to write the LineFile class, but it would be pretty trivial.
    That's not equivalent! What happens if the loop is terminated because of an exception? Then the Iterator returned by the LineFile instance won't be consumed and the file won't be closed.
  15. That's not equivalent! What happens if the loop is terminated because of an exception?
    Or break or return.
  16. That's not equivalent! What happens if the loop is terminated because of an exception?


    Or break or return.
    What happens if break or return is called from within the closure? Does it stop iteration or does it just move on to the next record? (I'm seriously asking, I've only played with Ruby and didn't really like it so I stopped) Using a function object would certainly be more correct, but the syntax would be more ugly. An exception within the Iterator could certainly be handled. An exception within the "user code" obviously would not.
  17. What happens if break or return is called from within the closure? Does it stop iteration or does it just move on to the next record? (I'm seriously asking, I've only played with Ruby and didn't really like it so I stopped)
    I haven't worked with Ruby so I can't say for sure. But a return would go to the next record and a break probably isn't allowed. But I could be way off. I use Python and I don't think there is anything like that. I've started learning Scala and what I was thinking is based on the fact that Scala has a for loop that looks much like an imperative for loop but in reality, when you write: for (...) { doStuff(); } It's actually passing an anonymous function (I apologize if I'm getting the details or terminology wrong here) to a 'for' function that does a foreach operation. I don't believe there is any support for a break from this (could be wrong) so I was just thinking, off the top of my head that if special syntactical support were added for break (and possibly also for return) to tell the iteration that it is done, you could get the best of both worlds. Maybe it would be too opaque for most people but I would like it.
  18. blocks throwing[ Go to top ]

    That's not equivalent! What happens if the loop is terminated because of an exception?


    Or break or return.


    What happens if break or return is called from within the closure? Does it stop iteration or does it just move on to the next record? (I'm seriously asking, I've only played with Ruby and didn't really like it so I stopped)

    Using a function object would certainly be more correct, but the syntax would be more ugly.

    An exception within the Iterator could certainly be handled. An exception within the "user code" obviously would not.
    The implementation of File#each looks something like this def File.each(path,mode) f = open(path,mode) if block_given? begin while line=f.readline yield line end rescue e log e end end close f end Passing a block allows the open/close, the loop, and the begin/rescue (try/catch) to all be in the library code instead of in your code. You get to concentrate on whatever magic you're doing to each line instead of writing the millionth loop and zillionth try/catch of your career.
  19. indents[ Go to top ]

    Sorry, about the missing indents. I "simply pressed spacebar" like the "How to post" says...
  20. Re: indents[ Go to top ]

    Sorry, about the missing indents. I "simply pressed spacebar" like the "How to post" says...
    You have to use the undocumented 'pre' tag.
  21. The core issue is not the ease of *writing* code in a language, but the ease of *maintaining* it.
    Or that is what they teach you in all the "right" books. It is, also, the most popular excuse for missing deadlines and going overbudget. Now, how about what customers REALLY care about i.e. - time-to-market? Besides, it's not "maintenance" that you should care about but ease of future modifications. And those two are by far not the same thing. People who think "maintain" way usually spend a lot of time finding "ideal" architecture that will serve all future needs (alas, the exact same ones they have no idea about right now) and end up with total garbage. People who think "ease of modifications" employ agile methodology, write unit-tests and continuously refactor the code. In my personal opinion, it's "good" code is way more about the personality of the developer than underlying programming language or technology. Some people are tidy, some people are mess. Period. As for Mr. Stroustrup... Well, let's just say - he is not my hero and C++ is not my beloved language :) Have a nice weekend!
  22. uh ya.[ Go to top ]

    "but the core issue is whether people can and do use it to get things done." This quote doesn't make any sense. He's almost advocating crappiness. Does he think Windows is the best OS since it is the most widely used? "but the core issue is whether people can and do use it to get things done." And IMO/E more expressive (more beautiful) languages "get things done" much more quickly than less expressive languages.
  23. Re: uh ya.[ Go to top ]

    sorry, cut and paste error. I meant to write: "There are more useful systems developed in languages deemed awful than in languages praised for being beautiful." This quote doesn't make any sense. He's almost advocating crappiness. Does he think Windows is the best OS since it is the most widely used? "but the core issue is whether people can and do use it to get things done." And IMO/E more expressive (more beautiful) languages "get things done" much more quickly than less expressive languages.
  24. Re: uh ya.[ Go to top ]

    I guess you might not have read his interview. It's a good read. He's talking about usefulness of C++ since it's criticised. Many good systems were and still are written in C++. The language is a bit ugly, but it does it's job well (it's a multi-purpose systems' language) and allows for elegant design.
    Does he think Windows is the best OS since it is the most widely used?
    He doesn't even say that C++ is the best language, I don't understand how you can say that. Please don't demonise him. He's a smart (and nice) guy who's helped OO become mainstream.
  25. Re: uh ya.[ Go to top ]

    He's a smart (and nice) guy who's helped OO become mainstream.
    Watch out. The SmallTalkers will go apeshit on you for saying that C++ is OO. I think BS pulls a lot of criticism because whenever someone points out that C++ has some warts he makes some argument like this. You are right that he didn't say it was the best but the other guy is also right to say this is a pretty weak argument. COBOL has probably been used to create more useful systems than C++. It's really neither here nor there. I've read other statements implying that if you have problems with C++, the fault is your skill level and not the complexity and enormous amount of baggage in the language. This is what gets people charged up about BS. Stroustrup's problems with the public are because of his lack of skill in diplomacy, not because people are out to get him. Dealing with the public is 'expert friendly', you could say.
  26. Re: uh ya.[ Go to top ]

    He's a smart (and nice) guy who's helped OO become mainstream.


    Watch out. The SmallTalkers will go apeshit on you for saying that C++ is OO
    Hmmm...haven't seen Paul around here in a while.
  27. Re: uh ya.[ Go to top ]

    He's a smart (and nice) guy who's helped OO become mainstream.


    Watch out. The SmallTalkers will go apeshit on you for saying that C++ is OO.
    ;) I actually didn't say it was OO (I was raised with Simula).
  28. Re: uh ya.[ Go to top ]

    Watch out. The SmallTalkers will go apeshit on you for saying that C++ is OO.
    Well, the infamous quote attributed to Alan Kay does come to mind. :)
  29. It is my impression that a large number of C++ features were designed to be aesthetic rather than usefulness. Unfortunately, those features are so tricky that nobody except a compiler-geek would consider them aesthetic anyway.
  30. It's not about how pretty the language is, because - as he says - more useful systems have been designed in languages that look like keyboard vomit than in "beautiful languages." A language has to be appealing, but the core issue is whether people can and do use it to get things done.
    "pretty" is subjective, of course, but the point for me has always been that the two should not be mutually exclusive. The core issue is the language should be both.
  31. Another "great" statement[ Go to top ]

    "There are more useful systems developed in languages deemed awful than in languages praised for being beautiful." Yup. Another "great" statement would be: There are more unusable systems developed in languages deemed awful than in languages praised for being beautiful. So?
  32. Rather than copying my answer all over, see my comments down at my blog