Hacker News Reader

Comment by shin_lao | Hacker News Reader

Although I'm mainly a C++ developer, I'm a big fan of functional programming languages.

Haskell is more difficult, it requires to really grasp some computer science principles whereas you can start hacking php/python/ruby right away. It requires to actually think about what you're going to do instead of integrating a couple of libraries: that's a double edged sword.

You need to understand that the added value of Haskell for most start ups is near zero. It will more difficult to hire, the final result will not be better and in the end code quality matters less than business relevance.

If your technical founder is a Haskell guru and knows a couple of engineers, then sure, why not, it may provide some competitive advantage, otherwise just forget about it.

View on HN

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.

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.

> 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.

>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".

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.

If the outlook is short-term than I agree. You will always be able to hack out a quick solution in PHP/Ruby/Lisp much faster than Haskell. But this advantage is only unmitigated if you fail and the code goes away before it has to be maintained. If the code is going to be around for a while it's going to need to be maintained, and here the advantage of Haskell grows with the code base size. It's a bit deceiving because the type of bugs that Haskell will catch automatically are not so much of a burden in a greenfield Ruby project, rather it's years later after bitrot and layers of iteration and no one really understands the whole system anymore that the advantages of Haskell really shine.

Granted, if you don't know Haskell then it's not worth the cost to learn with everything else you need to juggle when doing a startup, but if you can, I believe there are significant long-term advantages.

It really depends on the type of risk. My assertion is that most startups have most of their risk in the market bucket rather than the technical bucket. If you can move some risk from the market bucket to the technical bucket, and compensate by using Haskell, that may be a good tradeoff.

in the case where your risk is in the market bucket, you may go through many just-barely-working prototypes before you hit product-market fit. at that point, if you've saved some time using Ruby (say) because of external factors like Heroku, Bundler, and ruby-friendly services, you're ahead of the game, even if your tenth prototype sucks and needs to be rewritten.

Obligatory link: http://www.paulgraham.com/avg.html

Reply on news.ycombinator.com