The end goal was not just theoretical but pragmatic, as giving in to the language and adapting my thought process seemed in my experience to increase productivity, reliability, and maintainability by several orders of magnitude, in connection with non-programming languages and linguistic relativity.

I've written little languages (mostly for generating code in other languages, which proved to be an interesting way to explore certain design patterns) but always shied away from going all in on a bigger language. Maybe when I retire...

I think if you strip aside the emotional reasoning that's going on, some languages naturally fit with some people more than others. Thinking in terms of functional decomp and association is just different than thinking in terms of objects. Some people build their own "language within a language" each time they solve something. Some people just want a language that is easy to find help for on the internet. Perhaps the trick is to identify which of those paradigms best fits your long-term goals for your both you and your problem.

I once interviewed a guy with a bunch of different languages on his resume. "So which do you like best?" I asked. He responded, "Java". I said, "Why's that?" He said "Because when I hit the compile button most of the time it just runs."

I thought that was a good answer.

When I program, I try and think of the problem and possible solutions in the same way that I would if working with a human colleague. That is, I design systems in a human way. I try to program in such a way that maps to how I would explain the domain to someone else and not how the computer thinks of it.

Thus, I primarily think in terms of data, transformations on that data, interactivity, and concurrent or parallel operations. This approach almost chooses languages for me. My primary languages I am learning and using at home right now are F#, Racket, and Elixir. These are new (-ish) languages with new ideas based upon the strong foundation of old languages that had revolutionary ideas, so it's not surprising I landed on these, for me personally. Also, although each one is a complex language, they each have a simple core, which is another plus. Then there are visual languages like TouchDesigner and LabVIEW.

However, the curse is finding a place that uses the road less traveled because it requires the company and its employees to have made the non-standard choice and to consider the tools as important as whatever else they're working on. There are few places that use newer languages, but I am trying to become more agressive in just using them at my work. If they solve problems in an efficient way, you shouldn't necessarily need to ask for permission. People can be trained. Nobody asks for permission when they use Python or C or whatever else. They use it because that's all they know. The other way is to merge your personal interests with work by creating your own company, but that is an obvious high hurdle.

When using new languages, there is the problem of ecosystem, particularly in libraries. However, I am of the opinion that this isn't as big of a problem as often reported. It's a problem but not the no-go problem it is usually presented as.

"Thinking too much" seems to have hit a button for you; sorry about that. I do think this is a pretty common thing: The Paradox of Choice. That's sort of what I am feeling as I know quite a few languages and frameworks, and it's difficult for me to stop diddling over "what should I use" and just write it.

I've spent my career creating things - I haven't created a language yet and to be honest I don't think I have the ability to do so. Not sure what that has to do with my point, but OK.

Actually PG puts it really nicely [1]:

"The right way to solve that problem, I think, is to separate the meaning of a program from the implementation details."

"What program would one like to write? Whatever is least work. Except not quite: whatever would be least work if your ideas about programming weren't already influenced by the languages you're currently used to. Such influence can be so pervasive that it takes a great effort to overcome it. You'd think it would be obvious to creatures as lazy as us how to express a program with the least effort. In fact, our ideas about what's possible tend to be so limited by whatever language we think in that easier formulations of programs seem very surprising. They're something you have to discover, not something you naturally sink into."

http://www.paulgraham.com/hundred.html http://www.paulgraham.com/avg.html http://stackoverflow.com/questions/1003940/learn-a-new-langu...

Scala is a great example: the innovation of the language is not so much in new language features, but rather in its ingenious combination of so many powerful features into a single, coherent system. Of course, some may argue that Scala has too many features (I'm a bit terrified of it), but it's indisputable that putting all those pieces together in a way that works is tour de force of language design.

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.

When you're working on a system, how do you approach the question, "Is this really useful, or am I spinning my wheels chasing a conceit?" Is the answer as simple as try it out and see what happens? Or do you have some sort of heuristic that your many years of experience has proven to be helpful?

I mention why because different whys have different orderings of hows. (For example, if you're interested in some new semantics, working on a parser first is probably counter-productive.)

Designing a language consumes you; you never see programming the same way again. Whenever I write C (I'm implementing the interpreter in C), I get annoyed because I have to work around C's warts to do what I want, and that is only happening because I think in my language.

And the design never stops. As mentioned, I've been designing mine since 2011, and I'm only now writing an interpreter after two failed attempts to bootstrap a compiler.

So the author is correct: don't write a programming language unless you are prepared to be marked and scarred for life.

I want to learn things that shape my thinking in a way that makes me more efficient, and in a way that makes it easier to express ideas.

If your language isn't giving me that then it's bye bye.

I get the appeal but squinting your eyes at a string of single-character symbols is taking it too far. The whole thing has to be somewhat ergonomic as well.