10 ms·

It’s time to move on from OOP?

64 points by nnx 7y ago

pjmlp 7y ago
Sure, as if sucessful FP languages weren't hybrid ones with support for OOP programming as well. The future is neither pure OOP, nor pure FP, it is multi-paradigm. And with nice libraries, IDE and GUI tooling as well. Comparing languages based purely on grammar and semantics doesn't help much.
- smitty1e 7y ago
  Can anyone point to an IDE or GUI programmed from the ground up in an FP style? The declarative simplicity of FP makes it a joy, but I find myself skeptical that flattening the OOP hierarchy into what would be a right jolly long list of pure functions will prove practical.
  - pjmlp 7y ago
    Not really. Common Lisp ones make use of CLOS or similar concepts. For Haskell you have Leksah, but it uses Gtk and Typeclasses which allow for polymorphism, a basic OOP principle.
    - sixbrx 7y ago
      I'd call type classes a non-OO form of polymorphism, it doesn't become OO just because you have polymorphism (if that's what you're implying). I think of OO as late-as possible dispatch, whereas type classes are compile time only in most implementations.
ggambetta 7y ago
I've been around long enough to remember when OOP was the savior who would free us from the previous generation of trillion-dollar disasters (spaghetti code, CASE tools, DFDs), and I'm sure someone will be writing "Functional Programming - The Trillion Dollar Disaster" in 10-20 years. In other words, I don't do hype or fads anymore.
- trilila 7y ago
  This. Thank you. Thank you for thinking rationally.
- flyingcoder 7y ago
  Can we just agree that programming is a trillion dollar disaster in general?
  - dgellow 7y ago
    If during that same period programming as a whole generates more than a trillion dollar, is it an issue then? Or just an operation cost? :-)
    - kazinator 7y ago
      It's okay to break, as long as you break even?
- teekert 7y ago
  Seems like the whole world does the hype and then moves on to me.
- gluegadget 7y ago
  FP already existed at the time that OOP emerged as the savior. What currently in-practice paradigms do you think are likely to save us in 10-20 years?
  - kjeetgill 7y ago
    Sorta! I don't think enough credit is given to how Functional Programming as a paradigm has shifted and changed over the years. It's grown and developed a lot. There was definitely a time when having first class functions and functions as params was a big focus of Functional Programming. It opens the doors to a lot of expressive idioms. The inclusion of closures was an important part of this. This wave was definitely all about expressability more than structured reasoning. I'm talking lispy homoiconic macroy goodness. Later Functional Programming thought was focused in the direction of ML/Haskelly/OCamly languages with a stronger focus on function purity, immutability, side-effect management, type inference, abstract algebra, and static guarantees of program structure and correctness. Sure the ideas existed before, but they're hard to reason about until they're distilled into a paradigm/doctrine. And Functional Programming did that. Like OOP, I think both waves of Functional Programming had a big impact on the programming landscape by introducing and popularizing a new vocabulary to a broader audience. The situational application of them will always come with experience and so every "fad" has the baggage of over application once it goes mainstream. OOP with Java, Javascript's framework explosion, 500 blog posts about monads, etc.
blodovnik 7y ago
So if oo uis so bad, exactly what is better? What should I be programming with?
- StreamBright 7y ago
  I usually just keep it very lean group a bunch of functions into logical groups and KISS it.
  - trilila 7y ago
    In OOP those groups are called classes, and the fun is that you can instantiate them and call them objects. And within those objects you can set a state, so those functions operate against it. A nice feat of OOP is that you can also inherit logic and expand it.
    - blodovnik 7y ago
      Sounds disastrous.
      - trilila 7y ago
        In the wrong hands, it does. Easy to tangle OOP. But the point is each of the two paradigms has its own benefits, and should be used when best for the task at hand.
        pjmlp 7y ago
        Somehow it seems hard to grasp that at their core classes are basically extensible modules.
        trilila 7y ago
        Indeed. Sometimes tho one just needs to pass a data set to a function, then the result the another, and so on, without the execution branches needed for figuring out the modularity rules and constraints of OOP. And that is where functional programming is relevant (and in math like scenarios, where speed and accuracy are key). But not as a rule of thumb, for everything programming.
trilila 7y ago
I dream of a future where instead of following messianic paradigms, developers follow the mantra of “the most suitable tool or practice for the task at hand”.
- julius_set 7y ago
  I dream of a world where instead of finding the most suitable tool or practice for the task at hand, developers follow the mantra of questioning those most suitable tools or practices without blindly adopting them
  - trilila 7y ago
    Also that.
- raducu 7y ago
  Developers don't work in a vacuum, it's hard to just use a little bit of that paradigm here and a little bit of the other paradigm there. You do need to plan your career and pick the winning paradigm/stacks because you need to invest significant amounts of time in mastering them.
CyberFonic 7y ago
No paradigm, OOP, FP, etc is "perfect". Yet they are all practical in the hands of competent programmers. Personally I don't particularly like C++, C# or even Java. I have seen way too many dreadfully implemented systems in those languages. BUT it is not the fault of the languages. Bad programmers can shoot themselves in the foot with any language, it's just a bit harder with some but not impossible. In my experience, business applications are all about state. The state of an account, a customer contact, an invoice. Changing state is what messages / methods do. In a well designed and implemented system minimal inheritance gets the job done. And bypassing encapsulation is a big no-no. Polymorphism reduces cognitive load. A toString method should return a meaningful representation of the state of all objects in a well designed system, etc. But fear not, the majority of banks, insurance companies, big business still use COBOL on mainframes. No danger of OOP there. It's all 1960s & 1970s programming with GOTOs and spaghetti code. And yes, those are the systems that manage trillions of "REAL" dollars everyday.
- pjmlp 7y ago
  Well, they can slowly migrate to OOP extensions added in COBOL 2002. Latest standard revision is 2014.
- jddj 7y ago
  Completely agree. Some of the most literate, easy to comprehend and maintain, stateful, Gui-heavy desktop apps I've written / worked on have been detailed models of interactive objects, because it was appropriate for the problem. In other problems (the classic web, data processing), it doesn't make as much sense to hydrate this huge, complex ecosystem of objects over and over just to throw it away again, or to end up with functions which are nonsensically bound to what is really just a data structure. Other operations are particularly recursive or parallel by nature and lend themselves to FP at least in part because of the work done in the FP community to handle those paradigms extremely well.
- eska 7y ago
  Of course a bad programmer will write bad software, no matter the language. But are you not taking this to the extreme? Surely some programming paradigms are objectively worse than others for certain use cases? I've personally come to the realization that OOP is only useful in very niche cases.
