[dcz_self]

Start in the middle. It's the most interesting part, too. After all, that's the core of your idea.

I don't know where I heard this, but the idea is so important to me that I saved it on my blog: https://dorotac.eu/posts/in_the_middle/

[mjcohen]

That is also a good way to start an improv scene. Figure out later, if at all, what is really going on.

[lelanthran]

> Start in the middle. It's the most interesting part, too. After all, that's the core of your idea.

For a programming language? Maybe if you are designing your language by feature list.

What if you are designing a programming language for ergonomics instead?

Let's be real - the differentiating factor in any modern language design is the syntax, not the features. They all mostly support a similar cross-section of features, in terms of "getting things done".

What you are really designing is a competitor to the existing languages, in which case it is beyond the scope and effort of a lone developer to match feature-for-feature of modern languages.

My experience of lone-wolf programming languages is all the same ... namely ...

Even if you do have one, single, differentiating feature, people aren't going to adopt unless you have all the other features they want. Doesn't matter how good your feature is if your language is missing some feature that people like in current mainstream languages.

You should also be careful of thinking that a single good feature will cause a little adoption; if it's any good the existing languages will simply adopt it!

Another path into darkness is thinking that the batteries included is so different to current offerings that people will adopt it, such as that recent post on HN about a language developed for cloud by the author of CDK. There's nothing in that language that can't be implemented as a library for existing languages.

For programming languages alone, going feature-first is a good way to produce an obscure language that no one is interested in. Without even a small community, the original dev themselves won't use it.

Where a new language makes sense is in ergonomics, not in features.

Can you make the syntax such that people onboard quickly? Can your syntax support something complicated in a manner that the most simple-minded developer can understand? Is your syntax amenable to collaboration? Can it be easily parsed in pieces for IDEs? Will the output be package-distributable or module-distributable? Can you ensure easy GDB integration? What build mechanism can be used (for reading the sources and figuring out dependencies).

Syntax is the major difference between writing in Kotlin and writing in Java.

My new language project, I'm still trying to nail down what the syntax should look like. I have no problem documenting the tree to support features I want, but I find that settling on what good syntax looks like to the majority of corporate developers is really really difficult.

Compare with, from an AST, emitting code for some advanced language constructs. That's almost a mechanical effort that I think I can delegate a lot of to ChatGPT.

Designing universally acceptable syntax, on the other hand, is a lot more complex and requires actual human decision-making.

[wpietri]

As far as I can tell, this author is writing a language just for the experience of writing a language, without much regard to getting it used, so it sounds like their success criteria may be a fair bit different than yours.