He poisoned millions of developers. His "clean code" is not even clean. The dude is just a con man, he was never good, just a midwit with good speaking skills.
>His "clean code" is not even clean
Superficial principles for superficial cleanliness, leading to structurally unsound code.
My favorite part is where he recommends methods without parameters as the ideal, hence embracing state and mutability where it's not required and making it non-obvious at the same time.
I'd be hard pressed to come up with something dumber.
>My favorite part is where he recommends methods without parameters as the ideal
why you have to follow him that hard? The dude probably hasn't programmed in quite a while.
2 years ago
Anonymous
>why you have to follow him that hard?
Dude, I simply read the book years ago and tried following the advice for a while so it stuck with me.
But it's shit.
2 years ago
Anonymous
well, I do OOP but I learn from my own mistakes, the biggest one being writing untestable classes. You don't have to follow all of his advice. For example I find writing interfaces for your own code overkill. It's not like you'll write more than 1 implementation for 90% of your own code.
>My favorite part is where he recommends methods without parameters as the ideal, hence embracing state and mutability where it's not required and making it non-obvious at the same time.
This is his most blatant contradiction: he argues against side effects (something I agree with), but then claims that "the ideal number of parameters for a function is zero". The only way a function with zero parameters can do meaningful work is through side effects: otherwise, it can at most return a (potentially cached) constant (which should bet the question as to whether the function is really needed).
There are only two ways to influence the behavior of a function at runtime: parameters and side effects. Remove the former and you're left with the latter.
However, I do agree with the general concept that a function should have as few parameters as possible: if you find yourself passing a gigantic number of arguments to a single function, you should probably define an appropriate data structure to hold them.
2 years ago
Anonymous
Function or method? There is a difference here
A method with zero parameters can mutate the internal state of the object. Thats not really a side effect from the OOP perspective. Methods are essentially functions where the object is always an implicit first parameter
2 years ago
Anonymous
>Thats not really a side effect from the OOP perspective
How does a brain like yours manage to solve the captcha? Genuine question.
2 years ago
Anonymous
The term "method" means different things depending on which language you're talking about.
In Java, methods are member functions of an object (the only possible kind of functions, since there are no free functions). In Lisp, for instance, methods are functions that may perform dynamic dispatch on one or more of their arguments, but they are not "members" of any class specifically. And they are allowed to have exactly zero parameters, without even an implicit parameter.
But even then, a side effect is a side effect, period, even "from the OOP perspective".
>My favorite part is where he recommends methods without parameters as the ideal, hence embracing state and mutability where it's not required and making it non-obvious at the same time.
This is his most blatant contradiction: he argues against side effects (something I agree with), but then claims that "the ideal number of parameters for a function is zero". The only way a function with zero parameters can do meaningful work is through side effects: otherwise, it can at most return a (potentially cached) constant (which should bet the question as to whether the function is really needed).
There are only two ways to influence the behavior of a function at runtime: parameters and side effects. Remove the former and you're left with the latter.
However, I do agree with the general concept that a function should have as few parameters as possible: if you find yourself passing a gigantic number of arguments to a single function, you should probably define an appropriate data structure to hold them.
I think he meant that ideally you should have short param lists. You know, functions doing one thing well (you know that line). Most of what he's saying is just old ideas.
2 years ago
Anonymous
He LITERALLY says, in the book "the ideal number of arguments for a function is zero". While I agree that fewer arguments are generally better and easier to reason about, this particular statement, when taken literally, is in direct contrast with the goal of avoiding side effects.
2 years ago
Anonymous
Not really. A simple getter meets that criteria
2 years ago
Anonymous
A getter is not a pure function since the value it returns depends on the state of the program, hence, it relies on side effects.
2 years ago
Anonymous
>since the value it returns depends on the state of the program
irrelevant. getters that have no side effects are pure functions
2 years ago
Anonymous
but you can't know whether they have side effects or not because oop insists in hiding implementation details that aren't really just implementation details. Some getters are not ok to call twice and that should be reflected somewhere
2 years ago
Anonymous
A getter can return two distinct results when called at different times with the same arguments (none). Hence, no, it's not a pure function.
2 years ago
Anonymous
Yeah, I imagine it was figurative language or he was being slightly facetious. Unsurprisingly autistic people on IQfy can't understand that.
It's tough. Clean Code is a great read and taught me more about coding style than school ever did.
On the other hand the guy drinks the OOP kool aid way too hard. In one of his books he showcases a "correct" implementation of an arguments parser, and it is a massive unreadable jungle of polymorphism and design patterns for something that should have a straight forward implementation.
All-in-all he is a loud proponent of ultra dogmatic extreme OOP. If you read his stuff you can't go any further down the rabbit hole. Good to read so that you know what the final form of OOP looks like, but you have to not be an npc troony homosexual and be able to find value in the information without simping for it or chimping out about it.
Selling books and giving speeches about how one should write code. Of course, he doesn't go past the most trivial text book examples. He does not work, he does not code, he doesn't have a public repo, he does not have a released product. Yet he is out there giving everyone orders, every two years comes up telling you to do the opposite and selling guiding books
As with anything, you should listen to those who actually get shit done instead of those who only write books. There is no substitute for actual experience.
Even then, always use your head and never fall into dogma. An experienced and accomplished person can still be wrong on some things.
So after asking around at work and other guys in the industry who preach the praise of FP. They're argument always boils down too, "mutation dangerous, limitations good for low iq devs"
Is that it? That's why people low FP? Because it's artificially restricting them from doing things nobody is forcing them to do? And as a result they end up doing less stupid shit?
>doing things nobody is forcing them to do
I take it you have never worked with legacy code or in a team?
I knew a supposedly experienced (8+ years at the time) Java dev who used inheritance between classes with only static methods because it made calling the other class' methods easier.
After I told him 'no' in code review he wanted to have a full-blown discussion about it.
He did other stupid shit, too. Hell, I used to do stupid shit.
I'm now six years in and I'm probably still doing stuff that'll make me cringe in a couple years.
Currently working with several legacy PHP projects and the freedom and flexibility of that language allowed for each project to have its own unique brand of convoluted, unmaintainable garbage because nobody told the devs 'no'.
I'll be so happy when I'm done with that.
I have actually. So the argument for FP is that some devs are moronic as I initially mentioned and the solution is to force everyone into a inefficient mess that artificially restrict you by design? You could solve alot of these issues with actual good languages and a linter and a proper build pipeline.
It is nice to be able to mutate shit in the instances where the language don't have the algorithm I need bundled, and it would be nice to get that algorithm without writing it in C or something and load it as an external dependency. Because I can't imagine that making anything better
>I knew a supposedly experienced (8+ years at the time) Java dev who used inheritance between classes with only static methods because it made calling the other class' methods easier.
Yikes. Apparently, it's true: experience means more POTENTIAL competence, but not necessarily more actual competence.
The difference between functions working on algebraic data types, and objects with methods isn't as big as people make it out to be. Those two approaches have different advantages and disadvantages but you also can use both in multi-paradigm languages.
One new thing with OOP is it removed the conditional trees by introducing polimorphism/dynamic dispatch, but functional languages found their own patterns to get similar results.
Referential transparency makes programs easier to reason about. That's about it.
>Referential transparency makes programs easier to reason about
sometimes purity makes things easier to reason about and something it makes things harder to reason about
don't act like it's just a net benefit
2 years ago
Anonymous
Yeah, you're right. Many problems are hard to solve or not performant enough when done in a functional way.
Clojure sequences are a super cool abstraction that is worth looking into. Basically, it allows you to work with different data structures (lists, arrays, maps, sets) using the same set of tools.
I don't like him that much, I feel like he is a snake oils salesman. His talks are pretty shit because he spends half the talk talking about random shit. He seems to only shill shit that is popular at the time without any understanding of anything.
I'm not an OOP hater, it's good for some stuff. Functional + OOP is peak, but they tried far too hard for far too many years to make OOP the solution to everything.
I've grown to like og uncle bob (agile manifesto and parts of clean code). OOP brought some nice stuff like collections, message passing and debatably gc. That said frick him
I understand your hate, he hates trannies and that includes you OP. jump off a roof homosexual lol
He poisoned millions of developers. His "clean code" is not even clean. The dude is just a con man, he was never good, just a midwit with good speaking skills.
>His "clean code" is not even clean
Superficial principles for superficial cleanliness, leading to structurally unsound code.
My favorite part is where he recommends methods without parameters as the ideal, hence embracing state and mutability where it's not required and making it non-obvious at the same time.
I'd be hard pressed to come up with something dumber.
>My favorite part is where he recommends methods without parameters as the ideal
why you have to follow him that hard? The dude probably hasn't programmed in quite a while.
>why you have to follow him that hard?
Dude, I simply read the book years ago and tried following the advice for a while so it stuck with me.
But it's shit.
well, I do OOP but I learn from my own mistakes, the biggest one being writing untestable classes. You don't have to follow all of his advice. For example I find writing interfaces for your own code overkill. It's not like you'll write more than 1 implementation for 90% of your own code.
>My favorite part is where he recommends methods without parameters as the ideal, hence embracing state and mutability where it's not required and making it non-obvious at the same time.
This is his most blatant contradiction: he argues against side effects (something I agree with), but then claims that "the ideal number of parameters for a function is zero". The only way a function with zero parameters can do meaningful work is through side effects: otherwise, it can at most return a (potentially cached) constant (which should bet the question as to whether the function is really needed).
There are only two ways to influence the behavior of a function at runtime: parameters and side effects. Remove the former and you're left with the latter.
However, I do agree with the general concept that a function should have as few parameters as possible: if you find yourself passing a gigantic number of arguments to a single function, you should probably define an appropriate data structure to hold them.
Function or method? There is a difference here
A method with zero parameters can mutate the internal state of the object. Thats not really a side effect from the OOP perspective. Methods are essentially functions where the object is always an implicit first parameter
>Thats not really a side effect from the OOP perspective
How does a brain like yours manage to solve the captcha? Genuine question.
The term "method" means different things depending on which language you're talking about.
In Java, methods are member functions of an object (the only possible kind of functions, since there are no free functions). In Lisp, for instance, methods are functions that may perform dynamic dispatch on one or more of their arguments, but they are not "members" of any class specifically. And they are allowed to have exactly zero parameters, without even an implicit parameter.
But even then, a side effect is a side effect, period, even "from the OOP perspective".
I think he meant that ideally you should have short param lists. You know, functions doing one thing well (you know that line). Most of what he's saying is just old ideas.
He LITERALLY says, in the book "the ideal number of arguments for a function is zero". While I agree that fewer arguments are generally better and easier to reason about, this particular statement, when taken literally, is in direct contrast with the goal of avoiding side effects.
Not really. A simple getter meets that criteria
A getter is not a pure function since the value it returns depends on the state of the program, hence, it relies on side effects.
>since the value it returns depends on the state of the program
irrelevant. getters that have no side effects are pure functions
but you can't know whether they have side effects or not because oop insists in hiding implementation details that aren't really just implementation details. Some getters are not ok to call twice and that should be reflected somewhere
A getter can return two distinct results when called at different times with the same arguments (none). Hence, no, it's not a pure function.
Yeah, I imagine it was figurative language or he was being slightly facetious. Unsurprisingly autistic people on IQfy can't understand that.
I have no idea what this is or does sorry
One thing I know about him is that he was quoted by Factorio dev and soon after whole Twatter tried to cancel one poor czech man and his game.
Factorio is a fantastic game so this guy must be based
he stole 10000 hours of my life that i will never get back. i will never forgive him
how tf did he steal more than a YEAR of your life??
cracktorio + mods
OOP is fine, you not knowing how to implement it right is not. Go learn shit instead of lurking to prevent further thread waste
like communism, it's great in concept, but applied it's the most cancerous code ever that no one wants to touch
>Communism
>Good in theory
Sure, let's centralize all industry to the "worker's party". One party to rule It all. What could possibly go wrong?
It's tough. Clean Code is a great read and taught me more about coding style than school ever did.
On the other hand the guy drinks the OOP kool aid way too hard. In one of his books he showcases a "correct" implementation of an arguments parser, and it is a massive unreadable jungle of polymorphism and design patterns for something that should have a straight forward implementation.
All-in-all he is a loud proponent of ultra dogmatic extreme OOP. If you read his stuff you can't go any further down the rabbit hole. Good to read so that you know what the final form of OOP looks like, but you have to not be an npc troony homosexual and be able to find value in the information without simping for it or chimping out about it.
What did he even work on?
Selling books and giving speeches about how one should write code. Of course, he doesn't go past the most trivial text book examples. He does not work, he does not code, he doesn't have a public repo, he does not have a released product. Yet he is out there giving everyone orders, every two years comes up telling you to do the opposite and selling guiding books
As with anything, you should listen to those who actually get shit done instead of those who only write books. There is no substitute for actual experience.
Even then, always use your head and never fall into dogma. An experienced and accomplished person can still be wrong on some things.
Functional autismos seething nobody wants you to work for them.
OOP has functions too. They are called methods. Functionalism is a subset of OOP. OOP is clean code
You don't know what a function is.
10/10 bait
This. ever since we got 'const' functional languages have become obsolete.
>Functionalism is a subset of OOP. OOP is clean code
Why do we let Dunning-Kruger shitskins post?
You gays aren't up to speed, Uncle is now a big Clojure fan and writing a book on functional programming.
lol, its true...
boomers are a mistake
So after asking around at work and other guys in the industry who preach the praise of FP. They're argument always boils down too, "mutation dangerous, limitations good for low iq devs"
Is that it? That's why people low FP? Because it's artificially restricting them from doing things nobody is forcing them to do? And as a result they end up doing less stupid shit?
it's also easier to do TDD i would guess... I am doing OOP in php, and have to do quite a lot of mocking to be able to test stuff
it may be annoying, but not annoying enough to switch to fp
>doing things nobody is forcing them to do
I take it you have never worked with legacy code or in a team?
I knew a supposedly experienced (8+ years at the time) Java dev who used inheritance between classes with only static methods because it made calling the other class' methods easier.
After I told him 'no' in code review he wanted to have a full-blown discussion about it.
He did other stupid shit, too. Hell, I used to do stupid shit.
I'm now six years in and I'm probably still doing stuff that'll make me cringe in a couple years.
Currently working with several legacy PHP projects and the freedom and flexibility of that language allowed for each project to have its own unique brand of convoluted, unmaintainable garbage because nobody told the devs 'no'.
I'll be so happy when I'm done with that.
I have actually. So the argument for FP is that some devs are moronic as I initially mentioned and the solution is to force everyone into a inefficient mess that artificially restrict you by design? You could solve alot of these issues with actual good languages and a linter and a proper build pipeline.
It is nice to be able to mutate shit in the instances where the language don't have the algorithm I need bundled, and it would be nice to get that algorithm without writing it in C or something and load it as an external dependency. Because I can't imagine that making anything better
What is an actual good language?
>I knew a supposedly experienced (8+ years at the time) Java dev who used inheritance between classes with only static methods because it made calling the other class' methods easier.
Yikes. Apparently, it's true: experience means more POTENTIAL competence, but not necessarily more actual competence.
The difference between functions working on algebraic data types, and objects with methods isn't as big as people make it out to be. Those two approaches have different advantages and disadvantages but you also can use both in multi-paradigm languages.
One new thing with OOP is it removed the conditional trees by introducing polimorphism/dynamic dispatch, but functional languages found their own patterns to get similar results.
Referential transparency makes programs easier to reason about. That's about it.
>Referential transparency makes programs easier to reason about
sometimes purity makes things easier to reason about and something it makes things harder to reason about
don't act like it's just a net benefit
Yeah, you're right. Many problems are hard to solve or not performant enough when done in a functional way.
You're welcome to use unstructured programming for all your shit.
Clojure is cringe but lisp is good.
Maybe I should revisit it but it probably still feel like an inferior Lisp.
Clojure sequences are a super cool abstraction that is worth looking into. Basically, it allows you to work with different data structures (lists, arrays, maps, sets) using the same set of tools.
Yes I'll have to give it to Clojure. Handling sequence is a b***h in Common lisp because they're not the same...
OOP and FP are just two fingers pointing at the same moon
Those who think that OOP and FP are compatible understand neither.
We mean to use objects as data/function collections.
moon pointing again, you can literally mix&match both
and the moon is gay.
I don't like him that much, I feel like he is a snake oils salesman. His talks are pretty shit because he spends half the talk talking about random shit. He seems to only shill shit that is popular at the time without any understanding of anything.
What made boomers so biased toward OOP?
I'm not an OOP hater, it's good for some stuff. Functional + OOP is peak, but they tried far too hard for far too many years to make OOP the solution to everything.
boomers are psychotically arrogant
they got memed into it in the 90s and don't want to let go
It was supposed to be the future back then.
>I got filtered by the first chapter of Clean Code: the thread
t. doesn't even know what the first chapter is about
I've grown to like og uncle bob (agile manifesto and parts of clean code). OOP brought some nice stuff like collections, message passing and debatably gc. That said frick him
>collections, message passing and debatably gc
All of these predate OOP.