5 ms·

AFAIK, Credit Suisse only used Haskell for one particular project and that project came to a natural end. CS did end up adopting functional programming and F# b

by willtim 10y ago

AFAIK, Credit Suisse only used Haskell for one particular project and that project came to a natural end. CS did end up adopting functional programming and F# became their strategic choice. 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.

sheepmullet 10y ago
> and can assemble applications in hours or days, rather than weeks or months as is typical. 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!!
- willtim 10y ago
  It does takes significant investment to get to this point though. SCB have been building APIs and components in Haskell for 8 years. We can now glue these parts together very easily and can be confident it will work, thanks to strong types. With less disciplined languages and/or teams, 8 years of development can yield a codebase that most will want to throw away and start again.
pron 10y ago
First, anecdotal case studies are much harder to dismiss than the nothing we have now, and as case studies accumulate they become harder and harder to dismiss. Also, dismissal is not the point. People and organizations are free to make their own considerations and choose their tools. I'm not talking about a marketing campaign. It's about information. If I don't have information, choosing Haskell would be far less rational than not choosing it (in the absence of information, it is more rational to stick with what you have rather than pay heavily for something that may have a positive, neutral or even negative effect). 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.
- willtim 10y ago
  > People and organizations are free to make their own considerations and choose their tools. 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.
  - pron 10y ago
    > If enough FUD is spread about Haskell, for example it being a failure at CS, then it becomes difficult to convince management. 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.

by willtim 10y ago

sheepmullet 10y ago

> and can assemble applications in hours or days, rather than weeks or months as is typical. 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!!

willtim 10y ago
It does takes significant investment to get to this point though. SCB have been building APIs and components in Haskell for 8 years. We can now glue these parts together very easily and can be confident it will work, thanks to strong types. With less disciplined languages and/or teams, 8 years of development can yield a codebase that most will want to throw away and start again.

pron 10y ago

First, anecdotal case studies are much harder to dismiss than the nothing we have now, and as case studies accumulate they become harder and harder to dismiss. Also, dismissal is not the point. People and organizations are free to make their own considerations and choose their tools. I'm not talking about a marketing campaign. It's about information. If I don't have information, choosing Haskell would be far less rational than not choosing it (in the absence of information, it is more rational to stick with what you have rather than pay heavily for something that may have a positive, neutral or even negative effect). 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.

willtim 10y ago
> People and organizations are free to make their own considerations and choose their tools. 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.
- pron 10y ago
  > If enough FUD is spread about Haskell, for example it being a failure at CS, then it becomes difficult to convince management. 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.