Hacker News Reader

Comment by davidp | Hacker News Reader

I am simultaneously intrigued by the possibilities of functional programming, and horrified by the ways it can take people off into the weeds.

Were I to use Haskell in a real-world project with teammates, I'd have to keep an iron grip on the complexity of the code the team writes. Maintainability (mainly readability/comprehensibility as far as I'm concerned) is far more important for the kind of work I do than theoretical purity and hypothetical applicability to classes of problems the team isn't facing.

I could easily keep things on the rails on my own, but I suppose it's simply unsettling thinking about using Haskell for something sizable; probably due to my own lack of experience with it. I'd love to hear about sizable real-world Haskell projects, since I think FP is the future of software engineering.

View on HN

This is a Haskell insider-joke. As is the The International Obfuscated C Code Contest. You wouldn't judge the value of the C language for writing, let's say, a unix kernel based on the code from IOCCC, would you?

Don't take it so seriously.

Your concerns resonate with me. I think in most cases, particularly in commercial software development, we should value clarity, familiarity, and maintainability over cleverness, expressiveness, and terseness.

I think that like Haskell, Scala's flexibility tends to take some people off into the weeds. See, for example, Coda Hale's concerns about using Scala at Yammer, from about 2 years ago:

http://codahale.com/downloads/email-to-donald.txt

However, I think we need to be careful not to overvalue familiarity. Rich Hickey's talk "Simple Made Easy" is well-known, and I think he's correct to tell us that we should value simplicity over ease. I guess the answer is to use functional programming to make our software simpler, and not let cleverness take us off into the weeds.

Isn't maintainability going to be significantly added by so much being statically checked? Even if people are writing functions that are internally ugly, wouldn't haskell largely enforce that those functions can't really hurt the outside world?

It seems to me like "off the rails" in a pure language is going to be much nicer than off the rails in a language where mutable state is the norm.

I used to think this about Java's static typing. Then I worked on a ten person team writing a SAAS project, which had some... less than stellar coders. They would write 800 line functions, complete with 15 levels of nested "if else" statements and two-letter variable names.

Yes their code sorta worked, but Deity help you when it came time to add a feature or fix a bug.

Contrawise, my next project was with a team of moderately competent Perl programmers. Functions were concise and variable names reasonably clear. Maintenance was a breeze by comparison.

People who are going to use bad variable names and 800 line functions are probably not even worth thinking about, but if you had a bunch of mediocre programmers working in each language (perl, java, haskell), do you think their code would be more maintainable as you moved up the level of static typing? I would think so, but I don't have any actual experience with this or a really strong opinion on the subject.

My point is that architecture and programmer ability is a much stronger influence on maintainability than type system IME. Although your experiment would be an interesting one.

Java's static typing did make it easier to traverse the code using an IDE, and avoided the occasional subtle type casting bug. The easy integrated debugging was nice too (eg setting remote breakpoints).

These benefits were vastly offset by the productivity hit from wading through boilerplate code, language verbosity and dealing with type conversion issues.

> Isn't maintainability going to be significantly added by so much being statically checked? Even if people are writing functions that are internally ugly, wouldn't haskell largely enforce that those functions can't really hurt the outside world?

Yes and yes (in my experience).

Most of these aren't detailed but it's a start. FP complete is a startup devoted to bringing haskell into more production systems

http://www.joachim-breitner.de/blog/archives/606-Real-World-...

http://corp.galois.com/systems-software

http://www.haskell.org/haskellwiki/Haskell_in_industry

http://cufp.org/conference/schedule/2012

https://www.fpcomplete.com/business/resources/case-studies

_____________

similar for scala http://typesafe.com/company/casestudies

You can probably find as many ways to write an algorithm in most languages. At least here the different versions vary in length by at most one page ;)

FP is the future of software engineering, and always will be.

Clojure has worked wondrously for myself and my colleagues in terms of clean, nice idiomatic code that doesn't require a bunch of marshalling code standards together.

Reply on news.ycombinator.com