5 ms·

Î really love clojure, but this article is not a good plaidoyer, for a lots of reasons, the first and most pregnant being the ability of the author to vastly t

Î really love clojure, but this article is not a good plaidoyer, for a lots of reasons, the first and most pregnant being the ability of the author to vastly traverse subject he is probably not an expert about. > Functional programming, of the kind shown in SICP, is a way to write code that does not manage the state of variables, and could therefore be partitioned to run in parallel on as many processors as you like This is kind of true, but totally misleading, because very few tasks are actually easily paralelizable this way. When you stumble on one, you know it, and replacing map with pmap certainly is a joyful exercise, but this kind of parallelization are easy to do in any languages. The hard parts are those when you need to access shared state across threads. The facilities that clojure provide in this respect, while innovative and enlightening , have benefits that largely remain to be proven. > languages like F# and Scala which have a complexity and "quirkiness" reminiscent of C++ Erm, sorry, what, F# reminiscent of C++, did you even try to read some code written in F# ? F# has one of the tersest syntax you're likely to find in any language. As an ML descendant it does already have a very clean syntax, and the addition of significant whitespace only adds to that. > You can write Clojure code that derives from Java classes and overrides Java methods. In short, if you can do it in Java, you can do it in Clojure. Yeah sure, but in practice, most people that says that didn't ever had to really handle a non trivial project with java interaction in it. I did. And frankly it can get ugly. It's good to have it, but ideally, all should be encapsulated in idiomatic clojure wrappers. While this is not that hard because java interaction is very well thought, it's a long and boring process, and when you're in the middle of a project and just needs some bit of functionnality that isn't in a clojure lib (and trust me there are still a lot of those), you tend to just use the java interop in place. And then you get back and read your code, and you cry. In short, this is just a rehashing of what you usually hear about clojure, but with no insight of real use. My (uninformed) guess, is that the author probably didn't use clojure a lot, and frankly, this kind of stereotyped talk gets old.

swannodette 16y ago
Your response is more misleading than the article: > but this kind of parallelization are easy to do in any languages. Not if you have a GIL. Even then the languages without that limitation do not make what pmap does ... easy. > [STM] have benefits that largely remain to be proven. I always find this statement to be misleading. STM has been shown to greatly benefit the correctness of concurrent programs, you're managing that less by hand. The only thing that seems to be unproven is whether the performance tradeoff is worth it. It'd be nice to see some numbers that show what you lose in X% of the performance vs removing X% the amount of locking code. > [Java interop] And frankly it can get ugly. It's good to have it, but ... Yet far less tedious and simpler than writing a C module, or a C library binding. If you're comparing against that, Clojure's Java interop story is damn heavenly. > In short, this is just a rehashing of what you usually hear about clojure, but with no insight of real use ... Perhaps for you and I. But there are a lot of people in this big wide world. Uncle Bob taps into a community that's quite different from the language enthusiast crowd of HN. Your viewpoint more myopic than the OP. Yet you get upvotes. Oh well.
- _delirium 16y ago
  >> but this kind of parallelization are easy to do in any languages. > Not if you have a GIL. Even then the languages without that limitation do not make what pmap does ... easy. Sure, but it is easy in a lot of not-very-functional languages. The kind of parallelization that you can do by simply replacing a map with a pmap can usually be done in one line of OpenMP in C, C++, or Fortran, telling it to run the loop iterations in parallel.
- Raphael_Amiard 16y ago
  >Your response is more misleading than the article Well maybe, but i feel like you are purposedly misunderstanding me. This was not a rant about clojure, but about the article, yet you take my quotes out of their original context and make it seem like so. > Not if you have a GIL. Ok, fair point. But that's not the question. The OP was claiming functionnal programming made parallelization a breeze, which is a very stereotypical position you hear a lot lately. Well, the kind of parallelization which is made a breeze by FP is also the kind that is very easy, not in any language, but in any language claiming to have parallelization features, cf. delirium's answer. > Yet far less tedious and simpler than writing a C module, or a C library binding Okay, i was merely reacting to the claim that "anything you can do in java you can do in clojure". Which, for taking your comparison, would be like saying "anything you can do in C you can do in Python". Okay not exactly like that, but the fact remains. The impression the OP gives in this regard is that , since there is this java interop, the library problem is solved. Well no, it is not, and very far from it. If this kind of bullshit marketing talk went away, you'd see less newbies complaining in #clojure or on the group about how it's hard to do X. > Uncle Bob taps into a community that's quite different from the language enthusiast crowd of HN. But i'm commenting on HN, not on his blog. This is for a reason. I'm judging the interrest of the article relatively to the crowd here. On a side note, i did not even notice it was Uncle Bob. If i had, my rant would have been even worse, or i would not had written it maybe. It does indeed exhibit the same emptyness i feel from every of his articles. Maybe it's a good article, and i'm overly critical, and i should probably try and write my own article about why i love clojure, to realize it's not necessarily that easy. But i have a very bad reaction to marketing talk.