mathw 7y ago
I broadly agree, but this article is really poorly written. It takes every downside of OOP to extremes which make it really hard to take the author seriously. Yes there are problems with mutable state, even if you think you've encapsulated it. Yes there are problems with dependencies, dependency injection and the associated boilerplate. Yes there are hideous issues with concurrency. I don't think OOP as we see it in most languages today is particularly helpful. I do increasingly feel that data structures and operations should not be muddled together, and the polymorphism strategy should be something more like Haskell's typeclasses/Rust's traits or Go's idea of interfaces. I'm also sure that using those for a few decades would show us plenty of things wrong, and lead to something else. We are still children in this world. There are no correct answers - but there are definitely some wrong ones, and the increasing realisation of that is evident in the popularity of languages like Go and Rust, and the development of C# is also interesting - increasingly new language features are FP features, not OOP features, and the language becomes increasingly hybrid. It will always be limited by being built on a fundamentally OO runtime, but it's interesting how things are changing.
- 0815test 7y ago
  This article is just not very good, the author keeps talking about a zillion different things without really focusing on the actual, underlying issues. But one thing it does say right away is that mutable state is not a problem as far as it goes, what's problematic is mutability plus promiscuous sharing. This is what makes it unfeasible to reason about what the code is doing. Similarly, encapsulation (bundling code and data) definitely has its uses - in preserving class-wide invariants, or in providing a "common" interface that makes it possible to disregard the inner workings of some data structure, and interact with it in a way that's not dependent on the implementation. But in practice, implementation inheritance in OOP often encourages what amounts to breaking encapsulation and making it possible to violate class invariants, all in search of some dubious "code reuse". If you can't express your desired code reuse pattern via some combination of simple interface inheritance, delegation and dispatch over "sealed", non-extensible variants (the mechanisms that plain old composition/FP gives you) there are probably some underlying problems with it that you haven't thought through. Of course the standards of programming improve continuously over time. Even FP and broadly "FP-like" programming is not what it was in the 1980s, and some of that progress was brought (if perhaps incidentally!) by OOP languages. This is to be expected!
tehlike 7y ago
C++, java and other oop languages have been battle tested, and enabled a trillion dollar economy. Sure, others could do the same, but they didnt. Google, msft uses c++, c# and a bunch of others and they are probably the most complex software developers in the world. It works. Can it be better? Sure. Rust brings safety guarantees, f# enables functional programming mindset, julia is good for data processing. But oop did bring a lot of to market. We are evolving, and our languages will also evolve.
- flukus 7y ago
  Using an OOP language does not mean OOP programming. There is plenty of java/c++/c# code out there that use classes as glorified namespaces and stick to POCO/POJO objects. From my own experience I'd say that this describes the best and easiest to maintain code in those languages. The hardest to maintain code is almost usually a mess of inheritance and generics/templates by someone far to "clever" that thinks OOP is the goal and not the tool. More often than not an inheritance hierarchy is basically (not literally) an abstraction over if/switch statements, except the logic will usually be spread out over multiple files and it's impossible to track all these potential branches in your head because they're purposefully obscured from you.
  - mikekchar 7y ago
    This is a good point, however it also creates code that has no branch points (ideally) and is therefore easier to reason about. It is virtually identical to the situation of passing a flag to a function and branching based on the flag. This leads to a function that is more complex. You can move the branch above the function and write 2 functions, one which handles each case. But these 2 functions are inherently coupled (and may even share code). So it's a tradeoff. The OO style of programming also often moves the decision point. Instead of having an if statement above the 2 functions, you have the if statement at the construction of the object. If you happen to be writing code where you are doing mostly the same things, but certain details change in certain situations, you can group the differences into objects. If you are familiar with pattern lingo, this often happens if you are doing something that lends itself well to a template pattern. You can then use a bridge pattern to ensure that there is only ever 1 branch, instead of adding a decision point every time you want to vary the behaviour. Where I find people (reasonably, IMHO) disagree is that having the decision point at the place where the behaviour diverges allows you to see the logic of the situation right at that point. If you have a bug in the code related to that, then it's very easy to figure out where it is, because all of the logic is local. On the other hand, if you are refactoring the code, or changing the behaviour across the system, then it is very difficult to change because you have to search for all of those decision points. It's also harder to reason about on an architectural scale because it takes discipline (that may be lacking) to ensure that you always do things exactly the same way. You have a lot more flexibility because you can add all sorts of different logic to each decision point. The lack of constraint means that you have to inspect each case to determine if your overall change is going to work. I'll be honest. I like OO. There are a lot of really diabolical ways you can write bad OO code, but there are lots of diabolical ways you can write any code. I'm familiar and comfortable with imperative, modular code. I'm familiar and comfortable with FP. I'm even familiar and comfortable with declarative code (I wrote some large XSLT systems). There are trade offs which every approach. It's easy to see problems in code that you are not happy with and then throw the baby out with the bath water. Having said that, I don't think there is a problem with having a preference of one style over another, but it's a good idea not to fool oneself into thinking that it solves every problem.
barry27 7y ago
Drivel.
cty277 7y ago
Written by someone who... “Guides teams to building reliable software. JS/Node/React.” Enough said
- michaelmrose 7y ago
  Not really enough. Facile witty criticism doesn't add much to the discussion and lowers the level of discourse. The same thought expressed with enough meat to chew on might provide a worthwhile addition to the conversation but such venears once pierced are often as solid as movie sets. Think more deeply and take time to share.
jayd16 7y ago
>functions provide a level of code modularity and reusability never seen in OOP. Its like this guy has never used an OO language or at least tried to use some FP paradigms in one.
deleted 7y ago
[deleted]
teekert 7y ago
It's blocked for me, I have had 2 free reads... Any tips? I'd actually like to read these, the previous 2 were a let down and I never finished them even. I don't understand, I actually though medium was sort of free (as in beer), who is getting this money?
- stevula 7y ago
  I was able to bypass by opening in incognito mode as a logged out user.
- tiniuclx 7y ago
  http://archive.is/yAPEC http://archive.is/yAPEC
dgellow 7y ago
Abstractions and design patterns aren’t what object oriented programming is about, you can change the paradigm and you will still have these (though you will maybe name them differently).
jcelerier 7y ago
> There’s no objective and open evidence that OOP is better than plain procedural programming. Really depends on what is your definition of "OOP" here > Both Smalltalk and Erlang make use of OOP the way it was originally intended by its inventor, Alan Kay. ah, the bad definition of OOP then. Hint : most C apis that look like foo* foo_create(void); int foo_get_bananas(foo*); void foo_print(foo*, int, int); void foo_free(foo**); are OOP, not procedural. They just lack the syntax sugar. > Linus Torvalds is widely known for his open criticism of C++ and OOP. yet he went on doing C++ for user-space code : https://www.youtube.com/watch?v=ON0A1dsQOV0 https://www.youtube.com/watch?v=ON0A1dsQOV0 > Some might disagree with me, but the truth is that modern OOP has never been properly designed. It never came out of a proper research institution as someone who did a phd in a "proper research institution", that's a completely bullshit criterion. > OOP doesn’t have decades of rigorous scientific research to back it up oh come on https://scholar.google.com/scholar?q=object-oriented https://scholar.google.com/scholar?q=object-oriented
- 0815test 7y ago
  >are OOP, not procedural. They just lack the syntax sugar. ADT's/"Object-based" programming (which is what you show above) is not the issue. The biggest problems occur when you introduce non-trivial inheritance/polymorphism.
- eska 7y ago
  > Really depends on what is your definition of "OOP" here I smell a no-true-scotsman incoming.. >> Both Smalltalk and Erlang make use of OOP the way it was originally intended by its inventor, Alan Kay. > ah, the bad definition of OOP then. Message-based OOP is usually considered to be superior to inheritance by even OOP advocates, and even composition-based OOP by many. I don't see your evidence for "bad definition of OOP". >Hint : most C apis that look like > foo* foo_create(void); > int foo_get_bananas(foo); > void foo_print(foo, int, int); > void foo_free(foo); > > are OOP, not procedural. They just lack the syntax sugar. Not every API that uses a struct is OOP. If your foos use inheritance, virtual dispatch etc, then yes it's OOP. But usually it's just something like a struct to store state instead of having globals or multiple parameters even. >> Linus Torvalds is widely known for his open criticism of C++ and OOP. > yet he went on doing C++ for user-space code : https://www.youtube.com/watch?v=ON0A1dsQOV0 https://www.youtube.com/watch?v=ON0A1dsQOV0 He's a pragmatist first and foremost, and the GUI libraries he uses (Qt) and the programmers that work on GUI code use C++, he said. I doubt he would write his own GUI framework in C++.
