5 ms·

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 f

by d0m 16y ago

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)

acangiano 16y ago
> 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.
- d0m 16y ago
  What I meant is that functional in this situation is a bit vague. Clojure Dude (talking to ruby dude): Hey, you should try clojure. Ruby Dude: What is clojure ? Clojure Dude: Oh, clojure is a lisp/functional language. You should really give it a try. Ruby Dude: Why? Clojure Dude: Its main advantage is that it's functional. Ruby Dude: Wow, you convince me. I'm switching!
funcall 16y ago
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.
- WilliamLP 16y ago
  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++.
  - funcall 16y ago
    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.
    - cageface 16y ago
      I should have said functional programming has "already" demonstrated an advantage in producing robust and understandable concurrent programs Examples of this other than Erlang?
    - danieldk 16y ago
      Well, what's it worth if you are doing (real-world) number crunching, and your program turns out to be one or two orders of magnitude slower? For instance, after implementing some machine learning software in Scala, I ended up rewriting it in C++, because it was so slow (IIRC the Scala version was 50x slower). The only way you can get down to 'a couple of times' slower is by writing Scala as Java with a slightly different syntax. And since the program does many repeated matrix calculations in a loop, parallelizing the C++ version was done in half an hour (mostly testing where lock contention kills the advantage of parallelization). Yes, I do realize that there are more applications of multicore processing than number crunching ;).
- cageface 16y ago
jcromartie 16y ago
Functional programming eliminates mutable objects, and mutable objects are (at a certain scale and in certain scopes) the new spaghetti code. I have worked with too many projects where twiddling the attributes of distant (global/static/inherited/etc.) things was necessary to get anything done, and it's obnoxious. It's too many indirections. With functional languages and "dumb" data you don't have to guess about what your data can do. You just do what you want with it.

by d0m 16y ago

acangiano 16y ago

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

d0m 16y ago
What I meant is that functional in this situation is a bit vague. Clojure Dude (talking to ruby dude): Hey, you should try clojure. Ruby Dude: What is clojure ? Clojure Dude: Oh, clojure is a lisp/functional language. You should really give it a try. Ruby Dude: Why? Clojure Dude: Its main advantage is that it's functional. Ruby Dude: Wow, you convince me. I'm switching!

funcall 16y ago

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.

WilliamLP 16y ago
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++.
- funcall 16y ago
  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.
  - cageface 16y ago
    I should have said functional programming has "already" demonstrated an advantage in producing robust and understandable concurrent programs Examples of this other than Erlang?
  - danieldk 16y ago
    Well, what's it worth if you are doing (real-world) number crunching, and your program turns out to be one or two orders of magnitude slower? For instance, after implementing some machine learning software in Scala, I ended up rewriting it in C++, because it was so slow (IIRC the Scala version was 50x slower). The only way you can get down to 'a couple of times' slower is by writing Scala as Java with a slightly different syntax. And since the program does many repeated matrix calculations in a loop, parallelizing the C++ version was done in half an hour (mostly testing where lock contention kills the advantage of parallelization). Yes, I do realize that there are more applications of multicore processing than number crunching ;).
cageface 16y ago

jcromartie 16y ago

Functional programming eliminates mutable objects, and mutable objects are (at a certain scale and in certain scopes) the new spaghetti code. I have worked with too many projects where twiddling the attributes of distant (global/static/inherited/etc.) things was necessary to get anything done, and it's obnoxious. It's too many indirections. With functional languages and "dumb" data you don't have to guess about what your data can do. You just do what you want with it.