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.
I don't think the world of software development changed at all since 2009. It takes about 15 years to see noticable shifts in practices.
Also, shared-nothing "architecture" goes back to the 60s with the first investigations into concurrency. In fact, if I were being pedantic, I would say it predates computing itself: logic is all side-effect free.
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.
> 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!
> It allows you to write code which is multitudes shorter than in (almost) any other language.
It's not clear if you're making that claim only for 'distribution and fault tolerance'. In that case, I don't know enough to say. For pretty much anything else, I'm sure that Erlang is much more verbose than Ruby.
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.
Depends a lot on what you are trying to write, how much fault handling code you need and the size of your program. Programming languages which are "verbose" for small programs may not necessarily be it for large complex bodies of code.
In my experience it also tend towards what you are trying to do.
The "actual numbers" are numbers for a lot of numerical code like computing pi digits, spectral norms, n-body simulation. That fact that you show those representative as typical Erlang programs shows that you don't know what typical Erlang programs are used for or just trolling. (And either one of those could result in downvoting).
I know what Erlang is used for (my name appears in the acknowledgements here: http://www.amazon.com/dp/B002L4EXHY/?tag=dedasys-20#reader_B... as a reviewer ), and the language shootout is a convenient benchmark site, nothing more. I never claimed it was anything else, did I?
Ruby isn't exactly a whiz in the number crunching department either: it's significantly slower than Erlang and certainly not 'meant for that', and yet, its code is more concise.
If you are saying Erlang is only concise for problems that it was meant for (and excels at), fair enough.
I'd also say that my preference is for languages that do lots of things pretty well rather than one thing really well and other things not so great. It's frustrating in some ways, because for some things Erlang is absolutely brilliant.
I didn't downvote you, I asked you a question. I have an opinion on the relative verbosity of Erlang, and was interested in hearing an explanation of yours.
But thanks for projecting your insecurities on me.
It depends on whether the meaning of "exists" is, I think. By analogy to the finite universe (always dangerous in logic), it is like saying "we live in a sphere of diameter 4. We have proven (due some hypothetical variation of relativity) that all matter in the universe will never be able to move more than distance 1 from the original center of our existence. An object of length 3 can be mathematically described, but is theoretically impossible to construct." Or something.
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