7 ms·

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 Ha

by davidp 13y ago

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.

mwcampbell 13y ago
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 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.
gtani 13y ago
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-Haskell-Applications%20.html http://www.joachim-breitner.de/blog/archives/606-Real-World-... http://corp.galois.com/systems-software http://corp.galois.com/systems-software http://www.haskell.org/haskellwiki/Haskell_in_industry http://www.haskell.org/haskellwiki/Haskell_in_industry http://cufp.org/conference/schedule/2012 http://cufp.org/conference/schedule/2012 https://www.fpcomplete.com/business/resources/case-studies https://www.fpcomplete.com/business/resources/case-studies _____________ similar for scala http://typesafe.com/company/casestudies http://typesafe.com/company/casestudies
hiker 13y ago
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.
coolsunglasses 13y ago
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.
jeremiep 13y ago
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 ;)
6ren 13y ago
FP is the future of software engineering, and always will be.
cgag 13y ago
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.
- nikatwork 13y ago
  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.
  - cgag 13y ago
    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.
    - nikatwork 13y ago
      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.

by davidp 13y ago

mwcampbell 13y ago

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 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.

gtani 13y ago

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-Haskell-Applications%20.html http://www.joachim-breitner.de/blog/archives/606-Real-World-... http://corp.galois.com/systems-software http://corp.galois.com/systems-software http://www.haskell.org/haskellwiki/Haskell_in_industry http://www.haskell.org/haskellwiki/Haskell_in_industry http://cufp.org/conference/schedule/2012 http://cufp.org/conference/schedule/2012 https://www.fpcomplete.com/business/resources/case-studies https://www.fpcomplete.com/business/resources/case-studies _____________ similar for scala http://typesafe.com/company/casestudies http://typesafe.com/company/casestudies

hiker 13y ago

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.

coolsunglasses 13y ago

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.

jeremiep 13y ago

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 ;)

6ren 13y ago

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

cgag 13y ago

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.

nikatwork 13y ago
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.
- cgag 13y ago
  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.
  - nikatwork 13y ago
    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.