Learning from the Object Oriented Mania
lemire.me
lemire.me
For the former, then I would expect a computer science professor to do better than just bashing the concept. When is it good, and when is it bad? What did it bring to programming languages?
For the latter, I would expect a computer science professor to know that epidemiology is not their thing and they should refrain from concluding "stuff" from a scientific paper they found.
The point of scientific papers is for experts to share observations with other experts. Given enough studies, a group of experts may reach a consensus. Believing that a single study "proves" anything at all is a big misunderstanding of how science works. A single study "suggests" something, but the goal is to reach a consensus.
In this particular case, a computer science professor who is (apparently) not at all an expert in epidemiology throws sarcasm against an emergency response to Covid-19 for no apparent reason (unless object-oriented was an emergency response to some virus, I don't know).
What this computer science professor could do (but doesn't), though, is bring insights related to their expertise (presumably "computer science"). I mean something other than "object oriented == baaaaad, believe me".
I am pretty sure you understood what I meant: it is a poor take in terms of computer science (which I find disappointing coming from a "computer science professor") that includes unnecessary bashing at a completely unrelated measure.
If that were the case there'd have been no open access movement, and papers wouldn't even exist at all, just discussions in conference halls and private listservs. You also wouldn't need citations because you'd just assume every reader was already familiar with the literature.
The point of scientific papers is to disseminate knowledge and findings as widely as possible. This is the first time I've seen anyone explicitly argue otherwise.
> Believing that a single study "proves" anything at all is a big misunderstanding of how science works
If a single paper is done correctly then it can in fact prove things. History is full of examples like that. Again, the idea that science is all about consensus is just wrong - it's an idea modern academics cling too far too regularly but it's simply not true. Einstein himself said that.
Open access means that people don't need to be researchers at Harvard to have access to science. You can be an expert without being rich or without working in a rich university. I won't address the last part of the sentence because it is preposterous.
> The point of scientific papers is to disseminate knowledge and findings as widely as possible. This is the first time I've seen anyone explicitly argue otherwise.
Sure it is! But the target audience of a paper is quite obviously other experts in the field.
> If a single paper is done correctly then it can in fact prove things. History is full of examples like that.
Well of course, it can happen: a mathematical proof does not need consensus. But a study about the efficiency of masks in preventing Covid-19 is extremely different. If you are not convinced, try to read the study in question. The tone there explicitly shows that there is no certainty: they contribute valuable information, but it's not a definitive proof.
Not to mention that even if we could say today that masks were not effective, it does not mean that back then it was a ridiculous decision. Back then we did not know exactly how Covid-19 was propagating, so it seemed reasonable to wear masks.
It means they don't need to be in academia at all. That is the explicit goal of open access.
> But the target audience of a paper is quite obviously other experts in the field.
It doesn't matter who academics would like their audience to be, the actual audience is anyone who needs or wants to read it. That's why they get given grants and why the open access movement was created.
> Not to mention that even if we could say today that masks were not effective, it does not mean that back then it was a ridiculous decision
Remember that at the start, all the 'experts' were happy to say masks would have no effect! If you dig in and look at why they were saying that, it's because masks would have no effect (and didn't). Their step change came after political pressure to agree to masking both from within and without, which they just immediately acquiesced to apparently due to the strange belief that such things don't have any downsides. All this has been well documented.
I read a lot of mask and epidemiology papers during COVID. They were all terrible. Standards in computer science are much higher, so this belief that Lemire shouldn't be allowed to have opinions is kind of entertaining.
> Remember that at the start, all the 'experts' were happy to say masks would have no effect!
You are oversimplifying. At the start, we did not know if it was propagating with droplets or through the air. Masks do stop big droplets and are effective in that case. It seems like it was not so much droplets in the end, so the efficiency of the masks was limited (but I don't think you can conclude it was zero). But also let's not forget how stupidly people were behaving during the pandemic. It went further than just knowing how the virus was propagating: there was a whole part about people's behavior.
> I read a lot of mask and epidemiology papers during COVID. They were all terrible. Standards in computer science are much higher
Let's be honest: most papers are terrible. Maybe you're biased because you know how to select good papers in computer science (or maybe you understand epidemiology better than computer science :-)), but most papers are terrible everywhere. That's why it takes expertise to make sense of them: if you just blindly trust whatever you read because it looks like a scientific paper, then you're in a bad position.
> so this belief that Lemire shouldn't be allowed to have opinions is kind of entertaining.
I don't have any idea of the quality of Lemire's work. This particular article doesn't show anything interesting IMO, though. Also I did not say Lemire was not allowed to have opinions. Just that when you are in a position of authority (a professor in a university), you should know better than to just throw a link to a paper together with a half-baked opinion.
Good question. OOP seperates software into isolated units called "objects". But in order to function as a cohesive whole, these units have to communicate somehow. And this is usually where the fun begins.
OOP intentionally turns all software into a distributed system --- even if it is not distributed.
Whether there is any real advantage to this is a matter of opinion --- it can't be proven one way or the other. But in my experience with distributed systems, it is often less efficient and more difficult to see and reason about the logic flow and harder to debug and test. Your mileage may vary.
Could you elaborate on that? And would you say for instance that Rust suffers from the same problems? Because Rust offers many characteristics of OOP.
Distributed systems typically rely on messaging passing to some sort of "interface" in order to communicate and coordinate actions with remote nodes. Objects work much the same way and are designed to mimic the characteristics of an independent, remote computer node.
This can be done in any language that offers encapsulation of data, methods and state.
OOP does have a message-passing version, but even though the coiner of the term prefers this version, no one in the industry used it that way.
The industry settled on method calls as the primary channel for these messages, which are most of the way a form of synchronous communication on the same thread, quite far from being a distributed system.
Object `a` calling a method from object b’s public API is not a distributed system at all. And while I do agree that this cohesive whole is not necessarily represented in OOP, one solution is to create an object over the whole, that itself upholds the necessary conditions/order/etc between its subcomponents, exposing only a higher level API to the outside world, and making those subcomponents otherwise inaccessible.
What is the fundamental difference between a 'method call' and a 'message pass'?
In both scenarios, you can be synchronous or asynchronous, blocking or non-blocking, remain on one thread (technically 2 if it's across a network) or fork out into multiple threads. You can wait for a result, or you can fire-and-forget (void). A networking problem is just another kind of Exception.
Even in a typical microservice codebase, it's not immediately apparent from reading the code whether userService.createUser() will call across a network, or just into another class.
The only fundamental difference I can think of right now is that in a non-networked system, you can be pretty sure your static typing holds for the whole program, whereas in a networked system, your types might drift between versions.
But again, more similarities than differences.
Also, Smalltalk and alia of the “real OOP” kind has some extremes with regards to messaging, like the number 3 being told to increase itself by one, which would not be done this way in today’s OOP languages and not just for performance reasons.
Method calls are more of a degenerate case of a distributed system, which is significantly easier to reason about.
OOP turns software into a message passing architecture, which definitely has its advantages if the software you need to write fits well into its compartmentalisation features.
Like you mention (and as with almost anything with software development) it's a trade-off, reasoning about the logic flow can be harder if the design of the OOP software is too convoluted but the same is absolutely true for a badly designed C code with function calls, I don't think OOP itself makes software harder to reason about but it has footguns with its features to make code unreadable through layers of indirection/delegation, badly designed inheritance models (which I tend to avoid nowadays, I really prefer composition over inheritance for most cases), etc.
This is my main beef with OO: a good design will have good clean statefulness, and getting there is completely orthogonal to how much object-orientation you got.
"The lesson you should draw is not that object-oriented is bad, but rather that whatever is the current trendy technique and trendy idea, is likely grossly overrated."
It just felt like it was meant as an analysis: "Learning from ..." and "The lesson you should draw is ...". But that is not what it is.
Why do you think it is a poor take? What are your views on OOP?
It's called "Learning from the Object Oriented Mania", but what did we learn exactly? Would the industry be in a better place if all languages looked a lot more like C? Or maybe Haskell? Does Rust count as OOP or not? Was Object Oriented an unjustified trend, or was it a "natural" evolution of languages?
That last question is actually similar to the mask question: was it indeed stupid to ask people to wear masks, or did it make sense at the time, given our understanding at the time? But the article misses on this opportunity by just bashing at the masks without going any further.
> What are your views on OOP?
My view (which I wouldn't consider informed enough to be a blog post) is that modern languages like Rust mostly drops class inheritance, but other than that they look a lot more like Java/C++ than C. And that's the new "trend": dropping class inheritance, "Composition over inheritance". Which is a fair point: class inheritance can have issues. In some cases it actually does make sense, but languages like Rust decide not to allow it (I guess partly to avoid "footguns" and partly for performance reasons).
But the idea of encapsulation in an object is there in the most popular modern languages. If the concept of calling `my_list.is_empty()` instead of `is_empty(my_list)` is "OOP", then I think it is actually still very much in fashion and for good reasons.
Encapsulation is not specific to OOP at all. C is not OOP and yet it has encapsulation just fine.
> If the concept of calling `my_list.is_empty()` instead of `is_empty(my_list)` is "OOP", then I think it is actually still very much in fashion and for good reasons.
You're absolutely right, it's fashion.
> And that's the new "trend": dropping class inheritance, "Composition over inheritance".
New trend, huh? You realise that that saying came out 30 years ago? It took that long for the brainwashed OOP masses to even acknowledge that inheritance is bad.
I literally had an argument a few days ago with a junior that was dead set on saying that writing single-purpose functions in a C++ namespace was bad. In his own opinion "that should be a class or at least a static member function"...
It's basically as if most developers have a natural tendency to writing all code as if it was Java - because they have learnt so many "patterns" that only make sense in a Java world. The irony is that often they do not realise that Java is not, in fact, a "proper" object-oriented programming language (like Smalltalk for instance), but rather a formalisation of all those quirky hacks C++ implemented [1].
[1]: I recommend "Design and Evolution of C++" by Stroustrup - it's a great insight on how lots of things we now give for granted in "modern OOP" were actually hacks he had to introduce in order to merge Simula's model with C.
minute 54 https://www.youtube.com/watch?v=oKg1hTOQXoY&t=634s
on "The Art of the Metaobject Protocol"
The Cochrane Review has issued a statement about inaccurate and misleading interpretations of the paper linked in the article: https://www.cochrane.org/news/statement-physical-interventio...
It's one error to overhype things and another when we misclassify things like the object oriented codebase using C example from the article.
I don't disagree with your comment in general (I even upvoted) and I'm admittedly nitpicking on a very specific thing.
Did he get refused access to conferences over his anti-mask stance?
We know (proven) that viruses spread via cough, droplets, etc. We know (proven) masks are effective at stopping these droplets. Does the author come into operation theaters and mock the surgeon for wearing a mask, based on that one study he read?
**
From personal experience, I'm starting to notice a pattern when talking to or reading from some "too senior" engineers. They'll just dismiss your concerns out of hand and disregard anything they don't care for as irrelevant, based on their experience in a different context with PHP or Ruby or whatever twenty years ago.
I understand it's good to be able to see beyond the current hype, and notice long patterns, and trust in your own competence; but at some point it goes too far. I hope I won't end up like this.
The push towards "functional" programming mystified me until learning that it's really, really helpful when you've got threads running on multiple cores, which "rewrites the software laws of physics", according to Kevlin Henney. Once I got that, Rust made sense... I hate it, but at least it makes sense.
I get the reasons for preferring immutable data, avoiding globals, etc.. but sometimes you just need the global variable, and have to jump through the hoops to support it.
Note that you could take the article, and replace "Object oriented" with "Functional Programming", and it reads about the same, and it'll be relevant in a decade.
Functional programming on the other hand is better the closer we are to the hardware. It can be more efficient, and in some areas other ways just don't make any sense.
Both are important, and knowing only one structure is definitely bad. But still talking about an object-oriented mania feels like somebody hasn't gotten over the conflicts of 30 years ago.
A problem is mutability. Consider: "Is-a list of triangles a list of shapes?".
Most inexperienced people, using their intuition, would answer "Yes!", and try to design a "ShapeList" base class of "TriangleList", "CircleList", "SquareList"... and then puzzle over where to put the method "void add(Shape s)".
So you end up picking a subset of OO in which you take away inheritance, or mutability ("state"). But take those away and you don't really have OO any more (IMO)...
Even Eiffel got this wrong, fwiw. (https://staffwww.dcs.shef.ac.uk/people/A.Simons/research/pap...)
A couple of years later I was using bash and C on Ubuntu from a CD someone handed me on Stephen's Green. Still better, but no click. C++ and Python ditto. Friends tried to get me into Ruby or Visual Basic but like the other languages they all felt like they were deliberately perverse. Like they knew how thoughts were turned into CPU instructions but wanted you to take the long way around.
The eureka moment for me was reading Learn You a Haskell. I don't code much in Haskell day-to-day, but I think in Haskell constantly now. Strongly-typed functional thinking maps pretty well onto lots of things I use nowadays like Tensorflow. I knew some guys who took a course on Haskell in the final year of their CS undergrad and they found it inscrutable.
All that to say, I really don't like OOP-mania, though of course sometimes a problem is well-suited to an object oriented solution. Learning functional programming from Haskell really open-end my mind, I wonder how much time I might have saved by learning that first.
The problem was that all the students who had just been introduced to programming via Haskell where completely lost when they took the next intermediate programming class, which used Java.
>The lesson you should draw is not that object-oriented is bad, but rather that whatever is the current trendy technique and trendy idea, is likely grossly overrated.
He just happens to want to dunk on OOP at the same time.
I would replace "mania" by "hype". And this is not something new in the industry. Isn't it what's happening with AI right now? How many posts on HN like everyday discussing how to use LLMs to this, that and god knows what other non-sense idea to just use the tech? Looks like we are prone to see nails everywhere when we a get a new hammer on our hands.
I think one of the forces driving hype is "the need to belong". Because as we see over and over, people are cherished when they drum up the hype with them, and labeled wise when they reflect bad and say "we were wrong about this".
On the other hand, you'll be stoned to death if you show the problems early, or will be labeled "old school and backwards" if you find good use of these now-archaic technologies and get good use out of them.
Generative AI
They live in the trees leaving the forest to the "experts".
As a result, they tend to "believe" as much as they reason and will accept "hype" and "opinion" as readily as proven science.
And they do so repeatedly --- OOP, AI, OSS, XML and cryptocurrency are all examples of this. They don't care where the next train is going, just give them a pseudo-plausible excuse and they will jump onboard.
Then to the substance of your points, firstly, there's nothing whatsoever wrong with jumping aboard new tech to see what it's like. As engineers our curiousity should be enough to make us want to do that. The fact that people are prepared to pay money for us to do so is a nice added bonus.
Secondly I have worked with software engineers of all kinds during my career and if you throw 10 different engineers in a room and ask their views on some technology you'll have some n>>1 and probably n>=10 opinions about it. There isn't some engineering hivemind that all thinks the same thing. People who are into a certain thing are vocal about it. If you asked engineers whethere they are into oop, functional programming, rust, react, whatever they are likely to be no less vocal about it than engineers who are into EDM, HipHop, Jazz, Metal or Taylor Swift. People like different things, engineers are people therefore engineers like different things.
Finally, we are in a new discipline so there isn't very much proven science and the way we get there is by experimentation. That means trying tech out and learning lessons from how things go wrong. Until that stage of maturity much of everything is opinion.
Also, adding OSS (and to a lesser degree, XML) to a list of 'hype' product is quite the reach. The first because Open Source is 50 years old and gained ground slowly, and the second because I don't think XML was ever trendy amongst developers. Maybe Ops, sec or management liked it, but devs? I recognize it's qualities but I'd rather hang myself with poorly formatted CSV (even with libraries to generate it: XML is a fucking pain to debug).
Objects are larger than raw data, their this usually means that less data will fit in caches, therefore performance can suffer.
Everyone says that this kind of thing doesn't matter, it.all adds up, and it matters to me.
It's the decision of network effects.
Because that's how we rate things. Not only in programming but generally. Social amplification is a thing that enables fashion industry and advertising in general. Businesses spend tons of resources on ads and media campaigns because they work. "Influencer" is not even a swear word anymore, it's a profession.
Do you really think that programming is somehow safe from the well known effect that affects every other sphere of life?