millstone 7y ago
So much to critique in this article, but I decided to pick on this: "THE codebase becomes impossible to maintain" "THE codebase becomes too complex and unmaintainable" "What makes THE codebase complex?" I count fifteen references to "the codebase." THE codebase. THE. Well your program consists of more than one codebase! What then? Here's some code that ran on the linked site: window.webpackJsonp = window.webpackJsonp || []).push([[8], { "./config/polyfills.js": function(e, t, n) { Medium (codebase A) dynamically interrogates the API provided by my browser (codebase B) as influenced by plugins (codebase C) linking the UI framework of my OS (codebase D) and then loads some polyfills provided by Babel (codebase E)... Which one is "the codebase?" Your runtime environment is multiple components, each evolving independently! How do you write reliable software here? You can use static types but can't trust them, they can't predict the future and don't know the past. You want runtime interrogation and reflection. You want graceful degradation and dynamic polyfills. You need late bound interfaces. You need objects, not ADTs. This I think is the heart of the OOP idea: software components realized in classes/objects/messages which can evolve truly independently. Drop the "THE codebase" assumption and some of OOP's strengths will appear.
- drainyard 7y ago
  Are you essentially saying that because you are using libraries you need OOP? If that is what you are saying, that is nonsense.
danielscrubs 7y ago
"OOP is considered by many a crown jewel of computer science". No it's not. It's a crown jewel of programming. What do proper CS-researchers have to do to not be grouped together with pixel pushers? Slap Theoretical on every paper?
boringisnormal 7y ago
I would love to see atleast a few large projects implemented with Haskell/FP before making such tall claims. Large here means few millions of lines of source code and more than 50 engineers working on the same project, a monolith such as a database or a message broker.
- danielscrubs 7y ago
  “Measuring programming progress by lines of code is like measuring aircraft building progress by weight.” ― Bill Gates BTW: Are you considering Go to be OOP? Like it always is in the programming world everything is ill defined. Go has no inheritance from what I've read.
  - boringisnormal 7y ago
    The quote is fantastic and it does bring out an interesting dimension. Not all parts of the code base are equally important. That is for another day. I believe you are missing the context. Allow me to explain. Source lines of code is a proxy to the complexity of the problem in hand. With the assumption that the engineers will not unnecessarily write code just to fill up the code base or pass time, we can safely say that the number of lines of code for a database will be significantly higher than say a networking library. To write more lines of code, we need more engineers. And with more engineers, we uncover a variety of problems. No accomplished Haskell programmer will agree that Go is a functional language. At least the ones that I know don't. I think FP programmers are not in agreement as to what constitutes a functional language, example Haskell vs Clojure vs Elixir.
    - danielscrubs 7y ago
      Simplicity is a great virtue but it requires hard work to achieve it and education to appreciate it. And to make matters worse: complexity sells better. - Dijkstra My point today is that, if we wish to count lines of code, we should not regard them as "lines produced" but as "lines spent": the current conventional wisdom is so foolish as to book that count on the wrong side of the ledger. - Dijkstra The required techniques of effective reasoning are pretty formal, but as long as programming is done by people that don't master them, the software crisis will remain with us and will be considered an incurable disease. And you know what incurable diseases do: they invite the quacks and charlatans in, who in this case take the form of Software Engineering gurus. - Dijkstra
