Why do you dismiss this as dogma and not practical for real world use? I have used similar techniques in everything from bank customer portals to complex embedded systems. Our industry is plagued by bug ridden, crappy software. Please be a part of the solution, and not the problem.
> Why do you dismiss this as dogma and not practical for real world use?
I didn't, but the article does explicitly dismiss Agile "silliness", where one of the basic priorities is achieving working software.
> Our industry is plagued by bug ridden, crappy software.
Yes, it is. However, while I am as keen as the next guy to improve the quality of software, I also take the pragmatic view that you have to ship something before the quality is even relevant.
In particular, my personal experience has been that on real projects, there is a heavy price to pay for using anti-idiomatic techniques when it comes to maintenance time. Likewise, I have found that there is a heavy price to pay for using complicated APIs where simpler ones can do the job.
That means any benefits from techniques such as those advocated in the article must outweigh those costs before use of the techniques is justified. If a technique helps to prevent programmer errors that were otherwise likely, then that is a benefit to project quality that has some value. However, techniques that are theoretically neat but only remove classes of programmer error that were unlikely anyway are not inherently valuable, and once you're talking about real world projects with more open problem spaces, trying to check everything conceivable at compile time sounds a lot like one of those theoretically neat examples to me.
(As an aside, I aim similar criticism at various other trendy techniques in our field. I'm just as happy taking potshots at certain popular Agile techniques, such as prioritising unit testing everything even if it means compromising a sound modular design so the tests can have access to the internals of each module. Unit tests can be useful, but that corruption in the design comes with a price tag that has to be justified.)
> Please be a part of the solution, and not the problem.
It is interesting that when faced with a critic who does not accept theoretically sound/academically neat techniques as inherently superior to existing real world techniques, some people will assume that the critic is ignorant and/or lazy. Why is that?
First off, I apologize. I was in a horrible mood when I left this post, and you struck a nerve. I appreciate the discussion.
I don't understand this dichotomy between needing to ship, and creating quality software. It only exists because of the tools we choose to use. The techniques he discusses in this article I feel are founded in (pure) functional programming. These techniques have been around for quite some time. I have been using these techniques in languages from Haskell to C/C++ as much as possible, and they have vastly increased the quality of the software I write (measured in defects). I also do not feel they have slowed me down much at all. In fact, they really have forced me to think more about the problems I am solving and in the end creating better solutions faster (instead of constantly refactoring and unit testing).
He doesn't dismiss the technique as dogma. He dismisses the author for being dogmatic - there is a difference. I think Silhouette supported his actual reasons for not liking the technique.
Further, I think he is part of the solution by engaging in rational discussion of the issue.
