3 ms·

A 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 f

by tikhonj 14y ago

A 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 14y ago
Every 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 14y ago
  Untrue 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 14y ago
    You still have to know a lot to use those abstractions...like category theory (monads and arrows). You have to at least be able to read the paper even if you aren't capable of writing it. There is also a kind of compulsion to design elegant abstractions when using Haskell, to think about and understand problems really well before you write a solution. This is not just about the kind of people who are attracted to using Haskell, but the language itself promotes this compulsion. Sure, you can drop into Haskell's imperative subset, but it is frowned on and discouraged. Java as a language gives you very little, and there is not much pressure to obsess over the design of abstractions. This is both good and bad: good in that you feel less guilt about writing dirty code fairly quickly and with less understanding (to be acquired more gradually via trial and error), and bad in that this code will probably incur more technical debt. Sometimes worse is better [1], ironically (or maybe not) a concept that comes from Gabriel, who is a cornerstone of the common lisp community. [1] http://www.dreamsongs.com/WorseIsBetter.html http://www.dreamsongs.com/WorseIsBetter.html
    - tel 14y ago
      It's frowned upon because the imperative subsets tend to code that's less general and harder to reason about. These critiques falls identically on Java, though nobody misses it there because nobody practices the generality and reasonability available in a very simple typed lambda calculus there. It's remarkable how much more you have to keep alive in your mind to program in Java (or even Clojure) over Haskell. The reason things are more complex is because you're freed from having to think hard about state and execution methodology except at bottlenecks of design and performance.
danieldk 14y ago
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. The amount of type wizardry that Haskell permits is far larger than Java and C++ teaches us that in practice you have to expect all possible combinations language features that are allowed. A random Java library will have a far more understandable API than a random Haskell package, since there are not so many permutations of language features possible. If everybody stuck to just Haskell 98, things would be far simpler. Besides, have you ever tried to use the equivalent of Parsec or QuickCheck in Java? As a matter of fact, I just committed QuickCheck-like unit tests five minutes ago [1] :): https://github.com/danieldk/dictomaton/commit/7aaa89aae68524f32528b6fb5e28d0d14da9b828 https://github.com/danieldk/dictomaton/commit/7aaa89aae68524... I write such tests in Java quite often. Of course, you don't have the nice combinators of QuickCheck :). I am not saying that Haskell isn't more powerful it is. But it comes at a cost: many packages come with an up-front learning cost, Haskell is hard to optimize compared to Java or C, etc. The Java APIs are predictable, run-time performance is predictable (in the sense that it easy to profile and optimize) and the ecosystem is boring and predictable. These are some of reasons that Java is popular (besides having a steward with deep pockets). ([1] Ps. yes, I know there is a very obvious optimization optimization possible that commit, it's a development branch.)

by tikhonj 14y ago

seanmcdirmid 14y ago

Every 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 14y ago
Untrue 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 14y ago
  You still have to know a lot to use those abstractions...like category theory (monads and arrows). You have to at least be able to read the paper even if you aren't capable of writing it. There is also a kind of compulsion to design elegant abstractions when using Haskell, to think about and understand problems really well before you write a solution. This is not just about the kind of people who are attracted to using Haskell, but the language itself promotes this compulsion. Sure, you can drop into Haskell's imperative subset, but it is frowned on and discouraged. Java as a language gives you very little, and there is not much pressure to obsess over the design of abstractions. This is both good and bad: good in that you feel less guilt about writing dirty code fairly quickly and with less understanding (to be acquired more gradually via trial and error), and bad in that this code will probably incur more technical debt. Sometimes worse is better [1], ironically (or maybe not) a concept that comes from Gabriel, who is a cornerstone of the common lisp community. [1] http://www.dreamsongs.com/WorseIsBetter.html http://www.dreamsongs.com/WorseIsBetter.html
  - tel 14y ago
    It's frowned upon because the imperative subsets tend to code that's less general and harder to reason about. These critiques falls identically on Java, though nobody misses it there because nobody practices the generality and reasonability available in a very simple typed lambda calculus there. It's remarkable how much more you have to keep alive in your mind to program in Java (or even Clojure) over Haskell. The reason things are more complex is because you're freed from having to think hard about state and execution methodology except at bottlenecks of design and performance.

danieldk 14y ago

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. The amount of type wizardry that Haskell permits is far larger than Java and C++ teaches us that in practice you have to expect all possible combinations language features that are allowed. A random Java library will have a far more understandable API than a random Haskell package, since there are not so many permutations of language features possible. If everybody stuck to just Haskell 98, things would be far simpler. Besides, have you ever tried to use the equivalent of Parsec or QuickCheck in Java? As a matter of fact, I just committed QuickCheck-like unit tests five minutes ago [1] :): https://github.com/danieldk/dictomaton/commit/7aaa89aae68524f32528b6fb5e28d0d14da9b828 https://github.com/danieldk/dictomaton/commit/7aaa89aae68524... I write such tests in Java quite often. Of course, you don't have the nice combinators of QuickCheck :). I am not saying that Haskell isn't more powerful it is. But it comes at a cost: many packages come with an up-front learning cost, Haskell is hard to optimize compared to Java or C, etc. The Java APIs are predictable, run-time performance is predictable (in the sense that it easy to profile and optimize) and the ecosystem is boring and predictable. These are some of reasons that Java is popular (besides having a steward with deep pockets). ([1] Ps. yes, I know there is a very obvious optimization optimization possible that commit, it's a development branch.)