8 ms·
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.
by 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 agoIf 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 agoYou'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 agoI 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 agoI 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 agoyeah 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 agoA 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.