It was installed by default on one of my old debian boxes. The first time I stumbled upon it I felt like I was in the twilight zone. It took some time to realize what it was.

You can be a good bricklayer without knowing much about structural engineering. What happens when you want to build something taller than ten stories?

What happens when you want to program for more than ten CPU cores?

I find the assertion that the ONLY way to program for multiple cores or concurrency is to use functional programming annoying. It seems to be the default fall back of functional evangelists, as if there were no other way in the world to solve concurrency.

I recently took a course on concurrent programming, and the from what I learned, some problems are easier to deal with in erlang or something similar. But then again some aren't. And a lot of the time, they run an order of magnitude slower (though as my prof would say, correctness is sometimes more valuable than speed).

And granted my Erlang program for matrix multiplication was very concise. My MPI implementation ran WAY faster.

It seems to me, there are two schools of thought, and you can live in one, the other, or both. Certainly there are things to be learned in either.

I think all one can take away from articles like this is that it's good to keep learning.

You seem to be confusing "Erlang" with "functional programming." They are not equivalent. Erlang is not what makes functional style good for concurrency — it takes advantage of some of the factors, but it is not the be-all-end-all. Erlang's actor-based green-threaded messaging is only one concurrency style.

I was using Erlang as an example as I am familiar with it. My point was more so that there are (as you say) many styles of concurrency, and that I hate it when functional programers use "Try programming concurrently in an imperative language" as their fall back argument for the merits of FP.

It is one of the few arguments that doesn't first require the other person to have a deep understanding of functional programming.

Try to convince someone of the value of immutability without mentioning concurrency.

Imperative and functional programming relate in the same way that arithmetic and algebra relate. It is hard to do deep reasoning in maths without algebra and it is impossible to evaluate the value of most algebraic expressions without arithmetic.

There is a reason that functional programming is at the forefront of concurrency research. In the long run, imperative only approaches will be unable to compete, and functional only approaches will remain on paper.

That's because support for concurrency is one of the most relevant strengths of functional programming. It's a buzzword right now, and a lot of the advice for how to do it well points toward functional programming practices, so they see that and say, "Hey, we should let people know that we already have all this stuff!"

Learning functional programming for a programmer is like learning programming for a non-programmer. Someone who is a logistics expert is valuable. A logistics expert who knows how to program is even more so.

OO programmers who understand functional programming have a big advantage over OO programmers who don't. Learning FP gives one the mental tools to do better encapsulation.

I have written code for hundreds of cores. (can you say CUDA?) It was written entirely in C and ran very fast.

Thats great, but anecdotal evidence doesn't really prove anything. CUDA lets you write multi-core code for GPUs, but imagine writing C code for hundreds of cores over a datacenter cluster. C isn't the right tool for that job.

This is what I think they are doing.

Why does someone need a reason not to answer a silly question.

Do you use EV to run your Perl web apps as free standing applications? Or do you use it for some other purpose?

Yes. I use Coro/EV for web apps and non-web apps :)

Your point is invalid, and is in fact a much better argument for open standards, which don't require a predatory monopoly to benefit the ecosystem.

Consider: The value of TCP is not in itself, but in the applications that run on it. The greater the market share of TCP, the greater the utility of the applications. The greater the market share of TCP, the greater the incentive for applications to be created for it.

----

The value of Posix is not in itself, but in the applications that run on it. The greater the market share of Posix, the greater the utility of the applications. The greater the market share of Posix, the greater the incentive for applications to be created for it.

Yes we tried that, it was called the Unix Wars.

It is an interesting video.

Quick summary: Node.js is a program/api written in C that lets you write asynchronous servers in javascript. All IO is done through event loops and callbacks.

If you are interested in the efficiency/architecture of server programs then this is worth watching.

He confuses his own internal mental model with the actual nature of electricity.

Mostly this is just arguments about semantics.

They've moved the hosting to Australia.

I've been using HStringTemplate on top of happstack quite happily. REST would be fairly easy to achieve using this approach. I would venture to suggest that most people would find it easier to adapt happstack directly to their needs than trying to use happs at this point in time.