> Ultimately they all prioritize some subset of “problems” that they optimize solving.
Sure...but not solving quickly, at the expense of all else. Rust is optimized for solving certain problems -- but solving them robustly, not quickly. Python comes a bit closer, but Python also wants to be readable; I don't have to worry about that.
I guess one way to frame it is: the core values (https://vimeo.com/230142234) of this language are velocity, and...that's it. Maybe expressiveness (less typing) and transparency (immediate feedback), but really those are just aids to velocity moreso than orthogonal values.
> Sure...but not solving quickly, at the expense of all else.
I really, sincerely, think they do. It’s just that their optimizations focus on the subset of problems. For example:
> Rust is optimized for solving certain problems -- but solving them robustly, not quickly.
This is basically the same thing as saying: when the problem one wants to solve quickly is robustness, Rust may be a good choice.
> Python comes a bit closer, but Python also wants to be readable; I don't have to worry about that.
There are some problems I associate with quickly solving in Python, and others where I find it exceptionally slow. Sure, readability may be a contributing factor. Another is immature/complex tooling that makes static validation or dependency management a slog. Another still is that a lot of its concurrency story is in flux and you have to spend time researching approach and compatibility if your problems are concurrency related.
I’m still not trying to discourage, but I’ve spent most of my career working in scripting languages (those which most prioritize “rapid prototyping” and “repl driven development”), and ultimately when they’re applied to use cases that they’re not designed for their velocity is consumed by tooling.
My advice, intended with kindness and encouragement, is to consider which problems you wish your language to be able to solve rapidly.
To your points about velocity aids, expressiveness and transparency aren’t just velocity amplifiers at the time you write code. They also (can) aid velocity of reading comprehension, editing/refactoring, review. This is a place where Python does very well in terms of velocity: even when I had read less than 100 lines of it, I could generally review work and ask important questions about what it was doing in... well, frankly a shorter time than the JS I was actively working with as a lead at the time.
It’s clear you want a language that enables devs to dev fast. But what are they doing fast?
Solving programming challenges. Maybe this sounds broader than I intended. By "programming challenges" I literally mean Advent of Code, HackerRank, etc. This is by no means a general-purpose language!
I guess in your terms, the "problem one wants to solve quickly" is "outputting the answer that will be accepted as correct by the programming challenge website."
Oh my goodness, I seriously misunderstood your intent! Yes that’s a perfectly reasonable focus. I don’t know why I breezed past AoC. Sorry for the confusion!
FWIW I’m very curious what you’ve come up with. I’m imagining based on your Python commentary it’s not a lisp, but that’s probably where I’d start for something like this.
Currently it's more of a fusion between Haskell and bash. I've played with Lisp a lot, but never anything serious; I can imagine that Lisp syntax, with appropriate hotkeys, would make for some speedy navigation/refactoring, though!
Sure...but not solving quickly, at the expense of all else. Rust is optimized for solving certain problems -- but solving them robustly, not quickly. Python comes a bit closer, but Python also wants to be readable; I don't have to worry about that.
I guess one way to frame it is: the core values (https://vimeo.com/230142234) of this language are velocity, and...that's it. Maybe expressiveness (less typing) and transparency (immediate feedback), but really those are just aids to velocity moreso than orthogonal values.