So you’re saying it’s a matter of “right tool for the job”? Who woulda thunk it?
That said I use a good mix of OOP and functional when I write python. Also, my first real language I learnt was haskell by doing projecteuler: https://github.com/JonnoFTW/ProjectEulerJava/tree/master/src (ignore the java in the title)
In an ideal world, the ‘copy’ side of a functional programming language is not the programmer’s concern.
Haskell lazy eval or Erlang (not familiar with it) ‘way around’ are in my view an attempt at leaving it that way.
If ‘perfect’, those would auto-detect when actual implementation / compiled code should perform a copy, or could work directly on the original.
In an ideal world, the -way- you defined Fibonacci should not even matter to the final implementation…
This is in fact quite a complicated problem and none of these languages manage to to such things perfectly… and that’s why we still need to bother about copy-or-not-copy… or even ‘fusion’-rule by hand… ffs.
I once toyed with a script idea having to ‘work around’ those very subjects and…
well… I failed.
But once we have an AGI-enhanced compiler for Haskell able to deal with this, FP may take over the world !
Or what’s left of it…
Hi @matan_tsuberi,
This video is mostly (but not completely) an exercise in “Reductio ad absurdam” where one exaggerates a point to make it absurd, and then sits back and criticizes the exaggerated result.
He obviously makes some good points, but those would be ways in which one could improve one’s Object Oriented code, but in no convincing way (imho of course), does he make an argument for throwing away the whole domain of programming?
The problem is that there are a lot of people who follow heuristics for solving problems by deifying the heuristic and then over using it. This is NOT the fault of OOP - it simply means that it has followers who exaggerate the importance of a “principle” and then regurgitate it ad infinitum/nauseam!
So mostly, I don’t agree that he adequately supports his conclusions with his assertions. I call them “assertions” because if you’re careful to listen hard, he doesn’t support the majority of his claims with adequate examples.
The whole tirade he goes into regarding “cross-cutting-concerns” and its impact forcing a refactoring of semantics in order to include the concern in a top-down logical way or abstracting a “sub-god” handler is actually a GOOD thing, because it forces the new substructure to have adequate semantics whose description include the new cross-cut as concern which expresses an intent of the new structure under which it is now encapsulated.
A lot of programmers might not do this in a neat or elegant way, and may muddle the overall semantics of the structure - but again, that is NOT the fault of OOP in general (imho).
Part of the way we evolve as a society of professional interest-bearing specialists is to attack the prevailing thought model and to keep attacking it until something better emerges. It’s a natural phenomenon which if you live long enough you start to see as a prevailing pattern with no more menace than recognizing it as a benign societal dynamic. It’s simply the way thinking evolves itself.
But that doesn’t mean the abstractions or concepts undergoing attack are necessarily “bad” or “wrong”. It’s just that we do our thinking inside of a context that describes (and takes for granted that) longevity is bad (imho).
Now…
The reason why I support OOP is that a new programmer can take a look at a foreign code module and instantly understand what it is trying to accomplish (if done correctly or as correct as possible given the restrictions of the semantic undergoing the modeling attempt). If you get rid of that, you have code which may emphasize efficiency, but is not very maintainable.
Now I’m generalizing too. But for the most part, the abstraction of programs into everyday language semantics is a concept that caught on for good reason.
Also, context changes.
Some of the pitfalls of OOP were mostly shallow in a world of sequential programming.
Those get exacerbated when future developments seems all-parallel.
Some are banging their heads to it because it turned out as a Dogma for people in the industry who recruit based on OOP-resumes and whose sole standard for quality of produced code is to ask “is it OOP-enough?”.
Not the fault of OOP, as you say, true. But we currently require a switch in paradigm, in a context of immobilism.
BTW. Not a ‘FP’ alternative to OOP, but I once enjoyed that read, a lot:
Proposing a return to a database-oriented view, with a game programming hat.
Online-book. Priceless. Literally 
PURE FREAKIN’ GOLD! 
OOP encourages you to invent a lot of artificial unnecessary concepts and muddle the overall semantics.
Yes. If you really really try hard and refactor over and over again the same code you may get decent OOP code and you’ll find that it’s basically functional or at least procedural in nature.
OOP is a mess. You can see that by the plethora of design patterns, rule and heuristics that people have invented over the years in order to patch this broken paradigm.
All good OOP design patterns are simple higher-order functions.
The fact is that what really makes programming hard is mutable state, it makes everything exponentially more complicated. As long as you have mutable state, you can’t look at a small piece of code and have confidence in what it does without also understanding everything else in the system that may effect it. It doesn’t matter how many classes you throw at it.
Good programmers should strive to eliminate mutable state and limit side-effects to the edges of the program.
Here’s some FP propoganda:
Honestly, I think the people who said this (not you) are forwarding more OOP propaganda. Design Patterns aren’t meant to “fix” anything! They are meant to abbreviate an understanding in a common nomenclature that allows two programmers to communicate precisely about a given concept. It’s meant to ease communication and idea flow.
Also, of course OOP is going to evolve and the ideas surrounding its use are going to be refined. That doesn’t mean that the original paradigm is wrong?
I just don’t think it needs to come down to an either/or choice. Functional programming is damned BEAUTIFUL… I love it! But yet I don’t want to make everything I touch a Functional program, either? I also recognize the simplicity of modeling problems in everyday language… I like both.
Btw, anybody remember Aspect Oriented Programming? That was a whole new paradigm meant to enhance OOP with the ability to express cross-cutting concerns in a way that integrated with OOP methodology.
I still remember the first time my friend brought over the Bjarne Stroustrup c++ book - all excited about this cool new extension to C.
He went over the main features and I was immediately struck with my first impression of the language - look at all the horrible new ways to make mistakes!
I had been teaching computer classes at the time and had just read the Godel-Escher-Bach book and was acutely aware of the possibilities of errors that are distributed over different levels of description. In my hand was a book that actively promoted hiding errors in different (and now very hard to see) places.
Just to add a cherry on top - it was now possible to overload symbols so the very first problem with the code that you have not seen before is that the operators may not do what you might expect. This is one of the “features” that condemn some languages to the “write-only code” trash heap. Forth comes to mind here.
I am aware that you can create a perfect domain-specific set of tools but that also means that when you have to pick up where the last (sloppy) programmer left off you have very few guideposts as to what was tucked away where and which nasty interactions are built in due to bad partitioning of function.
I had some of this rubbed in my face when I was living as a consultant and had to go in and clean up the mess of bad OOP code. To be fair, companies don’t call in “experts from afar” to fix good code so I was only seeing the bad stuff, but when an OOP project goes bad the OOP features can make it mind-bogglingly worse.
Trying to cram something into the “patterns” of frameworks don’t make things better. I can say that my experience maintaining OOP code written by other has been uniformly unpleasant.
I would much rather reverse engineer undocumented embedded firmware systems or sort through spaghetti C code any day. (Done both, liked ‘em better)
I do not have enough experience with functional programming to make an informed statement but I am very curious how well they perform with hard real-time interrupt driven multi-tasking environments. This is the world I live (and code) in and poor-performing languages are a non-starter for me.
FP is typically less performent that its imperative counterpart, though Haskell has a very aggressive optimizer that uses the pureness to it’s advantage and can output quite performent binary executables despite being an extremely high level language. It’s not suited to embedded systems though, due to its massive runtime.
Moreover, Haskell is a lazy language which means it only computes what is nessery, which makes reasoning about performance pretty hard but also means that typically naively written Haskell code performs better than its strict counterpart (there are pitfalls however).
How about that one ? ^^
Lisp vs. everything else ? 
http://www.paulgraham.com/avg.html
I’m not so much Lisp-fluent myself but I have to admit, stuff that guy said made me very very very curious about it, at one point.
wouldn’t be my choice for bitwise logic against SDR… but still.
The lisp approach is very charming to me. Invent a programming language tailored to your problem. If only it was as easy as importing a library…
Lisp needs a powerful combinator-like way to mix and match programming language features without knowing much about compilers and to create new syntax without needing to worry about parsing.