Is it a poor take against object oriented, or some half-hidden criticism of the use of masks during the Covid-19 pandemic?
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.
No. That would be "popularization", I believe, and that is not done by scientific papers.
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".
University libraries should take journals out of the main library and move them to the relevant departments, we'll put a stop to this interdisciplinary nonsense (A sociologist reading an engineering journal, imagine!)
What you are doing here is called manipulation: you rephrase what I said ("a computer science professor should not throw a link to a study as a justification for unnecessary sarcasm in an article with an authoritative tone") and push it to the extreme ("universities should forbid people to read articles in domains where they are not experts").
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.
> The point of scientific papers is for experts to share observations with other experts
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.
> If that were the case there'd have been no open access movement
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.
> Open access means that people don't need to be researchers at Harvard to have access to science
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.
Open access means "people should not have to pay to access science". It does not mean that a 10 years old should be able to understand it all. I think we agree on this, I am not sure what point you are trying to make.
> 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.
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 intentionally turns all software into a distributed system
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.
I think there's more in common than you give credit for.
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.
I think the similarity is more like a mathematical/structural one, and doesn’t hold much water in a pragmatic sense. The possible error conditions for a network call are just insanely bigger than of a function call.
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.
Distributed systems have other issues that are unrelated to message passing. Message passing is just a protocol for them to communicate but it's not what creates most issues with distributed systems like networking, state management, etc.
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.
OOP implicitly says it is ok to have stateful information all over the place in your code: if it's in an object, then it must be OK...
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."
I think it is a poor take because it says almost nothing and it justifies nothing. It could fit in a tweet: "Beware of hypes. Oh and I was against masks during the pandemic".
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.
> But the idea of encapsulation in an object is there in the most popular modern languages.
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.
As with XML, OOP has its uses. I still use XML to mark up files. It's a great technology, which looks just like madness in JSON. And whenever you do simulations there is nothing better than OOP. Ideas spread like viruses, this insight is around since the 70s, starting from the Salk institute.
Software developers are highly trained and conditioned but poorly educated.
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.
I think you are generalising wildly here. My prior is that human beings are prone to hype and opinion in general. You'd need to provide some evidence that software developers are different from that in some important way for that to be significant.
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.
Clearly you don't know a lot of software developers. Or maybe you're right and I'm just lucky each time with my coworkers.
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).
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.
Yes, hype is a better world, and is no way new. I also agree with the author about its harms.
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.
I dont really see this article as a good one. He doesnt really mention the bad parts of OOP. And i dont see alternatives. I only read that people jump on trend trains. Well not everyone i can say.
>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.
My point of view regarding this topic is that Students tend to understand objects better, because it's how we perceive the world (I often work with art students in game design). If they'd have to find data related to each object in a list, they'd fully overwhelmed.
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.
"Students tend to understand objects better" -> I actually a disagree.
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)...
I know I'm not typical, but my experience was the opposite. The first language I formally learned was Java about twenty years ago. I remember asking gaijin teacher hundreds of questions because I just didn't "get it". I had a better time with random old-school languages I stumbled across, like batch scripts, php, and actionscript but nothing really clicked.
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.
My university taught Haskell in their intro programming class at the mathematics departments, and the students that were new to programming had on the whole no problem with it. The ones that struggled were the ones that knew a bit of programming and had to relearn a bunch of what they thought they 'knew' about programming.
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.
I'm struggling to observe a problem programming the world as we see it.
In Many cases it will be better, in Many cases not. At the end, the use of an OOP language is a the decision of a good professional.
When people fail to see that these paradigms are tools and every problem needs its own set of tools (or choices) to solve the problem the best way possible, we get these posts about how things are bad and backwards and unusable for anything and everything.
The problem is not with the programs representation , although even that can be a problem. The problem is that your software needs to run on hardware which has real performance and behaviour.
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.
I'm an infrequent programmer, of the Turbo Pascal and descendants kind. The OOP I learned was only used to deal with GUI elements, or perhaps databases, but not for each and every line of code ever. I've always felt this was the appropriate use for it. Like ingredients in food, you need balance.
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.
A professor in software performance who surprisingly doesn't consider himself a figure of authority rants about sociology and epidemiology, using a specific corporate fashion trend as a starting point.
Did he get refused access to conferences over his anti-mask stance?
sure object oriented paradigms were taken to an extreme, much like the AI mess we have to wade through now, but then the author goes and links some research paper pushing his agenda of masks not helping to control/contain viral outbreaks. gimme a break, why do we have to share a planet with these people. theyre everywhere.
The students used to get brainwashed about the advantages of object oriented programming at the University of Oslo. Two of the professors had coined the term object oriented programming, and created a programming language called simula. Simula was the first programming language with reserved words like "class". It took me many years with functional programming in react, to abolish the thought that oop was the only way to write clean and robust code.
Programming in JS using React has a lot of funtional-like aspects that are very helpful and practical, but I would kindly and humbly suggest that we shouldn't call it functional programming.
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.
I can second the central thought: "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."
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?
This. The obsession for object oriented in the '00s has made immense, irreparable damage to an entire generation of developers. I have to fight every day to keep our codebase sane against new entries that are still following that cargo cult that "everything must have an interface".
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.
I have never programmed in Smalltalk, however apparently Common Lisp Object System (CLOS) is similar. Object oriented programming in Java always seemed like a tone of unnecessary boilerplate just for the sake of making classes and interfaces (phone apps are a big example of this where even the simplest apps are waaay more complicated than they need to be), until I started using CLOS. Common Lisp also has macros and even a pure functional environment a-la ML, however all these paradigms are used quite sparingly in the community
Nice article about not following the hype. Being contrarian, it is not likely to get very many likes (everyone is so protective of their hype). Does not make it wrong.
"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."
The jab at mask-wearing during the pandemic is off-putting and senseless. The author even mentions "side effects" which aren't in the linked article at all. (if you're having side effects from wearing a mask, you're in dire health already)
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.
58 comments
[ 5.2 ms ] story [ 132 ms ] threadFor 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.
https://www.bitecode.dev/p/hype-cycles
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).
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.
>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.
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.
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.
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.
Did he get refused access to conferences over his anti-mask stance?
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.
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?
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"
https://www.adamtornhill.com/reviews/amop.htm
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...
Generative AI
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.