I'm at the point now where I just refuse to read any Medium post titled "Goodbye, {x}".
Goodbye, Object Oriented Programming
71–80 of 355 posts
Re: Goodbye, Object Oriented Programming
#72Programming 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 "…
Well said. I feel the same way about this as I do platforms. There is amazing projects on every platform. There is horrendous projects on every platform. Taking sides just a narrows your point of view and lessens the amount you can learn.
We have to take sides. If I commit to iPhone, but there's a lot of stuff in android but I can't take advantage of. And vice versa
Re: Goodbye, Object Oriented Programming
#73I 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…
> For instance I have yet to see an easy and simple to use (and as such maintainable) functional widget and gui library. I will continue to shill for Elm[1], like I always do. [1] http://elm-lang.org/
But that's not a library. It forces your whole project into a box in which it may not fit. Elm is not without problems as well, although they (him?) are working on the biggest pain-points.
Re: Goodbye, Object Oriented Programming
#74I 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/IP. The session state store server receives the byte array and deserializes it back to an instance of the class and stores it in an instance of a collection class. Works great. It's really convenient to have all the user's state in just one instance of one class. Terrific.
Encapsulation? I don't know what the OO principles say about encapsulation, but it looks useful to me as a source of scope of names and keeping separate any members in two different classes that are spelled the same. So, terrific: When I define a new class, I don't have to worry if the names of its members are also used elsewhere -- saved again by some scope of names rules.
Actually, I much prefer the scope of names rules in PL/I, but now something as good as PL/I is asking for too much!
But inheritance? Didn't think it made much sense and never tried to use it.
Polymorphism? Sure, just pass an entry variable much like I did in Fortran -- now we call that an interface. Okay. I do that occasionally, and it is good to have.
Otherwise I write procedural code, and the structure in my software is particular to the work of the software and not from OO.
I couldn't imagine doing anything else.
I've seen rule-based programming, logic programming, OO programming, frame-based programming, etc., but what continues to make sense to me is procedural programming with structure appropriate to the work being done. E.g., the structure in a piece of woodworking is different from that in metal working, residential construction, office construction, etc.
Re: Goodbye, Object Oriented Programming
#75OO is one of those things best used in strict moderation. Unfortunately, most people lack moderation, and strive not to necessarily solve the issue, but to show everyone just how smart they are. As a result we get object hierarchies 10 layers deep, and 1000-line source files (or worse, dozens of 100-line source files) which don't do anything meaningful.
Re: Goodbye, Object Oriented Programming
#76Earlier quoted context omitted.
You're making a false equivalence. Functional programming has a strong basis in discrete mathematics that OOP simply does not. This makes it better suited to accurately describing computation at a high level than OOP. However, you probably arrived at this conclusion because you still see programming languages as having intrinsic paradigms and those paradigms meaning anything about computation. The fact of the matter…
I came to this conclusion because as soon as a paradigm becomes popular clueless people who don't really understand the foundation will start using it. Then you have consultants popping up who don't know much either but come up with slick patterns to sell. This happened with OOP and will happen with FP. Functional programming is not that easy to do right in the real world. It takes some level of abstract thinking and…
Yes, but the foundation under OOP is considerably less solid. I agree that you can write a bad program in any language, but the fact remains that it is impossible to write certain bugs in statically typed pure functional languages and that functions as a base abstraction are more apt for describing computation than objects are.
Re: Goodbye, Object Oriented Programming
#77Interesting. I almost though this was going to be an advertisement for Swift, since I saw this exact argument in a WWDC talk. Apple calls Swift a "protocol-oriented" programming language, and with the addition of first class value types, tries to solve these problems in their own way. I'd definitely suggest people frustrated by the problems outlined in this post to check out the Apple talk on protocol-oriented progra…
Even before Swit apple advocated composition over inheritance.
Alas, when teaching programming and OOP somehow inheritance comes up as the most important and interesting part, so few learn proper architecture and a doomed to write articles like this.
Re: Goodbye, Object Oriented Programming
#78Earlier quoted context omitted.
You're making a false equivalence. Functional programming has a strong basis in discrete mathematics that OOP simply does not. This makes it better suited to accurately describing computation at a high level than OOP. However, you probably arrived at this conclusion because you still see programming languages as having intrinsic paradigms and those paradigms meaning anything about computation. The fact of the matter…
You mean lambda calculus? That model has plenty of shortcomings. Someone recently pinpointed the problem for me. Complexity analysis is impossible in a system that is inherently unaware of time and computational cost of transition rules. Lambda calculus is inherently timeless (both in the theoretical sense because of turing equivalence and the practical sense of being unable to provide a proper framework for complexi…
So you list one shortcoming, and don't even cover the position that lambda calculus is better suited as a foundation for a programming language despite not being better at time complexity than a Turing machine would be?
http://cstheory.stackexchange.com/questions/21705/what-is-th...
My point is basically made here:
This algebraic view of computation relates naturally to programming languages
used in practise, and much language development can be understood as the search
for, and investigation of novel program composition operators.Re: Goodbye, Object Oriented Programming
#79I 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…
This is a good point. Functional is a really useful model for mostly stateless data processing. When you have lots of state that needs to be mutable, not so much.
Re: Goodbye, Object Oriented Programming
#80Earlier quoted context omitted.
You mean lambda calculus? That model has plenty of shortcomings. Someone recently pinpointed the problem for me. Complexity analysis is impossible in a system that is inherently unaware of time and computational cost of transition rules. Lambda calculus is inherently timeless (both in the theoretical sense because of turing equivalence and the practical sense of being unable to provide a proper framework for complexi…
So you list one shortcoming, and don't even cover the position that lambda calculus is better suited as a foundation for a programming language despite not being better at time complexity than a Turing machine would be? http://cstheory.stackexchange.com/questions/21705/what-is-th... My point is basically made here: This algebraic view of computation relates naturally to programming languages used in practise, and muc…
This is the usual response. I didn't say the algebraic approach does not have advantages but the complexity analysis issue is always swept under the rug by proponents of the algebraic approach. Operational and axiomatic semantics also have their place and if the theoreticians haven't yet settled on "the one true way" why is it that regular programmers think they have?
I agree that the search for novel composition mechanisms is a prominent goal of PL theory and research but it is not the only one.