fetbaffe 7y ago
This article is just someone’s frustrated rant, poorly written. Definition of OOP has changed over the years, early on it was a lot of focus on inheritance & polymorphism, but today it is mostly about composition, which is basically what you do in FP as well. New inventive ideas like Go's & Typescript's interfaces flips the relationship between the caller & the callee. Or Rust's traits where you can expand your existing types with new behavior. There is criticism about OOP to be said, but using Java as your strawman to invalidate OOP is not really a good argument, it is just one implementation of many. Edit: removed the word dynamically from description about Rust traits.
- 0815test 7y ago
  I'm not going to defend the article's writing style, but Rust is effectively a functional language with controlled use of procedural-programming features. Not that much different from how Haskell places safeguards on the very same things. (No, I'm not saying Rust today is just as safe or just as elegant as Haskell - far from it! But it can get there with some work.) Even FP is not what it was back in the 1980s and 1990s!
  - fetbaffe 7y ago
    Can’t you make the argument that that part of Rust is OOP even though the rest of the language isn’t? Java has added more & more FP style constructs, does it make Java a FP language?
  - millstone 7y ago
    What does functional language mean here? Rust is not referentially transparent, does not model effects (any function can rm -Rf your drive), permits shared mutable state (RefCell, etc) includes statements not just expressions (break, return). Its most important safeguard is its affine type system, which is absent from Haskell.
    - steveklabnik 7y ago
      Break and return are both expressions in Rust. Item declarations, let statements, expression statements, and macro invocation statements are the four kinds of statements in Rust.
dandare 7y ago
> Real-world Example, Please! > Real-world example, please! > Real-world example, please! Would it be too much to ask for a REAL real-world example? Unless you are already an expert in both paradigms you (I) have no idea what is the author talking about. How is nullability supuerir in Functional? How is error handling superir in Functional? What is really meant by shared mutable state? (The example with a piece of papaer is equally useless as the explanation that "state is any temporary data stored in memory") How are "erroneous abstractions" promoted by OOP? What is the "low signal-to-noise ratio" How is the state NOT promiscously scatered between objects in Functional programming? How do you make "core parts of your application be stateless and pure" in Functional programming? How is global state "the root of all evil"? Could someone point me to a literature that can explains these questions to someone who don't know the answers already?
- eska 7y ago
  This may be a useful example for a different approach: http://www.dataorienteddesign.com/dodbook/ http://www.dataorienteddesign.com/dodbook/ Particularly the chapter "Relational Databases" which compares to programming with sets in databases. This book doesn't tell you to program as if you worked with SQL, but draws inspiration from it and makes a comparison.
madiathomas 7y ago
First I was programming in C and I was told C is bad and I must move to a better C -> C++. I listened and moved to C++. Then I was told C++ is horrible and I must switch to modern OOP langauges like Java and C#. I moved more than 15 years ago and I am now very productive when delivering solutions using C# and Java. 15 years later, I am now being told to dump my decade and a half knowledge and competitive advantage and learn a new programming paradigm? Miss me on this one. This time around, I will stick to what I know best. OOP has 80% of what I need and I know ways to deal with 20% of the problems. I will stick to it. It took me only 2-3 days to learn F# but I feel I will be doing my clients a disservice if I have to start from scratch and start delivering solutions to their problems using a programming paradigm that I have little experience with. No. Thank you. I will stick to delivering solutions to my clients using what I know best.
- danielscrubs 7y ago
  To be frank C# is a wonderful FP language. Try to minimise state (readonly structs helps) and see where it takes you. I recommend all programmers to go a programming paradigm course though.
  - madiathomas 7y ago
    I noticed when I was learning F# that it is leaning more and more towards Functional Programming.
- eska 7y ago
  Congrats, you're old now :) I think as developers we should constantly learn about new approaches. Doesn't mean we need to use them blindly and follow the herd. Sometimes it's also useful to learn something to realize why one should not use it, and how the current approach is actually better.
  - madiathomas 7y ago
    That's why I learnt F#. Just to see how functional programming is going to help me deliver solutions faster to my penny-pinching clients. It was an eye-opener but I will still stick to functional programming until FP catches on. If it happens. At age 37, I feel young and really wish that I will still be able to program at age of 50 and beyond.
lincpa 7y ago
Data dominates. the programming moves toward the data. from initial state to final state, the shortest linear distance between two points. Simplicity is the root of fast, stable and reliable. `The Pure Function Pipeline Data Flow`, based on the philosophy of `Taoism` and `the Great Unification Theory`, In the computer field, for the first time, it was realized that the unification of hardware engineering and software engineering on the logical model. It has been extended from `Lisp language-level code and data unification` to `system engineering-level software and hardware unification`. Whether it is the appearance of the code or the runtime mechanism, it is highly consistent with the integrated circuit system. Using the input and output characteristics of pure functions, pure functions are used as pipelines. Dataflow is formed by a series of pure functions in series. A dataflow code block as a function, equivalent to an integrated circuit element (or board)。 A complete integrated system is formed by serial or parallel dataflow. It has also been widely unified with other disciplines (such as management, large industrial assembly lines, water conservancy projects, power engineering, etc.). It's also very simple and clear, and the support for concurrency, parallelism, and distribution is simple and natural. There are only five basic components: 1. Pipeline (pure function) 2. Branch 3. Reflow (feedback, whirlpool, recursion) 4. Shunt (concurrent, parallel) 5. Confluence. The whole system consists of five basic components. It perfectly achieves unity and simplicity. It must be the ultimate programming methodology. This method has been applied to 100,000 lines of code-level pure Clojure project, which can prove the practicability of this method. [The Pure Function Pipeline Data Flow](https://github.com/linpengcheng/PurefunctionPipelineDataflow https://github.com/linpengcheng/PurefunctionPipelineDataflow)
teekert 7y ago
I learned Python about 5 years ago, just for context, I know a bit of bash, some html/css etc. I don't really understand this piece. I use Classes in Python, put them in a module, I also put functions there. Some things are nice as a class, some things are nice as general functions. I like inheritance, otherwise I repeat things. Maybe I need to grow my project and run into limitation before I understand the viewpoints. Maybe anyone has to go through this? Should I feel bad about using classes/objects?
gpderetta 7y ago
"""The venerable master Qc Na was walking with his student, Anton. Hoping to prompt the master into a discussion, Anton said "Master, I have heard that objects are a very good thing - is this true?" Qc Na looked pityingly at his student and replied, "Foolish pupil - objects are merely a poor man's closures." Chastised, Anton took his leave from his master and returned to his cell, intent on studying closures. He carefully read the entire "Lambda: The Ultimate..." series of papers and its cousins, and implemented a small Scheme interpreter with a closure-based object system. He learned much, and looked forward to informing his master of his progress. On his next walk with Qc Na, Anton attempted to impress his master by saying "Master, I have diligently studied the matter, and now understand that objects are truly a poor man's closures." Qc Na responded by hitting Anton with his stick, saying "When will you learn? Closures are a poor man's object." At that moment, Anton became enlightened."""
koonsolo 7y ago
I'm getting sick an tired of all these OOP bashing articles. X is terrible, Y is super! Fact is that everything has benefits and drawbacks, and so does OOP, Functional programming or whatever. The strength about OOP is that it's practically the best to program most software. If you look for example at the SDL library written in C, it uses an OOP interface with handles to keep things nice and simple. Yeah that's right, OOP in C, why would anyone do that? Because it has benefits, that's why. So why is most software nowadays written in OOP? Because it has the most benefits. You can sure find examples where functional programming would be better, but they are a minority. So yeah, next time I would expect an article to properly make a comparison between benefits and drawbacks of both things that are compared. Not the usual "all drawbacks of X, but look at all benefits of Y". This kind of thing screams "Junior alert" to me. Meantime, I'm developing my apps and games and applications in OOP, and absolutely loving it. Wouldn't trade it for anything else in the world.
- drainyard 7y ago
  SDL having an interface with handles has nothing to do with OOP and is simply the concept of opaque handles. This is often seen in data-oriented code bases where a system behind the scenes is dealing with transforming data in a hardware-oriented and cache optimized manner. Sure the article isn't super well-written, but it raises a fair point and shouldn't just be thrown away. Just because something is the most used or standard does not mean it is the best solution. Eating junk food is very common, but you would hardly argue that it is the best way for a human to get nutrients. You can use OOP all you want, and it's fair to say that the article should have been less biased (though he has a disclaimer that says he is biased), but there is nothing suggesting that OOP is practically the best paradigm to program most software other than the fact that it is the most used.
  - koonsolo 7y ago
    There is no doubt that using handles like that takes concepts the same like OOP, such as constructor, encapsulation, object methods, etc. Therefore moving this API interface to OOP would mean a straightforward 1-on-1 mapping. Claiming this has no relation to an OOP setup is therefore not correct. It would have had the exact same interface if it was written in OOP. Maybe we are talking next to each other about what a good programming language is. For me as a professional programmer, it means to sell value. This implies that the companies I work for can make the most amount of revenue. Thanks to free market forces, we can assume that the most "optimal" programming languages survive. Remark that "optimal" is not expressed in terms of aesthetics or whatever, but is purely the productivity of generating money. You can indeed claim that fast food is not healthy, but from a business perspective, it is a success story, and therefore also popular. I don't know how "healthy" OOP is, but it is hard to argue that it is not a business success story. And that is exactly what I offer to my clients. Edit: And to be honest, I would have no clue how I could make the business case for any of the projects I ever worked on for not using OOP. These include games, consumer mobile apps, robotics and various business applications (smart client-server, etc).
kazinator 7y ago
> [OOP] never came out of a proper research institution (in contrast with Haskell/FP). "Out with systems; in with formal languages!" https://www.dreamsongs.com/Files/Incommensurability.pdf https://www.dreamsongs.com/Files/Incommensurability.pdf > I do not consider Xerox or another enterprise to be a “proper research institution”. "Also, I don't consider a paper on systems to be publishable!"
thelazydogsback 7y ago
Smalltalk (which was a revelation to me when I played with it on Tektronics and Lisa) which the author mentions as a "real" OOP language, is actually a good example of a code maintenance nightmare as a is one of those languages that promotes "image saving"-based incremental development in the context of some unreproducable soup of classes. Also its single-dispatch nature (copied by most non-Lisp OOP systems) makes the intended receiver (and dynamic casting semantics) rather arbitrary. Any extremeism/fundamentalism taken too far tends not to work - and oop got just ridiculous at one point. It's also not just the idea, but how it is expressed and the level of abstraction that can be brought to bear. Unfortunately, Java, being a "class-orientated language" rather than an object-oriented one (not my original observation/coinage) and not supporting lambda/closures, etc., was both the reason and solution that we needed these baroque oop patterns in the fist place. (Even C# 1.0 had delegates before proper lambdas and didn't require realized nested inner classes to represent event handlers, etc.) Java's verbose solution to the simplest problems was (is?) frustrating, and is only matched by C++'s complex semantics of copy/assignment/... ctors and value/reference semantics which is more clearly make explicit rather than implicit in a vanilla C program.
thelazydogsback 7y ago
Two other random thoughts... It amazes me that despite the long-ago realization to favor composition over inheritance, that major oop langs only provide direct support for (implementation) inheritance of methods and not delegation. I suppose "delegation in context" has become be purview of DI/IoC add-ons - but direct language support would be nice. While confounded with OOP by many, Generics are probably best treated as orthogonal -- if they had been the primary focus (including higher-kinded types/modules) rather than inheritance, that would have been nice...

