4 ms·

If you want to save some clicking: - Author picks Lift/Scala not on the best future interests of the company (ease of hiring, scalability, agility, maturity) b

If you want to save some clicking: - Author picks Lift/Scala not on the best future interests of the company (ease of hiring, scalability, agility, maturity) but on fit for his world view about type safety and it would be fun for him. - Author commits startup to stateful servers / scaling issues from day 1 of the rewrite.

hubb 17y ago
that's not how i read it at all. he's experienced with java, prefers statically typed languages, and has had a lot of success so far with scala. for accusing someone of a heavy bias you're doing a pretty good job yourself
- wavesplash 17y ago
  That's a very narrow definition of success. There are at least 3 areas of technical focus at a startup after you reach product/market fit: 1) ease of feature development 2) ease of hiring 3) ease of scale under load The author sacrificed 2, needlessly created well-known scale issue that could be avoided in 3 (basic distributed systems class), for no substantial improvement over the other options for 1. Yes, I have a bias towards startup team members factoring in their future impact on their coworkers and the company.
sreque 17y ago
If you only pick tools that everyone else knows so your hiring pool is large, then new tools never stand a chance of being used. You would stagnate all progress in the industry! It's funny because when Paul Graham writes articles about how the web lets us use whatever language we want (see http://www.paulgraham.com/avg.html http://www.paulgraham.com/avg.html), everyone celebrates the possibilities of writing their web site in their favorite lisp dialect. Yet here we have this evil engineer who picks a technology he likes, successfully improves a product and meets business requirements with it, and is ridiculed for picking a relatively obscure technology! Check out tiobe. I wouldn't be surprised if in a year Scala passes the combination of all lisp/scheme dialects in the rankings.
- wavesplash 17y ago
  Startups aren't about language diversity for the sake of diversity, they're about unfair leverage. In this case the author made a choice that didn't add any leverage to Foursquare. If anything, the author admits he boxed the company into a corner because of a rookie scaling decision. In contrast, the Asana guys are writing their own language+framework and if it delivers on it's early promise they'll be outgunning the competition with a 10x improvement on development time and code size. http://asana.com/luna http://asana.com/luna That's the sort of advantage Paul Graham had by using Lisp in ViaWeb vs. his competition that was mostly writing c++.
  - sreque 17y ago
    My criticism wasn't of your comment that Lift was a poor choice because it doesn't scale well. It was of your comments that the technology shouldn't be used because there aren't that many developers to hire that know/are willing to learn scala/lift or that it isn't as mature as some other technologies. As for your argument on scalability, while I have dabbled in Lift, I am too ignorant to know how much work it would take to scale Lift versus alternative technologies. I find it hard to believe that choosing Lift is really going to make it that hard to scale. David Pollak and the creators of Lift seem like they are pretty smart people to me. However, I have no evidence to prove you wrong and therefore did not even address that point.
    - wavesplash 17y ago
      I don't believe I made that argument. Here's my point as a startup conjecture: "Sacrifice the network effects of established languages/frameworks only when it gives your startup an unfair (10x) advantage."

hubb 17y ago

that's not how i read it at all. he's experienced with java, prefers statically typed languages, and has had a lot of success so far with scala. for accusing someone of a heavy bias you're doing a pretty good job yourself

wavesplash 17y ago
That's a very narrow definition of success. There are at least 3 areas of technical focus at a startup after you reach product/market fit: 1) ease of feature development 2) ease of hiring 3) ease of scale under load The author sacrificed 2, needlessly created well-known scale issue that could be avoided in 3 (basic distributed systems class), for no substantial improvement over the other options for 1. Yes, I have a bias towards startup team members factoring in their future impact on their coworkers and the company.

sreque 17y ago

If you only pick tools that everyone else knows so your hiring pool is large, then new tools never stand a chance of being used. You would stagnate all progress in the industry! It's funny because when Paul Graham writes articles about how the web lets us use whatever language we want (see http://www.paulgraham.com/avg.html http://www.paulgraham.com/avg.html), everyone celebrates the possibilities of writing their web site in their favorite lisp dialect. Yet here we have this evil engineer who picks a technology he likes, successfully improves a product and meets business requirements with it, and is ridiculed for picking a relatively obscure technology! Check out tiobe. I wouldn't be surprised if in a year Scala passes the combination of all lisp/scheme dialects in the rankings.

wavesplash 17y ago
Startups aren't about language diversity for the sake of diversity, they're about unfair leverage. In this case the author made a choice that didn't add any leverage to Foursquare. If anything, the author admits he boxed the company into a corner because of a rookie scaling decision. In contrast, the Asana guys are writing their own language+framework and if it delivers on it's early promise they'll be outgunning the competition with a 10x improvement on development time and code size. http://asana.com/luna http://asana.com/luna That's the sort of advantage Paul Graham had by using Lisp in ViaWeb vs. his competition that was mostly writing c++.
- sreque 17y ago
  My criticism wasn't of your comment that Lift was a poor choice because it doesn't scale well. It was of your comments that the technology shouldn't be used because there aren't that many developers to hire that know/are willing to learn scala/lift or that it isn't as mature as some other technologies. As for your argument on scalability, while I have dabbled in Lift, I am too ignorant to know how much work it would take to scale Lift versus alternative technologies. I find it hard to believe that choosing Lift is really going to make it that hard to scale. David Pollak and the creators of Lift seem like they are pretty smart people to me. However, I have no evidence to prove you wrong and therefore did not even address that point.
  - wavesplash 17y ago
    I don't believe I made that argument. Here's my point as a startup conjecture: "Sacrifice the network effects of established languages/frameworks only when it gives your startup an unfair (10x) advantage."