3 ms·
This should remind us what programming is all about: Take a data set, modify it, present it to the user or write it back to a file or a database. And we can se
by menotyou 4y ago
This should remind us what programming is all about: Take a data set, modify it, present it to the user or write it back to a file or a database.
And we can see why imperative programming is much more simpler than OOP or functional programming.
- That that data!
- Transform the data!
- Take result of transformation and transform further!
- Display the result!
Not:
- Think about an abstraction of the problem
- Define a class which is vaguely near to the problem domain.
- Take the data and press into the object using a constructor.
- Write some methods which fits the object abstraction but not related to the actual problem
- Write a couple of methods to administrate the data inside the object
- Do the same for a second class because after doing the first transformation step you have a different kind of object
- Use a mixin to combine the two classes
- Refactor the code to adhere to Clean Code
- Write a helper class which is actually not an abstraction of anything
- Write test classes to test quality into your code because your codebase became to messy.
- Explain everybody why this approach is superior than just pipelining the data between functions.
- Complain about why the state of the industry is so bad.
- unsafecast 4y agoI would argue that functional code is much closer to Unix pipelines than imperative code. Each function takes inputs and transforms them. Pipelines are just function composition. 100% agree with everything else you just said though.
- NackerHughes 4y agoI'm glad I'm not the only one who thought this. When I first learned about function composition, a supposedly groundbreaking feature of functional programming, Unix pipes were the first thing that popped into my head, but making that comparison out loud was only met with facepalms and accusations of trolling. But it's literally 'take this input and apply these functions to it, in this order'.
- menotyou 4y agoYah, I was expecting this comment. I'd agree but I see nowadays to obsession on abstract issues around functional programming like clojures, monads, recursion and code is data and function as first class citizens which might be of theoretical interest, but quite often are only code obfuscating technics. When you use (progn ....) in lisp or (do ...) or (-> ...) in clojure you are pretty near to what I understand as imperative but you are leaving the orthodoxy of functional programming. What is relevant is idempotence which is easily achievable in functional programming and in procedural/imperative as long as you don't use global variables. Idempotence generally not a feature of OOP. (OOP quite often is not even deterministic).
- unsafecast 4y agoWhile a lot of the type theory stuff is controversial, closures and recursion are core concepts of functional programming. I mean, they date back to the first ever functional language, lisp. Removing them would be like removing classes in an OOP language.