Samuel Gélineau からの返信その1

Samuel Gélineauとは、現在はSimSpace Corporationで勤務しており
モントリオールでmeet-up の co-orginzerであり且つ
Mastering Haskell Programmingコースの講師である。
10年以上Haskell Programmingに関わっておりHaskellの有名ブロガーの一人である。

情熱的な先生に応える為、３シリーズに分けました
先生が示してるリンクは太文字の紫として表示しております。

返信その１

1. Do you think Haskell is underrated as an industrial, professional programming language by IT project managers?

Sure, I am happy to help!
Yes, definitely. There are a few aspects of Haskell which makes it look like a bad choice:

• Only a small fraction of companies use Haskell.This has a few consequences:

  • Haskell does not look like a safe choice, in the "nobody has ever been fired for buying IBM" sense.
  • Service providers who expose an API are unlikely to provide Haskell bindings for that API.

• Only a small fraction of programmers are familiar with Haskell. This has different consequences:

  • It looks like hiring Haskellers might be a challenge.
  • For any given domain, fewer people have written Haskell which deal with this domain, so we are less likely to find existing libraries for this domain.
  • Haskell is very different from conventional languages like C++, Java, and JavaScript. As a consequence: Senior employees who are comfortable with conventional languages might not be willing to make the jump. Junior employees might only have used conventional languages in school, so training them to use Haskell effectively might take a while.

• I think that a few of those objections are unfounded, but unfortunately some of them are true downsides, which have to be weighted against Haskell's advantages.

  • The number of companies which use Haskell is indeed very small, but it is growing. We're seeing a lot more job postings on the Haskell subreddit and on Twitter; in the past, each such posting was celebrated as proof that Haskell is finally breaking out into the industry, whereas today they are so common that people have started to complain about them!
    • Choosing Haskell is still a bold choice at the moment. For example, a friend created a startup and chose Haskell for the backend, but he knew that this choice would be considered a risk by investors, so he had to make safe choices everywhere else, for example he picked JavaScript instead of PureScript or GHCJS for the frontend. So this is indeed a downside.
    • At work, we are writing Haskell bindings for a third-party API, because we couldn't use the Java API they provided. So this is another real downside.
  • The number of programmers who are familiar with Haskell is small, but it is growing too! People no longer assume I said "Pascal" when I say "Haskell", and even Java programmers have heard of Monads.
    • The reason the small number of available Haskellers makes it seem like hiring is going to be difficult is that with popular languages, it is often necessary to interview a large number of candidates -before finding one which is worth hiring. But as Paul Graham explains in "The Python Paradox", those who bother to learn the good-but-not-yet-popular languages are those developers who are passionate about their job and really care about the quality of their tools. Python was not nearly as ubiquitous as it is today when Paul Graham wrote his essay. If he wrote this essay today, I'm sure he would have called it the Haskell paradox instead. Anyway, it's not just an essay, I found it to be true in practice: at work, we're hiring both Haskell and JavaScript programmers, and while we have had many more JavaScript applicants than Haskell applicants, our Haskell positions were a lot easier to fill than our JavaScript positions.
    • As for libraries, the days in which you were likely to have to write your own library are long gone. Nowadays, when people complain about libraries, it's because they have looked at six existing alternatives and still aren't happy or couldn't decide which one to pick, etc. -It is true that Haskell is very different from conventional languages, and that's a good thing! You can't improve on the status quo without being different from the status quo.
    • Unfortunately, it is true that senior developers who are comfortable with conventional languages might be unwilling to adapt. I have encountered circumstances in Java and C++ projects in which Haskell-inspired techniques would have been a great fit, but I have never been able to convince my otherwise-reasonable colleagues to adopt them. Another time, a Java programmer was helping us with a Scala program, our tech lead tried to show him how to make his code more functional, that led to a debate, and then to a verbal fight :( Of course, different people will react differently, so introducing FP to an OO-trained team isn't guaranteed or even likely to end in tears, but it's a possibility which needs to be considered.
    • About training time: yes, if someone is only familiar with conventional programming languages, then learning another conventional programming language will be easier and faster than learning a wildly dissimilar programming language such [as Haskell. This is just as true for junior programmers as for senior programmers. However, the extra training time is worth it: as John Wiegley explains, all languages have a cost, but in the case of Haskell most of the cost is paid upfront, while learning the language, instead of having to pay continuously while using the language.

感想

プログラマーのトレーニングという観点から、
言語の採用を論じているサミュエル先生のお話はとても面白かったです。
日本のIT産業界に置いても十分当てはまる議論なのではと思います。
例えばHaskellプログラマーを育てるには、ある程度のレベルに達するまでに
他の言語に比べてある程度のコストが必要なことは確かであり、
企業がHaskellプロジェクトを立ち上げるにあたっても、Haskellを選びづらくしている要因の一つかもしれません。

明日は質問その2に対しての先生の返信を書きたいと思います。