- phillips screw drivers are obsolete you should never use them just use torx and throw away anything that uses phillips screws because everybody is doing it. There never was any merit to using one vs the other either, just that people who are still using phillips screws need to get with the times and use torx.
Case against OOP is understated, not overstated (2020)
401–410 of 557 posts
Re: Case against OOP is understated, not overstated (2020)
#402Back in the 90s OOP was touted as revolutionary. The next big thing, would completely change programming. If something wasn't object oriented, it was looked down upon. SQL even got on the bandwagon. It was said that very complex inheritance structures, operator overloading, and all this other stuff would (somehow) make it far easier to write and understand complex projects. Many seemed to have taken and repeated this…
Wait, what’s wrong with NoSQL? It’s not good for shoving relational paradigms into, but it’s basically infinitely horizontally scalable, which, as far as I’m aware, isn’t possible with relational DBs, not at the same performance at massive scale, anyways. A bit annoying when people shove a relational DB into a NoSQL schema though.
Why do you think it's impossible to scale relations (aka tables) to infitine scale? It is totally possible, just look at various analytical SQL-ish DB-likes (Apache Hive, Presto, BigQuery, Snowflake, etc).
Now, what's harder is to provide some of the stronger ACID guarantees, say, fully atomic distributed commits. Most of the time it's just a question of time it takes to reach full concensus in a distributed context.
But this has nothing to do with the relational data model itself, which is just tables of uniform rows referencing each other. Say what you like about SQL, but the core model is perfectly fine.
Re: Case against OOP is understated, not overstated (2020)
#403- phillips screw drivers are obsolete you should never use them just use torx and throw away anything that uses phillips screws because everybody is doing it. There never was any merit to using one vs the other either, just that people who are still using phillips screws need to get with the times and use torx.
Microsoft word is the most sophisticated word processor, people who use nano and vim are just behind the times... you can do anything with microsoft word. you can do anything with microsoft excel for that matter it's turing complete https://www.infoq.com/articles/excel-lambda-turing-complete/
so its realistically the only programming language you'll ever need and it's the right tool for every job because its point and click and it interfaces with the real world so that people can relate to it better and the learning curve isn't as steep.
Re: Case against OOP is understated, not overstated (2020)
#404Earlier quoted context omitted.
I still don't understand why it's bad! Feels like spaghetti sentences tied together as a single article. Why is OOP so bad, anybody? With scenarios, code samples or alternate implementations?
I'm not sure that it is so bad. But I still don't understand why it's good ! Why is it so good? It is said to be better than (non-OOP) alternatives. Where's the evidence for that?
I would argue (my opinion) - OOP smashes together state + behavior. The original reason for this was good: I.e the user of the class(object) should not need to know ALL the internal details etc.
Something like ECS (data-orientated). Very explicit separates DATA(state) and BEHAVIOR (System, Functions, Methods etc).
For me at least it makes it easier and more reliable to "reason" and have a "mental model" about the big-complex system. If I know that for example in a game project ANYTHING with "gravity" is about the ONE Gravity-System(which runs 1x60 seconds in possible sep.thread) and that it Operates(change state) for ALL entities with the "Mass + Pos Components."
Re: Case against OOP is understated, not overstated (2020)
#405I have not read the article but I've seen other blog posts on the subject. The issue with "OOP is bad" is that OOP means different things to different people. Abstract Data Types are sort of a subset of OOP and are massively useful, I certainly don't think it's a good idea to expose the internal implementation of a data structure most of the time. Any sort of plugin system works in an OO matter. It is a useful tool,…
Do relational models support sum types? I find them an essential feature in programming languages, nearly as important as structs or rows.
Unfortunately many don't. Standard Datalog for example doesn't have disjunction which you need to model sum types as relations.
My preference is to have sum types modeled separately from relations as just a complex type that can be related as well. This is the approach taken by Souffle, a C++ Datalog implementation which supports sum types.
Re: Case against OOP is understated, not overstated (2020)
#406Earlier quoted context omitted.
Would you mind explaining this part a little more - I do not get the difference between a Customer class and a customer as a unique entity represented by an ID? "That said, best thing you can learn in your programming career is to get rid of "Customer" classes (or whatever the equivalent is for your particular problem). A customer is a unique entity represented by an ID, a private key if you will, which links data in…
Hi q-base, it all comes down to the single responsibility principle. What is the single responsibility of the Customer class? What methods should it have? What does a Customer do exactly? Or is it just a POD which simply stores customer data? If so which data? Does it mix authentication information with the user's purchase history? Maybe not that but what about the user's little Avatar in the UI? The answer is none o…
What is a POD?
Re: Case against OOP is understated, not overstated (2020)
#407In my mind, state is the real enemy impacting: comprehension, brittleness towards making changes, and the surface area exposed to potential bugs. OOP as frequently implemented, while claiming to encapsulate state, ends up creating so much more. In accordance with this view, I think project architecture should be approached with an emphasis around how much state is necessary for it to run. This is why simulations like…
Sorry, but state is everything. If you don’t have state, then you’re essentially doing useless work computing an answer that is already known. Computation is only useful because of state.
This is a really poor take and you know it. State can exist in functional systems - as results of computations passed to other computations. Recursion where the new argument is the state.
No one was saying "don't use state" they were saying we need to adjust how we use it.
Re: Case against OOP is understated, not overstated (2020)
#408Earlier quoted context omitted.
Hi q-base, it all comes down to the single responsibility principle. What is the single responsibility of the Customer class? What methods should it have? What does a Customer do exactly? Or is it just a POD which simply stores customer data? If so which data? Does it mix authentication information with the user's purchase history? Maybe not that but what about the user's little Avatar in the UI? The answer is none o…
What is a POD?
"Plain Old Data". An OO term for a simple record/struct with getters and setters and no associated behavior.
Re: Case against OOP is understated, not overstated (2020)
#409Earlier quoted context omitted.
Here's a pure computation: import Data.List (nubBy) refuteGoldbach :: Integer refuteGoldbach = head $ [ n | n If you think you already know the answer to this computation, get yourself a Field's medal. And then there are pure functions. Every time you compute a function using an input no-one has tried before, you are probably computing something that is not already known. You do this routinely even with a calculator.
And if you don't store the answer in some kind of state, it's lost and computing the pure function was useless.
In typical functional languages state is managed so that it doesn't hurt, not completely absent.
For example, a REPL keeps state in the messages it prints to the terminal and this state isn't visible in the pure function definitions and expression the program is concerned with.
Re: Case against OOP is understated, not overstated (2020)
#410Earlier quoted context omitted.
I'm not sure that it is so bad. But I still don't understand why it's good ! Why is it so good? It is said to be better than (non-OOP) alternatives. Where's the evidence for that?
I always think the best argument for OOP is avoiding name space collisions - with procedural programs you have a bunch of functions that could be named the same - how do you separate them? OOP gives you the ability to wrap things together - their variables along with the methods that make sense for the objects - little collections of things that go together. Then once you have an object, sometimes you'll want to make…
Isn't that just polymorphism? There are lots of ways to get that.