3 ms·
Apart from who'll have to fix it, I agree with you. This is a risk, and our software is early and buggy. That's why we're paying you to use it!
by pbiggar 9y ago
Apart from who'll have to fix it, I agree with you. This is a risk, and our software is early and buggy. That's why we're paying you to use it!
- vortico 9y agoUnfortunately "we'll fix it for you" isn't nearly enough unless you have 100 dedicated employees waiting at their keyboards for requests for the one "test" user you're hiring. Even environments like Erlang with years of support from hundreds of companies and individual programmers, you will run into blocking problems like "we need a binding to this database" or "my editor needs plugin support" or "we need a debugger and way to inspect memory". A language environment emerges using baby steps. - spark interest from hobbyists wanting to try new ideas - provide enough inertia to the platform for the hobbyists to want to join as users or contributers - accept the role as a contribution manager (accepting source code if open-source, or finances if proprietary), while still developing core stability by yourself (the language designer) - then encourage small companies to try it to solve problems that are made easy by a niche of your environment
- pbiggar 9y agoThat is how it has gone for many languages, but it isn't the only way. Examples of languages that have gone differently include Java, Javascript, Erlang and Visual Basic. More generally, if we look at devtools adoption as a whole (and I suspect Dark's adoption will more closely resemble a B2B devtool than a programming language), I don't believe those steps you outline are sequential at all. As an example, PHP was adopted by small companies extremely quickly, as were Parse and Firebase. So I understand your point, and I'm not going to claim that you're wrong, but there are definitely other adoption models that potentially apply here.