clojure vs haskell

I write C/python/javascript everyday at work and I wanted to mess around with a functional language at home.

Right now I'm leaning toward haskell because I figure It'd be more usefull for little scripts and parsers since you don't have to wait for jvm startup.

Also I don't know java.

I'd mainly be working on graphics programs with opengl/penumbra.

- Just like C++, Haskell is very hard to learn, and takes years to master. Things like Monads, Functors, Monoids, Higher-Order Types and a myriad of morphisms are hard to understand, especially without mathematical background. Most programmers probably don't have the ability or will to learn Haskell. Learning Haskell's syntax, libraries, functional programming techniques won't bring you closer to understanding: the true path to understand Haskell lies through Monoid-Functor-Applicative-Arrow-Monad. And even if you mange to learn Haskell, programming it still hogs a lot of brain resources, which could have been put to something more useful than just showing off about how clever you can be. "Haskell for Kids" even proposes exposing children to Haskell from yearly age, meaning Haskell, similar to mathematics and natural language, will be much harder to grasp at older age. "Zygohistomorphic prepromorphism: Zygo implements semi-mutual recursion like a zygomorphism. Para gives you access to your result à la paramorphism.", "Haskell is not 'a little different,' and will not 'take a little time.' It is very different and you cannot simply pick it up" -- HaskellWiki
- Poor backward compatibility: haskellers "don't want to replicate Java, which is outright flawed in order to avoid even the most unlikely of broken code", meaning they don't care if new version of GHC will break your code. Haskell projects are struggling under the weight of "DLL hell": typical Haskell package consist of just a few lines of code, thus many other projects depend on dozens of different packages, either directly or indirectly. It's near-impossible to embark on a serious Haskell project without spending time fighting dependency version issues.
- Haskell is slow and leaks memory. GHC's inefficient stop-the-world GC does not scale. A good understanding of evaluation order is very important for writing practical programs. People using Haskell often have no idea how evaluation affects the efficiency. It is no coincidence that Haskell programmers end up floundering around with space and time leaks that they do not understand. Functions take time to complete and debugging for time leaks is much more difficult than to debug for type errors. "The next Haskell will be strict." -- Simon Peyton-Jones
- Haskell's API lacks higher levels of abstraction, due to absence of variadic functions, optional arguments and keywords. Macros aren't possible either, due to overly complex syntax of Haskell. API documentation is very lacking: if you want to use regexes, you start at Text.Regex.Posix, seeing that =~ and =~~ are the high level API, and the hyperlinks for those functions go to Text.Regex.Posix.Wrap, where the main functions are not actually documented at all, so you look at the type signatures, trying to understand them and they are rather intimidating (class RegexOptions regex compOpt execOpt => RegexMaker regex compOpt execOpt source | regex -> compOpt execOpt, compOpt -> regex execOpt, execOpt -> regex compOpt where). They are using multi-parameter type classes and functional dependencies. The signature really wont give you any clue to how to actually use this API, which is a science in itself. Haskell is a language where memoization is a PhD-level topic.
- Haskell programming relies on mathematical modeling with type system (a version of mathematical Set Theory). If one does not use the type system for anything useful, it obviously will be nothing but a burden. Programs are limited by the expressiveness of the type system of the language - e.g. heterogeneous data structures aren't possible w/o reinventing explicit tagging. All that makes Haskell bad for prototyping or anything new, due to need of having design document with all types beforehand, which changes often during prototyping. Complex project are forced to reinvent dynamic typing. For instance, Grempa uses dynamic typing because the semantic action functions are put in an array indexing rule and production numbers (Ints) to functions, and they all have different types and so can not be put in an ordinary array expecting the same type for each element.
- The IDE options cannot be as good as those of dynamic programming languages, due to absence of run-time information and access to running program's state. Haskell's necrophilia forces you to work with "dead" code. Like other static languages, Haskell isn't well-known for its "reload on the fly" productivity. No eval or self-modifying code. Haskell code can't be changed without recompiling half of application and restarting the process. GHCI - is the best Haskell's interactivity can get, and still wont allow you to change types during runtime, while the single assignment semantics prevents redefinition of functions. As said Simon Peyton-Jones, "In the end, any program must manipulate state. A program that has no side effects whatsoever is a kind of black box. All you can tell is that the box gets hotter."
- Type system produced compile-time and link-time errors are distracting and make it harder to run and test your code, while type-checking isn't a substitute for testing, it is about correspondence to mathematical model, which has nothing to do with correctness - i.e. two numbers can be integers, but their quotient can still result into division by zero. Even though you may hear strong static-typing advocates say, "When your program type-checks, you'll often find that it just works", this is simply not true for large, intricate programs. Although type-checking may help you find model-related errors, it is not the same as testing.
- Absence of dynamic scope, implicit open recursion, late binding, and duck typing severely limits Haskell, since there are things that can't be done easily without these features: you can't implement dynamic scope in general (and be type-safe) without converting your entire program to use tagged values. So in this respect, Haskell is inferior to dynamic typing languages.
- Haskell makes it easy to write cryptic programs that no-one understands, not even yourself a few days later. Rich, baroque syntax, lazy evaluation and a tradition defining an operator for every function - all help obfuscation a lot. As a general rule, Haskell syntax is incredibly impenetrable: who in their right mind thought up the operators named .&., <|> and >>=?

agree with 2. leave the functional languages to academics. you are better off learning a new problem domain, advanced mathematics, operating system internals, and so on. Learning new languages doesn't teach you anything. FP is pure (heh) masturbation, something fakers do to put on their resume.

