4 ms·

If they had any marketing sense, they would start by telling me why it's better than Clojure. I'm sorry to offend the Scala guys, but if you want to be the bes

by blunte 10y ago

If they had any marketing sense, they would start by telling me why it's better than Clojure. I'm sorry to offend the Scala guys, but if you want to be the best JVM language, you need to improve on Clojure.

zzalpha 10y ago
I hope what you're really saying is that they need to do a better job of marketing to folks not already familiar with Haskell or similar ML-derived functional programming languages. And that's probably true. As for specifically competing with Clojure... frankly, who cares? The two are so different as to render such a comparison fairly useless: Lisp-y s-expressions versus ML-style syntax. Strict Hindley-Milner-style type system vs Lisp-style dynamic typing. Lazy evaluation versus strict. Pure versus impure. The list goes on and on. Clojure is an interesting language, no doubt. But your response would seem to imply it's the end-all and be-all of programming languages, and given how subjective such an assessment would be, it strikes me as a fairly vacuous claim...
- blunte 10y ago
  We are talking about the JVM. And as such, the existing competitors are Java, Scala, and Clojure. Scala had promise, but many significant users discovered warts on large projects. And on top of that, Lisp is not only sexy (rationally or irrationally), but Clojure has a lot of intellectual momentum. Further, we have Clojurescript for nodejs. It is the one to beat. So if someone is going to sell me on a better JVM language, they need to at least give me a pro/con list vs Clojure. While HN might disagree, the market (people who work in companies that live for revenue, not VC) will agree in my interest for that comparison.
  - rahulmutt 10y ago
    Lisp is sexy, but parenthesis are a really hard sell for the wide crowd. It sounds silly, but that's the reality. If they had forced people to learn & use Lisp instead of C, the world might be a very different place. I personally love them even now when I look back at Clojure code. Clojurescript is just wonderful. I'm not even sure a Haskell-like language that compiles to JavaScript (Elm, PureScript, GHCJS) with really good tooling can beat it, though I haven't tried. Would be an interesting experiment to do a comparison by writing the same app in all the languages.
    - _halgari 10y ago
      And yet, Clojure has less parens than your average JS program. Even Java has more syntactic sugar. Just compare: foo.bar(baz) to: (.bar foo baz) Same number of parens...they're just in different places. Sure CommonLisp has a ton of parens, but thats CL and it has its own set of issues. One more example: Runnable foo = new Runnable() { Object run(Object bar) { return bar; } } vs (reify Runnable (run [bar] bar)) Less parens, no brackets, no semicolons, and no ceremony. This "parens are killing Clojure" meme is just a straw-man.
  - hardwaresofton 10y ago
    Just expanding on the parent to your comment a little bit more... Clojure and Haskell are two almost completely different beasts. Thanks to clojure's simplicity (as a dialect of lisp), it could BECOME haskell if you wrote the DSLs for it, but the reverse is much harder, I would think. Eta is not looking to convince clojurists to use haskell on the jvm instead of clojure, it's (most likely, I don't maintain the project) to enable those who want to use haskell but want to also use the JVM to do so. Regardless of whether Haskell is a better choice for your project or clojure is, the eta team (or any other team for that matter) is under no obligation to find that out for you, or even to make your search any easier. That's your job -- if clojure still fits your needs and doesn't have any glaring issues, absolutely use it.
    - Buttons840 10y ago
      Are you saying that writing Haskell in Lisp is easier than writing Lisp in Haskell? Or did I get that backwards?
      - hardwaresofton 10y ago
        Yes -- to clarify, it I'm saying that it would be easier (for me at least) to write with haskell's semantics/paradigm than it would be for me to write with lisp's semantics/paradigm in haskell. I think the statement is almost axiomatic. Lisp is multi-paradigm, by way of simplicity/choices not being made for you. Haskell is decidedly functional (which is something I love about it). Making a more specific thing into a less specific thing (while possible in this case), seems like a more difficult task than molding the clay that is LISP to look like haskell.
  - lenkite 10y ago
    I looked at Clojure but the lack of static types and thus losing the benefit of refactoring always put me away. Out of curiosity - how do you safely refactor Clojure code ? Safe Refactoring offered by type safe languages is such a major aid to redesigning code that it has become difficult for me to work in dynamic languages for any large code bases.
    - _halgari 10y ago
      I've been a full-time Clojure dev for about 4-5 years now. And the number of times you have to refactor (in the traditional sense) Clojure code is pretty rare. And the reason is that Clojure leverages it's use of immutable data structures, namely hash maps. So let's say I have a function that needs :name and :addr and it adds a new field calls :name+addr. Now in most (all?) statically typed languages I would have to say that this function takes a "name and addr" and returns "name, addr, and name+addr". So I have a type conversion, right? If the time comes that I need to modify these types, I have to do some sort of refactor. In Clojure we'd just take a hash map and add a new k/v pair to the hash map we get. Any hash map will work, as long as it has the proper entries, and we'll just add a new entry to that. So if the time comes that I want to call this function with a "company" instead of a "person", it just works, as long as I have the proper keys. And to help check this sort of stuff we do have spec (https://clojure.org/about/spec https://clojure.org/about/spec). TL;DR -- my belief having programed in both static and dynamic languages is that deep refactoring is primarily driven by the inflexibility of static types.
- hardwaresofton 10y ago
  > Clojure is an interesting language, no doubt. But your response would seem to imply it's the end-all and be-all of programming languages, and given how subjective such an assessment would be, it strikes me as a fairly vacuous claim... As crazy as it sounds, I could imagine myself making such a claim, but only because of Clojure's position as a dialect of lisp. The reason I think I could make a claim is because of lisp's dedication to simplicity -- technically most general-purpose languages are equivalent, but lisps stand apart for me because they generally focus on giving the programmer the tools to build what they want and nothing else. As a result of this, lisps are generally (if not always): multi-paradigm, DSL-friendly, etc. This is getting long, but the basic point is, I could see lisp being an end-all be-all of programming languages, because it gives the programmer the right tools, and I can almost always easily envision going from lisp -> some other language (ex. haskell) than I can going from some other language (ex. haskell) -> lisp. You could also of course say similar things about assembly or other languages that give the programmer even less, but lisp strikes what I think is the best balance I've seen for giving just enough power, without requiring too much in return from the user, specifically talking about language ergonomics (leaving out implementation details like garbage collection, etc).
  - zzalpha 10y ago
    Eh, I've seen that claim enumerable times when reading about Lisps. "You can build any language you want on lisp!" Yeah, no one does that. There's a reason other languages exist and Lisp hasn't simply supplanted them. If I want a HM-style strictly typed, lazily evaluated programming language, I'm not going to build it myself on top of lisp. I'm going to find a language that suits my preferences and simply use it. Besides, you could make the same claim about any programming language. "Hey, C is the ultimate language because I could use it to build a compiler for the language I actually want!" Correct in theory. Meaningless in practice. As for being multi-paradigm, balance between functionality and simplicity, etc, those are all personal preference. A Haskeller could equally say they like an opinionated language that gives them a rich set of tools to build correct programs more easily. These are factless value-judgements. Which is why HN sees new programming language announcements every other week...
rahulmutt 10y ago
Thanks for bringing this up! I will definitely add a section for explaining the benefits for Scala and Clojure devs. I shipped a non-trivial Clojure web service to production that was handling 1M/requests a day. The experience is what made me finally understand that the JVM is wonderful platform, and what prompted me to work on Eta, given that Frege was insufficient for what I wanted (not supporting a lot of useful GHC extensions). Clojure was wonderful in the fact that I could become as concise as I wanted via EDSLs, and the immutability by default + concurrency primitive were a joy. The lack a type system (please don't mention core.typed) and compile-time errors at runtime were really a pain. I'm sure you can ameliorate that with libraries like prismatic/schema (which I did) and strong test discipline, but it's great when the compiler just takes care of all of that for you. Once you really "get" Haskell-like languages, you miss the benefits no matter what language you try. As for Scala, I haven't built anything significant and I wouldn't want to for some of the examples I've seen. It's too verbose for a typed functional language.
- yogthos 10y ago
  I find that you still need the same tests using a statically typed language that you would need using Clojure. The reason being that the type system does little to ensure semantic correctness. For example, consider a sort function. The types can tell me that I passed in a collection of a particular type and I got a collection of the same type back. However, what I really want to know is that the collection contains the same elements, and that they're in order. This is what you really care about at the end of the day, does the function do what I intended. This is difficult to express using most type systems out there. You could use dependent to express that, but it certainly wouldn't be something that you get for free with Haskell. So, you'll still have to write tests to ensure that the function is semantically correct for anything non-trivial. It's also worth noting that Clojure Spec lets me express exactly what I care about using the same language semantics I'm already using to write regular Clojure code: (s/def ::sortable (s/coll-of number?)) (s/def ::sorted #(or (empty? %) (apply <= %))) (s/fdef mysort :args (s/cat :s ::sortable) :ret ::sorted :fn (fn [{:keys [args ret]}] (and (= (count ret) (-> args :s count)) (empty? (difference (-> args :s set) (set ret)))))) The specification will check that the arguments follow the expected pattern, and that the result is sorted, and I can do an arbitrary runtime check using the arguments and the result. In this case it can verify that the returned items match the input.
js8 10y ago
About two years ago, before Haskell became my current favorite language, I really liked Common Lisp and Python, and I was transitioning to Clojure. So perhaps I can explain what sold me to Haskell from Clojure and Lisps in general. (I also looked at Scala, but I am a little worried about it being too complicated by wanting to be mix of OOP and FP.) What I really like about Lisps is the ability to define DSLs with functions and macros. I thought Haskell cannot do it very well, although I recognized that the most useful ability of macros - to selectively evaluate arguments - can be replaced with Haskell's lazy evaluation. Then I read the article http://www.haskellforall.com/2012/06/you-could-have-invented-free-monads.html http://www.haskellforall.com/2012/06/you-could-have-invented... and I became sold instantly. Not only Haskell can define DSLs that are on par with DSLs in Lisp, but it also gives you typechecking in those for free! There are still some use cases where Lisp macros can be stronger than standard Haskell, but not that many. The other thing I was worried with Haskell was the static typechecking. I am fan of dynamic languages, because they let me write the code without having to type types everywhere. But in practice with Haskell, I was pleasantly surprised; if you stick to the standard things, you don't really need to specify types that much (although I try to specify them for function arguments), Hindley-Milner inference will figure it all out. Specifying types upfront is still a trade off, but I found I don't really mind it if I don't have to write them everywhere as I have in Java or C. Haskell also isn't complicated language, it turns out, most features are either some obscure typing extensions to HM which you will avoid as a beginner anyway or just syntactic sugar over some kind of function composition. And I really like the functional approach, such as monadic representation of side-effects (which gives you ability to reinterpret actions done by some function differently). It's a powerful paradigm I think even though I am not very good at it yet. I even joke that it's simpler than Java, because the Java people have to be really smart to work with all those objects and patterns, where I can make do with types and functions (and an occasional type class), and I am not so smart, so I prefer Haskell. (There is truth to it, IMHO, the relatively clean and abstract design of Haskell makes many high order things more straightforward than in Java.)

by blunte 10y ago

zzalpha 10y ago

I hope what you're really saying is that they need to do a better job of marketing to folks not already familiar with Haskell or similar ML-derived functional programming languages. And that's probably true. As for specifically competing with Clojure... frankly, who cares? The two are so different as to render such a comparison fairly useless: Lisp-y s-expressions versus ML-style syntax. Strict Hindley-Milner-style type system vs Lisp-style dynamic typing. Lazy evaluation versus strict. Pure versus impure. The list goes on and on. Clojure is an interesting language, no doubt. But your response would seem to imply it's the end-all and be-all of programming languages, and given how subjective such an assessment would be, it strikes me as a fairly vacuous claim...

blunte 10y ago
We are talking about the JVM. And as such, the existing competitors are Java, Scala, and Clojure. Scala had promise, but many significant users discovered warts on large projects. And on top of that, Lisp is not only sexy (rationally or irrationally), but Clojure has a lot of intellectual momentum. Further, we have Clojurescript for nodejs. It is the one to beat. So if someone is going to sell me on a better JVM language, they need to at least give me a pro/con list vs Clojure. While HN might disagree, the market (people who work in companies that live for revenue, not VC) will agree in my interest for that comparison.
- rahulmutt 10y ago
  Lisp is sexy, but parenthesis are a really hard sell for the wide crowd. It sounds silly, but that's the reality. If they had forced people to learn & use Lisp instead of C, the world might be a very different place. I personally love them even now when I look back at Clojure code. Clojurescript is just wonderful. I'm not even sure a Haskell-like language that compiles to JavaScript (Elm, PureScript, GHCJS) with really good tooling can beat it, though I haven't tried. Would be an interesting experiment to do a comparison by writing the same app in all the languages.
  - _halgari 10y ago
    And yet, Clojure has less parens than your average JS program. Even Java has more syntactic sugar. Just compare: foo.bar(baz) to: (.bar foo baz) Same number of parens...they're just in different places. Sure CommonLisp has a ton of parens, but thats CL and it has its own set of issues. One more example: Runnable foo = new Runnable() { Object run(Object bar) { return bar; } } vs (reify Runnable (run [bar] bar)) Less parens, no brackets, no semicolons, and no ceremony. This "parens are killing Clojure" meme is just a straw-man.
- hardwaresofton 10y ago
  Just expanding on the parent to your comment a little bit more... Clojure and Haskell are two almost completely different beasts. Thanks to clojure's simplicity (as a dialect of lisp), it could BECOME haskell if you wrote the DSLs for it, but the reverse is much harder, I would think. Eta is not looking to convince clojurists to use haskell on the jvm instead of clojure, it's (most likely, I don't maintain the project) to enable those who want to use haskell but want to also use the JVM to do so. Regardless of whether Haskell is a better choice for your project or clojure is, the eta team (or any other team for that matter) is under no obligation to find that out for you, or even to make your search any easier. That's your job -- if clojure still fits your needs and doesn't have any glaring issues, absolutely use it.
  - Buttons840 10y ago
    Are you saying that writing Haskell in Lisp is easier than writing Lisp in Haskell? Or did I get that backwards?
    - hardwaresofton 10y ago
      Yes -- to clarify, it I'm saying that it would be easier (for me at least) to write with haskell's semantics/paradigm than it would be for me to write with lisp's semantics/paradigm in haskell. I think the statement is almost axiomatic. Lisp is multi-paradigm, by way of simplicity/choices not being made for you. Haskell is decidedly functional (which is something I love about it). Making a more specific thing into a less specific thing (while possible in this case), seems like a more difficult task than molding the clay that is LISP to look like haskell.
- lenkite 10y ago
  I looked at Clojure but the lack of static types and thus losing the benefit of refactoring always put me away. Out of curiosity - how do you safely refactor Clojure code ? Safe Refactoring offered by type safe languages is such a major aid to redesigning code that it has become difficult for me to work in dynamic languages for any large code bases.
  - _halgari 10y ago
    I've been a full-time Clojure dev for about 4-5 years now. And the number of times you have to refactor (in the traditional sense) Clojure code is pretty rare. And the reason is that Clojure leverages it's use of immutable data structures, namely hash maps. So let's say I have a function that needs :name and :addr and it adds a new field calls :name+addr. Now in most (all?) statically typed languages I would have to say that this function takes a "name and addr" and returns "name, addr, and name+addr". So I have a type conversion, right? If the time comes that I need to modify these types, I have to do some sort of refactor. In Clojure we'd just take a hash map and add a new k/v pair to the hash map we get. Any hash map will work, as long as it has the proper entries, and we'll just add a new entry to that. So if the time comes that I want to call this function with a "company" instead of a "person", it just works, as long as I have the proper keys. And to help check this sort of stuff we do have spec (https://clojure.org/about/spec https://clojure.org/about/spec). TL;DR -- my belief having programed in both static and dynamic languages is that deep refactoring is primarily driven by the inflexibility of static types.
hardwaresofton 10y ago
> Clojure is an interesting language, no doubt. But your response would seem to imply it's the end-all and be-all of programming languages, and given how subjective such an assessment would be, it strikes me as a fairly vacuous claim... As crazy as it sounds, I could imagine myself making such a claim, but only because of Clojure's position as a dialect of lisp. The reason I think I could make a claim is because of lisp's dedication to simplicity -- technically most general-purpose languages are equivalent, but lisps stand apart for me because they generally focus on giving the programmer the tools to build what they want and nothing else. As a result of this, lisps are generally (if not always): multi-paradigm, DSL-friendly, etc. This is getting long, but the basic point is, I could see lisp being an end-all be-all of programming languages, because it gives the programmer the right tools, and I can almost always easily envision going from lisp -> some other language (ex. haskell) than I can going from some other language (ex. haskell) -> lisp. You could also of course say similar things about assembly or other languages that give the programmer even less, but lisp strikes what I think is the best balance I've seen for giving just enough power, without requiring too much in return from the user, specifically talking about language ergonomics (leaving out implementation details like garbage collection, etc).
- zzalpha 10y ago
  Eh, I've seen that claim enumerable times when reading about Lisps. "You can build any language you want on lisp!" Yeah, no one does that. There's a reason other languages exist and Lisp hasn't simply supplanted them. If I want a HM-style strictly typed, lazily evaluated programming language, I'm not going to build it myself on top of lisp. I'm going to find a language that suits my preferences and simply use it. Besides, you could make the same claim about any programming language. "Hey, C is the ultimate language because I could use it to build a compiler for the language I actually want!" Correct in theory. Meaningless in practice. As for being multi-paradigm, balance between functionality and simplicity, etc, those are all personal preference. A Haskeller could equally say they like an opinionated language that gives them a rich set of tools to build correct programs more easily. These are factless value-judgements. Which is why HN sees new programming language announcements every other week...

rahulmutt 10y ago

Thanks for bringing this up! I will definitely add a section for explaining the benefits for Scala and Clojure devs. I shipped a non-trivial Clojure web service to production that was handling 1M/requests a day. The experience is what made me finally understand that the JVM is wonderful platform, and what prompted me to work on Eta, given that Frege was insufficient for what I wanted (not supporting a lot of useful GHC extensions). Clojure was wonderful in the fact that I could become as concise as I wanted via EDSLs, and the immutability by default + concurrency primitive were a joy. The lack a type system (please don't mention core.typed) and compile-time errors at runtime were really a pain. I'm sure you can ameliorate that with libraries like prismatic/schema (which I did) and strong test discipline, but it's great when the compiler just takes care of all of that for you. Once you really "get" Haskell-like languages, you miss the benefits no matter what language you try. As for Scala, I haven't built anything significant and I wouldn't want to for some of the examples I've seen. It's too verbose for a typed functional language.

yogthos 10y ago
I find that you still need the same tests using a statically typed language that you would need using Clojure. The reason being that the type system does little to ensure semantic correctness. For example, consider a sort function. The types can tell me that I passed in a collection of a particular type and I got a collection of the same type back. However, what I really want to know is that the collection contains the same elements, and that they're in order. This is what you really care about at the end of the day, does the function do what I intended. This is difficult to express using most type systems out there. You could use dependent to express that, but it certainly wouldn't be something that you get for free with Haskell. So, you'll still have to write tests to ensure that the function is semantically correct for anything non-trivial. It's also worth noting that Clojure Spec lets me express exactly what I care about using the same language semantics I'm already using to write regular Clojure code: (s/def ::sortable (s/coll-of number?)) (s/def ::sorted #(or (empty? %) (apply <= %))) (s/fdef mysort :args (s/cat :s ::sortable) :ret ::sorted :fn (fn [{:keys [args ret]}] (and (= (count ret) (-> args :s count)) (empty? (difference (-> args :s set) (set ret)))))) The specification will check that the arguments follow the expected pattern, and that the result is sorted, and I can do an arbitrary runtime check using the arguments and the result. In this case it can verify that the returned items match the input.

js8 10y ago

About two years ago, before Haskell became my current favorite language, I really liked Common Lisp and Python, and I was transitioning to Clojure. So perhaps I can explain what sold me to Haskell from Clojure and Lisps in general. (I also looked at Scala, but I am a little worried about it being too complicated by wanting to be mix of OOP and FP.) What I really like about Lisps is the ability to define DSLs with functions and macros. I thought Haskell cannot do it very well, although I recognized that the most useful ability of macros - to selectively evaluate arguments - can be replaced with Haskell's lazy evaluation. Then I read the article http://www.haskellforall.com/2012/06/you-could-have-invented-free-monads.html http://www.haskellforall.com/2012/06/you-could-have-invented... and I became sold instantly. Not only Haskell can define DSLs that are on par with DSLs in Lisp, but it also gives you typechecking in those for free! There are still some use cases where Lisp macros can be stronger than standard Haskell, but not that many. The other thing I was worried with Haskell was the static typechecking. I am fan of dynamic languages, because they let me write the code without having to type types everywhere. But in practice with Haskell, I was pleasantly surprised; if you stick to the standard things, you don't really need to specify types that much (although I try to specify them for function arguments), Hindley-Milner inference will figure it all out. Specifying types upfront is still a trade off, but I found I don't really mind it if I don't have to write them everywhere as I have in Java or C. Haskell also isn't complicated language, it turns out, most features are either some obscure typing extensions to HM which you will avoid as a beginner anyway or just syntactic sugar over some kind of function composition. And I really like the functional approach, such as monadic representation of side-effects (which gives you ability to reinterpret actions done by some function differently). It's a powerful paradigm I think even though I am not very good at it yet. I even joke that it's simpler than Java, because the Java people have to be really smart to work with all those objects and patterns, where I can make do with types and functions (and an occasional type class), and I am not so smart, so I prefer Haskell. (There is truth to it, IMHO, the relatively clean and abstract design of Haskell makes many high order things more straightforward than in Java.)