yfyf

Sure, theoretical investigations on things begin many years earlier than anyone starts actually using them, but somehow "concurrency" wasn't something available to your everyday Joe back in 60s, right? Multi-core wasn't the norm, there was no elastic cloud, what so on.

And I am not really claiming that software development changed much in 3 years, but I think people's mindsets are changing faster than that, especially of those who are actively involved in thinking about these things.

I wonder if he would claim the same argument today as he does in this[1] comment, in particular the paragraph "On side effects being bad <..>".

I would dare to claim that there's some trend to do things more side-effectlessly not only in programming, but also in general, people in IT are finally realizing* that the more isolated, light-weight and modular things are (think of increased interest in functional programming (pure functions), dominance of cloud-based/inspired solutions (spinning up small instances of VMs)) the better. Somehow this particular mindset helps at all levels.

Hah, there's actually a term for what I'm trying to describe: Shared nothing architecture[2]. Allowing side-effects on any level implies "sharing" to me.

[*]: of course you could say "this has always been the case", but somehow some years ago Java and the friends seemed like the only "enterprise level" solution to most businesses and the general fat-stack+vertical-scaling seemed somewhat reasonable.

[1]: http://neopythonic.blogspot.nl/2009/04/tail-recursion-elimin... [2]: http://en.wikipedia.org/wiki/Shared_nothing_architecture

Yes, I am only claiming that it results in shorter code for the code which deals with problems in that specific domain. In general -- obviously not! But the overall gain is still significant. I don't care if e.g. some library dealing with some specific type of string manipulation is longer in Erlang than in other languages. This is a completely isolated modular component of the whole system. It does not prevent me from understanding the important bits. I do care if the core components are bloated, but are only describing some very simple behaviour.

> erlang is great for anything that requires a lot of moving pieces and doesn't require the code to actually look nice or be readable"

Sorry, but this is such a BS claim. Yes, there are bits of Erlang syntax which are ugly. Yes, you can write absolutely unreadable Erlang code, just like in any other language. But the whole point is that Erlang is extremely expressive for the problems in question - distribution and fault tolerance. It allows you to write code which is multitudes shorter than in (almost) any other language. Your code ends up being very succinct which is a huge benefit because of clarity/maintenance/etc.

For some extremely elegant code go look around at basho[1] and 99s[2] code. In particular, riak_core and cowboy. These are works of art!

[1]: https://github.com/basho [2]: https://github.com/extend

Someone needs to make a poster for this, I'd put it up in our department.

Now someone please explain Skolem's paradox to a 12 year old.

I'm sorry, but his photography is terrible. Cliche, boring and not even that well produced in the technical sense.