20 Hacker News comments link this video. Each one links back to its thread.
jmulhoDec 2019Strongly recommends
Looking at your top priority books I recalled a slide from one of Brian Will's videos on object oriented programming: "Object Oriented Programming is Bad" ▶ this video . At around the 43:51 he pulls up a slide picturing several of these (and similar) books. Here is a rough quote: "I can tell you from personal experience of having read these books that you don't need to read them. They don't have answers, they aren't going to square the circle, and you are going to waste productive years of your life trying to live up to their ideals." Now that is just one rather controversial opinion, but we are talking about potentially wasting productive years of your life so I wanted to let you know that opinion is out there. That being said, it would probably be hugely beneficial to read a few of those books and then watch a few of Brian's videos (he has three or four on the topic) and sort out your own opinion. Also, Brian's other (not controversial) videos (dozens) are excellent for learning about programming. Also, Steve Krug's Don't Make Me Think is a keeper. I thought of it last night when I was checking out at a store. I stuck my debit card into the thing, entered my PIN number, then clicked the big blue button that said "Skip PIN". The woman behind the counter said "don't worry about it; everybody does that!"
in “Ask HN: Books you plan to read in 2020?” · View on HN
ryanmarshNov 2017Strongly recommends
Code should be written first and foremost for humans to understand, and incidentally for compilers to understand. [link] If we can all agree about that then we have to ask ourselves if encapsulating data and behavior at the granularity of classes makes the most sense for human comprehension. In naive OO examples (Animal -> Cat) it does. In practice however, it's debatable (at best). I highly recommend this video by Brian Will who does a much better job explaining this problem than I could. ▶ this video Douglas Crockford also does a good job of explaining some of the trouble with classes. [link]
in “When I use classes, when I don’t, what I do instead and why” · View on HN
DeathArrowMar 2022Recommends
I think this is a valid critique. But then, most of the development (C aside) has been a victim to OOP. I have begun to think that OOP creates more problems than it solves. Added complexity and performance loss being the biggest. It's insane if you peek into a big projects where many developers came and went and each of them read an article about what it seemed an interesting design pattern and tried to implement them. You can have some kind of procedural programming if you use classes just to store data and use static methods. But the frameworks are OOP and there is no way around that unless you write your own frameworks. I am a big fan of Mike Acton's Data Oriented Architecture speeches, but I didn't find a way to implement something similar in C#. For those interested in something better than OOP, here's a few links: [link] ▶ this video [link]
in “.NET Myths Dispelled” · View on HN
Show 14 more comments
cloogshicerMar 2022Recommends
That's fair - I'm not against abstraction in general. I agree that we wouldn't be able to handle the essential complexity of software without it. I'm just saying that each abstraction also has a cost, and makes understanding the whole thing more difficult. Abstraction is, in my understanding, a necessary but costly tool. A lot of my thoughts are summarized well by Brian Will in this video: ▶ this video
in “The Big TDD Misunderstanding” · View on HN
cxrJun 2020Recommends
At the risk of putting readers off by the title, there's a video essay on YouTube called "Object-Oriented Programming is Bad"[1]. It's both thoughtful and thought-provoking, although I don't agree with the conclusion. Steve Naroff (from Stepstone/NeXT/Apple) did a recent-ish set of interviews with the Computer History Museum[2][3] and referenced that video a bit (and extemporized about objects in small parts throughout). Side note: Naroff and Brad Cox are set to present a paper on Objective-C at this year's HOPL[4]. I wish it were as readily available as Allen Wirfs-Brock's JS paper for the same conference[5][6]. 1. ▶ this video 2. [link] 3. [link] 4. [link] 5. [link] 6. [link]
in “Design Principles Behind Smalltalk (1981)” · View on HN
crimsonalucardDec 2019Recommends
This isn't about OOP vs. FP. This is about OOP vs. everything else. Rust, Go and javascript are three languages that are moving away from the OOP paradigm. None of those three languages are classified as functional. >Is there some resource you can point to that says in the past when faced with situation X developers tended to use pattern Y, these days that has been superseded with way of doing things Z? No. A general trend is an anecdotal observation. Still a quick google search yielded: [link] Take a look at the following video: ▶ this video While I don't agree with a lot of it, I think it sums up my opinion really clearly. It's not about DP's but because DP's focus around OOP and the video is a criticism of OOP therefore the arguments apply to DPs.
in “Ask HN: Books you plan to read in 2020?” · View on HN
lazulicurioOct 2019Recommends
There was an article on state in OOP posted here a few days ago that I found very thought-provoking[1]. The blog post and related youtube videos are pretty interesting as well[2][3][4]. [1] [link] [2] [link] [3] ▶ this video [4] [link]
in “Why Isn't Functional Programming the Norm? [video]” · View on HN
NegatioNMar 2017Recommends
Prodcedural code can also be well compartmentalized and tested. I was also until recently quite convinced OOP was the only way to go, but I'm seeing signs everywhere that a lot of the design-problems I've met over the past few years are at least magnified by OOP. The abstraction promised by OOP is a good thing, however very few people are able to consistently make good, reusable and maintained abstractions. To the point where it becomes a weakness rather than a strength. I don't want a billion wrapper-objects that obfuscate my code, and makes the surface area of it bigger than it has to be. Often I struggle understanding code more because of how it was separated, than because of the complexity of what it actually does. I liked Rich Hickeys talk "Simple made Easy" [1] and "Brian Will: Why OOP is Bad" [2] [1]: [link] [2]: ▶ this video
in “How we secretly introduced Haskell and got away with it” · View on HN
hackitsMar 2017Recommends
One of the video that can articulate the whole thing better than me is ( ▶ this video ) It was a long winded written rant. I still use OOP but its more or less glorified name spaces with functions. Today I rather work on procedural code than OOP code. It may have bugs, it may have their own little quirks but its like a old rusted vehicle that still keeps going.
in “Principles for C programming” · View on HN
thunderbongMar 2016Recommends
Previous videos Object-Oriented Programming is Bad ▶ this video Object-Oriented Programming is Embarrassing: 4 Short Examples [link] I'm watching the 'is Bad' one, and honestly, it rings too close to my experience. Need to think about this a bit more deeply!
in “Object-Oriented Programming is Garbage: 3800 SLOC example [video]” · View on HN
muixoozieFeb 2025Cites it
Lol Reminds me of Brain Will's ▶ this video he has a series basically ranting about this. One of them he goes into examples simplifying needlessly abstract code.
in “Do-nothing scripting: the key to gradual automation (2019)” · View on HN
imbnwaJul 2022Cites it
I find an uncanny correspondence between the recommendation given here, following as it does from an interpretation of the Agile manifesto, and Brian Will's procedural programming recommendation contra OOP in his classic 'Object-Oriented Programming is Bad'[1] [0] ▶ this video
in “Why long-term plans don't work and how to fix them” · View on HN
zackmorrisNov 2021Cites it
Engineering within the wrong paradigm can kill your product. I see far more problems on a day-to-day basis with patterns and anti-patterns taken too far. For example, I never use the factory pattern, because it leads one down the Java road where everything ends up an object with mutable state. Which isn't scalable over some metric (like a million lines of code) because a human brain can't trace execution, even with a debugger. A far better pattern generally is to take a functional approach of accepting data, swizzling it, and returning the resulting data without mutability or side effects. Another really bad pattern is when execution suspends and resumes somewhere else (goto hell). Any project which uses queuing, eventual consistency, promises, nonblocking streams, even basic notifications or things as complex as monads will encounter this nondeterminism and inability to statically analyze code. Note that pretty much all web development suffers from some aspect of this due to its async and multi-signaling nature. So what I do now, which I don't see much these days, is solve problems abstractly in a spreadsheet (pure functional programming), in the shell (the Actor model) or as a flowchart (declarative and data-driven design), and then translate that to whatever crappy language/framework I have to use for the project. I find that today, roughly 90% of developer effort goes to discovery, refactoring and testing of ill-conceived code. Only 10% is "actual work" and that's probabl
in “Overengineering can kill a product” · View on HN
nooberminJul 2019Cites it
I'm not a systems designer, so I am somewhat ignorant to make this statement, but this sounds almost like "nouns-first" is the right thing, but almost every single one of those people cited in the article are anti-oop people. Moreover, OOP has generally fallen by the way side and been blamed for unnecessary complexity in some legacy systems from the 90s/00s. The moment you conceptualize your system as the interaction of concrete data types, OOP starts to seem like a logical paradigm to choose. May be this is just in my head because I recently discovered this talk (ignore the incendiary title): ▶ this video
in “Data Still Dominates” · View on HN
RumperuuMar 2019Cites it
Brian Will of “Object-Oriented Programming is Bad”[0] fame presents ‘a positive case for an alternative’, or a ‘prescription for how code should be written, rather than how it shouldn't .’ [0] ▶ this video
in “Object-Oriented Programming Is Good*” · View on HN
fogettiDec 2018Cites it
You are implying that the causation goes like this: redux good -> so the app will be good too. And to make a case in point you are trying to make an argument that because many apps are poorly designed, everyone should use redux. You really can't see how fundamentally broken is your argument? Really??? And you are not the only one who makes this HUGE fallacy. All the redux/react fanboys are like you. At this point I already consider those people who make these arguments that they are just following/using redux because it's a religion for them. Not to mention the fact that some people considers the whole uni-directional message flow a HUGE antipattern. See: ▶ this video
in “Why Do React Hooks Rely on Call Order?” · View on HN
fenesiistvanFeb 2016Cites it
Brian Will says that that whole OOP concept is bad (not to say about C++ which is OOP in the ugly way): ▶ this video
in “Why I haven't given up on C++” · View on HN