Thoughts on Clojure

francoisdevlin wrote: post #2

For the inevitable "Where do I start" questions, read this previous comment: http://news.ycombinator.com/item?id=1033503

... and an example of web development in Clojure:

http://mmcgrana.github.com/2010/03/clojure-web-development-r...

Just install leiningen, whip out your favorite text editor, and you don't have to worry about downloading/installing clojure, libraries and deps.

Re: Thoughts on Clojure

#5

Post by d0m » Fri, Jul 09, 2010, 4:28 PM UTC

In the middle of the article, the author talks about three advantages that clojure has over ruby. Simply put, speed, easy concurrence and functional.

I don't find these to be really good advantages.. First, "functional" isn't an advantage.. I mean, the advantage of functional code might be easier maintenance, concise code, easier to concurrence etc.. but "functional" isn't an advantage. It's like saying C++ is better than ruby because it is imperative or OO.. "Why is imperative or OO better?", that's the interesting part.

In my opinion, the advantage of clojure by comparing it with Ruby are:

- You get the best of Java (lots of library, OO) - You get the best of Lisp (macro, high level function)

Re: Thoughts on Clojure

#6

Post by acangiano » Fri, Jul 09, 2010, 4:36 PM UTC

d0m wrote: post #5

In the middle of the article, the author talks about three advantages that clojure has over ruby. Simply put, speed, easy concurrence and functional. I don't find these to be really good advantages.. First, "functional" isn't an advantage.. I mean, the advantage of functional code might be easier maintenance, concise code, easier to concurrence etc.. but "functional" isn't an advantage. It's like saying C++ is better…

> First, "functional" isn't an advantage.. I mean, the advantage of functional code might be easier maintenance, concise code, easier to concurrence etc..

Those are all good reasons why functional programming is an advantage. I guess you object to my grouping of all these under the "functional" umbrella term.

> In my opinion, the advantage of clojure by comparing it with Ruby are: - You get the best of Java (lots of library, OO)

I mention this as well, but that's not really an advantage over Ruby. JRuby gives you access to all the Java libraries you want.

Re: Thoughts on Clojure

#7

Post by funcall » Fri, Jul 09, 2010, 4:38 PM UTC

d0m wrote: post #5

In the middle of the article, the author talks about three advantages that clojure has over ruby. Simply put, speed, easy concurrence and functional. I don't find these to be really good advantages.. First, "functional" isn't an advantage.. I mean, the advantage of functional code might be easier maintenance, concise code, easier to concurrence etc.. but "functional" isn't an advantage. It's like saying C++ is better…

For a certain (large) class of programs, being "functional" is an advantage. Interestingly, you made the point that being functional means easier maintenance etc., but fail to attribute those advantages to being functional. If your argument is that there can be bad functional code which performs worse than non-functional (imperative or OO) code, I don't disagree. However, in the multicore future that our semiconductor overlords have in store for us, functional programming has a demonstrable advantage in helping build understandable and robust programs.

Re: Thoughts on Clojure

#8

Post by WilliamLP » Fri, Jul 09, 2010, 4:58 PM UTC

funcall wrote: post #7

d0m wrote: post #5

In the middle of the article, the author talks about three advantages that clojure has over ruby. Simply put, speed, easy concurrence and functional. I don't find these to be really good advantages.. First, "functional" isn't an advantage.. I mean, the advantage of functional code might be easier maintenance, concise code, easier to concurrence etc.. but "functional" isn't an advantage. It's like saying C++ is better…

For a certain (large) class of programs, being "functional" is an advantage. Interestingly, you made the point that being functional means easier maintenance etc., but fail to attribute those advantages to being functional. If your argument is that there can be bad functional code which performs worse than non-functional (imperative or OO) code, I don't disagree. However, in the multicore future that our semiconducto…

I don't think you should claim "demonstrable" and "future" in the same sentence. "Theoretical" or even "promising", perhaps. The most performance intensive problems in the world, when they have competition, are very much still solved in C and C++.

Re: Thoughts on Clojure

#9

Post by dpritchett » Fri, Jul 09, 2010, 4:59 PM UTC

twism wrote: post #4

francoisdevlin wrote: post #2

For the inevitable "Where do I start" questions, read this previous comment: http://news.ycombinator.com/item?id=1033503

... and an example of web development in Clojure: http://mmcgrana.github.com/2010/03/clojure-web-development-r... Just install leiningen, whip out your favorite text editor, and you don't have to worry about downloading/installing clojure, libraries and deps.

... provided you have java installed.

Re: Thoughts on Clojure

#10

Post by funcall » Fri, Jul 09, 2010, 5:08 PM UTC

WilliamLP wrote: post #8

funcall wrote: post #7

Earlier quoted context omitted.

For a certain (large) class of programs, being "functional" is an advantage. Interestingly, you made the point that being functional means easier maintenance etc., but fail to attribute those advantages to being functional. If your argument is that there can be bad functional code which performs worse than non-functional (imperative or OO) code, I don't disagree. However, in the multicore future that our semiconducto…

I don't think you should claim "demonstrable" and "future" in the same sentence. "Theoretical" or even "promising", perhaps. The most performance intensive problems in the world, when they have competition, are very much still solved in C and C++.

You're quite right about the juxtaposition of "demonstrable" and "future". I should have said functional programming has "already" demonstrated an advantage in producing robust and understandable concurrent programs, which will continue to be relevant in our multicore future. Really, there's nothing "theoretical" about that fact.

To your second point, I made no claims that C and C++ are not used to solve performance intensive problems. I'm sure C and C++ (or Assembly, for that matter) can be applied to solve any number of problems, if that's one's calling.