64 points by nnx 7y ago

Sure, as if sucessful FP languages weren't hybrid ones with support for OOP programming as well. The future is neither pure OOP, nor pure FP, it is multi-paradigm. And with nice libraries, IDE and GUI tooling as well. Comparing languages based purely on grammar and semantics doesn't help much.

smitty1e 7y ago
Can anyone point to an IDE or GUI programmed from the ground up in an FP style? The declarative simplicity of FP makes it a joy, but I find myself skeptical that flattening the OOP hierarchy into what would be a right jolly long list of pure functions will prove practical.
- pjmlp 7y ago
  Not really. Common Lisp ones make use of CLOS or similar concepts. For Haskell you have Leksah, but it uses Gtk and Typeclasses which allow for polymorphism, a basic OOP principle.
  - sixbrx 7y ago
    I'd call type classes a non-OO form of polymorphism, it doesn't become OO just because you have polymorphism (if that's what you're implying). I think of OO as late-as possible dispatch, whereas type classes are compile time only in most implementations.

ggambetta 7y ago

I've been around long enough to remember when OOP was the savior who would free us from the previous generation of trillion-dollar disasters (spaghetti code, CASE tools, DFDs), and I'm sure someone will be writing "Functional Programming - The Trillion Dollar Disaster" in 10-20 years. In other words, I don't do hype or fads anymore.

trilila 7y ago
This. Thank you. Thank you for thinking rationally.
flyingcoder 7y ago
Can we just agree that programming is a trillion dollar disaster in general?
- dgellow 7y ago
  If during that same period programming as a whole generates more than a trillion dollar, is it an issue then? Or just an operation cost? :-)
  - kazinator 7y ago
    It's okay to break, as long as you break even?
teekert 7y ago
Seems like the whole world does the hype and then moves on to me.
gluegadget 7y ago
FP already existed at the time that OOP emerged as the savior. What currently in-practice paradigms do you think are likely to save us in 10-20 years?
- kjeetgill 7y ago
  Sorta! I don't think enough credit is given to how Functional Programming as a paradigm has shifted and changed over the years. It's grown and developed a lot. There was definitely a time when having first class functions and functions as params was a big focus of Functional Programming. It opens the doors to a lot of expressive idioms. The inclusion of closures was an important part of this. This wave was definitely all about expressability more than structured reasoning. I'm talking lispy homoiconic macroy goodness. Later Functional Programming thought was focused in the direction of ML/Haskelly/OCamly languages with a stronger focus on function purity, immutability, side-effect management, type inference, abstract algebra, and static guarantees of program structure and correctness. Sure the ideas existed before, but they're hard to reason about until they're distilled into a paradigm/doctrine. And Functional Programming did that. Like OOP, I think both waves of Functional Programming had a big impact on the programming landscape by introducing and popularizing a new vocabulary to a broader audience. The situational application of them will always come with experience and so every "fad" has the baggage of over application once it goes mainstream. OOP with Java, Javascript's framework explosion, 500 blog posts about monads, etc.

blodovnik 7y ago

So if oo uis so bad, exactly what is better? What should I be programming with?

StreamBright 7y ago
I usually just keep it very lean group a bunch of functions into logical groups and KISS it.
- trilila 7y ago
  In OOP those groups are called classes, and the fun is that you can instantiate them and call them objects. And within those objects you can set a state, so those functions operate against it. A nice feat of OOP is that you can also inherit logic and expand it.
  - blodovnik 7y ago
    Sounds disastrous.
    - trilila 7y ago
      In the wrong hands, it does. Easy to tangle OOP. But the point is each of the two paradigms has its own benefits, and should be used when best for the task at hand.
      - pjmlp 7y ago
        Somehow it seems hard to grasp that at their core classes are basically extensible modules.
        trilila 7y ago
        Indeed. Sometimes tho one just needs to pass a data set to a function, then the result the another, and so on, without the execution branches needed for figuring out the modularity rules and constraints of OOP. And that is where functional programming is relevant (and in math like scenarios, where speed and accuracy are key). But not as a rule of thumb, for everything programming.

trilila 7y ago

I dream of a future where instead of following messianic paradigms, developers follow the mantra of “the most suitable tool or practice for the task at hand”.

julius_set 7y ago
I dream of a world where instead of finding the most suitable tool or practice for the task at hand, developers follow the mantra of questioning those most suitable tools or practices without blindly adopting them
- trilila 7y ago
  Also that.
raducu 7y ago
Developers don't work in a vacuum, it's hard to just use a little bit of that paradigm here and a little bit of the other paradigm there. You do need to plan your career and pick the winning paradigm/stacks because you need to invest significant amounts of time in mastering them.

CyberFonic 7y ago

No paradigm, OOP, FP, etc is "perfect". Yet they are all practical in the hands of competent programmers. Personally I don't particularly like C++, C# or even Java. I have seen way too many dreadfully implemented systems in those languages. BUT it is not the fault of the languages. Bad programmers can shoot themselves in the foot with any language, it's just a bit harder with some but not impossible. In my experience, business applications are all about state. The state of an account, a customer contact, an invoice. Changing state is what messages / methods do. In a well designed and implemented system minimal inheritance gets the job done. And bypassing encapsulation is a big no-no. Polymorphism reduces cognitive load. A toString method should return a meaningful representation of the state of all objects in a well designed system, etc. But fear not, the majority of banks, insurance companies, big business still use COBOL on mainframes. No danger of OOP there. It's all 1960s & 1970s programming with GOTOs and spaghetti code. And yes, those are the systems that manage trillions of "REAL" dollars everyday.

pjmlp 7y ago
Well, they can slowly migrate to OOP extensions added in COBOL 2002. Latest standard revision is 2014.
jddj 7y ago
Completely agree. Some of the most literate, easy to comprehend and maintain, stateful, Gui-heavy desktop apps I've written / worked on have been detailed models of interactive objects, because it was appropriate for the problem. In other problems (the classic web, data processing), it doesn't make as much sense to hydrate this huge, complex ecosystem of objects over and over just to throw it away again, or to end up with functions which are nonsensically bound to what is really just a data structure. Other operations are particularly recursive or parallel by nature and lend themselves to FP at least in part because of the work done in the FP community to handle those paradigms extremely well.
eska 7y ago
Of course a bad programmer will write bad software, no matter the language. But are you not taking this to the extreme? Surely some programming paradigms are objectively worse than others for certain use cases? I've personally come to the realization that OOP is only useful in very niche cases.

mathw 7y ago

I broadly agree, but this article is really poorly written. It takes every downside of OOP to extremes which make it really hard to take the author seriously. Yes there are problems with mutable state, even if you think you've encapsulated it. Yes there are problems with dependencies, dependency injection and the associated boilerplate. Yes there are hideous issues with concurrency. I don't think OOP as we see it in most languages today is particularly helpful. I do increasingly feel that data structures and operations should not be muddled together, and the polymorphism strategy should be something more like Haskell's typeclasses/Rust's traits or Go's idea of interfaces. I'm also sure that using those for a few decades would show us plenty of things wrong, and lead to something else. We are still children in this world. There are no correct answers - but there are definitely some wrong ones, and the increasing realisation of that is evident in the popularity of languages like Go and Rust, and the development of C# is also interesting - increasingly new language features are FP features, not OOP features, and the language becomes increasingly hybrid. It will always be limited by being built on a fundamentally OO runtime, but it's interesting how things are changing.

