4 ms·

It is an issue of the language's qualities if it does not really make it easier to reason about code. I find reason to question the simplicity of something whi

• papsosouid 14y ago
  >It is an issue of the language's qualities if it does not really make it easier to reason about code. The primary point of haskell is making it easier to reason about your code. >I find reason to question the simplicity of something which is widely acknowledged to take a lot of time to learn, to be mind-bending, and which seems to be impossible to explain simply It takes a long time to learn any programming language. You create an invalid comparison when you compare learning language X++ after already learning X to learning language Y++ without having learned language Y. Haskell only takes longer to learn if you compare it to learning a language that is virtually identical semantically to a language you already know. And I don't know why you think it is impossible to explain haskell simply, there's a reason everyone points to learnyouahaskell.com when people ask how to learn haskell. >The virtues of survivors like C and LISP are not all "social issues". How is lisp a "survivor" exactly? Haskell is more widely used than any lisp is.
  • rafcavallaro 14y ago
    The tiobe index has lisp in the top 20 (at 13th) while Haskell is at 33rd, so lisp is more popular than Haskell even though lisp is over a half century old. Being in the top twenty after 50 years looks like the very definition of "survivor" to me.
    • papsosouid 14y ago
      Lisp isn't a language, it is a whole bunch of languages. Lumping half a dozen languages together obviously moves it up the list. Being old is working in its favour, not against it. Older languages have more written about them purely because of the time they've existed. Pick a specific lisp and try your comparison again.
• tikhonj 14y ago
  Simple does not imply easy. As an extreme example, a unicycle is simpler than a bicycle--fewer components, simpler structure, no gearing--but also more difficult to learn. Really, I'll just have to point you to the "Simple Made Easy" talk again. The core point being that there's a difference between something being "simple" and something being "easy", and we should generally strive for the former rather than the latter. Having a deep theoretical foundation is also not a sign of complexity. Instead, like most of math, it's usually a sign of simplicity. After all, math always strives for elegance and simplicity. What it means is that a lot of smart people have spent a lot of time thinking things through using a strict framework for reasoning that ensures everything is consistent. The theoretical framework lets us simplify by recasting different concepts using the same fundamental ideas. If we can capture things like state, errors and non-determinism using a single concept, we've made things simpler because now we have a common ground and relationship between seemingly disjoint ideas. This is exactly what Haskell (and the theory behind it) does. This theoretical foundation, coupled with the relative simplicity and consistency of the language, actually make code much easier to reason about in Haskell than in other languages, except for some performance issues. Basically, as long as your main concern is in semantics--and, for 90% of your code, it is--Haskell makes life easier than any other language I know. You can manipulate the code purely algebraically, without worrying about what it does, and be content that the meaning remains the same. Having well designed libraries with actual algebraic laws governing their behavior, a powerful type system and very transparent syntactic sugar is what makes the code particularly easy to reason about. A simple, elegant semantics also really helps. You can really see the influences of a good denotational semantics when using the language. Now, reasoning about performance is sometimes an issue. It's certainly reasonably hard without additional tooling. Happily, there are some nice tools like criterion[1] to make life easier for you. [1]: http://www.serpentine.com/blog/2009/09/29/criterion-a-new-benchmarking-library-for-haskell/ http://www.serpentine.com/blog/2009/09/29/criterion-a-new-be... Also, the Haskell community does acknowledge trade-offs. They're just not the same trade-offs that people not knowing Haskell lambast. Which should not be a surprise--you can't expect somebody who hasn't really learned Haskell or its underlying ideas to have a thorough idea of what its real problems (or even its real advantages) are.
  • joe_the_user 14y ago
• nightski 14y ago
  Hrm, I have found the main benefit of Haskell is that it makes it far easier to reason about code. The separation of side effecting operations from non-side effecting is huge. Also I am very comfortable with monads and have never dug into the theoretical category theory side of it. I bet you could be writing code in the IO monad within a day with some proper guidance. It really isn't hard at all.
• tieTYT 14y ago
  That's not fair. Remember how long it took to learn how to program for the first time? Haskell is so different from imperative programming you should approach it like that.