[balamaci]

Yeah they will still probably be labeled as dead man walking for the next 20 years long after your FP langue de jour will have outlasted it's pristine days and got damned to hell by the devs having to maintain the programs written in it. Don't get me wrong if you are currently doing consultancy business for a niche FP language far for me to blow the wistle to companies that instead of paying your fees and hefty salary for that rare programer(who might be me) who would have dabbled in your obscure language they would be better of paying 10$ a month and get 2 more DigitalOcean instances to support the rise in traffic your non sharable state code is solving.

[pmarreck]

I don't think so, this time:

http://gamasutra.com/view/news/169296/Indepth_Functional_pro...

"My pragmatic summary: A large fraction of the flaws in software development are due to programmers not fully understanding all the possible states their code may execute in. In a multithreaded environment, the lack of understanding and the resulting problems are greatly amplified, almost to the point of panic if you are paying attention. Programming in a functional style makes the state presented to your code explicit, which makes it much easier to reason about, and, in a completely pure system, makes thread race conditions impossible."

[balamaci]

Well I don't think functional languages are something new and by reading the latest death and doom I'd wonder how we ever got this far and why suddenly it's so much harder to do concurrency. I confess that I don't write low level software for lunar modules but just the regular enterprise stuff and having worked with high level concurrent constructs like ConcurrentHashMap, LinkedBlockingQueue, RingBuffers on the jvm I've yet to experience the concurrency issues everyone is lamenting. I know it must be hard for the people developing the jvm to make those high level concurrency constructs available for me, but that is why I'm grateful for their work and "happy" that I can rely on them. I don't know maybe I've just been very lucky until now.

[pmarreck]

Most of the bugs I see in the wild are of the "runaway state" variety; in other words, a state the programmer(s) involved forgot to imagine might happen. This class of bugs includes EVERY bug or crash that is fixed by a restart of an app or system (because all that does is reset state to a "known" a.k.a. "modeled" state, bringing it back within the code's, i.e. programmer's understanding). Therefore, anything (whether it is a language, a methodology, or both) which mitigates or eliminates this class of bugs would be HUGELY valuable.

Functional paradigms/languages, and immutable values, and controlling side effects, greatly help with that, in my front-line coding experience. Therefore, I am a fan.

Do you enjoy doing needless extra work? In other words, are you a little bit lazy? (in the Larry Wall "laziness/impatience/hubris" sense). If so, you should be at least trying out functional paradigms and see if they work for you like they have for pretty much everyone else who has taken them on.

[balamaci]

I'm going more pragmatic and I think most of the bugs were/ are NullPointerException the kind that today's IDE(due to their maturity of working for years and years with the language) can now even warn you about, compared to obscure ones that force you to do resets. On the other hand I don't see why the concepts of immutable values cannot be adopted in OOP languages. There is http://javaslang.com/ and immutable collections were long time present in Guava library. Sure immutability might not be enforceable in the language itself but you can do it. Java8 has streams for a functional approach to collections. Hell you can even use Akka if you cannot do without an actor framework in java.

But suggesting we need to start from scratch with new untested 3rd party libraries(that other people take for granted) and rewriting some of them. Even the simpler stuff like suffering the quirks of the extra tooling(build tools, IDEs) for a new language and all because of the death and doom we are supposedly seeing today(which I dont and I've yet to see people doing nightly restarts of web servers for some years). Unless you do consultancy for that language(or are seeking employment in a niche market) I think it's a little mad.

For me to declare the defeat of OOP and win of a FP language I first need to hear the voice of people having to do maintenance work on legacy code in that language as I'm too old to only believe there is such a thing as panaceea or there are only upsides to an alternative.

[15155]

If you're working a problem capable of being solved by two $10/mo DO VMs, you're working a problem that can be solved in /any/ language.

[balamaci]

I'm amazed by the number of people that declare the shared mutable state of the current languages as their bottleneck. You'd think everybody is suddenly working with realtime stream analysis on huge datasets and are battling millions of concurrent users these days.

My thinking is that if you are so popular you can afford maybe to start 20 more 5$ instances. And really I find it hard to think of problems that cannot be solved with 20 x 5$ DO VMs at least in Java.

[BuckRogers]

Your comments are probably not intended to make anyone laugh but I'm enjoying them. But what you're saying is so true. I'd like to take it a bit further and add there's a reason while the implementation is slightly barbaric, Node.js continues to thrive. While I don't use Node, I have, and tend to think making things even more 'regressive' than say, Java, is the right way forward for most work.

Writing multi-pthreaded Java apps is not my idea of a good time. I am very interested in Elixir, but at the same time recognize that in reality I use Python. And if folks want to knock themselves out writing multithreaded Java apps... to go use Java.

I think the Node model for most, if not almost everything, fits needs well with its single-threaded event loop and scaling by process. Explicitly spinning up pthreads should be reserved for systems-programming, and in which case you are probably going to be using C(++)/Rust(?).

>You'd think everybody is suddenly working with realtime stream analysis on huge datasets and are battling millions of concurrent users these days.

I almost want to archive this somewhere or put it on a plaque next to my desk.