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

31–40 of 43 posts

Re: Thoughts on Clojure

#31

Post by neilc »

microtonal wrote: post #25
neilc wrote: post #21

Earlier quoted context omitted.

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…

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.

I'm curious -- were the programs that were easily parallelized with OpenMP largely data parallel to begin with? I haven't used OpenMP extensively, but I'd suspect that the ease of parallelizing a program with OpenMP probably varies inversely with the amount of explicit coordination/synchronization/update of shared state that the program requires.

Re: Thoughts on Clojure

#32

Post by cageface »

lukev wrote: post #29
cageface wrote: post #28

Earlier quoted context omitted.

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++…

I wonder if the kind of concurrency people have been focused on in these kinds of conversations is really going to turn out to be that important. It seems to me like a lot of the really cpu-intensive problems people are trying to solve are way beyond the scale of a single machine - the kinds of problems you need a big hadoop-style farm to tackle. How many apps are there left that really need maximum throughput in a shared memory architecture?

Re: Thoughts on Clojure

#33

Post by lukev »

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…

As an added note, I'm not aware of anyone doing this yet, but it would be really cool to have a VM that did JIT-like analysis of purely functional code as it runs to determine optimal points for thread segregation.

Re: Thoughts on Clojure

#35

Post by technomancy »

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'm a huge Emacs fan, but I'd recommend against learning Emacs and Clojure at the same time. While the tight REPL integration can be difficult to set up in vim, you can use a separate REPL/editor environment to get going, and then ease yourself into a more integrated environment once you get a little more familiar with things.

Re: Thoughts on Clojure

#36

Post by microtonal »

neilc wrote: post #31
microtonal wrote: post #25

Earlier quoted context omitted.

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…

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. I'm curious -- were the programs that were easily parallelized with OpenMP largely data parallel to begin with? I haven't used OpenMP extensively, but I'd suspect that the ease of paral…

Mostly, yes. This particular program evaluates effectiveness of features given an existing log-linear model. So, you can evaluate the effectiveness of features in parallel. For each feature, you can also partition the training data, process the the data in parallel, and apply a reduction step[1].

But 'map' in MapReduce is also a typical data-parallel task.

[1] In practice, there is a trade-off: the vectors are usually so large for the average training set, that you do not really want to copy them for memory-efficiency, so the mapping and reduction are interleaved, requiring some locking.

Re: Thoughts on Clojure

#37

Post by Turing_Machine »

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…

"When people speak of concurrency in functional languages, they don't mean that each function executes in its own thread"

Erlang does do that, more or less, although Erlang processes are much lighter weight than what we usually think of as a "process" or "thread".

Re: Thoughts on Clojure

#38

Post by herdrick »

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…

Really? Can you post some profiling data?

Re: Thoughts on Clojure

#39

Post by frognibble »

TallGuyShort wrote: post #24
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.

This is exactly how I work with Clojure. Emacs is not required to develop in Clojure.

Re: Thoughts on Clojure

#40

Post by peregrine »

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?

This is a great place to look for several IDE's and guides to getting started with VIM.

http://www.assembla.com/wiki/show/clojure/Getting_Started

Post reply on HN