> but I'm sure that quote holds true
How can you be sure? Have you seen Haskell shops churn out software significantly faster than others?
How can you be sure? Have you seen Haskell shops churn out software significantly faster than others?
Are other banks really spending orders of magnitude more on that kind of software? I've heard that SC adopted Haskell when Lennart Augustsson -- who wrote the first Haskell compiler -- moved to SC from Credit Suisse. When he left CS, they stopped using Haskell. If Haskell gives an order-of-magnitude difference in productivity as you claim, why did CS drop it after Augustsson had left?
I never claimed "orders of magnitude" productivity from a language alone. Haskell has every weakly-typed mainstream imperative language as a valid subset. You need good people, teams and processes to get the best out of the language. This means it is difficult to do case studies without getting dismissed as anecdotal.
Most other banks have settled on Python for similar use cases. I hear on the grapevine that they have significant maintenance problems (unsurprisingly). Haskell is spreading to larger software in the bank and we are currently hiring.
So you are building in hours and days applications that other banks are spending weeks and months on.
I'd love to see a few case studies!!
Second, that Haskell "has every weakly typed mainstream imperative language as a valid subset" (which I don't think is accurate, because projects are not built from scratch, and libraries match a certain programming style) does not mean that Haskell is worth it. For the sake of argument, suppose Haskell has a 5% improvement in maintenance cost over Python but a 10% higher cost of adoption, then it's not worth it.
> CS did end up adopting functional programming and F# became their strategic choice.
That's great, but doesn't have much to do with Haskell. The investment required for a pure-FP language like Haskell seems to be much greater than the investment in an imperative functional language like F# (or Clojure). It seems like CS, after having evaluated Haskell, decided that it may not be worth it.
Not true. If enough FUD is spread about Haskell, for example it being a failure at CS, then it becomes difficult to convince management.
> If I don't have information, choosing Haskell would be far less rational than not choosing it
No one is suggesting choices be made blindly. Managers should hire good people and then delegate those decisions to those people. If they want to use Haskell, don't stop them due to lack of case studies.
> For the sake of argument, suppose Haskell has a 5% improvement in maintenance cost over Python but a 10% higher cost of adoption, then it's not worth it.
I don't subscribe to nineteenth-century management science. My point was that software development is more about people than technologies. You will never be able to compare Haskell and Python like that, without comparing the people behind the code. What we can say for sure, is that many good developers are asking to develop in Haskell. The best way for other developers to understand why, is to try it.
> That's great, but doesn't have much to do with Haskell.
You were implying that Haskell had failed somehow because SC had stopped using it. Decisions within large organisations are rarely made on purely technical grounds. I can assure you there are many Haskell advocates still there.
Haskell is not yet at an adoption level where anything said about it would qualify as FUD. If I told you I have a great cold remedy and all of my friends really like it, you saying that you may want some more carefully researched information first doesn't qualify as FUD. I don't see why anyone can be expected to make a rational decision based on nothing but marketing from enthusiasts. Haskell is not even at the point where management is the part of the organization that needs convincing.
> If they want to use Haskell, don't stop them due to lack of case studies.
That is precisely the job of responsible management: to stop technical teams from using expensive technologies, that are not only unproven, but hardly have any actual anecdotal information at all. The precise difference between management and developers is that management sees the bigger picture. As a manager I wouldn't mind technical people experimenting with Haskell or any other unproven technology on side projects, though.
> The best way for other developers to understand why, is to try it.
Yes, but when you come out with an experimental, very expensive drug, you don't say, "the best way for people to see if it works is to try it". Instead, some people try it, and then they research and report on their experience. After all, you're not asking me to try a new sorting routine, but a whole new language ecosystem. I understand why some early adopters and PL enthusiasts would be happy to try, but most organizations don't and shouldn't act in this way. There are tons of promising technologies. Is every company supposed to just try each one? Do we all need to try Elixir, Kotlin, Clojure, Scala, Haskell, F#, and Go? Now, it may not be fair, but the fact is that the more expensive the experiment, the more data we'd want before we'd allocate resources to conducting it. A language like Kotlin is nearly free for Java shops to try. Haskell? Not so much. The best way for other developers to understand is, therefore, for the few early adopters to research and report on their experience, with some actual data (cost, duration, size etc.).
> You were implying that Haskell had failed somehow because SC had stopped using it.
Yes, that is a very negative signal. I don't see how choosing F# changes things.
> Decisions within large organisations are rarely made on purely technical grounds.
True, but in general, organizations shouldn't make decisions on "technical grounds", but "bottom line grounds". Even that doesn't always happen, but it generally does, and it's reasonable to guess that if Haskell had had a huge advantage, it wouldn't have been abandoned. Also, remember that the converse is also true. If abandoning a language isn't conclusive evidence that it isn't cost-effective, adopting it isn't conclusive evidence that it is. That's why we need some data. It can be anecdotal data, but it must be actual data, and not a marketing lecture.
> I can assure you there are many Haskell advocates still there.
I'm sure there are. Unfortunately, the number or enthusiasm of advocates is never a substitute for evidence. It's perfectly fine that some early adopters are swayed by the advocates, but it's also perfectly rational not to be swayed by it. I absolutely believe that some people truly enjoy Haskell and feel that it makes them more productive, but without some data, it would simply be irresponsible to pay so much based on marketing alone.
In most cases management isn't qualified to make technical decisions. Managers rarely see the bigger picture.
I've worked on a Haskell project that worked, never crashed, was lightning fast and was meeting deadlines for new features without a problem. Then higher management decided to throw away probably around 7-10 man-years and rewrite the whole thing in Java, quite literally "just because Java". We even had a consultant from FP complete come over to take a look at our codebase and talk in front of management about the advantages of a mature codebase in Haskell. Management didn't even come.
Abandoning Haskell, in my case, had absolutely nothing to do with its technical merits and everything to do with incompetent management. When I left one year after they started rewriting the project in Java (I was staying to help maintain the Haskell code while the transition was happening) everything was buggy as hell, slow and unmaintainable. Not to mention that half the Java guys they hired had already left again.
All I could do is collect metrics like lines of code and intentionally vague experience reports from former colleagues who are still there, but I guess that's hardly gonna convince anybody.
Maybe "FUD" isn't precisely the right term, but Haskell does seem to attract a special level of attacks that isn't applied to other languages at a similar level of maturity.
> Is every company supposed to just try each one? Do we all need to try Elixir, Kotlin, Clojure, Scala, Haskell, F#, and Go?
Well, companies have to make the choice one way or another, and they don't seem willing to pay what it would cost to study these questions to a scientific level. And the decision to stick with "industry best practice" (probably currently Java) is not a safe option either - anyone who does that runs the risk of being outcompeted by those who pick a better lanugage.
> A language like Kotlin is nearly free for Java shops to try.
Oh? To my mind a language that young, backed by a relatively small company, and whose popularity is heavily based on marketing (including a history of repeatedly announcing features before they were actually implemented) would come with a high risk factor.
> The best way for other developers to understand is, therefore, for the few early adopters to research and report on their experience, with some actual data (cost, duration, size etc.).
Sure - but the business incentives don't seem to be there for those early-adopter businesses to publish that kind of report (whether the outcome is positive or negative). How can we make that happen?
It's a level of attack reserved for a special level of unsupported hype. I have absolutely no problem with those who say they really like Haskell, it fits well with how they think, and they feel more productive with it. I even have no problem with those who say that they believe the language has objective benefits in some domains and circumstances and that it deserves a closer look. But if you go around claiming that we can significantly reduce the cost of software development using your language (or any tool), I think an intsy-bitsy amount of even anecdotal evidence is required, especially after two decades.
You may not believe me, but I truly admire Haskell's elegance (even though I believe pure-FP is not the right path for most kinds of software; I have my own pet hypotheses). I just don't like the religious ecstasy that surrounds it.
> and they don't seem willing to pay what it would cost to study these questions to a scientific level.
Because in order for a business to invest in a costly experiment, there should first be some evidence that there's a good chance for the experiment to pay off significantly. Businesses aren't research institution, and they can't afford to invest in researching every new technology that somebody really likes.
> anyone who does that runs the risk of being outcompeted by those who pick a better lanugage.
As soon as the competition pulls ahead, people will be quick to flock to the new language. That's what happened with late Java adopters.
> would come with a high risk factor.
You're right that the risk isn't nonexistent, but it's relatively low (and Kotlin is backed by a larger company than the ones backing most new languages, with the exceptions of Go, Swift and maybe Rust). There's automatic translation and seamless interop, and gradual adoption is very easy. You can pick a class at random and translate it to Kotlin to test if build/debug/profile/deploy etc. works well, and then translate more classes. I'm not sure such a tool exists, but it should be fairly trivial to translate Kotlin back to very readable Java if the need arises to revert for whatever reason.
> but the business incentives don't seem to be there for those early-adopter businesses to publish that kind of report
I think that the business interests are there. If you invest heavily in a language, you'd want it to gain wide adoption so you get more maintenance, more libraries, easier recruiting, more tools and lower risk. The business interests would not be there if Haskell provided an incredible boost in productivity, that is so large that the competitive advantage offsets the downsides of low adoption. I don't think anyone is even making that claim.
How carefully researched was your very public assessment of what happened at CS?
> Do we all need to try Elixir, Kotlin, Clojure, Scala, Haskell, F#, and Go?
Of course not. Those interested in learning more about pure functional programming should try Haskell, the others have different niches they are trying to fill.
> If Haskell had had a huge advantage, it wouldn't have been abandoned
No one is claiming Haskell is some sort of magic bullet for all use cases. If you require ease-of-use, are writing disposable software, or high performance software, then it may not be the best choice.
Nobody is arguing against further studies, but I suspect that most of our industry isn't really interested. As I have said elsewhere, Haskell does not optimise for ease-of-use or aesthetics. It has a growing niche and will continue to be successful in that niche, with or without further productivity studies.
It wasn't. I simply stated that it's a negative signal; that's not FUD. It is a negative signal whether or not I mention it. Mentioning it gives Haskell advocates a chance to address it. You don't have to, but whatever you do, the signal is there. But it's just one signal. I don't think anyone should make a decision based on just one signal.
> Those interested in learning more about pure functional programming should try Haskell, the others have different niches they are trying to fill.
What should those interested in increasing productivity learn? This entire discussion isn't about learning a new programming style, but about achieving a goal of reducing development costs.
> No one is claiming Haskell is some sort of magic bullet for all use cases.
So what is the claim, and is there actual evidence (even anecdotal) to support it?
> I suspect that most of our industry isn't really interested.
The industry is extremely interested in anything that can significantly reduce the cost of developing software. We don't care if it's called Haskell or an omniscient debugger, or a static analysis tool.
> and will continue to be successful in that niche, with or without further productivity studies.
That's terrific, but don't blame the industry for being short-sighted and investing heavily in something that has little evidence of a great promise. You can only blame the industry for ignoring evidence, not for ignoring hype.
Productivity for whom? And over what timescales? As I have been trying to say, it is not that simple, you are oversimplifying.
> So what is the claim, and is there actual evidence (even anecdotal) to support it?
It sounds like you are completely satisfied with existing approaches, in which case there is little point in me trying to convince you.
> The industry is extremely interested in anything that can significantly reduce the cost of developing software.
Industry as a whole, does not have a good track record of adopting even good ideas in a timely manner. c.f. Garbage collection. So again, I think you are oversimplifying.
I'm only simplifying as much as the claims in the article. It's just pretty hard to understand what the claims about Haskell are given all of the vague hype. The article we're discussing says, "Haskell decreases development time by narrowing the scope of development to your domain." Obviously, I understand there are caveats, and it's unclear how big the savings are. I just want reports with some meat.
> It sounds like you are completely satisfied with existing approaches, in which case there is little point in me trying to convince you.
The question of being "completely satisfied" is irrelevant. I'm not a researcher and my goal isn't to dream up better approaches, nor do I have the resources to invest in experimenting with every new tool. I am, however, very interested if someone says they have a tool that can provide significant savings. If there were only some more actionable information, convincing me would be quite easy. I want to be convinced, but throwing general promises around serves to confuse more than enlighten.