7 ms·
I am a Ruby guy torn between diving into Haskell or Clojure. Help! Every time I get excited about one feature of one (ClojureScript) I learn the other has somet
by lectrick 12y ago
I am a Ruby guy torn between diving into Haskell or Clojure. Help! Every time I get excited about one feature of one (ClojureScript) I learn the other has something equivalent or potentially better (Haste).
One thing that has put me off on Clojure is 1) the ugly as hell JVM stacktraces, 2) hitting the wall of the number system results in nasty JVM errors if you are used to Ruby's trivial (to the developer at least) handling of numbers of any size, 3) the time it takes to fire up the JVM itself (I like really fast really instant unit tests)
On the other hand, what has put me off on Haskell is that 1) all its users seem like mathematics professors, 2) a lot of its libraries will fail to compile when combined with each other without a lot of hand-holding and carefulness
- jhh 12y agoI'll try to dispel some of the concerns about Clojure. 1) Stacktraces in JVM may be ugly, but the amount of insight into runtime issues that the JVM offers you is generally way higher than in runtimes like cpython or MRI. 2) Clojure gives you a rather elegant way to work with the different JVM number types as it offers literals for those. I think Java Longs (the integer default) should be long enough as it's a 64 bit value. And on the floating point side the default is a double, which also seems nice to me. See: http://docs.oracle.com/javase/tutorial/java/nutsandbolts/datatypes.html http://docs.oracle.com/javase/tutorial/java/nutsandbolts/dat... Above this Clojure offers BigDecimal literals and native ratios. 3) The startup time is gigantic. However, while developing you usually should not have to restart the JVM as you can update the JVM with new bytecode through the REPL. This should also dispel the concern about unit tests (although I'm not sure you can reach the necessary speed, if you talk about < 0.5 second unit tests, because the code needs to be compiled to JVM bytecode 1st. There's definitely still potential there.
- wtetzner 12y agoOne thing I've noticed is that the JVM startup time is actually pretty small. What's slow is waiting for Clojure to bootstrap itself.
- pron 12y agoYep. A JVM doesn't take more than a about 100ms to start up. But Clojure takes a long time, and Leiningen is slow as hell.
- jhh 12y agoThat's true, but it's generally like this with any Java application. The JVM starts in 0.3 seconds, but loading all your classes usually takes seconds. I don't know the arcitecture well enough, but I think it's because it looks for classes in a lot of places and unpacks JAR files etc.
- strictfp 12y agoThat of course depends on the number of deps that you have, but you have to have a _lot_ to reach into the second range.
- rossjudson 12y agoDetailed discussion on startup times at http://nicholaskariniemi.github.io/2014/02/11/jvm-slow-startup.html http://nicholaskariniemi.github.io/2014/02/11/jvm-slow-start... (and subsequent articles by the same author).
- mduerksen 12y agoJVM Feature Request: The ability to preserve a complete JVM state (in this case with loaded Clojure stuff) and quickly start from there. Does anybody know if something like that is possible/already exists?
- wink 12y agohttps://github.com/ninjudd/drip https://github.com/ninjudd/drip http://www.martiansoftware.com/nailgun/ http://www.martiansoftware.com/nailgun/ http://leiningen.org/grench.html http://leiningen.org/grench.html All 3 not perfect, but have a look :)
- 616c 12y agoNot quite what you asked, but I found people recommending this. https://github.com/ninjudd/drip https://github.com/ninjudd/drip
- Expez 12y ago2) Clojure has sensible math with auto promotion to bignums, you don't have to worry about overflows like in Java. 3) You don't pay the price for the JVM startup time when running unit tests. When developing Clojure you have a JVM active at all time for your REPL. The JVM startup time is really only a problem if you want to write scripts. Your first issue with Haskell is a plus! Everyone in #Haskell on freenode are incredibly helpful, and well, if they're all professors you likely to get some quality help, right?
- tieTYT 12y ago> Your first issue with Haskell is a plus! Everyone in #Haskell on freenode are incredibly helpful, and well, if they're all professors you likely to get some quality help, right? Eh... The Haskell community is amazing and always willing to help. They get an A for effort, but they often have the curse of knowledge[0]. > The curse of knowledge is a cognitive bias that leads better-informed parties to find it extremely difficult to think about problems from the perspective of lesser-informed parties. [0]: http://en.wikipedia.org/wiki/Curse_of_knowledge http://en.wikipedia.org/wiki/Curse_of_knowledge
- brunov 12y agoI shared your worries about the turnover time for unit tests. But if you use something like [Midje][1] with the 'autotest' feature on, your tests will run in the background after each save. It typically takes a fraction of a second to run the full suite, so by the time I'm done hitting save and switching over to the midje console, the test results are already there. [1]: https://github.com/marick/Midje https://github.com/marick/Midje
- yogsototh 12y agoSo the two languages have all their strength and weaknesses. I start with Haskell, and I try Clojure, time to time. After working a while, I finally give a clear advantage to Haskell. Yes, Math people are chatty in Haskell, but you can do _a lot_ with very few Math. In fact, with Haskell, the more your project growth, the more time you spend on interesting things. While in Clojure (and most dynamic languages), you'll lose your precious time with undetected syntax errors, and all standard unitype errors. But for _very_ simple projects, Clojure is great in term of productivity. So in general, I try to use the right tool for the right job. - If you want to make a dirty thing, use a shell script or Perl. - If you want to make a prototype, Clojure is great. - If you want to make a project for production, then Haskell is the clear winner here (in term of bugs/efficiency/time). One thing I get with Haskell I didn't got with Clojure is "code scalability". In Haskell, my code tend to be more reusable than in Clojure.
- erichmond 12y agoI'm curious how Haskell could be a clear winner for production code, particularly as it pertains to efficiency and time. Clojure sits on top of the JVM, and as such, has the benefit of interop with some of the most robust software packages in the world. Unless I'm missing something, you'd need to roll your own packages in Haskell for all this functionality. I would argue that the most efficient code is well maintained open-sourced code that you don't have to write. I don't use Haskell, so there may be lots of libraries I don't know about, so forgive me if this question is naive.
- scott_s 12y agoGeneral advice: don't let the desire to learn the "right" thing prevent you from learning, period. Eventually, it's better to just make a choice and dive in, then to spend more time trying to figure out which one is "better".
- lectrick 12y agoAgreed 100%. I can learn both, given enough time.
- JackMorgan 12y agoAbsolutely learn both! Make sure you learn macros well (I suggest Let Over Lambda) and Haskell's powerful type system. I know Clojure and macros pretty well, but learning Haskell the last couple months has been incredible. And then learn Forth, J, Prolog, do SICP in Scheme, etc. ;)
- dsrguru 12y agoThey're both amazing languages that are simultaneously very fun to use and very powerful, not to mention great with concurrency, but here's the grossly oversimplified gist of when you'd want which language: Clojure has a beautiful dynamic type system. Haskell has a beautiful static type system. If you're working on a project with changing requirements (which for me means most nontrivial applications), Clojure will be much easier to work with and, as with most Lisps, is very well suited to what pg calls exploratory development. If you're working on a project whose requirements are largely static and known in advance (compilers, interpreters, parsers, static analyzers, mathematical tools, etc.), then you won't have to worry about coding yourself into a corner and Haskell's insanely powerful type system becomes a positive.
- chongli 12y agoWow. I came to the exact opposite conclusion you have. Changing requirements is really where Haskell shines. The ability to make a change in the types and have the compiler tell you everything that needs to be updated is an enormous aid to refactoring. As for exploratory programming? Haskell has powerful tools to do that as well. GHCI, type inference and typed holes[0] work extremely well for exploration of what's possible and can even give you solutions to your problem that you hadn't even thought of. [0]. http://www.haskell.org/haskellwiki/GHC/TypedHoles http://www.haskell.org/haskellwiki/GHC/TypedHoles
- platz 12y agoI agree, though one has to compare apples and apples. experienced programmer vs inexperienced programmer is not fair. Of course if one is unfamiliar with how to build a flexible type safe systems, (newbies), there could be these sorts of issues. But for experienced programmers, not really.
- chongli 12y agothough one has to compare apples and apples. experienced programmer vs inexperienced programmer is not fair. Oh, definitely. I just feel that far too many people focus on programming languages that are good for beginners without really thinking about them from an experienced programmer's perspective. What may be good for a beginner can often be terrible for an expert. What may be hard to understand for a beginner can be extremely powerful and simplifying for an expert. I think the question people should ask themselves is: "Do I want to stay a beginner forever? If not, why am I using tools that are designed for beginners?"
- dopamean 12y agoHey, I'm a Rubyist in the process of learning Clojure and Haskell. Shoot me an email sometime. I'd love to bounce some ideas around nick dot mcd at gmail
- pseudonom- 12y agobitemyapp seems to have pretty clear opinions on Haskell vs Clojure: http://bitemyapp.com/posts/2014-04-29-meditations-on-learning-haskell.html http://bitemyapp.com/posts/2014-04-29-meditations-on-learnin...
- cies 12y agoI went for Haskell. I think Clojure is too close to Ruby in the respect that there is not much safety build in. And I --like you-- am JVM-averse. :)
- Myrmornis 12y agoHere's a serious downside of Haskell: https://github.com/jwiegley/github/issues/25 https://github.com/jwiegley/github/issues/25 Experienced and skilled developers (wiegley's open source work includes ledger and great contributions to emacs org-mode), and the task is to make the API client's base URL configurable. Should be trivial. And yet it descends into farcical stuff about whether they need to introduce a new github monad or to "abstract over a type class". It seems like the purity was really getting in their way. The issue was never solved. I may be cherry picking an example which serves to parody Haskell, but for me that example is really off putting.