5 ms·

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

by carlmr 4y ago

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

jve 4y ago
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/build.fsx https://github.com/jordimontana82/fake-xrm-easy/blob/master/...
- pliftkl 4y ago
  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#.
  - carlmr 4y ago
    Wlaschin is also the owner of fsharpforfunandprofit.com, which I highly recommend.
- TuringTest 4y ago
  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...)
menaerus 4y ago
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.
- bluetomcat 4y ago
  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.
  - sshine 4y ago
    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.
  - menaerus 4y ago
    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.
sshine 4y ago
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.)

by carlmr 4y ago

jve 4y ago

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/build.fsx https://github.com/jordimontana82/fake-xrm-easy/blob/master/...

pliftkl 4y ago
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#.
- carlmr 4y ago
  Wlaschin is also the owner of fsharpforfunandprofit.com, which I highly recommend.
TuringTest 4y ago
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...)

menaerus 4y ago

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.

bluetomcat 4y ago
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.
- sshine 4y ago
  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.
- menaerus 4y ago
  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.

sshine 4y ago

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