neither, learn Scala

Scala is a very easy language to learn, very similar to Python and Ruby in its syntax and the way it combines functional programming with OO. Scala is as fast as Java, which is a very vast language, faster than Go, probably the fastest VM language. Scala has very good concurrency/threaded programming constructs which is the future of programming. Clojure is not a bad language if you like the Lisp style of programming. But Lisp programming requires a complete change in style of programming whereas Scala is really no different than Python except it has static typing and type inference instead of dynamic typing. Haskell is a very difficult language, it requires a complete conversion into the functional style of programming, it has zero toleration for imperative programming style.

>>4
requires a complete change in style of programming whereas Scala is really no different than Python except it has static typing
as if python-style or static typing are something good.


Null, null, Nil, Nothing, None, and Unit in Scala

Null- Its a Trait.
null- Its an instance of Null- Similar to Java null.

Nil- Represents an emptry List of anything of zero length. Its not that it refers to nothing but it refers to List which has no contents.

Nothing is a Trait. Its a subtype of everything. But not superclass of anything. There are no instances of Nothing.

None- Used to represent a sensible return value. Just to avoid null pointer exception. Option has exactly 2 subclasses- Some and None. None signifies no result from the method.

Unit- Type of method that doesn’t return a value of anys sort.

    Note: Any is supertype of AnyRef and AnyVal. AnyRef is the supertype of all the reference classes (like String, List, Iterable) in scala. AnyVal is the supertype of all the value classes (like Int, Float, Double, Byte, Short..). Null is a subtype of all the reference classes. null is its only instance. Nothing is subtype of every other type i.e of reference and value classes.

    Think- AnyRef == Object in Java.

The above is a breif summary of a wonderful post by Matt Malone where he has explained all these concepts in depth with examples. Read the blog post here.

Don’t forget the object _scala.xml.Null_. I was stuck for some time, mistaking it for null. Its used in scala.xml.MetaData which in turn is used for xml attributes.

read Seven Languages in Seven Weeks if you want to try out Haskell, Erlang, Scala, Prolog, Clojure

>>1
Check out Shen. It's a minimalist Lisp with some modern features.

http://www.shenlanguage.org/

>>2
Slow GC, what?  In my experience it was very fast, much faster and more reliable than shitty CPython and Perl5 GCs.  I don't know about Sun JVM's GC.  I ask you to post a real-life example where GHC GC becomes a bottleneck, or even a major burden.

Yes, you have to know about order of evaluation, understand that lazy implies much much more than simply ``not evaluated if not needed'', know about head normal forms etc.  This is hard, but you are supposed to be really smart if you program haskell, so it's not an issue.

Haskell may be bad (but not necessary, it really depends on your thought process) for prototyping Python code because it disallows heterosexual lists.  But having them in Python is already a sign of poor hacky design.

Regex documentation is a known issue because its author refuses to write it on principle grounds.

Absence of dynamic scope, implicit open recursion, late binding, and duck typing severely limits Haskell
Absence of embedded Prolog in Python makes writing Prolog programs in Python hard, same big fucking surprise.

a tradition defining an operator for every function - all help obfuscation a lot.
No, it does not, as very little libraries provide operators for their functions (and most operators are just aliases for sanely named binary functions).  You only have to learn the very basic operators, namely arithmetic, applicative functors, monads, arrows, and bit operators from Data.Bits.  Regexp operators are hard to learn unless you google for ``Haskell regexp howto chris kuklewitz is an asshole'', which will give you a ton of useful examples.

Background: I learned Scheme off SICP, and Haskell later on. I've no experience with Clojure except a quick tutorial. I've dabbled with Emacs-Lisp.

Right now I'm leaning toward haskell because I figure It'd be more usefull for little scripts and parsers since you don't have to wait for jvm startup.

Use Python for little scripts, it excels at them and you don't have to wait for compilation (long with Haskell generally) or JVM startup time.

Python also has many functional features to the point that you can write very functional Python.

Between Clojure and Haskell I would go with Clojure, Haskell is big and complicated with many hard concepts, and you need to spend a long time learning it, while Lisp is generally not a large language once you get the concepts down.

So really: use Python for your little scripts and use it to learn some functional programming. I recommend SICP for learning Scheme (or you can go through the book with Clojure, many people have done so). Between Clojure and Haskell I'd go with Clojure.

>>1
is not that bad,op. you could be working in Java/Adobe Flex and be a tormented soul like me.

>>2

What would you recommend?

I was looking for a functional programming language (since I already know C and ASM).
My mathematics is STRONG.

Thank you

They're both shit. Learn scheme.

>>12
From Scheme to Common Lisp is like a refugee
  from very rural Pakistan who gets relocated to Oslo, Norway, and still
  thinks that he could make better food if he were only allowed to light a
  fire in his living room instead of using that complex electric stove.
  (This is a real news item.  Every now and then, landlords discover indoor
  fireplaces and occasionally the "newbies" to civilization burn down the
  building.)  While it may seem "jarring" to the newbie to learn the ropes
  of a society that has evolved at least a thousand years further than what
  they left, it would not be the same for us to try out their lifestyle.

>>13
Maybe when I don't have to sell my children to Saudi Sheiks in order to get my hands on tree shaking I'll listen.

 Kimi to Kanojo to Kanojo no Koi was poorly written and had little going for it other than the meta gimmick. Only play it if you're really interested in having someone preach at you about how horrible a person you are for playing eroge

I was offered a position at a Japanese chemical company, starting stateside, and moving to Japan in a few years.