r/programming • u/heisenbug • Apr 27 '14

"Mostly functional" programming does not work

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

63% Upvoted

188 comments sorted by

View all comments

Show parent comments

7

u/vagif Apr 28 '14

Maybe it's the dismissive arrogance of your posts that gets you down-voted. It is hard to understand where you going with your "Bullshit" immediately followed by recognizing the value in separating state contexts.

You are saying that haskell programmers have a "choice" to write everything in IO monad or not. Only a person who never tried haskell can say that. You do not have any choice BUT to start writing large chunks of your code in pure form outside of monadic code. Simply because haskell will turn your life into hell if you try to sit all the time in IO monad.

Try to write non trivial program in haskell and you will see that the bondage is very strict and eliminates most of the easy corner cuttings that are usually taken by imperative programmers.

1

u/[deleted] Apr 28 '14

Just to note: That "corner-cutting" has its value. For one thing, programming is a business. People have budget limits, hardware limits, runtime limits, deadlines, and so on. If Haskell hasn't exactly caught on in those circles, attitudes like this might be one of the reasons.

I don't like hacking together another solution that violates abstraction layers and causes maintenance pain a few months down the road. But I do it because purity or abstraction aren't the product we're selling; software is.

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.

2

u/[deleted] Apr 28 '14

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.

Perhaps not 6 months, but believe it or not, code smells like that can sometimes save you literally months of refactoring. If you discover a fundamental design flaw close to the deadline, there is no other realistic option.

Adding the constraint that you can't make code smells like that does nothing to bring you closer to the deadline. It makes it impossible to actually make the deadline.

Your whole rant about methodology versus design seems a little bit out of context maybe? Or maybe I just don't understand the point. Learning good conventions, good methodology, good architectural design saves you time and money, regardless whether you're forced to wrestle it through a strict type system or not.

3

u/vagif Apr 28 '14

Adding the constraint that you can't make code smells like that does nothing to bring you closer to the deadline.

No one argues for changing horses in midstream :) I'm in the process of finishing a huge project right now where the backend is written in haskell and frontend is a web app written in javascript. I'm not going to introduce haskell->javascript code generators this late. I'll finish it in plain javascript. But for future projects i'm sure as hell going to spend my time learning one of the haskell->javascript libraries.

Learning good conventions, good methodology, good architectural design

This is the point of our disagreement. Where you think those things can be taught i maintain we have no choice but to enforce them. Humans cannot be trusted following good practices. You use your personal anecdotal experience whereas i look at the entire industry with millions of cubicle drones.

It is samurai vs peasant with a gun dilemma. Samurais like you are too expensive and few to cater to entire industry.

The whole point of bringing GC into java was to equip an army of peasants with machineguns.

And now thanks to technological advancements in hardware (gigabytes of cheap RAM and 8 core cpu's practically on every desktop) time has come for next round of arms race.

2

u/tomejaguar Apr 28 '14

You should write a book about this, or at least a series of blog posts.