Why not? When it comes to “I need a simple website with a rather generic editing interface that’s easy to deploy and maintain”, PHP based software is still king.
Isn’t the jury still out on whether abstractions like these offer concrete returns for the investment? Does the steep learning curve of languages like Haskell offer enough advantages compared to the cost of learning and writing it? Do we get fewer bugs and increased maintainability such that developing software using these languages is worth it, financially?
Consider an example. A team develops software in Haskell. They design it to be bug-free and maintainable, with free monad based DSLs and all that jazz, effectively taking about 500 man-hours. A year later they’ve spent only 50 man-hours in bug-fixing and improvements. Later, another team does the same in Java, writing up less abstract code but does it in 350 hours, and a year later, have spent about 200 hours in bug fixes and subsequent improvements.
The point here is that the numbers here is arbitrary but they are equal. If one cares about dollars, here, Java and Haskell are equal. Nobody making business desicions (unless they are about image) cares about what language systems are written in, only about cost (time).
So to make this point valid from a $$$ perspective we need to prove that:
The cost of writing and maintaining code with higher-kinded polymorphism will always be smaller than in code that doesn’t have these
The reduction is significant enough to warrant rewrites or organizational changes to switch teams to use FP
I don’t think the case here is clear, what I’ve seen we’ve failed to establish whether high-quality type systems do actually produce better software. They do prevent bugs, most probably, but if we can get away with writing crap and then spend time in fixes post-launch, amounting to equal or less hours than in other languages, it’s still not justified from a financial sense.
Don’t get me wrong, I’m a FP guy myself, a full-time Scala/Haskell programmer, but stating such financial claims as facts is naïve.
The point here is that the numbers here is arbitrary but they are equal. If one cares about dollars, here, Java and Haskell are equal.
Assuming the Java team is done featurewise (for some definition of done) after 350 hours, and the Haskell team after 500 hours, they are not equal. Opportunity costs. I’m not sure if your scenario describes that, though.
I’d like to add a couple of more points:
many bugs in day-to-day software are design and workflow logic bugs and issues. (“If I login and go there, I would like to able to add things to my list of things”) Many of those are not covered by a language per se. (Although some can be modeled, so I’d say I have hope for better-type languages)
Platform effects are often underestimated. Rails has a bad rep as a framework in some circles, but it brings an amazing amount of stuff and encoded knowledge to the table just by writing rails new (especially up-to-date secure data handling, covering many aspects of website security). While a fictive Haskell on Rails ecosystem would be great (and there are some attempts at that), they are exactly that: fictive.
Abstraction-based development has a problem: once there’s no abstraction for a thing, you are lost - or you find a new one. That thing is getting better depending on the age of the platform. Imperative coding, though, has the advantage of being very approachable to “quick hacks” that are somewhat within the model of the language.
Finally, I love FP and well-typed languages and always cringe when I see someone bashing out code in a very imperative or cargo-culting OO style. I do see no benefit in selling them as absolutely necessary to a working solution. There are so many more problems to solve that are not covered by either of those.
Instead of comparing Java and Haskell, instead compare:
Java
Java with higher-kinded polymorphism
Or:
Haskell without higher-kinded polymorphism
Haskell
I’ve been writing Java all week. Java with higher-kinded polymorphism would have saved my time copying/pasting code and now the ongoing cost of having to reason about copy/pasted code. Atlassian would have a better project delivered more quickly.
Java with higher-kinded polymorphism would have saved my time copying/pasting code and now the ongoing cost of having to reason about copy/pasted code. Atlassian would have a better project delivered more quickly.
I do agree with you there, but Java with higher-kinded polymorphism doesn’t exist. It’s cool do dream of tools that don’t exist and say they are better (and we need to do so!), but it doesn’t write the software of today.
This guy’s tech stack contains Elm, Haskell, and… Drupal?
Why not? When it comes to “I need a simple website with a rather generic editing interface that’s easy to deploy and maintain”, PHP based software is still king.
If you care about making dollars by writing software, you care about higher-kinded types.
Would you care to elaborate further as to why you believe this?
I don’t think anybody disagrees that polymorphism:
Higher-kinded polymorphism (the term “higher-kinded types” is a bit of a misnomer) just gives more of the above.
(Higher-kinded) polymorphism is great for business and a CTO should care deeply.
Isn’t the jury still out on whether abstractions like these offer concrete returns for the investment? Does the steep learning curve of languages like Haskell offer enough advantages compared to the cost of learning and writing it? Do we get fewer bugs and increased maintainability such that developing software using these languages is worth it, financially?
Consider an example. A team develops software in Haskell. They design it to be bug-free and maintainable, with free monad based DSLs and all that jazz, effectively taking about 500 man-hours. A year later they’ve spent only 50 man-hours in bug-fixing and improvements. Later, another team does the same in Java, writing up less abstract code but does it in 350 hours, and a year later, have spent about 200 hours in bug fixes and subsequent improvements.
The point here is that the numbers here is arbitrary but they are equal. If one cares about dollars, here, Java and Haskell are equal. Nobody making business desicions (unless they are about image) cares about what language systems are written in, only about cost (time).
So to make this point valid from a $$$ perspective we need to prove that:
I don’t think the case here is clear, what I’ve seen we’ve failed to establish whether high-quality type systems do actually produce better software. They do prevent bugs, most probably, but if we can get away with writing crap and then spend time in fixes post-launch, amounting to equal or less hours than in other languages, it’s still not justified from a financial sense.
Don’t get me wrong, I’m a FP guy myself, a full-time Scala/Haskell programmer, but stating such financial claims as facts is naïve.
Assuming the Java team is done featurewise (for some definition of done) after 350 hours, and the Haskell team after 500 hours, they are not equal. Opportunity costs. I’m not sure if your scenario describes that, though.
I’d like to add a couple of more points:
rails new(especially up-to-date secure data handling, covering many aspects of website security). While a fictive Haskell on Rails ecosystem would be great (and there are some attempts at that), they are exactly that: fictive.Finally, I love FP and well-typed languages and always cringe when I see someone bashing out code in a very imperative or cargo-culting OO style. I do see no benefit in selling them as absolutely necessary to a working solution. There are so many more problems to solve that are not covered by either of those.
Instead of comparing Java and Haskell, instead compare:
Or:
I’ve been writing Java all week. Java with higher-kinded polymorphism would have saved my time copying/pasting code and now the ongoing cost of having to reason about copy/pasted code. Atlassian would have a better project delivered more quickly.
I do agree with you there, but Java with higher-kinded polymorphism doesn’t exist. It’s cool do dream of tools that don’t exist and say they are better (and we need to do so!), but it doesn’t write the software of today.