7 ms·

I respect the ambition, but doesn't it seem like a waste of time and money for a brand new startup to focus on the creation of a brand new language (+compiler +

by m0th87 17y ago

I respect the ambition, but doesn't it seem like a waste of time and money for a brand new startup to focus on the creation of a brand new language (+compiler +debugging facilities +documentation for new employees +libraries +...) before making the core product? I understand the argument that better languages = increased productivity. But designing a new language is a serious investment, and unless what they've made is so revolutionary that it completely changes the web development paradigm, it doesn't seem as if it would pay off.

smcq 17y ago
Programming languages aren't that hard, so I'd say, if it makes them way more productive later, then no it's not a waste of time.
- davidw 17y ago
  If they aren't that hard, how come so many never seem to be... well, 'finished'? I think they tend to be a fairly large time sink, especially because it's great fun to work on one. It's exactly the kind of thing that could be very distracting for a startup.
  - raganwald 17y ago
    You're making two points, either or both of which may be good, but they are two different points. First, are they hard or easy? Second, are they distracting because they're fun/engaging? Either "problem" may lead to them being a huge time sink for startups and either may lead to them being perennially unfinished. The good news is that a language for in-house use need not be finished to be useful. For example, FB's PHP compiler can't compile "eval." No problem, don't use eval in-house. If they were trying to "finish" it in the sense of writing a compiler for every possible PHP app, they would have to address that somehow. But instead, they punt on it and carry on using it in house.
    - davidw 17y ago
      I would say reasonably easy to start with, but needing a lot of ongoing effort for improvements, bug fixes, and so on, which is exactly why I think it's a dangerous combination for a small company. I think they're likely to be an ongoing distraction for the above reason, and also because of the fun/intellectual challenge reason. > punt on it and carry on using it in house. Over time, that kind of thing can (if you're not careful) lead to dangerous cruft, where the in-house divergences pile up to the point where it's no longer so easy to go back and forth between the public/open version. And thus is born a new species with a far smaller ecosystem than the original.
      - plinkplonk 17y ago
        "I think it's ... dangerous .. for a small company." of non compiler/language processing experts. If you've built compilers before and know what you are doing (I have no idea if these guys are such experts or not) , it may be a reasoned decision taken after weighing benefits and costs. Leon Bottou and Yann LeCun seems to have built the Lush dialect of lisp to build commercial systems. (http://lush.sourceforge.net/credits.html http://lush.sourceforge.net/credits.html) For example, I can easily imagine PG building a variant of lisp and building a product/company around that . Of course if you only have a vague idea of how to build a compiler/interpreter/whatever, then building a company around your first such project may be ... interesting.
        raganwald 17y ago
        I can easily imagine PG building a variant of lisp and building a product/company around that Or perhaps using Lisp to write his own continuation-based web framework and building a company around that?
        plinkplonk 17y ago
        yeah sure. I first wrote "arc" and then replaced it with "a variant of lisp" then replaced "another company" with "a company" so the sentence reads oddly.
  - spoondan 17y ago
    A language doesn't need to be "finished" to be usable. There is a minimal viable implementation for internal use. I'll grant that investing in language development is unusual. But the risks involved aren't sufficiently different from those taken by 37signals in choosing Ruby and developing a framework. There are payoffs for core technology development.
glymor 17y ago
If it increases the chance of a technology or people acquisition it would be creating value.
- deleted 17y ago
  [deleted]
- tptacek 17y ago
  It decreases the chance of an acquisition, unless things have changed since the last time I was involved in acquisition talks. A sticking point in at least 3 acquisition attempts I was involved in (one consummated) was the use of idiosyncratic tech; in one case, it was using Tcl; in another, OpenBSD.
  - psranga 17y ago
    Great information, thanks! I take it the companies using Tcl and OpenBSD failed to get acquired. I didn't realize the technology used would deter an acquirer. This probably explains why most startups go with "safe choices".
    - tptacek 17y ago
      I'm not going to say that (eg) OpenBSD kept a company from getting acquired; terms and timing were more important. But it was continuously raised as an issue, seriously enough that the engineering team was asked to port. Bizdev is an awful reason to choose technology, or for that matter to make any other decision about your product. I'm just refuting the statement that writing your own programming language will help you get bought.
jessep 17y ago
Seems to me like being able to implement things 10x more quickly than your competitors is a sustainable competitive advantage. If you're trying to appeal to employees/investors, being an order of magnitude faster is a good pitch. Think about it this way: When you evaluate a startup, what do you look at first, the idea or the team? Obviously, the team. Why? Because (a) you want to know if they're capable of implementing the idea and (b) because you know that ideas almost always change, so the team's ability to rapidly implement and iterate is its real strength. I agree that this struck me as somewhat absurd when I heard Asana was developing a new language, but if it actually works as advertised then it's really smart.
- davidw 17y ago
  > being able to implement things 10x more quickly than your competitors is a sustainable competitive advantage. The only way you are going to get 10x, with roughly equivalent people is if someone is using a wholly inappropriate language (Ruby vs Forth for web apps, say), or if you can avoid writing libraries because someone has already written them. This is one of the positive network externalities involved in programming language economics: the more people involved, the more likely it is someone has already written the code you need. Of course, these effects are not so strong that everyone gravitates to only a few languages, but they are certainly a consideration. By writing your own language, unless it makes it very easy to take advantage of some other language (the JVM languages are a good example), you are pretty much guaranteeing that you will have to do this work yourself.
  - deleted 17y ago
    [deleted]
  - smcq 17y ago
    You're effectively arguing that all languages/frameworks are equal within an order of magnitude. I think this has been demonstrated false time and time again, and you even demonstrate it again in your own post (saying Forth is unacceptable for web development). Why so negative?
    - 17y ago
extension 17y ago
With a team of rock stars and $9M+ to burn, they can take the time to scratch a really big itch.
- fleitz 17y ago
  Hopefully they've retained George Broussard to head the team up.
  - extension 17y ago
    If you've got chicken pox then stop scratching
olalonde 17y ago
37signals ?
- davidw 17y ago
  In the Rails source tree: find . -name "*.rb" | xargs wc -l | tail -1 161472 total In the Ruby source tree: find . -name "*.rb" | xargs wc -l | tail -1 639682 total find . -name "*.c" | xargs wc -l | tail -1 590656 total
rudin 17y ago
Maybe there is another side to things. I know that creating a new programming language isn't the easiest way to earn money but if you are successful there are lots of interesting ways to make money. Even an open source language provides possibilities for books, conferences, advocate positions, merchandize etc.
narcvs 17y ago
I had a chance to chat with them - I honestly think lunascript and its platform is the core product. The productivity app they're building is a first show case (and in-house infrastructure)
narcvs 17y ago
I had a chance to chat with them - I honestly think lunascript and its platform is the core product. The productivity app they're building is a first show case (and in-house infrastructure)

by m0th87 17y ago

smcq 17y ago

Programming languages aren't that hard, so I'd say, if it makes them way more productive later, then no it's not a waste of time.

davidw 17y ago
If they aren't that hard, how come so many never seem to be... well, 'finished'? I think they tend to be a fairly large time sink, especially because it's great fun to work on one. It's exactly the kind of thing that could be very distracting for a startup.
- raganwald 17y ago
  You're making two points, either or both of which may be good, but they are two different points. First, are they hard or easy? Second, are they distracting because they're fun/engaging? Either "problem" may lead to them being a huge time sink for startups and either may lead to them being perennially unfinished. The good news is that a language for in-house use need not be finished to be useful. For example, FB's PHP compiler can't compile "eval." No problem, don't use eval in-house. If they were trying to "finish" it in the sense of writing a compiler for every possible PHP app, they would have to address that somehow. But instead, they punt on it and carry on using it in house.
  - davidw 17y ago
    I would say reasonably easy to start with, but needing a lot of ongoing effort for improvements, bug fixes, and so on, which is exactly why I think it's a dangerous combination for a small company. I think they're likely to be an ongoing distraction for the above reason, and also because of the fun/intellectual challenge reason. > punt on it and carry on using it in house. Over time, that kind of thing can (if you're not careful) lead to dangerous cruft, where the in-house divergences pile up to the point where it's no longer so easy to go back and forth between the public/open version. And thus is born a new species with a far smaller ecosystem than the original.
    - plinkplonk 17y ago
      "I think it's ... dangerous .. for a small company." of non compiler/language processing experts. If you've built compilers before and know what you are doing (I have no idea if these guys are such experts or not) , it may be a reasoned decision taken after weighing benefits and costs. Leon Bottou and Yann LeCun seems to have built the Lush dialect of lisp to build commercial systems. (http://lush.sourceforge.net/credits.html http://lush.sourceforge.net/credits.html) For example, I can easily imagine PG building a variant of lisp and building a product/company around that . Of course if you only have a vague idea of how to build a compiler/interpreter/whatever, then building a company around your first such project may be ... interesting.
      - raganwald 17y ago
        I can easily imagine PG building a variant of lisp and building a product/company around that Or perhaps using Lisp to write his own continuation-based web framework and building a company around that?
        plinkplonk 17y ago
        yeah sure. I first wrote "arc" and then replaced it with "a variant of lisp" then replaced "another company" with "a company" so the sentence reads oddly.
- spoondan 17y ago
  A language doesn't need to be "finished" to be usable. There is a minimal viable implementation for internal use. I'll grant that investing in language development is unusual. But the risks involved aren't sufficiently different from those taken by 37signals in choosing Ruby and developing a framework. There are payoffs for core technology development.

glymor 17y ago

If it increases the chance of a technology or people acquisition it would be creating value.

deleted 17y ago
[deleted]
tptacek 17y ago
It decreases the chance of an acquisition, unless things have changed since the last time I was involved in acquisition talks. A sticking point in at least 3 acquisition attempts I was involved in (one consummated) was the use of idiosyncratic tech; in one case, it was using Tcl; in another, OpenBSD.
- psranga 17y ago
  Great information, thanks! I take it the companies using Tcl and OpenBSD failed to get acquired. I didn't realize the technology used would deter an acquirer. This probably explains why most startups go with "safe choices".
  - tptacek 17y ago
    I'm not going to say that (eg) OpenBSD kept a company from getting acquired; terms and timing were more important. But it was continuously raised as an issue, seriously enough that the engineering team was asked to port. Bizdev is an awful reason to choose technology, or for that matter to make any other decision about your product. I'm just refuting the statement that writing your own programming language will help you get bought.

jessep 17y ago

Seems to me like being able to implement things 10x more quickly than your competitors is a sustainable competitive advantage. If you're trying to appeal to employees/investors, being an order of magnitude faster is a good pitch. Think about it this way: When you evaluate a startup, what do you look at first, the idea or the team? Obviously, the team. Why? Because (a) you want to know if they're capable of implementing the idea and (b) because you know that ideas almost always change, so the team's ability to rapidly implement and iterate is its real strength. I agree that this struck me as somewhat absurd when I heard Asana was developing a new language, but if it actually works as advertised then it's really smart.

davidw 17y ago
> being able to implement things 10x more quickly than your competitors is a sustainable competitive advantage. The only way you are going to get 10x, with roughly equivalent people is if someone is using a wholly inappropriate language (Ruby vs Forth for web apps, say), or if you can avoid writing libraries because someone has already written them. This is one of the positive network externalities involved in programming language economics: the more people involved, the more likely it is someone has already written the code you need. Of course, these effects are not so strong that everyone gravitates to only a few languages, but they are certainly a consideration. By writing your own language, unless it makes it very easy to take advantage of some other language (the JVM languages are a good example), you are pretty much guaranteeing that you will have to do this work yourself.
- deleted 17y ago
  [deleted]
- smcq 17y ago
  You're effectively arguing that all languages/frameworks are equal within an order of magnitude. I think this has been demonstrated false time and time again, and you even demonstrate it again in your own post (saying Forth is unacceptable for web development). Why so negative?
  - 17y ago

extension 17y ago

With a team of rock stars and $9M+ to burn, they can take the time to scratch a really big itch.

fleitz 17y ago
Hopefully they've retained George Broussard to head the team up.
- extension 17y ago
  If you've got chicken pox then stop scratching

olalonde 17y ago

37signals ?

davidw 17y ago
In the Rails source tree: find . -name "*.rb" | xargs wc -l | tail -1 161472 total In the Ruby source tree: find . -name "*.rb" | xargs wc -l | tail -1 639682 total find . -name "*.c" | xargs wc -l | tail -1 590656 total

rudin 17y ago

Maybe there is another side to things. I know that creating a new programming language isn't the easiest way to earn money but if you are successful there are lots of interesting ways to make money. Even an open source language provides possibilities for books, conferences, advocate positions, merchandize etc.

narcvs 17y ago

I had a chance to chat with them - I honestly think lunascript and its platform is the core product. The productivity app they're building is a first show case (and in-house infrastructure)

narcvs 17y ago

I had a chance to chat with them - I honestly think lunascript and its platform is the core product. The productivity app they're building is a first show case (and in-house infrastructure)