3 ms·

Honestly if you're going to take a step back and consider those things, why not also consider that we already have so many programming languages that it's almos

by RyanZAG 11y ago

Honestly if you're going to take a step back and consider those things, why not also consider that we already have so many programming languages that it's almost impossible to get to a deep level of understanding of all of them. Obviously if you enjoy making languages then you should do so - and in that case, noticing that your dynamic un-toolable language won't get wide scale adoption shouldn't matter. It's already a guarantee it won't get that wide scale adoption. Either make your un-toolable language because you enjoy making them, or contribute your efforts to an already popular language that you enjoy. There are tons of interesting problems and huge areas for improvements in every single language. Don't make a new language for the goal of gaining widescale adoption.

hyperpape 11y ago
This won't be good advice until it's been at least 20 years since any mainstream language was born. Today, you can point to Go, Rust, and Clojure as counterexamples within the past decade (and if there's a new mainstream language born last year, we probably won't know for 5-10 years). I suspect what you're trying to say is "don't expect to succeed." That's true--most people will fail, but we should all hope people continue trying, unless we're satisfied with what we have. I'm not satisfied, and I think progress will require new languages, not just improving the ones we have. Some things require that a lot of people try and fail. Language design is one of them.
- tachyonbeam 11y ago
  I think he's also saying "do it for fun, not for success, have fun doing it", which is good advice IMO.
  - hyperpape 11y ago
    "and in that case, noticing that your dynamic un-toolable language won't get wide scale adoption shouldn't matter." That's what I'm reacting to, and I still disagree. People should have an eye on what getting traction would require, even if only a tiny fraction of language designers can make it.
    - RyanZAG 11y ago
      The problem is that a static easily tooled language is not going to be as good as the dynamic un-toolable one without massive tooling support specifically for that language's features. Creating those tools is not the job of a lone developer. The cost is immense. The language first has to achieve popularity to receive the tooling, or be heavily backed by a large tooling capable company (eg, Google, Jetbrains, Microsoft). So far, the only recent languages to receive the kind of required static tooling are from those 3 companies. Also note that the language did not come first in those cases - the requirement for the language came first, and a language was made to fit what was needed. However even more importantly - if you're going to create a language, it needs to be the ultimate language in your own eyes. You can't leave off novel features that you have experience in because it doesn't have mass appeal or has tooling issues. You need to create the best language you possibly can if you want to compete with others trying to create the best language. Hamstringing your enjoyment of the language by going in a direction you don't like because it has more apparently mass market appeal isn't any more likely to be successful, and it certainly isn't going to be enjoyable enough for you to slog through the tiny complexities. While there is a tiny chance that your language becomes the next big thing, it probably won't. That means you need to make the language you want to make and hope it succeeds, not make the language that 'will succeed' but you don't want to make.
      - hyperpape 11y ago
        Your point about support is well taken, but while Rust is being supported by Firefox, it was Graydon Hoare's side project for 3 years. It is at least possible for an individual to run with an idea for a static language and get community or corporate support, even if it is tremendously difficult. And I don't know if you can say that the language sprang from the requirement. It did, so far as a lot of people have had longstanding dissatisfaction with C++, but I'm not sure Mozilla originally was looking for a replacement (ditto for Google and Go--though lessons learned there may not apply to people who aren't Rob Pike...). I agree with you so far as it can't be a language you don't want to make. I don't think this article describes that, but a more modest set of constraints. Elsewhere, the author mentions Julia as a positive inspiration. I think the idea of compromise depends on the idea you're trying to bring into the world. You can't compromise your core idea, but you can compromise on other things. I guess I'm making assumptions about what the author is compromising that I'm not entitled to. Perhaps you know that I'm wrong.

by RyanZAG 11y ago

hyperpape 11y ago

This won't be good advice until it's been at least 20 years since any mainstream language was born. Today, you can point to Go, Rust, and Clojure as counterexamples within the past decade (and if there's a new mainstream language born last year, we probably won't know for 5-10 years). I suspect what you're trying to say is "don't expect to succeed." That's true--most people will fail, but we should all hope people continue trying, unless we're satisfied with what we have. I'm not satisfied, and I think progress will require new languages, not just improving the ones we have. Some things require that a lot of people try and fail. Language design is one of them.

tachyonbeam 11y ago
I think he's also saying "do it for fun, not for success, have fun doing it", which is good advice IMO.
- hyperpape 11y ago
  "and in that case, noticing that your dynamic un-toolable language won't get wide scale adoption shouldn't matter." That's what I'm reacting to, and I still disagree. People should have an eye on what getting traction would require, even if only a tiny fraction of language designers can make it.
  - RyanZAG 11y ago
    The problem is that a static easily tooled language is not going to be as good as the dynamic un-toolable one without massive tooling support specifically for that language's features. Creating those tools is not the job of a lone developer. The cost is immense. The language first has to achieve popularity to receive the tooling, or be heavily backed by a large tooling capable company (eg, Google, Jetbrains, Microsoft). So far, the only recent languages to receive the kind of required static tooling are from those 3 companies. Also note that the language did not come first in those cases - the requirement for the language came first, and a language was made to fit what was needed. However even more importantly - if you're going to create a language, it needs to be the ultimate language in your own eyes. You can't leave off novel features that you have experience in because it doesn't have mass appeal or has tooling issues. You need to create the best language you possibly can if you want to compete with others trying to create the best language. Hamstringing your enjoyment of the language by going in a direction you don't like because it has more apparently mass market appeal isn't any more likely to be successful, and it certainly isn't going to be enjoyable enough for you to slog through the tiny complexities. While there is a tiny chance that your language becomes the next big thing, it probably won't. That means you need to make the language you want to make and hope it succeeds, not make the language that 'will succeed' but you don't want to make.
    - hyperpape 11y ago
      Your point about support is well taken, but while Rust is being supported by Firefox, it was Graydon Hoare's side project for 3 years. It is at least possible for an individual to run with an idea for a static language and get community or corporate support, even if it is tremendously difficult. And I don't know if you can say that the language sprang from the requirement. It did, so far as a lot of people have had longstanding dissatisfaction with C++, but I'm not sure Mozilla originally was looking for a replacement (ditto for Google and Go--though lessons learned there may not apply to people who aren't Rob Pike...). I agree with you so far as it can't be a language you don't want to make. I don't think this article describes that, but a more modest set of constraints. Elsewhere, the author mentions Julia as a positive inspiration. I think the idea of compromise depends on the idea you're trying to bring into the world. You can't compromise your core idea, but you can compromise on other things. I guess I'm making assumptions about what the author is compromising that I'm not entitled to. Perhaps you know that I'm wrong.