4 ms·

This article is just pointing at the flaws, not really offering any alternative. It is just as GP said, a rant better kept for the water cooler area. You can g

by gutnor 11y ago

This article is just pointing at the flaws, not really offering any alternative. It is just as GP said, a rant better kept for the water cooler area. You can guess that functional programming is going to be his response I suppose considering this page is the second part of a functional programming article. (the first part being missing) If you want to analyse, you would need to also talk about what OOP is good at and how that translate in whatever other paradigm. This article only concludes with a "I do think it is a valuable mechanism for developing software", but there is absolutely no backing for that statement anywhere in the article. I tend to agree with GP. At the end of the day, for general programming, any paradigm is going to end up producing similar quality of code. Developer competence, motivation and budget are going to be #1 factors that determine code quality. Google, OSS, Modern IDE, Engineering practices like Continuous Integration/Deployment, TDD/BDD are all having a much bigger impact on the code quality than the specific languages or paradigms.

radu_floricica 11y ago
> At the end of the day, for general programming, any paradigm is going to end up producing similar quality of code. Developer competence I'd say that "pure" paradigms tend to be almost equally bad (tried functional programming in production code, wasn't all it's advertised to be). But this actually leaves you with more freedom, because you have to pick pieces and create your own style. So it turns out to be more important, not less, that you understand the how and why of each paradigm. As for how good this particular article was - well, I agree with the premise and it gives links to sources. May not be the Mona Lisa of articles, but it got my upvote. I'm not a regular HN reader so it's the first article on this topic I've seen in a while.
excepttheweasel 11y ago
Author here, FWIW this article was one of many posts some colleagues and I wrote at Pivotal during a "blog writing tontine" to encourage us all to write more and develop our skills, written hastily and intended to be part of a series I didn't finish before leaving. My intention was to point readers to some of the good ideas that were emerging (more accurately: had emerged some time ago) from alternative paradigms and how they could be used to make OOP programs better. Agreed that its certainly more about the team than what syntax you use to push bytes around, but tools do matter.

by gutnor 11y ago

radu_floricica 11y ago

> At the end of the day, for general programming, any paradigm is going to end up producing similar quality of code. Developer competence I'd say that "pure" paradigms tend to be almost equally bad (tried functional programming in production code, wasn't all it's advertised to be). But this actually leaves you with more freedom, because you have to pick pieces and create your own style. So it turns out to be more important, not less, that you understand the how and why of each paradigm. As for how good this particular article was - well, I agree with the premise and it gives links to sources. May not be the Mona Lisa of articles, but it got my upvote. I'm not a regular HN reader so it's the first article on this topic I've seen in a while.

excepttheweasel 11y ago

Author here, FWIW this article was one of many posts some colleagues and I wrote at Pivotal during a "blog writing tontine" to encourage us all to write more and develop our skills, written hastily and intended to be part of a series I didn't finish before leaving. My intention was to point readers to some of the good ideas that were emerging (more accurately: had emerged some time ago) from alternative paradigms and how they could be used to make OOP programs better. Agreed that its certainly more about the team than what syntax you use to push bytes around, but tools do matter.