5 ms·

Meh, this is unfortunate advice because everyone tends to act this way too much. Almost everybody errs towards stable technologies; the exceptions are people wi

by tikhonj 14y ago

Meh, this is unfortunate advice because everyone tends to act this way too much. Almost everybody errs towards stable technologies; the exceptions are people with a genuine interest in the novel. They are disproportionately vocal so judging from the internet there's a lot of them, but in reality they're a minority. This makes sense psychologically. The cost of spending an extra day setting up a build system? It's obvious, hard to miss and annoying. A 10% benefit to productivity thanks to a superior programming model? Sure, that'll add up to a day in just two weeks of use, but most people wouldn't notice it at all! This is doubly true if the benefit is delayed--for example, if you win out on less time spent on maintenance and debugging. I've seen far more people ignore great technologies for fairly limited and superficial reasons that I've seen use superior technology in the face of true practical concerns. Too often it's something like "well, yes, it's much better, but it doesn't have a JSON parser built in". Of course, writing a JSON parser should take less than a day, so the cost is essentially negligible. That example, coincidentally, is taken from a talk by Brian O'Sullivan about running a startup with Haskell. (I don't have a link to it handy, I'm afraid.) Essentially, he found that the productivity benefits outweighed having to write some basic libraries (including a JSON one) himself. And he shared those libraries with the community, so everyone is now better off. So my advice is completely the opposite: don't be distracted by superior polish.

