Comment by carlmr | Hacker News Reader

Comment by carlmr | Hacker News Reader

Functional programming. I learned OOP in school, and always thought it overcomplicates things, why can't this comparison operator in one page of Java just be a function, I thought. How can you make the state of objects manageable, especially if it's private, how do you test, without opening up too much of the API, couldn't we just make this a set of functions with an explicit state so it's easier to understand? How do people understand a method that is spread over a hierarchy of 15 layers of inheritance.

For years I thought there must be something I don't grok about OOP. Some point where these design patterns click and make sense. Until I set out to learn OCaml, switched to F# because I was on Windows, and found https://fsharpforfunandprofit.com. All these concepts had really foreign sounding names, but they clicked right away. I finally found that there are people that think like me.

I'm happy functional programming is slowly taking off, influencing almost every modern language. So I guess I should have just trusted my intuition.

I feel the same way for OOP paradigm but I found it's usually hard to argue against it because it seems to be so ingrained into people's minds. After all that's what we are taught in universities and presented as a first go-to toolbox so it's no wonder.

I'm guilty of that defending attitude too but after probably several hundreds kLoC of OOP style and utilization of whatnot design patterns I've came to realization that it's mostly great for overcomplicating stuff for no materializable advantage.

I think the problem is that OOP is mostly taught as a separate paradigm, when it should be seen as a convenience layer over procedural imperative programming. It is about bundling procedures together in groups, associating them with mutable state, and protecting and encapsulating that state from other pieces of code.

I see two big problems with OOP:

1) OOP takes credit for a lot of programming concepts by rebranding them. E.g. abstraction.

2) OOP-specific concepts are either over-used or downright broken. E.g. inheritance, encapsulation.

Yes, I agree, my experience is also that OOP is taught as something orthogonal over procedural imperative programming whereas it should be taught as an extension to it. But even with that said I honestly cannot think of many examples where OOP provides more elegant solution to the problem. Quite the contrary, any larger and more complex OOP-style codebase is quite an unreadable mess despite all the standard promises about the readability, maintainability, "testability", clean abstractions etc.

I think that the biggest bend in my mind was when I set myself a goal to try to digest "Elements of Programming" by A. Stepanov and "Modern C++ Design" by A. Alexandrescu. Don't let the "modern" in the title trick you, it's a book from 2001.

But irrelevant of the programming language, which in my example happens to be the C++, these two books triggered me to start challenging the tunnel vision I had up until then. It took me some time and a lot of experimentation to basically unlearn the OOP way of approaching the problems and trying to embrace a totally different, I'd say, almost mathematical way of looking at the things. It felt like a relief and it really had a huge impact not only on my code style but the way I think about the problems.

Since then I think I started producing much simpler and, what I think, non over-engineered code of better quality without a lot of unnecessary cruft.

The bigger problem is that OOP isn't even consistently defined. Kay's (who is oft credited with inventing the term) definition revolves around message passing, which negates the idea of it being a layer over procedural imperative languages as Erlang fits his model of OOP.

The problem, I think, is that OOP is teach with lots of inheritance. And people think is all about inheritance, and is the only valid tool. Correctly (sparingly) used is ok, but 99% of the time is over used. That is the "All has to inherit from something" illness. Another thing that is overused is hiding: all has to be private, all accessed through getters/setters, all so deeply hidden as possible...

OOP has good ideas, but they have their place. They are way way way to much overused.

Agreed. OOP is a valid tool and we use tools to solve problems but the moment it becomes a wrong tool to use is when you find yourself trying hard to retrofit the original problem only so that it can match your abstract OOP puzzle. That's just calling for more problems in my experience.

As a C# developer, F# is something I long to learn. I heard about F# until I had to adjust some build script which I thought is elegant [1]. I did try some F# tutorials at free time, but nothing that would make me comfortable and "click" on how to write functional code.

But I long to bring some improvements to code correctness that can be statically checked by embracing immutability, pattern matching with discriminated unions where compiler ensures you have handled all cases, typing system which makes illegal state impossible... those are just some features I spotted could be very useful. On top of that, F# code seems so much shorter.

[1]: https://github.com/jordimontana82/fake-xrm-easy/blob/master/...

One of the things that made F# "click" for me was Wlaschin's "Domain Modeling Made Functional". It's largely a focus on how to think about the underlying data, and getting in that mindset helped tremendously in feeling more comfortable with F#.

Wlaschin is also the owner of fsharpforfunandprofit.com, which I highly recommend.

Learning functional programming well is like learning algebra; it really pays off to take a theoretical course from first principles, by a teacher who can also teach you the idioms (parameter accumulators, currying, monads...)

By order of impact, not chronological introduction:

0) Macro programming: I learned TCL as a kid, so that made the impact stronger; writing programs that write programs is insanely powerful. Learning macro programming via TCL incidentally let me skip learning FP at the same time, which I would've with a Lisp.

1) Functional programming: correctness and beauty. Standard ML, Haskell.

2) Erlang: extreme concurrency via message passing. Erlang is functional, too.

3) C: manual memory management: Understanding how programs allocate memory.

After that it gets more obscure. (Prolog, linear type systems, hardware DSLs, etc.)

I feel like TCL made me numb to the Lisp bug. I might go into Clojure at some point.

(Also, OOP can go suck a thumb.)

Reply on news.ycombinator.com