Comment by ilovecaching | Hacker News Reader

Comment by ilovecaching | Hacker News Reader

My first big Erlang project made me completely rethink my acceptance of object oriented programming in C++, Java, Python, etc. I realized that I had blindly accepted OO because it was taught as part of my college curriculum. After several years in industry I had concluded that programming was just hard in general. It wasn't until my first project in Erlang, where an entire team of OO devs were ramping up on functional programming, that I discovered that the purported benefits of OO were lies. I also realized that the idea that concurrency and parallelism must be hard is untrue. OO simply makes it hard.

Now I see OO as something I have to deal with, like a tiger in my living room. Thankfully, so many new languages have come out recently; Go, Rust, and Elixir being the ones that I use regularly, that have called out OO for what it is and have gone in more compelling directions.

Hopefully one day they will teach OO alongside other schools of thought, as a relatively small faction of programming paradigms.

Erlang. Same here. Reading first few pages of a book describing principles of OTP (processes, share-nothing, messages, etc) was mind blowing. Company I worked for at the time (and I still do) decided to switch from Java to Erlang in middleware area. This decision seemed like a mixture of insanity and enlightment. Do you switch from one of the most popular languages in the world to something that most developers never heard of? Surely, exciting, but will it work? How do we hire new staff? After our R&D confirmed it was promising, me with couple of other developers were tasked with rewriting quite an expensive piece of middleware software that was unfortunately reaching its maximum capacity. We had no knowledge of how the software worked, we just knew its API. We were given time to learn erlang so we did. We all switched from eclipse to vim (some to emacs). After a bit of playing around with erlang we did our job in just 3 months. New app was much smaller and was easily capable of handling many more messages than the previous one. And it was written by erlang newbies! Then many more erlang apps we have created. It turned out to be a really good choice. Also the level of introspection you get out-of-the box with erlang is just amazing. I have never seen anything like this before.

Now I can compare Erlang to Java and it is really baffling how the heck Java took over the world. To do erlang I just need an editor with some plugins, ssh connection to linux with OTP installed and of course rebar3. To do Java I need 4GB of RAM to simply run an IDE with gazillion of plugins, maven to cater for thousands of dependencies for the simplest app and I need to know Spring, Hibernate, AOP, MVC and quite a chunk of other 26^3 3-letter abbreviations. No thanks.

May I ask what was the book? Do you recommend it?

There are 2 erlang books. "OTP in action" and "Learn you some Erlang". I highly recommend both of them.

I already asked about this in the parent post that refers to Erlang, but do you happen to have a write up by any chance, where you go into more details. I’m super interested! It would be really appreciated. (This is not the first time I hear people praising Erlang in comparison to popular OOP languages)

Ironically, Erlang’s message passing makes it more like Alan Kay’s original definition of OOP than the bowdlerised view of OO perpetrated by Java and C++.

Yep. That is why I can not ever interpret the term "OOP" anymore.

Same reaction but different type of project and language. Immutable data with persistent data structures was a game changer for me. There is place for OO but it does feel like the last 20 years our profession has been suffering from collective insanity.

Try code large a GUI project without OO.

The model is a data structure and the view is a series of functions on it. The rest is convenience and interface state (render cache, undo stack, etc).

Have a look at functional reactive programming.

As the other commenter already pointed out, functional reactive programming wiped the floor (React) of OO style approaches to GUI design. It turns out thinking about interfaces is made considerably easier with one way data flow.

If you’ll open https://reactjs.org/ you’ll read right on their main page:

> Build encapsulated components that manage their own state, then compose them to make complex UIs.

Components managing their own state is a textbook definition of OOP. They even use inheritance in their example on the main page:

> class HelloMessage extends React.Component

React isn't really object-oriented. Components rarely pass messages to each other. Instead, the way that data flows is through function/constructor arguments. You can directly invoke a method on a component, but that's only really used as an escape hatch. It's inconvenient, and IMO, a code smell.

For the React that I write, class components are used only when there's some trivial local state that I don't want to put into Redux (e.g. button hovering that can't be done in CSS), or when I need to use component lifecycle methods.

And yes, class components do inherit from React.Component, but they specifically discourage creating your own component base classes.

> React isn't really object-oriented.

I don't do web development but I've read react API docs and user guides.

Objects calling other objects is optional for OOP, I never saw a definition that requires them to do. OOP is about code and data organization.

Objects and methods are everywhere in react. Some are very complex.

Just because it uses a few lambdas doesn't mean it's not OOP.

For reference, here's now a non-OOP GUI library may look like: http://behindthepixels.io/IMGUI/ As you see not only it's hard to use, it doesn't scale.

Like it or not, OOP is the only way to deal with complex state invented so far. Even in functional languages: https://medium.com/@gaperton/let-me-start-from-the-less-obvi... And modern rich GUIs have very complex state.

> Objects calling other objects is optional for OOP, I never saw a definition that requires them to do. OOP is about code and data organization.

Smalltalk, which is the prototypical OO language, does the exact opposite of everything you said (all computations happen by message passing and all members are public).

> does the exact opposite of everything you said

No it doesn’t.

> all computations happen by message passing

I did not say message passing is required to be not present, I said it’s optional.

> and all members are public

I did not say anything about encapsulation. I said OO is about organization of code and data. If you have classes with properties and methods, it’s OOP.

Calling a function of another component is a way of passing a message to another object, no matter what that message is, be it the data flows you mentioned, or anything else.

Facebook is written in React. React is (almost) without oo. There are web and mobile guis written in React. Native aren't, yet, but that's mostly because it's young and there are no libraries for that.

This is a reply to @lallysingh (sorry I'm replying after your post is too old to get directly replied :)

Re "The model is a data structure and the view is a series of functions on it." This is exactly how I see my OO-based GUI programs. The object I define is firstly a data structure. Then I want some operations/views on it? define methods on it.

This sounds fascinating. Do you have a write-up where you go into more details? A couple of examples with before and after perhaps? Seriously that would be amazing.

Reply on news.ycombinator.com