6 ms·
I agree. >[The 911 is] so obviously superior to the Cadillac that a child could tell it's better. My first thought was that the Cadillac looked better even th
by Nav_Panel 13y ago
I agree.
>[The 911 is] so obviously superior to the Cadillac that a child could tell it's better.
My first thought was that the Cadillac looked better even though the internals of the 911 were certainly higher quality. Does that mean I have worse design sense than a child? :(
>The Cadillac was carefully designed to appeal to the average driver. The 911 was designed for performance. Which one is better design?
It all depends on how you evaluate quality: there are so many ways to determine the "best" that questions like this are almost meaningless.
Regardless of the car metaphor, I think PG's point makes a lot of sense.
- rdl 13y agoYeah, I also prefer the Cadillac visually. (although I'd drop either for a BMW 2002) And for 90% of what you do with the car, the Cadillac was probably more practical. Particularly if you lived in any parts of the US except maybe LA/SF/NY in 1973.
- danieldk 13y agoRegardless of the car metaphor, I think PG's point makes a lot of sense. Does it? From the article: C, Smalltalk, Lisp. The languages that were consciously designed for "average" programmers (Cobol, Pascal, Ada) have tended to be evolutionary dead ends. COBOL and Pascal (via Delphi) are probably used more than Smalltalk and Lisp in the real world. Also, Java and C#, designed for the 'average' programmer, are immensely popular outside our little bubble. Java has been around for twenty years and will probably be for at least two more decades. I like tinkering with new and 'revolutionary' languages - I wrote a fair share of Prolog and Haskell, but I have come to the realisation that that I like to solve interesting problems (mostly in NLP and machine learning) far more. And when you focus on solving an interesting problem it can be good that the language and ecosystem are boring and predictable (Java, C, C++), so that you can focus at the problem at hand. For example, in Java you can easily add a library to a project via Maven and its usage will often be completely predictable, you don't have to deal with the fact that the library writer was in an existential typing, GADT, or arrows phase and fight with its API. BTW. I still love Prolog and Haskell ;).
- tikhonj 13y agoA false dichotomy. Somehow, these always crop up when discussing languages. Sure, in Java you don't have to deal with GADTs. But you do have to deal with the fact that people think functions are dark magic and expect you to extend an abstract class instead. (Yes, Swing, I'm looking at you!) I've found that the advantages of using a nice high-level language like Haskell far outweigh issues with build systems and libraries and the usual boring stuff Java et al are supposed to excel at. This for very interesting problems--most recently, program synthesis using MCMC. (Following the "Stochastic Superoptimization" paper, but I honestly think that name is a bit silly :P.) Besides, have you ever tried to use the equivalent of Parsec or QuickCheck in Java? Even boring, practical things like that are better in Haskell!
- seanmcdirmid 13y agoEvery time someone figures out how to solve a small programming problem elegantly in Haskell, it is interesting enough for a 10 page ICFP paper with a 10 page appendix. Sure, Java is inelegant and dirty, but you don't have to perform the thinking needed to write a dissertation to use it.
- tikhonj 13y agoUntrue for the things Java makes easy. After all, in the worst case, you can just drop into Haskell's imperative subset. Besides, it's mostly small programming problems like practical STM, deterministic parallelism, easy randomized testing or DSLs for describing derivatives (alliterative). These are things not even dreamed of in Java--the only reason they're small is because Haskell makes them small. However, all this is not important. Sure, coming up with abstractions requires research and produces papers. But using the abstractions doesn't! OOP and Java and the JVM are all based on a ton of CS research themselves, but clearly you don't think that makes them impenetrable. The same applies to Haskell--you don't have to create your own abstractions from scratch; instead, just use the brilliant ones people have created for you.
- seanmcdirmid 13y ago