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

Thoughts on Clojure

programmingzen.com

Post reply on HN
Print view View original

21–30 of 43 posts

Re: Thoughts on Clojure

#21

Post by neilc »

cageface wrote: post #16
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…

From an interview with the father of Haskell: http://www.infoq.com/interviews/armstrong-peyton-jones-erlan... But it turned out to be very hard to turn that into actual wall clock speedups on processes, leaving aside all issues of robustness or that kind of stuff, because if you do that style of concurrency you get lots of very tiny fine-grained processes and you get no locality and you get very difficult scheduling…

It may be true that FP does make concurrency easier, but I don't think this has been demonstrated to be generally true yet

Perhaps not generally true, but I think MapReduce and LINQ are two prominent examples of how a "functional programming-like" model lends itself to easy parallelization and distribution.

Re: Thoughts on Clojure

#22

Post by SkyMarshal »

aphyr wrote: post #19

I really want to get into Clojure, but everything I've read suggests that I'll have to learn Emacs to do it. Does anyone think giving up Vim for a few months is worth it?

You can modify Emacs to mimic Vim, which might be help you bridge the gap:

http://www.sanityinc.com/articles/vim-vs-emacs

Re: Thoughts on Clojure

#23

Post by tsuraan »

aphyr wrote: post #19

I really want to get into Clojure, but everything I've read suggests that I'll have to learn Emacs to do it. Does anyone think giving up Vim for a few months is worth it?

I've been using clojure for a while now (nothing huge LOC-wise, but it's a pretty significant part a large system). I use vim, and haven't had any troubles. The clojure REPL doesn't seem to have readline support, but it works fine with the rlwrap program. I've been meaning to learn emacs to try out the niftier select and execute functionality that it has, but vim does work for me.

Re: Thoughts on Clojure

#24

Post by TallGuyShort »

aphyr wrote: post #19

I really want to get into Clojure, but everything I've read suggests that I'll have to learn Emacs to do it. Does anyone think giving up Vim for a few months is worth it?

I still use exclusively Vim for all my clojure coding. I have Vim in one window (with VimClojure for syntax highlighting and some other features), a REPL in another (for quick experimenting), and my ant script in another for compiling and testing the whole thing. It's not as integrated as SLIME and emacs, but I don't feel like my tools are slowing me down significantly.

Re: Thoughts on Clojure

#25

Post by microtonal »

neilc wrote: post #21
cageface wrote: post #16

Earlier quoted context omitted.

From an interview with the father of Haskell: http://www.infoq.com/interviews/armstrong-peyton-jones-erlan... But it turned out to be very hard to turn that into actual wall clock speedups on processes, leaving aside all issues of robustness or that kind of stuff, because if you do that style of concurrency you get lots of very tiny fine-grained processes and you get no locality and you get very difficult scheduling…

It may be true that FP does make concurrency easier, but I don't think this has been demonstrated to be generally true yet Perhaps not generally true, but I think MapReduce and LINQ are two prominent examples of how a "functional programming-like" model lends itself to easy parallelization and distribution.

And there are also enough 'prominent examples' for impure imperative languages. For instance, OpenMP makes parallelizing some loops in C/C++ a walk in the park, and I have parallelized some of my programs by adding only a few pragmas.

The 'FP makes concurrency easier' is a often-used selling point, but I think the jury is still out. First of all, many functional languages are impure, and do not have this advantage in the same manner that e.g. Haskell has. Second, purity can be an expensive trade-off due to the copying involved. For lots of things (e.g. fast linear algebra) you'll still want to work in an impure world.

I think a better selling point of some functional languages is clarity. For instance, some class of problems can be solved very elegantly in Haskell and ML using algebraic data types, pattern matching, etc. But then again, some other classes of problems can be solved elegantly in Prolog.

Re: Thoughts on Clojure

#26

Post by lukev »

cageface wrote: post #16
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…

From an interview with the father of Haskell: http://www.infoq.com/interviews/armstrong-peyton-jones-erlan... But it turned out to be very hard to turn that into actual wall clock speedups on processes, leaving aside all issues of robustness or that kind of stuff, because if you do that style of concurrency you get lots of very tiny fine-grained processes and you get no locality and you get very difficult scheduling…

While true, this is somewhat disingenuous. When people speak of concurrency in functional languages, they don't mean that each function executes in its own thread (even if it can, according to the semantics of the language). As this quote points out, the overhead of that is absurd, though maybe we'll get there someday with specialized hardware.

What functional programming does mean right now is that it's much easier to chop your program up into reasonable-sized chunks: big enough that it's worth the overhead, small enough that you can distribute as widely as possible.

In other words, if you think of a functional program as a tree and then expect to run each leaf in its own thread, the overhead will vastly outweigh the benefits. But the functional semantics also allow you to run each of the dozen main branches in separate threads with little effort.

I do this in Clojure all the time.

Re: Thoughts on Clojure

#27

Post by microtonal »

funcall wrote: post #10
WilliamLP wrote: post #8

Earlier quoted context omitted.

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…

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

Re: Thoughts on Clojure

#28

Post by cageface »

lukev wrote: post #26
cageface wrote: post #16

Earlier quoted context omitted.

From an interview with the father of Haskell: http://www.infoq.com/interviews/armstrong-peyton-jones-erlan... But it turned out to be very hard to turn that into actual wall clock speedups on processes, leaving aside all issues of robustness or that kind of stuff, because if you do that style of concurrency you get lots of very tiny fine-grained processes and you get no locality and you get very difficult scheduling…

While true, this is somewhat disingenuous. When people speak of concurrency in functional languages, they don't mean that each function executes in its own thread (even if it can , according to the semantics of the language). As this quote points out, the overhead of that is absurd, though maybe we'll get there someday with specialized hardware. What functional programming does mean right now is that it's much easier…

Sure but this is also what you generally do in an imperative threaded app. Break the work up into discrete jobs and use a producer/consumer model to parallelize it. This has to be done carefully and usually requires an intimate understanding of the flow of the computation. It might be easier to do this in a functional language but their advantages tend to be mostly at the micro level and the hard stuff tends to be at the macro level.

I honestly think that the advantages of FP for concurrency will turn out to be relatively minor and that FP is more interesting as a means of improving code reuse and reducing bug counts. I'm not convinced that the current crop of FP languages are a win in those respects either though, taken as a whole.

Re: Thoughts on Clojure

#29

Post by lukev »

cageface wrote: post #28
lukev wrote: post #26

Earlier quoted context omitted.

While true, this is somewhat disingenuous. When people speak of concurrency in functional languages, they don't mean that each function executes in its own thread (even if it can , according to the semantics of the language). As this quote points out, the overhead of that is absurd, though maybe we'll get there someday with specialized hardware. What functional programming does mean right now is that it's much easier…

Sure but this is also what you generally do in an imperative threaded app. Break the work up into discrete jobs and use a producer/consumer model to parallelize it. This has to be done carefully and usually requires an intimate understanding of the flow of the computation. It might be easier to do this in a functional language but their advantages tend to be mostly at the micro level and the hard stuff tends to be at…

Well, yeah. There's no silver bullet. But it's much easier to start lopping off branches from the tree if there are no unmanaged side effects.

Programming languages of the future need to enforce thread safety and mutation semantics as well as they do type safety. Functional programming is a step in that direction.

Nobody's necessarily claiming that a concurrent Clojure/Erlang/Haskell app is faster than concurrent C++/Java one, but they're definitely safer and easier to write.

Re: Thoughts on Clojure

#30

Post by jcromartie »

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…

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.

Post reply on HN