I've enjoyed OOP more than anything else. The real issue here is that these pillars are but low-level building blocks. To fully take advantage of the OOP paradigm, you need to take a look at DESIGN PATTERNS. They'll solve (almost) any issue mentioned here. That is, if you know how to apply them, the right way, at the right time (just like everything else in this damn world).
Goodbye, Object Oriented Programming
141–150 of 355 posts
Re: Goodbye, Object Oriented Programming
#142Earlier quoted context omitted.
The self-descriptions people use these days are so ludicrous it's hard to tell if it's satire. If I had a Medium account, here's how my description would read: "Software Engineer, Philanthropist, Astronaut, Shark Hunter, Breaker of Chains, Lord Commander of the Snack Bin, Protector of the Repo, and Part-time Cat Dad" Too much or just right?
'Part-time Cat Dad' doesn't sound plausible to me --- everyone knows that owning a cat is a full time job. And as for 'Protector of the Repo'... basically what you're saying is that you're a repo man?
part time cat dad is totally plausible. my wife has three cats.
Re: Goodbye, Object Oriented Programming
#143I find many of the objects in .NET very useful and use them in my code. Also in my code I define and use some classes. I like the idea of classes. E.g., in my Web pages, I have a class for the user's state . When a new user connects, I allocate an instance of that class. Then I send that instance to my session state store server. To do that, I serialize the class to a byte array and then send the byte array via TCP/I…
What were the benefits of PL/I scoping vs others?
Get two kinds of essentially nested descendancy, static (from the source code) and dynamic from execution as make calls but from which have not yet returned. It's good to think about both at the same time. The push down stack of dynamic descendancy defines what parts of the code are active and, thus, can be called. E.g., the names currently known by inheritance are from the dynamic descendancy working through the static descendancy. And, then, can call code back in dynamic descendancy that is still known from the static descendancy.
Wow! It's simpler than that: Can have BEGIN-END as a chunk of code with its own names. Any name used inside there but not declared there is inherited from the code that is active (in dynamic descendancy) and in the static descendancy.
E.g., can have ON CONDITION X; BEGIN; ... END; and execute that. That execution just says that, in the future, if see RAISE X, then execute the code in the BEGIN-END. Then that code can do GOTO Y where Y is a label known in the BEGIN-END block and in code in the dynamic descendancy. If the code of Y is 11 steps back in the stack from the RAISE, then all the 10 lower levels of code are exited. Lots of cleanup happens automatically.
So, the ON CONDITION is executing code back in the stack of dynamic descendancy -- darned cute. And can do such things quite generally.
So, code block A can have an internal subroutine B, call C, pass an entry variable to B, and the code of C can call B. B then can have values inherited from the code of A and use those values as B executes from the call of C. Did that once when scheduling the fleet for FedEx!
Once in some AI work at IBM's Watson lab, used a fancy case of that name scoping to save our project a few weeks of work and improved the quality of our product. Got an award for that!
That's a fast outline -- maybe not fully clear. Any questions?
Re: Goodbye, Object Oriented Programming
#144Programming paradigms are a lot like political parties -- they tend to lump a lot of disparate things together with a weakly uniting theme. You don't need inheritance for encapsulation to be useful, for instance. The problem is, sometimes you agree with only a small part of the platform. None of these things individually are terrible ideas if tastefully applied, but it all gets clumped together into one big blob of "…
> Programming paradigms are a lot like political parties
And this comment is just.. politically correct.
Re: Goodbye, Object Oriented Programming
#145God damn it I begin to hate Medium. Just another Bullshit article. When I read those dips ts description: "Software Engineer and Architect, Teacher, Writer, Filmmaker, Photographer, Artist…" Great. And you want to tell me that OO is dead and functional the only future? Fuck off.
Well, I don't know much about the photographer and artist tags, but he was credited as writer on a few movies.[0] The "teacher" bit may be because he ran a training session somewhere, or was a TA or tutor at some point.
But, yeah. I agree with you.
Re: Goodbye, Object Oriented Programming
#146Earlier quoted context omitted.
Except that there is a real advantage to using pure functional programming; being able to easily prove theorems about your code and understand different components in isolation. There is a reason why the majority of proof assistants are implemented as functional languages. Most functional languages even give you ways of modelling imperative code (e.g. monads) in a way which hardly sacrifices expressiveness. The real…
The real disadvantage of pure functional programming is that it is notoriously difficult to use and thus only very few programs outside specialized domains are written in them. For example I would guess that in a typical enterprise (say, a manufacturing company), 0.0001% of the software is written in a pure functional language. Things OO languages 'force' us seem to be relatively easy to use: sending a message to a c…
I would argue this is inertia and a hype train that never slowed down -- up until the last 2 or so years that is.
I do agree with you that thinking in FP takes a bit more experience however.
Re: Goodbye, Object Oriented Programming
#147I think the functional vs OO debate is being done with a very narrow point of view. Functional came before OO and there are reasons why it became much more popular- it had much better, easier and simpler solution to the most common problems of the 90's and early 2000's, namely handling GUI and keeping single process app state (usually for a desktop app). It fares much worse in today's world of SaaS and massive parall…
I don't have any idea what you're talking about when you say 'functional came before OO'.
I'm guessing you are talking about Lisp, but not only are Common Lisp (and the languages it evolved from) not at all functional in any technical sense of the word, many of them only had dynamic scoping, and often used mutation of data structures implicitly.
Stop talking nonsense.
EDIT: If you are talking about scheme, then the same exact points apply. On top of all of the above points, nobody in the world other than a few extreme language-philes ever use any of the functional languages, and for good reason. Functional programming is nonsense, the only people that talk about it are academics and people who want to seem smart. Functional != Structured Programming, Functional != Procedural, 'functional' has a precise meaning: treats computation as the evaluation of mathematical functions and avoids changing-state and mutable data. Neither Schema nor Lisp nor any but a very few quite obscure languages satisfy this.
Re: Goodbye, Object Oriented Programming
#148Most of the problems he brings up are already addressed in major OOP languages. 1) Inheritance can be confusing and messy. Yes, hence the advice: Prefer composition over inheritance. Instead of having B inherit from A, declare an interface I, and have both A and B implement I. If B wants to reuse A's functionality, it's free to do so through composition, and not through inheritance. There are some edge cases where in…
The argument about encapsulation was the most confusing for me. I do not see where the problem is in the example he gives: either you want an object of class A to be used by multiple objects (of different classes possibly), and we have no problem, or you want every instance of A to be used by one and only one instance of some class B, and in that case like you said either you make a deep copy / create the object inside the constructor instead of passing it around. (if no state is needed)
I guess he does make a point about inheritance and how confusing it can be, but like you said OOP still has value outside of inheritance.
Re: Goodbye, Object Oriented Programming
#149Earlier quoted context omitted.
That is a good analysis. While I was reading this article all I could think is "You wanted to do things in a bad way and then you learned how to do it the right way and you don't like the right way?" His entire problem seems to be he thought OO was a magic bullet he could do whatever he wanted with and then he learned there was more to using OO than the three concepts he cites at the beginning. And this guy has suppo…
> And this guy has supposedly been writing in OO languages for decades? What? This is the bit i don't get. It's like he learned OOP in the '90s, when everyone thought inheritance was rad and nobody had realised how terrible mutating shared state was, and then fell asleep for twenty years. None of this article, none of it , has any relevance to how OOP is practiced by informed people today.
> It's like he learned OOP in the '90s
Well, if he's been doing OOP for decades, isn't that likely to be the case?
Re: Goodbye, Object Oriented Programming
#150Programming paradigms are a lot like political parties -- they tend to lump a lot of disparate things together with a weakly uniting theme. You don't need inheritance for encapsulation to be useful, for instance. The problem is, sometimes you agree with only a small part of the platform. None of these things individually are terrible ideas if tastefully applied, but it all gets clumped together into one big blob of "…
Except that there is a real advantage to using pure functional programming; being able to easily prove theorems about your code and understand different components in isolation. There is a reason why the majority of proof assistants are implemented as functional languages. Most functional languages even give you ways of modelling imperative code (e.g. monads) in a way which hardly sacrifices expressiveness. The real…
There are things that are painful to express in a pure functional language. I'll give you an example: rasterize a triangle to a mutable buffer. (An inherently mutable and stateful algorithm). You can certainly do this in a purely functional language, but I doubt it will be any clearer or more performant than its procedural C counterpart.
I think pure functional programming is super useful in other contexts, for instance, a compiler. I'm weary of people suggesting that a specific school of thought is universally applicable, though.