BruceIV 14y ago
Counter-example: A few years back, I was looking for a way to do user authentication for HTTP web services; I decided that HTTP Basic/Digest weren't sufficiently cryptologically strong - OAuth was the new hotness, so we were going to use that. There was a nice Apache-licenced library, but it wasn't laid out right for our purposes, so I spent two weeks re-writing it [maintenance burden #1]. Then I had to integrate it into our (terribly ill-documented open-source) web services framework [maintenance burden #2], then we had to make it work with the other OAuth libraries [maintenance burden #3]. And of course, it was all new, so there was no documentation anywhere on how to make it work, but if I'd been working with better established tech I wouldn't have wasted those weeks of development work, and that project wouldn't still be using OAuth 1.1. There were no productivity benefits to the new tech (quite the opposite, in fact), and the technical benefits were likely unneccessary.
dllthomas 14y ago
> Of course, writing a JSON parser should take less than a day, so the cost is essentially negligible. Writing a JSON parser that parses my examples correctly is a couple hours at most, yes. Writing a JSON parser that I am confident is correct and robust and efficient takes somewhat longer.
- ams6110 14y ago
  It's really more of a case of porting a JSON parser because many working examples of JSON parsers already exist, as do complete sets of test data that your parser must be able to handle. There's really not a lot of original thought that has to go into recreating something that's already well-established elsewhere.
  - dllthomas 14y ago
    Fair point. There can still be a lot of work to ensure robustness and efficiency in the new setting (especially so if the execution model is particularly different).
- jfoutz 14y ago
  Haskell, and BoS, i think, are both special cases. First, Haskell is actually pretty old. There are changes, of course, but the core language is '98. IIRC, Brian O'Sullivan wrote a high performance parsing library, attoparsec. In general, I think i agree with the article. In this specific case, it's a fantastic example of leveraging your strengths to do something amazing.
soup10 14y ago
Pretty bad advice imo. History is littered with examples of tech companies that used the wrong programming technology to build their app, then had to rewrite or otherwise go through significant pain when the failings became apparent at scale. Haskell is a bad choice for business simply because you limit yourself to a very small talent pool. On the other hand, the beauty of a small startup is that you can do whatever the fuck you want. If Sullivan knew a few really good haskell programmers, it may even have been the correct business decision in his case. But if I were making a web back-end meant to scale, and I know very good java programmers and very good haskell programmers, it makes more sense to go with the tried and true(even though it's not as fun). I would also take most X language is better than Y with huge grains of salt. It's much like the my phone is better than your phone debate, the people making the noise have spent thousands of hours deeply learning language X and tend to be heavily biased.
- calopetreep 14y ago
  > Haskell is a bad choice for business simply because you limit yourself to a very small talent pool. Actually, there are many more Haskell programmers than jobs available, so it's possible to pick and choose when hiring.
  - soup10 14y ago
    Interesting, but how many are good enough that they make up for the handicaps of poor library support and whatever other issues people have when they use Haskell for 'real' work. And how many are willing to stay at your company when it becomes bigger and more boring? Many Haskell programmers come from academia, how many are willing to do boring business logic? Not saying it's always the wrong choice, but I think there's pretty sound reasoning for avoiding esoteric languages.
    - calopetreep 14y ago
      Actually, I've found that Haskell libraries are absolutely fantastic- For me, its ecosystem is superior to other languages I've used, and I find libraries tend to be better designed and easier to pick up and use. > And how many are willing to stay at your company when it becomes bigger and more boring? I feel like this is an argument that could apply to any set of programmers- I'm not sure I see how it's relevant to Haskellers in particular. > Many Haskell programmers come from academia, how many are willing to do boring business logic? I don't know, but it's almost certainly non-zero. I know of a few Haskellers with PhDs working in startups.
gtani 14y ago
No Meh: you and the blogger are substantially in accord on your optimal tech stack: someone would inevitably point out a language that gracefully handled that particular issue in a much nicer way than Haskell, ML, or Erlang. Except that the suggested language was an in-progress research project.
malandrew 14y ago
Here's the Brian O'Sullivan presentation: http://www.infoq.com/presentations/Running-a-Startup-on-Haskell http://www.infoq.com/presentations/Running-a-Startup-on-Hask...

by tikhonj 14y ago

BruceIV 14y ago

Counter-example: A few years back, I was looking for a way to do user authentication for HTTP web services; I decided that HTTP Basic/Digest weren't sufficiently cryptologically strong - OAuth was the new hotness, so we were going to use that. There was a nice Apache-licenced library, but it wasn't laid out right for our purposes, so I spent two weeks re-writing it [maintenance burden #1]. Then I had to integrate it into our (terribly ill-documented open-source) web services framework [maintenance burden #2], then we had to make it work with the other OAuth libraries [maintenance burden #3]. And of course, it was all new, so there was no documentation anywhere on how to make it work, but if I'd been working with better established tech I wouldn't have wasted those weeks of development work, and that project wouldn't still be using OAuth 1.1. There were no productivity benefits to the new tech (quite the opposite, in fact), and the technical benefits were likely unneccessary.

dllthomas 14y ago

> Of course, writing a JSON parser should take less than a day, so the cost is essentially negligible. Writing a JSON parser that parses my examples correctly is a couple hours at most, yes. Writing a JSON parser that I am confident is correct and robust and efficient takes somewhat longer.

ams6110 14y ago
It's really more of a case of porting a JSON parser because many working examples of JSON parsers already exist, as do complete sets of test data that your parser must be able to handle. There's really not a lot of original thought that has to go into recreating something that's already well-established elsewhere.
- dllthomas 14y ago
  Fair point. There can still be a lot of work to ensure robustness and efficiency in the new setting (especially so if the execution model is particularly different).
jfoutz 14y ago
Haskell, and BoS, i think, are both special cases. First, Haskell is actually pretty old. There are changes, of course, but the core language is '98. IIRC, Brian O'Sullivan wrote a high performance parsing library, attoparsec. In general, I think i agree with the article. In this specific case, it's a fantastic example of leveraging your strengths to do something amazing.

soup10 14y ago

Pretty bad advice imo. History is littered with examples of tech companies that used the wrong programming technology to build their app, then had to rewrite or otherwise go through significant pain when the failings became apparent at scale. Haskell is a bad choice for business simply because you limit yourself to a very small talent pool. On the other hand, the beauty of a small startup is that you can do whatever the fuck you want. If Sullivan knew a few really good haskell programmers, it may even have been the correct business decision in his case. But if I were making a web back-end meant to scale, and I know very good java programmers and very good haskell programmers, it makes more sense to go with the tried and true(even though it's not as fun). I would also take most X language is better than Y with huge grains of salt. It's much like the my phone is better than your phone debate, the people making the noise have spent thousands of hours deeply learning language X and tend to be heavily biased.

calopetreep 14y ago
> Haskell is a bad choice for business simply because you limit yourself to a very small talent pool. Actually, there are many more Haskell programmers than jobs available, so it's possible to pick and choose when hiring.
- soup10 14y ago
  Interesting, but how many are good enough that they make up for the handicaps of poor library support and whatever other issues people have when they use Haskell for 'real' work. And how many are willing to stay at your company when it becomes bigger and more boring? Many Haskell programmers come from academia, how many are willing to do boring business logic? Not saying it's always the wrong choice, but I think there's pretty sound reasoning for avoiding esoteric languages.
  - calopetreep 14y ago
    Actually, I've found that Haskell libraries are absolutely fantastic- For me, its ecosystem is superior to other languages I've used, and I find libraries tend to be better designed and easier to pick up and use. > And how many are willing to stay at your company when it becomes bigger and more boring? I feel like this is an argument that could apply to any set of programmers- I'm not sure I see how it's relevant to Haskellers in particular. > Many Haskell programmers come from academia, how many are willing to do boring business logic? I don't know, but it's almost certainly non-zero. I know of a few Haskellers with PhDs working in startups.

gtani 14y ago

No Meh: you and the blogger are substantially in accord on your optimal tech stack: someone would inevitably point out a language that gracefully handled that particular issue in a much nicer way than Haskell, ML, or Erlang. Except that the suggested language was an in-progress research project.

malandrew 14y ago

Here's the Brian O'Sullivan presentation: http://www.infoq.com/presentations/Running-a-Startup-on-Haskell http://www.infoq.com/presentations/Running-a-Startup-on-Hask...