2 ms·

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

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

by tikhonj 14y ago

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.