0815test 7y ago
This article is just not very good, the author keeps talking about a zillion different things without really focusing on the actual, underlying issues. But one thing it does say right away is that mutable state is not a problem as far as it goes, what's problematic is mutability plus promiscuous sharing. This is what makes it unfeasible to reason about what the code is doing. Similarly, encapsulation (bundling code and data) definitely has its uses - in preserving class-wide invariants, or in providing a "common" interface that makes it possible to disregard the inner workings of some data structure, and interact with it in a way that's not dependent on the implementation. But in practice, implementation inheritance in OOP often encourages what amounts to breaking encapsulation and making it possible to violate class invariants, all in search of some dubious "code reuse". If you can't express your desired code reuse pattern via some combination of simple interface inheritance, delegation and dispatch over "sealed", non-extensible variants (the mechanisms that plain old composition/FP gives you) there are probably some underlying problems with it that you haven't thought through. Of course the standards of programming improve continuously over time. Even FP and broadly "FP-like" programming is not what it was in the 1980s, and some of that progress was brought (if perhaps incidentally!) by OOP languages. This is to be expected!

tehlike 7y ago

C++, java and other oop languages have been battle tested, and enabled a trillion dollar economy. Sure, others could do the same, but they didnt. Google, msft uses c++, c# and a bunch of others and they are probably the most complex software developers in the world. It works. Can it be better? Sure. Rust brings safety guarantees, f# enables functional programming mindset, julia is good for data processing. But oop did bring a lot of to market. We are evolving, and our languages will also evolve.

flukus 7y ago
Using an OOP language does not mean OOP programming. There is plenty of java/c++/c# code out there that use classes as glorified namespaces and stick to POCO/POJO objects. From my own experience I'd say that this describes the best and easiest to maintain code in those languages. The hardest to maintain code is almost usually a mess of inheritance and generics/templates by someone far to "clever" that thinks OOP is the goal and not the tool. More often than not an inheritance hierarchy is basically (not literally) an abstraction over if/switch statements, except the logic will usually be spread out over multiple files and it's impossible to track all these potential branches in your head because they're purposefully obscured from you.
- mikekchar 7y ago
  This is a good point, however it also creates code that has no branch points (ideally) and is therefore easier to reason about. It is virtually identical to the situation of passing a flag to a function and branching based on the flag. This leads to a function that is more complex. You can move the branch above the function and write 2 functions, one which handles each case. But these 2 functions are inherently coupled (and may even share code). So it's a tradeoff. The OO style of programming also often moves the decision point. Instead of having an if statement above the 2 functions, you have the if statement at the construction of the object. If you happen to be writing code where you are doing mostly the same things, but certain details change in certain situations, you can group the differences into objects. If you are familiar with pattern lingo, this often happens if you are doing something that lends itself well to a template pattern. You can then use a bridge pattern to ensure that there is only ever 1 branch, instead of adding a decision point every time you want to vary the behaviour. Where I find people (reasonably, IMHO) disagree is that having the decision point at the place where the behaviour diverges allows you to see the logic of the situation right at that point. If you have a bug in the code related to that, then it's very easy to figure out where it is, because all of the logic is local. On the other hand, if you are refactoring the code, or changing the behaviour across the system, then it is very difficult to change because you have to search for all of those decision points. It's also harder to reason about on an architectural scale because it takes discipline (that may be lacking) to ensure that you always do things exactly the same way. You have a lot more flexibility because you can add all sorts of different logic to each decision point. The lack of constraint means that you have to inspect each case to determine if your overall change is going to work. I'll be honest. I like OO. There are a lot of really diabolical ways you can write bad OO code, but there are lots of diabolical ways you can write any code. I'm familiar and comfortable with imperative, modular code. I'm familiar and comfortable with FP. I'm even familiar and comfortable with declarative code (I wrote some large XSLT systems). There are trade offs which every approach. It's easy to see problems in code that you are not happy with and then throw the baby out with the bath water. Having said that, I don't think there is a problem with having a preference of one style over another, but it's a good idea not to fool oneself into thinking that it solves every problem.

barry27 7y ago

Drivel.

cty277 7y ago

Written by someone who... “Guides teams to building reliable software. JS/Node/React.” Enough said

michaelmrose 7y ago
Not really enough. Facile witty criticism doesn't add much to the discussion and lowers the level of discourse. The same thought expressed with enough meat to chew on might provide a worthwhile addition to the conversation but such venears once pierced are often as solid as movie sets. Think more deeply and take time to share.

jayd16 7y ago

>functions provide a level of code modularity and reusability never seen in OOP. Its like this guy has never used an OO language or at least tried to use some FP paradigms in one.

deleted 7y ago

[deleted]

teekert 7y ago

It's blocked for me, I have had 2 free reads... Any tips? I'd actually like to read these, the previous 2 were a let down and I never finished them even. I don't understand, I actually though medium was sort of free (as in beer), who is getting this money?

stevula 7y ago
I was able to bypass by opening in incognito mode as a logged out user.
tiniuclx 7y ago
http://archive.is/yAPEC http://archive.is/yAPEC

dgellow 7y ago

Abstractions and design patterns aren’t what object oriented programming is about, you can change the paradigm and you will still have these (though you will maybe name them differently).

jcelerier 7y ago

> There’s no objective and open evidence that OOP is better than plain procedural programming. Really depends on what is your definition of "OOP" here > Both Smalltalk and Erlang make use of OOP the way it was originally intended by its inventor, Alan Kay. ah, the bad definition of OOP then. Hint : most C apis that look like foo* foo_create(void); int foo_get_bananas(foo*); void foo_print(foo*, int, int); void foo_free(foo**); are OOP, not procedural. They just lack the syntax sugar. > Linus Torvalds is widely known for his open criticism of C++ and OOP. yet he went on doing C++ for user-space code : https://www.youtube.com/watch?v=ON0A1dsQOV0 https://www.youtube.com/watch?v=ON0A1dsQOV0 > Some might disagree with me, but the truth is that modern OOP has never been properly designed. It never came out of a proper research institution as someone who did a phd in a "proper research institution", that's a completely bullshit criterion. > OOP doesn’t have decades of rigorous scientific research to back it up oh come on https://scholar.google.com/scholar?q=object-oriented https://scholar.google.com/scholar?q=object-oriented

0815test 7y ago
>are OOP, not procedural. They just lack the syntax sugar. ADT's/"Object-based" programming (which is what you show above) is not the issue. The biggest problems occur when you introduce non-trivial inheritance/polymorphism.
eska 7y ago
> Really depends on what is your definition of "OOP" here I smell a no-true-scotsman incoming.. >> Both Smalltalk and Erlang make use of OOP the way it was originally intended by its inventor, Alan Kay. > ah, the bad definition of OOP then. Message-based OOP is usually considered to be superior to inheritance by even OOP advocates, and even composition-based OOP by many. I don't see your evidence for "bad definition of OOP". >Hint : most C apis that look like > foo* foo_create(void); > int foo_get_bananas(foo); > void foo_print(foo, int, int); > void foo_free(foo); > > are OOP, not procedural. They just lack the syntax sugar. Not every API that uses a struct is OOP. If your foos use inheritance, virtual dispatch etc, then yes it's OOP. But usually it's just something like a struct to store state instead of having globals or multiple parameters even. >> Linus Torvalds is widely known for his open criticism of C++ and OOP. > yet he went on doing C++ for user-space code : https://www.youtube.com/watch?v=ON0A1dsQOV0 https://www.youtube.com/watch?v=ON0A1dsQOV0 He's a pragmatist first and foremost, and the GUI libraries he uses (Qt) and the programmers that work on GUI code use C++, he said. I doubt he would write his own GUI framework in C++.

