Live data from Hacker News

Haskell vs. Clojure (2014)

gist.github.com

11–20 of 55 posts

Re: Haskell vs. Clojure (2014)

#11
post #2

Clojure is beautiful and elegant. If not for it's lack of popularity and necessity of keeping up with JS constantly, it would be my most used language especially on side projects. Clojure is one of my favorite languages. If they get the stack traces/better errors figured out, it will be damn near perfect IMO.

The stacktraces are a bit verbose but still very readable

Re: Haskell vs. Clojure (2014)

#12
post #3

The Clojure code is shorter, but that's almost entirely because it's dynamically typed. And that's not necessarily a benefit, either. Cheshire just takes JSON and turns it into plain old Clojure data (maps, vectors, strings or keywords, etc.) whereas Aeson requires the programmer to manually unroll the whole structure from top to bottom into user-defined types. But by doing so it guarantees that if something is missi…

http://clojure.org/about/spec

Re: Haskell vs. Clojure (2014)

#13
post #3

The Clojure code is shorter, but that's almost entirely because it's dynamically typed. And that's not necessarily a benefit, either. Cheshire just takes JSON and turns it into plain old Clojure data (maps, vectors, strings or keywords, etc.) whereas Aeson requires the programmer to manually unroll the whole structure from top to bottom into user-defined types. But by doing so it guarantees that if something is missi…

While it isn’t a static guarantee, clojure’s new spec lib (https://clojure.org/about/spec), get you out of just being stringly typed

Re: Haskell vs. Clojure (2014)

#15
post #4
post #3

The Clojure code is shorter, but that's almost entirely because it's dynamically typed. And that's not necessarily a benefit, either. Cheshire just takes JSON and turns it into plain old Clojure data (maps, vectors, strings or keywords, etc.) whereas Aeson requires the programmer to manually unroll the whole structure from top to bottom into user-defined types. But by doing so it guarantees that if something is missi…

hmm still unsure what the types win me then

It's pretty handy to only have to be vigilant at the boundary layer. With the untyped approach, all consumers of the deserialized map have to guard against data which doesn't conform to expectations. With the typed approach, all subsequent functions only have to work with data conforming to the specification as laid out by types.

Re: Haskell vs. Clojure (2014)

#16
post #5

If you just want to get shit done, Clojure is fine (though any other Lisp would arguably be better than Clojure). If you want to get shit done, and make sure the types are correct, and make sure all side effects are properly managed and accounted for, that's Haskell's niche.

>If you want to get shit done, and make sure the types are correct, and make sure all side effects are properly managed and accounted for, that's Haskell's niche.

Dont Clojure's immutable types handle the side-effect issues well? Without the contortions that Haskell puts you through.

Re: Haskell vs. Clojure (2014)

#18
post #7
post #5

If you just want to get shit done, Clojure is fine (though any other Lisp would arguably be better than Clojure). If you want to get shit done, and make sure the types are correct, and make sure all side effects are properly managed and accounted for, that's Haskell's niche.

> ... Clojure is fine (though any other Lisp would arguably be better than Clojure). Care to elaborate why you think any other Lisp is better than Clojure? I would like to hear your arguments.

Not the GP, but for quick things I prefer CL because:

* TIMTOWTDI. Doing everything with map/reduce/filter is great, but sometimes it's more direct to just use the LOOP macro. Immutability is great, but sometimes it's way faster to just SETF something (and not have to worry about atoms).

* Batteries (more) included. IME, I find myself needing to use third-party libraries sooner with Clojure than with CL. Also, QuickLisp is arguably faster to get rolling with than Leiningen (I've found it easier to get the new library into my existing lisp image). And CL tends to have clusters of functions that do similar-but-different things, whereas Clojure puts the cognitive burden on you to do things right (example off the top of my head: CL has REMOVE, REMOVE-IF, and REMOVE-IF-NOT, Clojure has ????? (like ten different ways, I'm serious), `(filter pred list)`, and `(filter (complement pred) list)`).

* The debugging situation is fantastic. Both because CL deals with errors a lot more gracefully than Clojure (are we allowed to blame the JVM?) and because SLIME >>> CIDER, at least for now.

Re: Haskell vs. Clojure (2014)

#19
That haskell implementation is less than ideal. If he uses Data.Aeson.Lens, most of that instance declaration business is not necessary. It would just be mapping over the chapter keys to create the list of lists, then sorting it.

Re: Haskell vs. Clojure (2014)

#20
post #7
post #5

If you just want to get shit done, Clojure is fine (though any other Lisp would arguably be better than Clojure). If you want to get shit done, and make sure the types are correct, and make sure all side effects are properly managed and accounted for, that's Haskell's niche.

> ... Clojure is fine (though any other Lisp would arguably be better than Clojure). Care to elaborate why you think any other Lisp is better than Clojure? I would like to hear your arguments.

Clojure has neither the cool constructs of CL (CLOS, conditions) nor the minimal design and fantastic set of control primitives of Scheme. In fact it has no significant advantage over Scheme aside from running on the JVM, and a few disadvantages (recur, why TF are lambda lists vectors?, etc.). It's different enough to be weird and annoying, but the differences aren't advantageous enough to make me want to switch: Scheme (and CL!) has been made to run efficiently on the JVM (with some caveats, which Clojure has also!).
Post reply on HN