Hacker News Reader

Comment by pmarreck | Hacker News Reader

Object-oriented languages are Dead Men Walking due to the problem of global mutable state management in any medium- to large-sized codebase, coupled with dependency/inheritance hell, leading to complexity hell, leading to geometric progression of tech debt. Compounding this is the lack of good unit test suites across the board, meaning that even if you write absolutely perfectly tested and maintainable Python (or Ruby, or Java, etc.) code, you still are stuck using libraries that have not been written with that in mind.

And yes, I'm talking broadly about the rise of FP.

View on HN

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.

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.

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.

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.

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."

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.

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.

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.

You mean all those FP languages that happen to support OOP as well?

Lisp, Clojure - CLOS

OCaml - The O is for Objective, e.g. Objects

Scala, F# - Hybrid FP/OOP

Haskell - Type classes support polymorphism and extensibility.

Erlang - Message passing as envisioned by Smalltalk

So what are FP languages that have zero support for OOP concepts and are on the rise?

To be pedantic, Clojure has nothing to do with CLOS. It does leverage JVM and lets you use objects and OOP patterns though.

So where do you think multi-methods and protocols come from?

Okay, TIL, still there's more OOP in Clojure beyond CLOS influences.

>Haskell - Type classes support polymorphism and extensibility.

While most of your examples are valid, I don't think Haskell is remotely object oriented. Type classes are not classes.

Any Haskell coder knows that.

Quoting myself

> ... support polymorphism and extensibility.

OOP isn't only the C# and Java view of the world.

Polymorphism and extensibility are features of OOP, but Haskell implements them in a rather different way to most OOP languages.

I realise people disagree about what exactly should be considered OOP, but personally I think not including inheritance in the definition broadens the term beyond usefulness.

There is no disagreement, Smalltalk is the object system. Object-orientation was invented in Smalltalk. Other languages and systems are just poor imitations.

Being a "hybrid FP/OOP" language is like taking a pure soup and allowing anyone to put a little bit of fecal matter in it and still thinking the product is "A-OK." ;)

Opinion aside, it's still true that some classes of algorithms are still too slow in FP and benefit from procedural mutation of state. But those should be managed very carefully as they destroy concurrency. I linked it elsewhere here but I think John Carmack's comments on this are quite lucid, and he is merely talking about using a functional style within OO languages: http://gamasutra.com/view/news/169296/Indepth_Functional_pro...

The thing is, 16-core CPU's are coming out soon, and we still have 99% of software that cannot take advantage of that well, at least within a single process.

One clarification

> Erlang - Message passing as envisioned by Smalltalk

Smalltalk, despite being called an "OO" language, did not come up with the gigantic class inheritance chains which have been attributed to OO.

Object oriented does not require state: it requires encapsulation. I incorporate as much immutability into my code as possible and I would say most of our objects never have their state changed from instantiation and I write Enterprise Java all day long.

Interesting that FP started from as long back as the time of John Backus (of Backus-Naur fame):

https://en.wikipedia.org/wiki/John_Backus

Not taking any sides in this beef, though, just an interested bystander.

This either or thinking is not very productive. FP existed before OOP, it's hardly reasonable to think it will replace it.

WeddeddSsx

Reply on news.ycombinator.com