[applepple]

If the article only attacked that specific book "Clean Code", then I would not be as critical. But the first line in the article suggests that it is an attack against the entire idea of writing good quality code:

'It may not be possible for us to ever reach empirical definitions of "good code" or "clean code"'

It might seem far fetched that someone might question the benefits of writing high quality code (readable, composable, maintainable, succinct, efficient...) but I've been in this industry long enough (and worked for enough different kinds of companies) to realize that there is an actual agenda to push the industry in that direction.

Some people in the corporate sphere really believe that the best way to implement software is to brute force it by throwing thousands of engineers at a giant ball of spaghetti code then writing an even more gargantuan spaghetti ball of tests to ensure that the monstrosity actually works.

I see it as an immoral waste of human potential.

[oriolid]

> is an attack against the entire idea of writing good quality code: > 'It may not be possible for us to ever reach empirical definitions of "good code" or "clean code"'

I read it as an attack against the idea that there are hard and fast, objective and empirically verifiable rules for good quality code. The Clean Code book itself is a perfect example of how subjective such rules are. I feel really sorry for you if the only methods for software development that you know are "brute force it by throwing thousands of engineers at a giant ball of spaghetti code" and sticking a book that has some fanatic supporters. "Readable", "maintainable", "succint" or "efficient" don't really describe Martin's examples and many functional programming enthusiasts would question "composable" too. Yes, I wasted several hours of my life reading that book and I'm never getting them back.

[applepple]

>> I feel really sorry for you if...

I never said that this is what I believe. I said it's what a lot of people in the corporate sphere believe. It's the opposite of what I believe.

OOP solves complex problems in a simple way.

Functional Programming solves simple problems in a complex way.

Some concepts from FP are useful when applied within OOP, but pure FP is simply not practical. It doesn't scale in terms of code size, it's inefficient, it's inflexible, it takes longer to develop and maintain, it's less readable because it encourages devs to write long chains of logic spread out across many files. FP's lack of emphasis on important concepts such as blackboxing, high cohesion and loose coupling encourages developers to produce poor abstractions whose names sound highly technical but whose responsibilities are vague and impossible to explain without a long list of contrived statements which have little in common with one another.

Abstractions in FP tend to be all over the place. It seems to encourage vague, unstructured thinking. Decoupling state from logic makes it impossible to produce abstractions which are high cohesion and loosely coupled. It forces every component to mind every other component's business.

This is madness. If you don't care about structure, why not just write the entire system as a single file and define thousands of functions which call each other all over the place? You would get the same spaghetti, but you would save yourself the effort of having to jump around all these files which don't add any meaningful structure anyway.

[oriolid]

I feel really sorry for you if you believe a word of what you wrote above.

[applepple]

It's always the case that when I present these arguments above to FP devs, they respond with personal insults instead of counter-arguments. This suggests that they know my arguments are accurate but they are too invested in FP and are in denial - It's emotional, so they respond emotionally.

You shouldn't think of it like "I've been fooled and wasted all this time on FP". You should think about it like "I gave FP a thorough analysis over several years and it was a worthwhile experiment which didn't work out but I learned a lot from it".

I also spent quite a lot of time working with and reading FP code over the last 15 years. That's why I can criticize it with confidence today. It was not a waste.

[oriolid]

Comments like "Functional Programming solves simple problems in a complex way, "Abstractions in FP tend to be all over the place." or "If you don't care about structure, why not just write the entire system as a single file and define thousands of functions which call each other all over the place?" don't really invite polite discussion. To me they look like you either are reacting on pure emotion, or don't understand what you are writing about (note that this opposite of "accurate"). It also seems that you think that I'm whatever you believe "functional programmers" are.

If there's something we maybe agree on, it's that enforcing pure functionality (I guess that's what you're writing about. If you think functions as first class objects is bad, you're incorrigibly wrong) is about as bad as maximal OOP that Martin is preaching. There's a lot of space between these two extremes if you're willing to look. And a lot of money to be made by sticking to an ideology and preaching it.

[applepple]

It would be an interesting experiment if you could show me the GitHub repo of the best written open source FP project you've ever encountered and I could point out its flaws and rank them on a scale based on how critical they are in terms of maintenance and performance.

[CRConrad]

> But the first line in the article suggests that it is an attack against the entire idea of writing good quality code:

> 'It may not be possible for us to ever reach empirical definitions of "good code" or "clean code"

If you re-read that line you quoted you may find that it talks of the (im)possibility of defining what "good code" or "clean code" is, not of actually writing it.

A bit like pornography in that way.