Dn_Ab 16y ago
You emphasize two points that I would also like to add to. 1) Functional languages makes parallel programming magically easy. This is something that is misleading as you point out. Functional languages (where you have not used mutable state) do make it easy to convert you algorithm to run on multiple cores but that doesn't translate to an algorithm that scales well with number of cores. The problem of parallelization is not one of syntax or even semantics, it is an algorithmic one. You need to have in mind the problem and how to make it scale. Just cause you didn't use state doesn't mean that the algorithm that you wrote automatically takes full advantage of parallelism to solve a problem. What functional programming does is allow you to more easily express the parallel algorithm when you have it as well as giving you more options in how to do so. But for now and maybe this is cultural inertia, coming up with parallel algorithms is hard regardless of language. This is a distinction that is often glossed over probably because those who are aware of it find it so basic as to not worth mentioning. 2) F# and Scala are quirky and complex I will give a disclaimer and say that I use F# to write machine learning stuff so I am likely extra sensitive to this kind of bashing but.. That statement makes no sense and has no real meaning. Does he mean that the semantics allow undefined behaviours ala C++ or that the syntax is overly verbose or the syntax is just plain confusing? F# syntax is not so far from ML or Haskell or even python. As for undefined behaviour, strongly I doubt that applies. Scala has a formal specification. While F# doesn't have a formal specification it does have a very thorough (good enough) informal one. I am certain that it will not have implementation dependent behaviour and its strong static type system and garbage collected nature precludes the chance for un-trapped errors so the C++ style undefined behaviour can't be the issue. F# is certainly not verbose and although Scala, being more OOP centric is a bit more wordy, both languages are quite expressive. Terse syntax is meaningless. What matters is how easy and quickly it is to correctly express an algorithm balanced with how easy it is to mentally uncompress it later (on this case F# may even sometimes be too terse! I have taken to commenting and using quite long names for complex algorithms since otherwise it takes a goodly number of minutes to decompress - especially when the code is littered with single letter variable names that the mathematics like syntaxes subconsciously promote). I will admit that where F# is clunky is the number of ways you can cast and it is a fairly big language with Active Patterns, Workflows and Async and Agents on top of the typical functional idioms. But each such feature transfers a lot of expressive power - a fair trade. To brush aside languages like Scala , F# without having spent much time on them and in such an ambiguous manner is simply not fair. It is okay that he chose Clojure (wonderful language) but did not have the time (measured in months - fair enuff) to properly investigate all the choices but to brush them aside so trivially is intellectually dishonest, to be brutally truthful.

swannodette 16y ago

Your response is more misleading than the article: > but this kind of parallelization are easy to do in any languages. Not if you have a GIL. Even then the languages without that limitation do not make what pmap does ... easy. > [STM] have benefits that largely remain to be proven. I always find this statement to be misleading. STM has been shown to greatly benefit the correctness of concurrent programs, you're managing that less by hand. The only thing that seems to be unproven is whether the performance tradeoff is worth it. It'd be nice to see some numbers that show what you lose in X% of the performance vs removing X% the amount of locking code. > [Java interop] And frankly it can get ugly. It's good to have it, but ... Yet far less tedious and simpler than writing a C module, or a C library binding. If you're comparing against that, Clojure's Java interop story is damn heavenly. > In short, this is just a rehashing of what you usually hear about clojure, but with no insight of real use ... Perhaps for you and I. But there are a lot of people in this big wide world. Uncle Bob taps into a community that's quite different from the language enthusiast crowd of HN. Your viewpoint more myopic than the OP. Yet you get upvotes. Oh well.

