You’re allowed to make whatever assumptions you like about my language knowledge, but I am indeed quite well aware of the fact that pure functional code can be parallelized “automatically.” How much parallelism can be extracted in such a fashion, though, is going to be based on the higher-level algorithm you choose and the data-dependencies therein. My contention was basically that unless you explicitly try to avoid those dependencies by using higher-level algorithms that avoid them, just writing something in a pure functional language won’t lead to sustained usage of multiple cores because the data dependencies in your code will still cripple it. So even if you’re programming functionally with no side effects, you still have to think about parallelism and plan for it just like you would in an imperative language. I’ve also conceded that thinking functionally might help you to structure things that way, and that’s what I think is the real value there.

I’m always happy to be proven wrong; if someone is consistently able to take single-threaded imperative programs and translate them into functional programs that scale arbitrarily horizontally (or even to an 8-core desktop) without completely rethinking the overall approach, that would be interesting.

Plain assertions that I’m an idiot and that I don’t understand things that I’ve explicitly addressed in this post, subsequent posts, and the comments to those posts, however, aren’t particularly convincing.

You know nothing about the topic on which you speak. Had you known anything about Haskell, for example, you would understand that pure functional code can be parallelized *automatically*. That’s the point, man.

Ignorance consistently begets confidence. Your post is confidently ignorant.

Anders has a great, wide-ranging talk up on programming languages and where he sees things going. If you get to around the 54 minute mark, he talks about data parallelism

http://jaoo.blip.tv/#1324214

He makes a great point that I didn’t really do a good job conveying: data parallelism is a very syntactically cheap way to test taking advantage of parallelism. No need to massively rewrite your program or adopt strange architectures from the start. The places where parallelism is really going to help you you can sprinkle some on and, in the places it won’t, you don’t pay any additional cost.

Cheers,
Carson

Yeah, that was perhaps intentionally a bit overstated. My point is merely that network effects and barriers to entry matter are a consideration for most people when choosing a language. Most people just aren’t going to go choose a language that 1) only a very small set of people know and 2) is notoriously difficult to become proficient at. That doesn’t mean they’re not good languages, or that they can’t/shouldn’t/won’t be used for projects, and certainly no one really cares what language their tools are written in so long as they can write in their language of choice.

Again, my main target wasn’t the languages themselves, it’s the hype around the languages. The breathless “multicore changes everything!” and “run out and learn to program Erlang right now!” sorts of posts are, I think, not all that useful. It’s great to expose people to the full range of tools so they can select what’s useful to them, but I think it’s also important to spend time and effort on improving the tools that the vast majority of programmers will use, and to focus on creating mainstream tools and frameworks rather than just on more esoteric, niche things.

And yeah, I agree that it’s kind of self-defeating as someone who’s helping design yet another programming language. But I kinda got calls ‘em as I sees ‘em in this case.

_shrug_

I think parallelization in general will get us fairly little return on investment at the application level because structuring a program for parallelization ends up meaning creating difficult to debug, non-sequential systems. If I’m given a few easy to use parallelized data-manipulation methods then, in the few cases it helps, I can use them.

There may be more bang for the buck at deeper points in the application stack (e.g. apache or tomcat) but those sorts of programs have two other things going for them: they are usually very targeted and they are usually written by pretty smart kids who can handle more difficult concurrency problems even with today’s technologies. Us poor grinds who have to write very wide and shallow enterprise apps aren’t in the same position.

I’ll grant you that the DBMS is a layer that does a great job exploiting parallelism (as well as providing caching and all the rest.) That’s why I’m such a huge fan of LINQ: it makes the declarative nature of SQL look at home in an otherwise imperative language. And, if I’m honest with myself, I agree that that will be far more beneficial for the average enterprise developer.

Cheers,
Carson

In general, automatic parallelization has gotten very little return-on-investment. It has significant overhead and significant complexity, for only modest returns on a very small subset of programs.

To get better return you need to structure your program with that parallelization in mind, and you might as well use APIs that explicitly allow it to happen. A DBMS is again an example. Another example would be in apache, with a request handlers spread across threads or processes.

Awwwww, c’mon. If my data set is large enough to warrant parallelization, I’ll get a kick out of the parallelized sorting. Of course, if it’s small enough that parallelizing won’t help, well, no other approach is gonna do much for me.

My point is that, by using closures, we can create data-parallel operations on common data structures that don’t require end-users to know much about parallel computing or concurrency. Smart guys like you can write the implementations and dumb guys like me can use them as needed.

I agree with your point regarding the database being the right place for this operation though. That’s one reason to admire microsofts LINQ: it makes the highly-parallelizable operations of finding, filtering and sorting data not suck in an OO language. It’s another ingredient in the perfect blend of functional and imperative features necessary for The Perfect Language ™.

But, yeah, no silver bullet.

Cheers,
Carson

Whether or not languages like Haskell and Erlang will become mainstream, I personally don’t care. They are used today for serious commercial development, and programmers who like this style of programming stand an increasingly good chance of finding a place where they can do it for money. Also, These languages influence the mainstream in ways that are quite beneficial.