3 ms·

You need to understand that the added value of Haskell for most start ups is near zero. I used to have that opinion as well, but I am slowly retracting it. Ver

You need to understand that the added value of Haskell for most start ups is near zero. I used to have that opinion as well, but I am slowly retracting it. Very strong typing and great abstraction does make development easier. E.g., I have been writing parsers lately for an application-specific macro language. Writing such parsers using a good Haskell parser combinator library such as parsec is many times more productive than parser generators for most imperative languages. Another advantage is that strong languages allow you to refactor code easily. If you change some types, the compiler will find type mismatches, allowing you to fix code rapidly. I can imagine that startups often refactor and substantially modify their codebase. In the end you do not only want to develop an application quickly, but also correctly. If a strong language can be used to eliminate most errors and improve productivity, I see it as an asset to a startup.

shin_lao 14y ago
You have tools to help you find mismatches in Python. I agree that maintaining a large code base in Python (or Ruby) is harder, but it's possible and is mainly a question of discipline and process. If a strong language can be used to eliminate most errors and improve productivity, I see it as an asset to a startup. Most startups projects I've seen are technically trivial.
- chii 14y ago
  > Most startups projects I've seen are technically trivial. may be this is due to the fact that technically non-trivial problems aren't easily solved by startups, who might tend to choose a technology thats easy to use (such as php/ruby), but makes it difficult to solve the technically non-trivial problems with the same degree of ease? I m just guessing here having no real insight.
- papsosouid 14y ago
  >Most startups projects I've seen are technically trivial. Most startup projects are made by people who are only capable of solving technically trivial problems, and who are only willing to consider languages that make solving difficult problems borderline impossible. Imagine someone said "welding is a good way to fasten metal to metal". You are responding with "all the carpenters I've seen use screws".
mwotton 14y ago
A lot of context is lost in a slideshow. I am very much a fan of the experience of developing in Haskell. My problem was tangential stuff like Cabal & the difficulty of operationalising Haskell. It's the reason I spent a few fruitless weekends trying to get a heroku haskell buildpack: if it was trivial to deploy prototypes, it would be a much more appealing target for time-poor startups.

shin_lao 14y ago

You have tools to help you find mismatches in Python. I agree that maintaining a large code base in Python (or Ruby) is harder, but it's possible and is mainly a question of discipline and process. If a strong language can be used to eliminate most errors and improve productivity, I see it as an asset to a startup. Most startups projects I've seen are technically trivial.

chii 14y ago
> Most startups projects I've seen are technically trivial. may be this is due to the fact that technically non-trivial problems aren't easily solved by startups, who might tend to choose a technology thats easy to use (such as php/ruby), but makes it difficult to solve the technically non-trivial problems with the same degree of ease? I m just guessing here having no real insight.
papsosouid 14y ago
>Most startups projects I've seen are technically trivial. Most startup projects are made by people who are only capable of solving technically trivial problems, and who are only willing to consider languages that make solving difficult problems borderline impossible. Imagine someone said "welding is a good way to fasten metal to metal". You are responding with "all the carpenters I've seen use screws".

mwotton 14y ago

A lot of context is lost in a slideshow. I am very much a fan of the experience of developing in Haskell. My problem was tangential stuff like Cabal & the difficulty of operationalising Haskell. It's the reason I spent a few fruitless weekends trying to get a heroku haskell buildpack: if it was trivial to deploy prototypes, it would be a much more appealing target for time-poor startups.