_delirium 16y ago
>> but this kind of parallelization are easy to do in any languages. > Not if you have a GIL. Even then the languages without that limitation do not make what pmap does ... easy. Sure, but it is easy in a lot of not-very-functional languages. The kind of parallelization that you can do by simply replacing a map with a pmap can usually be done in one line of OpenMP in C, C++, or Fortran, telling it to run the loop iterations in parallel.
Raphael_Amiard 16y ago
>Your response is more misleading than the article Well maybe, but i feel like you are purposedly misunderstanding me. This was not a rant about clojure, but about the article, yet you take my quotes out of their original context and make it seem like so. > Not if you have a GIL. Ok, fair point. But that's not the question. The OP was claiming functionnal programming made parallelization a breeze, which is a very stereotypical position you hear a lot lately. Well, the kind of parallelization which is made a breeze by FP is also the kind that is very easy, not in any language, but in any language claiming to have parallelization features, cf. delirium's answer. > Yet far less tedious and simpler than writing a C module, or a C library binding Okay, i was merely reacting to the claim that "anything you can do in java you can do in clojure". Which, for taking your comparison, would be like saying "anything you can do in C you can do in Python". Okay not exactly like that, but the fact remains. The impression the OP gives in this regard is that , since there is this java interop, the library problem is solved. Well no, it is not, and very far from it. If this kind of bullshit marketing talk went away, you'd see less newbies complaining in #clojure or on the group about how it's hard to do X. > Uncle Bob taps into a community that's quite different from the language enthusiast crowd of HN. But i'm commenting on HN, not on his blog. This is for a reason. I'm judging the interrest of the article relatively to the crowd here. On a side note, i did not even notice it was Uncle Bob. If i had, my rant would have been even worse, or i would not had written it maybe. It does indeed exhibit the same emptyness i feel from every of his articles. Maybe it's a good article, and i'm overly critical, and i should probably try and write my own article about why i love clojure, to realize it's not necessarily that easy. But i have a very bad reaction to marketing talk.

Dn_Ab 16y ago

You emphasize two points that I would also like to add to. 1) Functional languages makes parallel programming magically easy. This is something that is misleading as you point out. Functional languages (where you have not used mutable state) do make it easy to convert you algorithm to run on multiple cores but that doesn't translate to an algorithm that scales well with number of cores. The problem of parallelization is not one of syntax or even semantics, it is an algorithmic one. You need to have in mind the problem and how to make it scale. Just cause you didn't use state doesn't mean that the algorithm that you wrote automatically takes full advantage of parallelism to solve a problem. What functional programming does is allow you to more easily express the parallel algorithm when you have it as well as giving you more options in how to do so. But for now and maybe this is cultural inertia, coming up with parallel algorithms is hard regardless of language. This is a distinction that is often glossed over probably because those who are aware of it find it so basic as to not worth mentioning. 2) F# and Scala are quirky and complex I will give a disclaimer and say that I use F# to write machine learning stuff so I am likely extra sensitive to this kind of bashing but.. That statement makes no sense and has no real meaning. Does he mean that the semantics allow undefined behaviours ala C++ or that the syntax is overly verbose or the syntax is just plain confusing? F# syntax is not so far from ML or Haskell or even python. As for undefined behaviour, strongly I doubt that applies. Scala has a formal specification. While F# doesn't have a formal specification it does have a very thorough (good enough) informal one. I am certain that it will not have implementation dependent behaviour and its strong static type system and garbage collected nature precludes the chance for un-trapped errors so the C++ style undefined behaviour can't be the issue. F# is certainly not verbose and although Scala, being more OOP centric is a bit more wordy, both languages are quite expressive. Terse syntax is meaningless. What matters is how easy and quickly it is to correctly express an algorithm balanced with how easy it is to mentally uncompress it later (on this case F# may even sometimes be too terse! I have taken to commenting and using quite long names for complex algorithms since otherwise it takes a goodly number of minutes to decompress - especially when the code is littered with single letter variable names that the mathematics like syntaxes subconsciously promote). I will admit that where F# is clunky is the number of ways you can cast and it is a fairly big language with Active Patterns, Workflows and Async and Agents on top of the typical functional idioms. But each such feature transfers a lot of expressive power - a fair trade. To brush aside languages like Scala , F# without having spent much time on them and in such an ambiguous manner is simply not fair. It is okay that he chose Clojure (wonderful language) but did not have the time (measured in months - fair enuff) to properly investigate all the choices but to brush them aside so trivially is intellectually dishonest, to be brutally truthful.