This is a rant and therefore not really full of useful information. If you like rants about OOP then you might like this post.
However I use OOP all the time despite being something of a functional programming nerd. Most of the time when I use OOP its for one of the following uses:
An easier to understand closure. All the state that the methods rely on are defined in the class not grabbed from the environment. This can be cleaner. I will frequently make the class internals immutable when this is my purpose.
Defining interfaces. A class is a convenient way to group things. An interface is a convenient way to say what grouping you require or expect. This is often an aid to understanding code.
The crusade for or against OOP/Funtional is tired at this point though. I think for any developer who moves beyond framework glue coding what our industry cares about are the component ideas of each. Immutability, Encapsulation, Liskov Substitution, others I won’t bother to list here. You may learn about these ideas in OOP or Functional approaches but you eventually you learn that what is actually important are the component concepts not whether your code is OOP or Functional.
Yeah sometimes you need to abstract data and state, and sometimes you don’t. It’s really as simple as that.
It’s kind of like the JSON vs. XML/HTML debates, which I always thought were stupid. Sometimes you have more data than text – use JSON. Sometimes you have more text than data – use XML/HTML.
It’s silly to encode objects as XML, just as it’s silly to encode documents in JSON. (Not to say every instance of it is wrong, but it’s awkward.)
Likewise there are some problems where it’s obviously silly to use OOP – every AST written in an OO language is unabstracted data, not objects. Martin Odersky even mentioned this experience with an OO AST and it was a mistake.
On the other hand representing various elaborations on a stack is completely natural in OO (and I use this all over Oil). It’s state that has a limited interface. Splitting a string on a delimiter is awkward and inefficient in functional programming. Use a state machine and don’t generate so much garbage, etc.
I hate to bring out this platitude, but “use the right tool for the right job” … IMO all programmers should be familiar with both styles and use them as appropriate.
On the other hand representing various elaborations on a stack is completely natural in OO (and I use this all over Oil). It’s state that has a limited interface. Splitting a string on a delimiter is awkward and inefficient in functional programming. Use a state machine and don’t generate so much garbage, etc.
I’ve wondered how much default data structures in functional programming are hamstrung by pattern matching. Pattern matching very beautiful and feels very natural (and I absolutely love it), but it fundamentally ties code execution to the structure of the data. As a result, you might end up using suboptimal representations because they work well with pattern matching. As you allude to above, linked lists are suboptimal for a lot of string operations, but linked lists work wonderfully with pattern matching.
OO, on the other hand, is about encapsulation. By default, people will do things that provide performance benefits. E.g., updating the length of a collection on each insert/deletion rather than traversing the entire collection on each call to length. It ends up making the code more complex and stateful, but it makes some operations more efficient.
I think having some user definable form of pattern matching may push functional programmers towards using better default data structures. Effectively, it would be a new form of encapsulation for in functional programming. Currently, I only know one programming language that has extensible pattern matching (Egison), but I haven’t used it and don’t know how effective it is.
Anyways, I agree with you. OO (technique | culture | design space) has it’s uses. This is mainly an overlong tangent on a relatively minor point.
While I kind of, maybe agree on the FP nature going against best structure of the data (it’s more nuanced then this) …
OO, on the other hand, is about encapsulation. By default, people will do things that provide performance benefits.
… this is absolute not the case. Quite the opposite. Dogmatic OOP (and encapsulation in particular) are typically even worse performance offenders. Just so I don’t have to repeat myself, you might waant to peak at this rant.. Having said that - since OOP doesn’t have really an exact meaning, any software written with data-oriented architecture mindset, where authors understand a difference between value types (plain data) and objects, and employ actual meaningful coarse-grained objects, can have a stellar performance and be considered actually OOP, but far from what most people would call OOP.
Yeah, to clarify, I don’t mean that people using OO will only create performant designs. I mean that they will do some performance oriented things, like caching computable properties, by default because encapsulation is a more important design consideration in OO than in FP. (Which isn’t to say encapsulation isn’t used in FP languages, but that it’s not as central.) I know that there is a lot of pointer chasing in OO code and that thrashes the CPU cache. Data oriented design has gotten big in games programming for that reason.
Languages like Haskell, F# and OCaml are able to compete with (and sometimes exceed) procedural and OO languages on performance. I am offering a minor critique of a paradigm that I prefer.
This isn’t a rant about OOP. It’s a rant about an OOP book. Not that it significantly affects the rest of what you wrote, but I think it’s an important distinction. Most of the rant seems equally correct (or incorrect, whatever the case may be) from the perspective of an OOP fanatic as it does from the perspective of an OOP hater.
This is perhaps the most unfair review I’ve ever read of anything, but I suppose it has to be what I expected after reading your other work. At this point I think it’s clear you just like to hate things
It’s a gimmick, not very well done, but I’m giving the author the benefit of the doubt. I believe he’s honestly just trying to figure things out. Sucks to try to figure things out when you already know everything, but sadly many of us live in that spot.
I do my best to encourage coders to vent and write about how they’re processing and learning about their work. I do this no matter what I feel about their writing technique, style, or maturity level. I learn when I watch other people learn.
It’s a book of exercises and the main complaint of the article is that it’s full of exercises. Exercises are not real code, of course they are not they are meant to be small enough to demonstrate the idea under study
The only code from the book that is quoted is the example of procedural code to be refactored and then the article says “this is procedural, not OOP!” Of course it is! It’s the procedural example! And the author even says that if this code were never going to change or get more complex this is how one should write things, so complaints that making it more OOP doesn’t make it better are shared by the author
It’s a book of exercises and the main complaint of the article is that it’s full of exercises. Exercises are not real code, of course they are not they are meant to be small enough to demonstrate the idea under study
What’s the point of exercise when it has nothing to do with what you’re trying to learn? When you reduce the exercise to absurd simplification, it’s just a waste of time that confuses people. Do weightlifters practice by lifting spoons with their fingers?
The only code from the book that is quoted is the example of procedural code to be refactored and then the article says “this is procedural, not OOP!”
All code in the book is not a meaningful OOP. It starts with not-an-OOP, and then goes on twisting the code without making it meaningfully OOP. The self goes unused 95% of the time, using classes as namespaces. The only time it is used is for a utterly contrived and confusing wrapper around a number that is there to show polymorphism.
Even comparing to typical lame examples of cats & dog objects making sounds, it falls short as there isn’t even any side-effect involved to talk about.
it falls short as there isn’t even any side-effect involved to talk about.
If you believe OOP requires side-effect, then you’re talking about a very different kind of OOP than the one taught by the book, I agree. As I think we’ve agreed in other threads, the term OOP is over-broadly used to describe radically different things. Some of those things involve side effects.
If you believe OOP requires side-effect, then you’re talking about a very different kind of OOP than the one taught by the book, I agree.
It’s not that it’s required. It’s that without any side-effect in sight there is no meaningful difference between procedural, functional, OOP style. All other OOP books I’ve read in one form or another describe an importance of using messages to make objects do something: trigger other messages, change internal state, print something on the console. How can it teach about OOP when there isn’t any OOP to talk about. Where is the state encapsulation where each method just returns a value. All that is presented is a little bit polymorphism.
For a user account 1 month old, they have only submitted their own stuff, and 3/4 of it has been variations on OOP clickbait.
Personally, I like to see folks submitting their own stuff–unless it’s really, really good and in most cases frankly it isn’t–at like a 1 in 5 or smaller ratio…and only after they’ve been actively engaging in the community for months.
He is engaging substantively here in the comments and isn’t promoting a business so I don’t have an issue with it (don’t have an opinion on quality of this post)
This seems like their way of engaging in the community. I would encourage them to post a variety of sources on top of their own content, but months of other participation before submitting anything of their own seems like gatekeeping. All the posts are well-rated and have led to active conversations that they themselves participate in - I don’t see a big deal.
I’d say, by the number of spam votes, the community doesn’t want him engaging in this specific way. It’d feel less spammy if he submitted things in addition to anti-OOP rants.
I was already seeing the spam votes on this climb well before friendlysock commented. They’re all on this one because his first two posts weren’t spam while this one is, being his third anti-OOP rant in ten days.
To be quite frank, if someone runs post chapter 1 and says “In the first chapter, the author contrasts 4 versions of a program generating the text of the “99 bottles of Beer” song. They are all effectively the same, with 3 of them being slightly too clever, and one being a clear simplicity winner.”, they have run past the point of the book. None of the examples given are super contrived (I would even go as far an saying that they spot-on illustrate malpractice in the Ruby community), the book uses the comparison to introduce some terms and it picks an common problem that many people know about. But the point that the author makes super clear leading up to those examples is that there are cases where aspects of each can be the proper solution.
I don’t want to argue the quality of the book (I haven’t read it, I only know Sandi Metz for her talks), but seemingly trivial examples are what make accessible teaching material. Any transformation of those examples to a different practice are easy to make - that means learners can quickly follow and change examples themselves. It’s entirely okay to bring out the big guns for a small example for the sake of learning.
I have read the book (first edition not the new one). It was great. To me, disliking it is a sign of poor taste. It’s a totally thoughtful book for programmers at any skill level to benefit from. If you don’t like it, you probably don’t like programming.
@dpc_pw, have you read “Object-Oriented Software Construction, 2nd ed.” by Bertrand Meyer? It’s insanely thick, but I feel that this is what you’d want to read. I’ve read it almost in entirety twenty years ago, and it influenced me a lot.
It’s abundantly clear that the author doesn’t know who the authors of this book are, so some context to bear in mind:
Sandi Metz teaches OOP to people who have built a giant mess and need help refactoring. She focuses on taking non-OOP code and using principles from it to solve problems. Her conference talk All The Little Things is one of the best refactoring talks I’ve ever seen.
As I haven’t read the book, I can’t comment on more, but it seems to me that the OP is bothered that the book is not much about OOP (despite being advertised as), and there is a lot of refactoring. Your comment seems to suggest that the book authors indeed focus mostly on refactoring, so OPs criticism might be well placed.
The OP is bothered by the teaching approach that the authors are taking. He seems to want a book about designing ideal OOP systems from first principles, and this book was never intended to be that.
The preface to the book could just as well have been a response to this blog:
Despite what one might predict, novices often have an easier time with this material. As they are unencumbered by prior knowledge, their minds are open, and easily absorb these ideas.
It’s the veterans who struggle. Their habits are deeply ingrained. They know themselves to be good at programming. They feel quick, and efficient, and so resist new techniques, especially when those techniques temporarily slow them down.
This book will be useful if you are a veteran, but it cannot be denied that it teaches programming techniques that likely contradict your current practice. Changing entrenched ideas can be painful. However, you cannot make informed decisions about the value of new ideas unless you thoroughly understand them, and to understand them you must commit, wholeheartedly, to learning them.
Is it any wonder that a person hate-reading this would come away with a negative view? (I just discovered the OP is into Urbit. That explains a lot)
It’s abundantly clear that the author doesn’t know who the authors of this book are, so some context to bear in mind:
It’s true. I pretty much never dig into who wrote a given book.
Both of these people focus on practical advice for digging your way out of a messy codebase by refactoring.
And that’s how indeed this book feels to me.
My review came out ranty, primarily because of frustration. I was asking around for good books/examples of code to study and critique OOP. Multiple people recommended 99 bottles, and it’s not about OOP, but about refactoring code. And at very, very small scope for that matter, using examples that probably confuse a lot of people and possibly backfire. (Number6 inheriting from BottleNumber?!)
My main gripe with this article is the bitter negative tone, but others have already commented on that.
Trying to be a bit more constructive, i think this article would really benefit from a code example of how the author would have solved the 99 bottles problem. In fact the first chapter of the book presents the problem and invites the reader to write a solution for it, also providing a test suite to test against. I think most of the value of an exercise-based book like this one comes from trying to solve the exercises and then contrasting the solution with the author’s, or with peers. So, there’s a lot of complaints, but where is the counter-argument or counter-example? Show me the code! :)
About the book itself, i’ve read it, and in general i do agree that as an OO book, i didn’t get much form it. But i’m not a fan of OOP and in general try to avoid using it, so i’m already biased there. What i did find valuable from the book were the refactoring exercises, which showcased doing meaningful refactors in very small steps, while keeping all tests green between every little step. I think this can be quite valuable, especially in dynamically typed languages, or languages with poor tooling support in general, where there’s no such thing as “the compiler will guide me through this refactor”, or where even a class/method rename can be non-trivial because of stringly-typed code calling things via reflection.
My main gripe with this article is the bitter negative tone, but others have already commented on that.
I guess I’m overly negative, because the book sells itself as OOP book, and people keep mentioning it to me as an OOP when I ask for examples of “Good OOP”, and $40 later turns outthe book have nothing to do with OOP. 99% of the time the self there goes unused and classes are used as namespaces. The OOP stuff in there doesn’t make any sense. How can there be any discussion about Liskov Principle, when there’s no interface or subclassing around?
Had it been called “Basics of structuring your code well”, maybe I would just shruged and moved on. But then it would probably not sell as well, so catch-all OOP marketing has to be used.
would really benefit from a code example of how the author would have solved the 99 bottles problem.
Just like the version considered most simple in the Chapter 1 that I pasted verbatim. And then the sixpack requirement by adding the when 6 case. The book go on and on about “OOP for changeability” but actually handling this requirement was trivial in the simplest version already.
Just like the version considered most simple in the Chapter 1 that I pasted verbatim. And then the sixpack requirement by adding the when 6 case.
Even at such a simple level as this problem, i think it might have been valuable to actually write that solution and make the tests pass. It turns out that with that starting code, a when 6 is not enough; you also need a when 7 case to account for the modification on the verse that starts with 7 bottles:
7 bottles of beer on the wall, 7 bottles of beer.
Take one down and pass it around, 1 six-pack of beer on the wall.
Still manageable with that when/case structure i think, but it exemplifies the issue that the author is trying to convey about that sort of code: you wanted to changed a single “concept”, but you needed to change two places in the code because that concept is spread through different branches of that when statement.
I don’t think that the over-architected solution of inventing “BottleNumber”s is justified TBH; i’d personally would have gone for some helper formatting function for printing quantities of bottles and that’s it, but i digress.
the book sells itself as OOP book, and people keep mentioning it to me as an OOP when I ask for examples of “Good OOP”
I didn’t know about this. In that case, yes, i agree with the general conclusion of the book not really having any realistic example of “good” OOP code.
I don’t think that the over-architected solution of inventing “BottleNumber”s is justified TBH; i’d personally would have gone for some helper formatting function for printing quantities of bottles and that’s it, but i digress.
The author agrees with you! For something that is simple or unchanging, the procedural style is often most clear. The point of using such a simple example is to make the techniques used for refactoring stand out, not that they are the right fit for the tiny problem at hand “in the real world” but rather that they are the right fit for related-but-real problems of the same shape.
I feel that a lot of “software theory” (very broad generalization) suffer from examples that are trivial or has no use in the real world, and this post exemplifies this.
Can anyone recommend software books (both OOP and functional) that look at multiple real-world cases (such as web applications, data processing or other non-trivial-at-size examples) and also offer some thoughts on when to break some patterns for simplicity?
Software Tools by Kernighan and Plauger demonstrates structured design in Ratfor a preprocessor for Fortran 66. One of the example applications is a Ratfor processor. This book is also available in a Pascal version.
Can anyone recommend software books (both OOP and functional) that look at multiple real-world cases (such as web applications, data processing or other non-trivial-at-size examples) and also offer some thoughts on when to break some patterns for simplicity?
The architecture of open source applications is probably the closest thing to what you are asking for http://aosabook.org/en/index.html. I am not sure I am ready to recommend it: I don’t remember learning a lot from it.
https://www.tedinski.com/archive/ (read in chronological order from the first entry) is not what you ask for, but might be what you want. I might be biased, but for me personally this series (especially earlier articles) provided more insights than all the other software architecture stuff I’ve read combined.
There are some good books on operating system internals (Linux, FreeBSD and Minix are well-documented contemporary ones). It should be possible to extract some good design ideas from those. But I don’t know of any books that compare multiple systems of the same type, probably because that’s often going to be an apples versus oranges example as different systems typically don’t have exactly the same goals in mind to begin with.
Whenever I’ve tried to write proper examples for complex problems, I’ve found that just explaining the background in a realistic way takes way too long, and I’d lose readers before I get to the main point.
Some language features (like encapsulation, advanced type systems) become useful when you deal with programs large enough and maintained for long enough that you actually forgot how things were implemented. But how do you introduce a “too large to keep in your head” program in a blog post or even a book? I suspect that’s an inherent trade-off in describing complex problems.
I agree that it’s not an easy thing to solve, and a lot of wisdom on these subjects come from experience and making mistakes, which is difficult to distill into meaningful chapters in a book.
Can anyone recommend software books (both OOP and functional) that look at multiple real-world cases (such as web applications, data processing or other non-trivial-at-size examples) and also offer some thoughts on when to break some patterns for simplicity?
Trying to present more than just one real-life program example is probably too much.
As I mention in the article the Growing Object Oriented Software does a good job at presenting OOP with one real-like program.
It’s a content-free comment, but I have to say I love this guy! He went onto the crusade I never worked up courage to do myself, apart from doing it orally among my OOP-brainwashed colleagues.
Thanks. I really appreciate it. There’s a lots of negative feedback, which is to expected, so a little shout of support is nice to see.
My motivation comes from the fact that I’ve seen many projects completely devastated by OOP (one could argue if it was a “Good OOP” or just “incorrect” OOP). Teams producing monstrosities where Object–relational impedance mismatch made the code insufferable to work with, the team blaming it on the ORM they used, and move on to make a rewrite using a different ORM but same OOP style, which leads them into the same place. It keeps popping up wherever I go, as OOP is still considered a blessed default methodology of some kind - spoon-fed to all the new developers. I have wrote many (mostly in free time) unenlightened-OOP projects myself in the past, so I know how it is to be bamboozled and confused by OOP. So I think people have to speak up: either steelman this stuff, and make sure OOP is understood and practice in some reasonable form, or just keep ranting on it, until it completely looses its marketing appeal.
I have wrote many (mostly in free time) unenlightened-OOP projects myself in the past, so I know how it is to be bamboozled and confused by OOP. So I think people have to speak up: either steelman this stuff, and make sure OOP is understood and practice in some reasonable form, or just keep ranting on it, until it completely looses its marketing appeal.
I’m sorry but I really dislike this. You’re going to continue ranting about OOP because you dislike it, and flood this site with your low-content rants? I really don’t think this kind of attitude belongs on this site. Twitter is probably a better home for this feelings-based engagement.
This is a rant and therefore not really full of useful information. If you like rants about OOP then you might like this post.
However I use OOP all the time despite being something of a functional programming nerd. Most of the time when I use OOP its for one of the following uses:
An easier to understand closure. All the state that the methods rely on are defined in the class not grabbed from the environment. This can be cleaner. I will frequently make the class internals immutable when this is my purpose.
Defining interfaces. A class is a convenient way to group things. An interface is a convenient way to say what grouping you require or expect. This is often an aid to understanding code.
The crusade for or against OOP/Funtional is tired at this point though. I think for any developer who moves beyond framework glue coding what our industry cares about are the component ideas of each. Immutability, Encapsulation, Liskov Substitution, others I won’t bother to list here. You may learn about these ideas in OOP or Functional approaches but you eventually you learn that what is actually important are the component concepts not whether your code is OOP or Functional.
Yeah sometimes you need to abstract data and state, and sometimes you don’t. It’s really as simple as that.
It’s kind of like the JSON vs. XML/HTML debates, which I always thought were stupid. Sometimes you have more data than text – use JSON. Sometimes you have more text than data – use XML/HTML.
It’s silly to encode objects as XML, just as it’s silly to encode documents in JSON. (Not to say every instance of it is wrong, but it’s awkward.)
Likewise there are some problems where it’s obviously silly to use OOP – every AST written in an OO language is unabstracted data, not objects. Martin Odersky even mentioned this experience with an OO AST and it was a mistake.
On the other hand representing various elaborations on a stack is completely natural in OO (and I use this all over Oil). It’s state that has a limited interface. Splitting a string on a delimiter is awkward and inefficient in functional programming. Use a state machine and don’t generate so much garbage, etc.
I hate to bring out this platitude, but “use the right tool for the right job” … IMO all programmers should be familiar with both styles and use them as appropriate.
I’ve wondered how much default data structures in functional programming are hamstrung by pattern matching. Pattern matching very beautiful and feels very natural (and I absolutely love it), but it fundamentally ties code execution to the structure of the data. As a result, you might end up using suboptimal representations because they work well with pattern matching. As you allude to above, linked lists are suboptimal for a lot of string operations, but linked lists work wonderfully with pattern matching.
OO, on the other hand, is about encapsulation. By default, people will do things that provide performance benefits. E.g., updating the length of a collection on each insert/deletion rather than traversing the entire collection on each call to length. It ends up making the code more complex and stateful, but it makes some operations more efficient.
I think having some user definable form of pattern matching may push functional programmers towards using better default data structures. Effectively, it would be a new form of encapsulation for in functional programming. Currently, I only know one programming language that has extensible pattern matching (Egison), but I haven’t used it and don’t know how effective it is.
Anyways, I agree with you. OO (technique | culture | design space) has it’s uses. This is mainly an overlong tangent on a relatively minor point.
While I kind of, maybe agree on the FP nature going against best structure of the data (it’s more nuanced then this) …
… this is absolute not the case. Quite the opposite. Dogmatic OOP (and encapsulation in particular) are typically even worse performance offenders. Just so I don’t have to repeat myself, you might waant to peak at this rant.. Having said that - since OOP doesn’t have really an exact meaning, any software written with data-oriented architecture mindset, where authors understand a difference between value types (plain data) and objects, and employ actual meaningful coarse-grained objects, can have a stellar performance and be considered actually OOP, but far from what most people would call OOP.
Yeah, to clarify, I don’t mean that people using OO will only create performant designs. I mean that they will do some performance oriented things, like caching computable properties, by default because encapsulation is a more important design consideration in OO than in FP. (Which isn’t to say encapsulation isn’t used in FP languages, but that it’s not as central.) I know that there is a lot of pointer chasing in OO code and that thrashes the CPU cache. Data oriented design has gotten big in games programming for that reason.
Languages like Haskell, F# and OCaml are able to compete with (and sometimes exceed) procedural and OO languages on performance. I am offering a minor critique of a paradigm that I prefer.
This isn’t a rant about OOP. It’s a rant about an OOP book. Not that it significantly affects the rest of what you wrote, but I think it’s an important distinction. Most of the rant seems equally correct (or incorrect, whatever the case may be) from the perspective of an OOP fanatic as it does from the perspective of an OOP hater.
This is perhaps the most unfair review I’ve ever read of anything, but I suppose it has to be what I expected after reading your other work. At this point I think it’s clear you just like to hate things
I agree, however I also liked the essay.
It’s a gimmick, not very well done, but I’m giving the author the benefit of the doubt. I believe he’s honestly just trying to figure things out. Sucks to try to figure things out when you already know everything, but sadly many of us live in that spot.
I do my best to encourage coders to vent and write about how they’re processing and learning about their work. I do this no matter what I feel about their writing technique, style, or maturity level. I learn when I watch other people learn.
[Comment removed by author]
I haven’t read the book under review, so I don’t know how fair the review is. What would be your take of the book, why does the review seem unfair?
Top two reasons the review is unfair IMHO:
What’s the point of exercise when it has nothing to do with what you’re trying to learn? When you reduce the exercise to absurd simplification, it’s just a waste of time that confuses people. Do weightlifters practice by lifting spoons with their fingers?
All code in the book is not a meaningful OOP. It starts with not-an-OOP, and then goes on twisting the code without making it meaningfully OOP. The
selfgoes unused 95% of the time, using classes as namespaces. The only time it is used is for a utterly contrived and confusing wrapper around a number that is there to show polymorphism.Even comparing to typical lame examples of cats & dog objects making sounds, it falls short as there isn’t even any side-effect involved to talk about.
If you believe OOP requires side-effect, then you’re talking about a very different kind of OOP than the one taught by the book, I agree. As I think we’ve agreed in other threads, the term OOP is over-broadly used to describe radically different things. Some of those things involve side effects.
It’s not that it’s required. It’s that without any side-effect in sight there is no meaningful difference between procedural, functional, OOP style. All other OOP books I’ve read in one form or another describe an importance of using messages to make objects do something: trigger other messages, change internal state, print something on the console. How can it teach about OOP when there isn’t any OOP to talk about. Where is the state encapsulation where each method just returns a value. All that is presented is a little bit polymorphism.
I am beginning to get concerned at the author’s self-promotion here.
Do you just mean the number of self-authored articles posted in a row?
What are the lobste.rs rules (or unofficial norms) around submission frequency?
For a user account 1 month old, they have only submitted their own stuff, and 3/4 of it has been variations on OOP clickbait.
Personally, I like to see folks submitting their own stuff–unless it’s really, really good and in most cases frankly it isn’t–at like a 1 in 5 or smaller ratio…and only after they’ve been actively engaging in the community for months.
He is engaging substantively here in the comments and isn’t promoting a business so I don’t have an issue with it (don’t have an opinion on quality of this post)
This seems like their way of engaging in the community. I would encourage them to post a variety of sources on top of their own content, but months of other participation before submitting anything of their own seems like gatekeeping. All the posts are well-rated and have led to active conversations that they themselves participate in - I don’t see a big deal.
I’d say, by the number of spam votes, the community doesn’t want him engaging in this specific way. It’d feel less spammy if he submitted things in addition to anti-OOP rants.
About 100 upvotes and 150ish comments vs 22 spam votes, mostly on this post where an influential community member commented about self promotion.
I was already seeing the spam votes on this climb well before friendlysock commented. They’re all on this one because his first two posts weren’t spam while this one is, being his third anti-OOP rant in ten days.
I see +36, -18, 20 users hidden. I think it’s safe to say it’s controversial.
We gatekeep by requiring invitations.
Gatekeeping with social norms works pretty well for keeping the site worth reading.
Yes, that would be the objective.
The top post from an earlier discussion proposed a guideline that one third of your submissions can be your own material.
The source marks users as heavy self promoters if they authored 51% or more of their submissions.
For those interested, substantial parts of the book discussed can be found here: https://sandimetz.com/99bottles-sample-ruby, especially chapter 1.
To be quite frank, if someone runs post chapter 1 and says “In the first chapter, the author contrasts 4 versions of a program generating the text of the “99 bottles of Beer” song. They are all effectively the same, with 3 of them being slightly too clever, and one being a clear simplicity winner.”, they have run past the point of the book. None of the examples given are super contrived (I would even go as far an saying that they spot-on illustrate malpractice in the Ruby community), the book uses the comparison to introduce some terms and it picks an common problem that many people know about. But the point that the author makes super clear leading up to those examples is that there are cases where aspects of each can be the proper solution.
I don’t want to argue the quality of the book (I haven’t read it, I only know Sandi Metz for her talks), but seemingly trivial examples are what make accessible teaching material. Any transformation of those examples to a different practice are easy to make - that means learners can quickly follow and change examples themselves. It’s entirely okay to bring out the big guns for a small example for the sake of learning.
I have read the book (first edition not the new one). It was great. To me, disliking it is a sign of poor taste. It’s a totally thoughtful book for programmers at any skill level to benefit from. If you don’t like it, you probably don’t like programming.
@dpc_pw, have you read “Object-Oriented Software Construction, 2nd ed.” by Bertrand Meyer? It’s insanely thick, but I feel that this is what you’d want to read. I’ve read it almost in entirety twenty years ago, and it influenced me a lot.
Hey, half the price of 99 Bottles. Ordered. Thanks.
Meyer is definitely a guru of OOP. If he can’t convincingly explain what “OOP done right” ought to look like, no-one can.
It’s abundantly clear that the author doesn’t know who the authors of this book are, so some context to bear in mind:
Sandi Metz teaches OOP to people who have built a giant mess and need help refactoring. She focuses on taking non-OOP code and using principles from it to solve problems. Her conference talk All The Little Things is one of the best refactoring talks I’ve ever seen.
The other author is Katrina Owen, who is also well-known for her talks on refactoring. Notable, she is also the creator of Exercism.
Both of these people focus on practical advice for digging your way out of a messy codebase by refactoring.
Isn’t this an appeal to authority?
As I haven’t read the book, I can’t comment on more, but it seems to me that the OP is bothered that the book is not much about OOP (despite being advertised as), and there is a lot of refactoring. Your comment seems to suggest that the book authors indeed focus mostly on refactoring, so OPs criticism might be well placed.
The OP is bothered by the teaching approach that the authors are taking. He seems to want a book about designing ideal OOP systems from first principles, and this book was never intended to be that.
The preface to the book could just as well have been a response to this blog:
Is it any wonder that a person hate-reading this would come away with a negative view? (I just discovered the OP is into Urbit. That explains a lot)
It’s true. I pretty much never dig into who wrote a given book.
And that’s how indeed this book feels to me.
My review came out ranty, primarily because of frustration. I was asking around for good books/examples of code to study and critique OOP. Multiple people recommended 99 bottles, and it’s not about OOP, but about refactoring code. And at very, very small scope for that matter, using examples that probably confuse a lot of people and possibly backfire. (
Number6inheriting fromBottleNumber?!)This is an awfully long post to say “I don’t understand OOP, and I claim to hate it based on this misunderstanding.”
My main gripe with this article is the bitter negative tone, but others have already commented on that.
Trying to be a bit more constructive, i think this article would really benefit from a code example of how the author would have solved the 99 bottles problem. In fact the first chapter of the book presents the problem and invites the reader to write a solution for it, also providing a test suite to test against. I think most of the value of an exercise-based book like this one comes from trying to solve the exercises and then contrasting the solution with the author’s, or with peers. So, there’s a lot of complaints, but where is the counter-argument or counter-example? Show me the code! :)
About the book itself, i’ve read it, and in general i do agree that as an OO book, i didn’t get much form it. But i’m not a fan of OOP and in general try to avoid using it, so i’m already biased there. What i did find valuable from the book were the refactoring exercises, which showcased doing meaningful refactors in very small steps, while keeping all tests green between every little step. I think this can be quite valuable, especially in dynamically typed languages, or languages with poor tooling support in general, where there’s no such thing as “the compiler will guide me through this refactor”, or where even a class/method rename can be non-trivial because of stringly-typed code calling things via reflection.
I guess I’m overly negative, because the book sells itself as OOP book, and people keep mentioning it to me as an OOP when I ask for examples of “Good OOP”, and $40 later turns outthe book have nothing to do with OOP. 99% of the time the
selfthere goes unused and classes are used as namespaces. The OOP stuff in there doesn’t make any sense. How can there be any discussion about Liskov Principle, when there’s no interface or subclassing around?Had it been called “Basics of structuring your code well”, maybe I would just shruged and moved on. But then it would probably not sell as well, so catch-all OOP marketing has to be used.
Just like the version considered most simple in the Chapter 1 that I pasted verbatim. And then the sixpack requirement by adding the
when 6case. The book go on and on about “OOP for changeability” but actually handling this requirement was trivial in the simplest version already.Even at such a simple level as this problem, i think it might have been valuable to actually write that solution and make the tests pass. It turns out that with that starting code, a
when 6is not enough; you also need awhen 7case to account for the modification on the verse that starts with 7 bottles:Still manageable with that
when/casestructure i think, but it exemplifies the issue that the author is trying to convey about that sort of code: you wanted to changed a single “concept”, but you needed to change two places in the code because that concept is spread through different branches of thatwhenstatement.I don’t think that the over-architected solution of inventing “BottleNumber”s is justified TBH; i’d personally would have gone for some helper formatting function for printing quantities of bottles and that’s it, but i digress.
I didn’t know about this. In that case, yes, i agree with the general conclusion of the book not really having any realistic example of “good” OOP code.
The author agrees with you! For something that is simple or unchanging, the procedural style is often most clear. The point of using such a simple example is to make the techniques used for refactoring stand out, not that they are the right fit for the tiny problem at hand “in the real world” but rather that they are the right fit for related-but-real problems of the same shape.
I feel that a lot of “software theory” (very broad generalization) suffer from examples that are trivial or has no use in the real world, and this post exemplifies this.
Can anyone recommend software books (both OOP and functional) that look at multiple real-world cases (such as web applications, data processing or other non-trivial-at-size examples) and also offer some thoughts on when to break some patterns for simplicity?
Here are some books that use real examples:
Edited to add some more books.
Real World Haskell.
It teaches how to make a JSON parser, a barcode decoder, a regular expression library, binary-enconding parser,
syslog, among other stuff.The architecture of open source applications is probably the closest thing to what you are asking for http://aosabook.org/en/index.html. I am not sure I am ready to recommend it: I don’t remember learning a lot from it.
https://www.tedinski.com/archive/ (read in chronological order from the first entry) is not what you ask for, but might be what you want. I might be biased, but for me personally this series (especially earlier articles) provided more insights than all the other software architecture stuff I’ve read combined.
There are some good books on operating system internals (Linux, FreeBSD and Minix are well-documented contemporary ones). It should be possible to extract some good design ideas from those. But I don’t know of any books that compare multiple systems of the same type, probably because that’s often going to be an apples versus oranges example as different systems typically don’t have exactly the same goals in mind to begin with.
Whenever I’ve tried to write proper examples for complex problems, I’ve found that just explaining the background in a realistic way takes way too long, and I’d lose readers before I get to the main point.
Some language features (like encapsulation, advanced type systems) become useful when you deal with programs large enough and maintained for long enough that you actually forgot how things were implemented. But how do you introduce a “too large to keep in your head” program in a blog post or even a book? I suspect that’s an inherent trade-off in describing complex problems.
I agree that it’s not an easy thing to solve, and a lot of wisdom on these subjects come from experience and making mistakes, which is difficult to distill into meaningful chapters in a book.
Trying to present more than just one real-life program example is probably too much. As I mention in the article the Growing Object Oriented Software does a good job at presenting OOP with one real-like program.
It’s a content-free comment, but I have to say I love this guy! He went onto the crusade I never worked up courage to do myself, apart from doing it orally among my OOP-brainwashed colleagues.
Thanks. I really appreciate it. There’s a lots of negative feedback, which is to expected, so a little shout of support is nice to see.
My motivation comes from the fact that I’ve seen many projects completely devastated by OOP (one could argue if it was a “Good OOP” or just “incorrect” OOP). Teams producing monstrosities where Object–relational impedance mismatch made the code insufferable to work with, the team blaming it on the ORM they used, and move on to make a rewrite using a different ORM but same OOP style, which leads them into the same place. It keeps popping up wherever I go, as OOP is still considered a blessed default methodology of some kind - spoon-fed to all the new developers. I have wrote many (mostly in free time) unenlightened-OOP projects myself in the past, so I know how it is to be bamboozled and confused by OOP. So I think people have to speak up: either steelman this stuff, and make sure OOP is understood and practice in some reasonable form, or just keep ranting on it, until it completely looses its marketing appeal.
I’m sorry but I really dislike this. You’re going to continue ranting about OOP because you dislike it, and flood this site with your low-content rants? I really don’t think this kind of attitude belongs on this site. Twitter is probably a better home for this feelings-based engagement.
Nit: “wreck havoc” ==> “wreak havoc”
No reply please
A minor note: there’s a missing double-quote at the end of the line:
…which confuses the syntax highlighting.
Fixed! Much appreciated.