Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Haskell vs. Clojure (2014)

gist.github.com

Post reply on HN
Print view View original

21–30 of 55 posts

Re: Haskell vs. Clojure (2014)

#21

Post by tsm »

asciihacker wrote: post #16
bitwize wrote: 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.

Clojure's immutable types mean just that—the values are immutable (e.g., in CL you could do (defvar x 42) (setf x 84), but in Clojure the equivalent is not allowed).

But there are many more side effects than changing variables. Clojure makes no guarantees that a given function is referentially transparent, nor does it promise that a given function doesn't write to stdout/stderr, read from stdin, change the file system, make a network connection, send missiles to foreign countries, etcetera.

Re: Haskell vs. Clojure (2014)

#22

Post by hardwaresofton »

elliotec wrote: 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.

Keeping up with JS? Maybe you're referring to clojurescript, for that criticism?

Re: Haskell vs. Clojure (2014)

#23

Post by alexbanks »

fbreduc wrote: post #4
sdegutis wrote: 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

If your only benchmark is less code, dynamic typing is fine. This example also doesn't really exemplify the value of static typing, in that the example is a "sandboxed"(it does not have to work with external APIs, other developers, etc) "non-maintained"(once it's written it won't change over a few years requiring support) code block.

An example of "Lets take 6 devs and have them build something" would probably create a more obvious use for Haskell over Clojure, as the biggest problem (to me) with Dynamic Typing is its scalability under development. As in, alone I (and most devs) could write dynamically typed code with little issue, as all decisions are made internally and guard cases can be written correctly based on those internal decisions. But throwing a second dev (or n devs) into the mix makes those internal decisions much more difficult, making the guard clauses much more difficult to write correctly. Static typing takes a lot of the guard-clause-writing out of the picture, as the compiler creates them for you.

Re: Haskell vs. Clojure (2014)

#24

Post by sgk284 »

fbreduc wrote: post #4
sdegutis wrote: 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 completely eliminates a class of runtime errors from your code, while also allowing all code that consumes the data to make assumptions about the data.

In the untyped code you must validate everywhere you access the data or trust that someone above you already validated it (which can break silently with any future modification).

Re: Haskell vs. Clojure (2014)

#26

Post by sarnowski »

tsm wrote: post #21
asciihacker wrote: post #16

Earlier quoted context omitted.

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

Clojure's immutable types mean just that—the values are immutable (e.g., in CL you could do (defvar x 42) (setf x 84), but in Clojure the equivalent is not allowed). But there are many more side effects than changing variables. Clojure makes no guarantees that a given function is referentially transparent, nor does it promise that a given function doesn't write to stdout/stderr, read from stdin, change the file syste…

Not arguing that the following method can be trusted as much as in Haskell but properly used also prevents this kind of scenario:

https://clojuredocs.org/clojure.core/io℅21

The 'io!' macro marks a code block to have side effects which prevents using it in a STM transaction as 'dosync' might need to execute the functions multiple times in case of conflicts during the optimistic locking.

Re: Haskell vs. Clojure (2014)

#27

Post by nafarlee »

hardwaresofton wrote: post #22
elliotec wrote: 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.

Keeping up with JS? Maybe you're referring to clojurescript, for that criticism?

I think he meant he has to spend so much time keeping up with JS, that he does not have the chance to use Clojure more.

Re: Haskell vs. Clojure (2014)

#28

Post by gyim »

tsm wrote: post #18
Zolomon wrote: post #7

Earlier quoted context omitted.

> ... 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, QuickL…

I haven't used the LOOP macro in CL, but the for macro in Clojure is also very powerful and (imho) very readable.

My take on the 'versify' example in 4 lines:

    (for [book book-order
          chapter (range 1 1000) :when (get-in bible [book (str chapter)])
          verse (range 1 1000) :when (get-in bible [book (str chapter) (str verse)])]
      [book chapter verse (get-in bible [book (str chapter) (str verse)])])
Notice that a single "for" can iterate in a multi-level structure. You can also use :let if you don't want to call (get-in) multiple times (which makes the code shorter, but more redundant and less efficient)

Re: Haskell vs. Clojure (2014)

#30

Post by elliotec »

nafarlee wrote: post #27
hardwaresofton wrote: post #22

Earlier quoted context omitted.

Keeping up with JS? Maybe you're referring to clojurescript, for that criticism?

I think he meant he has to spend so much time keeping up with JS, that he does not have the chance to use Clojure more.

Yes thank you.
Post reply on HN