millstone 7y ago

So much to critique in this article, but I decided to pick on this: "THE codebase becomes impossible to maintain" "THE codebase becomes too complex and unmaintainable" "What makes THE codebase complex?" I count fifteen references to "the codebase." THE codebase. THE. Well your program consists of more than one codebase! What then? Here's some code that ran on the linked site: window.webpackJsonp = window.webpackJsonp || []).push([[8], { "./config/polyfills.js": function(e, t, n) { Medium (codebase A) dynamically interrogates the API provided by my browser (codebase B) as influenced by plugins (codebase C) linking the UI framework of my OS (codebase D) and then loads some polyfills provided by Babel (codebase E)... Which one is "the codebase?" Your runtime environment is multiple components, each evolving independently! How do you write reliable software here? You can use static types but can't trust them, they can't predict the future and don't know the past. You want runtime interrogation and reflection. You want graceful degradation and dynamic polyfills. You need late bound interfaces. You need objects, not ADTs. This I think is the heart of the OOP idea: software components realized in classes/objects/messages which can evolve truly independently. Drop the "THE codebase" assumption and some of OOP's strengths will appear.

drainyard 7y ago
Are you essentially saying that because you are using libraries you need OOP? If that is what you are saying, that is nonsense.

danielscrubs 7y ago

"OOP is considered by many a crown jewel of computer science". No it's not. It's a crown jewel of programming. What do proper CS-researchers have to do to not be grouped together with pixel pushers? Slap Theoretical on every paper?

boringisnormal 7y ago

I would love to see atleast a few large projects implemented with Haskell/FP before making such tall claims. Large here means few millions of lines of source code and more than 50 engineers working on the same project, a monolith such as a database or a message broker.

danielscrubs 7y ago
“Measuring programming progress by lines of code is like measuring aircraft building progress by weight.” ― Bill Gates BTW: Are you considering Go to be OOP? Like it always is in the programming world everything is ill defined. Go has no inheritance from what I've read.
- boringisnormal 7y ago
  The quote is fantastic and it does bring out an interesting dimension. Not all parts of the code base are equally important. That is for another day. I believe you are missing the context. Allow me to explain. Source lines of code is a proxy to the complexity of the problem in hand. With the assumption that the engineers will not unnecessarily write code just to fill up the code base or pass time, we can safely say that the number of lines of code for a database will be significantly higher than say a networking library. To write more lines of code, we need more engineers. And with more engineers, we uncover a variety of problems. No accomplished Haskell programmer will agree that Go is a functional language. At least the ones that I know don't. I think FP programmers are not in agreement as to what constitutes a functional language, example Haskell vs Clojure vs Elixir.
  - danielscrubs 7y ago
    Simplicity is a great virtue but it requires hard work to achieve it and education to appreciate it. And to make matters worse: complexity sells better. - Dijkstra My point today is that, if we wish to count lines of code, we should not regard them as "lines produced" but as "lines spent": the current conventional wisdom is so foolish as to book that count on the wrong side of the ledger. - Dijkstra The required techniques of effective reasoning are pretty formal, but as long as programming is done by people that don't master them, the software crisis will remain with us and will be considered an incurable disease. And you know what incurable diseases do: they invite the quacks and charlatans in, who in this case take the form of Software Engineering gurus. - Dijkstra

fetbaffe 7y ago

This article is just someone’s frustrated rant, poorly written. Definition of OOP has changed over the years, early on it was a lot of focus on inheritance & polymorphism, but today it is mostly about composition, which is basically what you do in FP as well. New inventive ideas like Go's & Typescript's interfaces flips the relationship between the caller & the callee. Or Rust's traits where you can expand your existing types with new behavior. There is criticism about OOP to be said, but using Java as your strawman to invalidate OOP is not really a good argument, it is just one implementation of many. Edit: removed the word dynamically from description about Rust traits.

