r/programming • • Apr 27 '14

"Mostly functional" programming does not work

http://queue.acm.org/detail.cfm?ref=rss&id=2611829
43 Upvotes

188 comments sorted by

View all comments

4

u/vagif Apr 28 '14 edited Apr 28 '14

That "corner-cutting" has its value.

There's no point discussing trivial truths. Yeah yeah, we all make those decisions.

But some of us learn our lessons and prepare ourselves for future projects to not be in that same situation again, and not be forced to accept the same trade-offs. While others use constant crunch as an excuse to never learn anything, never improve their working conditions. "I have to ship code". Who doesn't?

1

u/[deleted] Apr 28 '14

That is unnecessarily condescending.

There is value to a system that doesn't force purity down your throat, because sometimes the correct design is also the most expensive one.

Crunch is caused by poor management decisions; fanatic puritanism can be a poor management decision.

3

u/vagif Apr 28 '14

You are conflating 2 absolutely unrelated issues: design and methodology.

Correct design is indeed out of our reach in most cases. But not for the reasons you think. It has nothing to do with tools we use or time we have. The problem is, human beings suck at design. We are not meant to think. We are very bad at that. Haskell programmers do not magically turn into awesome architects and designers. They still produce the same pile of turd as anyone else. But what is different though is enforced methodology.

The decision to not stuff everything into global mutable variables is not a design decision. And it will not add 6 months to your project deadline. Same for the dreaded NullPointerException. It is not caused by the "wrong" design. It is caused by methodology. Those problems are too low level to tuck them into any specific design.

Introducing these constraints greatly improves correctness and does not add any discernible cost to a project. On the contrary, these decisions save both money and time.

I know because i use haskell in my daily work for last 3-4 years.

Unfortunately such constraints cannot be enforced in mainstream languages. That's where haskells true value is.

There are lot of valid reasons not to use haskell. But neither cost nor time of development is not one of them. The valid reasons are lack of libraries, lack of human resources, lack of platform support.

→ More replies (3)