0815test 7y ago
I'm not going to defend the article's writing style, but Rust is effectively a functional language with controlled use of procedural-programming features. Not that much different from how Haskell places safeguards on the very same things. (No, I'm not saying Rust today is just as safe or just as elegant as Haskell - far from it! But it can get there with some work.) Even FP is not what it was back in the 1980s and 1990s!
- fetbaffe 7y ago
  Can’t you make the argument that that part of Rust is OOP even though the rest of the language isn’t? Java has added more & more FP style constructs, does it make Java a FP language?
- millstone 7y ago
  What does functional language mean here? Rust is not referentially transparent, does not model effects (any function can rm -Rf your drive), permits shared mutable state (RefCell, etc) includes statements not just expressions (break, return). Its most important safeguard is its affine type system, which is absent from Haskell.
  - steveklabnik 7y ago
    Break and return are both expressions in Rust. Item declarations, let statements, expression statements, and macro invocation statements are the four kinds of statements in Rust.

dandare 7y ago

> Real-world Example, Please! > Real-world example, please! > Real-world example, please! Would it be too much to ask for a REAL real-world example? Unless you are already an expert in both paradigms you (I) have no idea what is the author talking about. How is nullability supuerir in Functional? How is error handling superir in Functional? What is really meant by shared mutable state? (The example with a piece of papaer is equally useless as the explanation that "state is any temporary data stored in memory") How are "erroneous abstractions" promoted by OOP? What is the "low signal-to-noise ratio" How is the state NOT promiscously scatered between objects in Functional programming? How do you make "core parts of your application be stateless and pure" in Functional programming? How is global state "the root of all evil"? Could someone point me to a literature that can explains these questions to someone who don't know the answers already?

eska 7y ago
This may be a useful example for a different approach: http://www.dataorienteddesign.com/dodbook/ http://www.dataorienteddesign.com/dodbook/ Particularly the chapter "Relational Databases" which compares to programming with sets in databases. This book doesn't tell you to program as if you worked with SQL, but draws inspiration from it and makes a comparison.

madiathomas 7y ago

First I was programming in C and I was told C is bad and I must move to a better C -> C++. I listened and moved to C++. Then I was told C++ is horrible and I must switch to modern OOP langauges like Java and C#. I moved more than 15 years ago and I am now very productive when delivering solutions using C# and Java. 15 years later, I am now being told to dump my decade and a half knowledge and competitive advantage and learn a new programming paradigm? Miss me on this one. This time around, I will stick to what I know best. OOP has 80% of what I need and I know ways to deal with 20% of the problems. I will stick to it. It took me only 2-3 days to learn F# but I feel I will be doing my clients a disservice if I have to start from scratch and start delivering solutions to their problems using a programming paradigm that I have little experience with. No. Thank you. I will stick to delivering solutions to my clients using what I know best.

danielscrubs 7y ago
To be frank C# is a wonderful FP language. Try to minimise state (readonly structs helps) and see where it takes you. I recommend all programmers to go a programming paradigm course though.
- madiathomas 7y ago
  I noticed when I was learning F# that it is leaning more and more towards Functional Programming.
eska 7y ago
Congrats, you're old now :) I think as developers we should constantly learn about new approaches. Doesn't mean we need to use them blindly and follow the herd. Sometimes it's also useful to learn something to realize why one should not use it, and how the current approach is actually better.
- madiathomas 7y ago
  That's why I learnt F#. Just to see how functional programming is going to help me deliver solutions faster to my penny-pinching clients. It was an eye-opener but I will still stick to functional programming until FP catches on. If it happens. At age 37, I feel young and really wish that I will still be able to program at age of 50 and beyond.

lincpa 7y ago

Data dominates. the programming moves toward the data. from initial state to final state, the shortest linear distance between two points. Simplicity is the root of fast, stable and reliable. `The Pure Function Pipeline Data Flow`, based on the philosophy of `Taoism` and `the Great Unification Theory`, In the computer field, for the first time, it was realized that the unification of hardware engineering and software engineering on the logical model. It has been extended from `Lisp language-level code and data unification` to `system engineering-level software and hardware unification`. Whether it is the appearance of the code or the runtime mechanism, it is highly consistent with the integrated circuit system. Using the input and output characteristics of pure functions, pure functions are used as pipelines. Dataflow is formed by a series of pure functions in series. A dataflow code block as a function, equivalent to an integrated circuit element (or board)。 A complete integrated system is formed by serial or parallel dataflow. It has also been widely unified with other disciplines (such as management, large industrial assembly lines, water conservancy projects, power engineering, etc.). It's also very simple and clear, and the support for concurrency, parallelism, and distribution is simple and natural. There are only five basic components: 1. Pipeline (pure function) 2. Branch 3. Reflow (feedback, whirlpool, recursion) 4. Shunt (concurrent, parallel) 5. Confluence. The whole system consists of five basic components. It perfectly achieves unity and simplicity. It must be the ultimate programming methodology. This method has been applied to 100,000 lines of code-level pure Clojure project, which can prove the practicability of this method. [The Pure Function Pipeline Data Flow](https://github.com/linpengcheng/PurefunctionPipelineDataflow https://github.com/linpengcheng/PurefunctionPipelineDataflow)

teekert 7y ago

I learned Python about 5 years ago, just for context, I know a bit of bash, some html/css etc. I don't really understand this piece. I use Classes in Python, put them in a module, I also put functions there. Some things are nice as a class, some things are nice as general functions. I like inheritance, otherwise I repeat things. Maybe I need to grow my project and run into limitation before I understand the viewpoints. Maybe anyone has to go through this? Should I feel bad about using classes/objects?

gpderetta 7y ago

"""The venerable master Qc Na was walking with his student, Anton. Hoping to prompt the master into a discussion, Anton said "Master, I have heard that objects are a very good thing - is this true?" Qc Na looked pityingly at his student and replied, "Foolish pupil - objects are merely a poor man's closures." Chastised, Anton took his leave from his master and returned to his cell, intent on studying closures. He carefully read the entire "Lambda: The Ultimate..." series of papers and its cousins, and implemented a small Scheme interpreter with a closure-based object system. He learned much, and looked forward to informing his master of his progress. On his next walk with Qc Na, Anton attempted to impress his master by saying "Master, I have diligently studied the matter, and now understand that objects are truly a poor man's closures." Qc Na responded by hitting Anton with his stick, saying "When will you learn? Closures are a poor man's object." At that moment, Anton became enlightened."""

koonsolo 7y ago

I'm getting sick an tired of all these OOP bashing articles. X is terrible, Y is super! Fact is that everything has benefits and drawbacks, and so does OOP, Functional programming or whatever. The strength about OOP is that it's practically the best to program most software. If you look for example at the SDL library written in C, it uses an OOP interface with handles to keep things nice and simple. Yeah that's right, OOP in C, why would anyone do that? Because it has benefits, that's why. So why is most software nowadays written in OOP? Because it has the most benefits. You can sure find examples where functional programming would be better, but they are a minority. So yeah, next time I would expect an article to properly make a comparison between benefits and drawbacks of both things that are compared. Not the usual "all drawbacks of X, but look at all benefits of Y". This kind of thing screams "Junior alert" to me. Meantime, I'm developing my apps and games and applications in OOP, and absolutely loving it. Wouldn't trade it for anything else in the world.

drainyard 7y ago
SDL having an interface with handles has nothing to do with OOP and is simply the concept of opaque handles. This is often seen in data-oriented code bases where a system behind the scenes is dealing with transforming data in a hardware-oriented and cache optimized manner. Sure the article isn't super well-written, but it raises a fair point and shouldn't just be thrown away. Just because something is the most used or standard does not mean it is the best solution. Eating junk food is very common, but you would hardly argue that it is the best way for a human to get nutrients. You can use OOP all you want, and it's fair to say that the article should have been less biased (though he has a disclaimer that says he is biased), but there is nothing suggesting that OOP is practically the best paradigm to program most software other than the fact that it is the most used.
- koonsolo 7y ago
  There is no doubt that using handles like that takes concepts the same like OOP, such as constructor, encapsulation, object methods, etc. Therefore moving this API interface to OOP would mean a straightforward 1-on-1 mapping. Claiming this has no relation to an OOP setup is therefore not correct. It would have had the exact same interface if it was written in OOP. Maybe we are talking next to each other about what a good programming language is. For me as a professional programmer, it means to sell value. This implies that the companies I work for can make the most amount of revenue. Thanks to free market forces, we can assume that the most "optimal" programming languages survive. Remark that "optimal" is not expressed in terms of aesthetics or whatever, but is purely the productivity of generating money. You can indeed claim that fast food is not healthy, but from a business perspective, it is a success story, and therefore also popular. I don't know how "healthy" OOP is, but it is hard to argue that it is not a business success story. And that is exactly what I offer to my clients. Edit: And to be honest, I would have no clue how I could make the business case for any of the projects I ever worked on for not using OOP. These include games, consumer mobile apps, robotics and various business applications (smart client-server, etc).

kazinator 7y ago

> [OOP] never came out of a proper research institution (in contrast with Haskell/FP). "Out with systems; in with formal languages!" https://www.dreamsongs.com/Files/Incommensurability.pdf https://www.dreamsongs.com/Files/Incommensurability.pdf > I do not consider Xerox or another enterprise to be a “proper research institution”. "Also, I don't consider a paper on systems to be publishable!"

thelazydogsback 7y ago

Smalltalk (which was a revelation to me when I played with it on Tektronics and Lisa) which the author mentions as a "real" OOP language, is actually a good example of a code maintenance nightmare as a is one of those languages that promotes "image saving"-based incremental development in the context of some unreproducable soup of classes. Also its single-dispatch nature (copied by most non-Lisp OOP systems) makes the intended receiver (and dynamic casting semantics) rather arbitrary. Any extremeism/fundamentalism taken too far tends not to work - and oop got just ridiculous at one point. It's also not just the idea, but how it is expressed and the level of abstraction that can be brought to bear. Unfortunately, Java, being a "class-orientated language" rather than an object-oriented one (not my original observation/coinage) and not supporting lambda/closures, etc., was both the reason and solution that we needed these baroque oop patterns in the fist place. (Even C# 1.0 had delegates before proper lambdas and didn't require realized nested inner classes to represent event handlers, etc.) Java's verbose solution to the simplest problems was (is?) frustrating, and is only matched by C++'s complex semantics of copy/assignment/... ctors and value/reference semantics which is more clearly make explicit rather than implicit in a vanilla C program.

thelazydogsback 7y ago

Two other random thoughts... It amazes me that despite the long-ago realization to favor composition over inheritance, that major oop langs only provide direct support for (implementation) inheritance of methods and not delegation. I suppose "delegation in context" has become be purview of DI/IoC add-ons - but direct language support would be nice. While confounded with OOP by many, Generics are probably best treated as orthogonal -- if they had been the primary focus (including higher-kinded types/modules) rather than inheritance, that would have been nice...