I hope this will in no way be interpreted as discouraging or snobbish, just want to add a little perspective. Please understand that I’m very supportive of your endeavor...
> As far as I'm aware, there aren't any existing languages in this space.
In some form or another, all existing languages (other than joke langs) are in this space. That’s why we have programming languages. Ultimately they all prioritize some subset of “problems” that they optimize solving.
That said, in terms of instant feedback I’d look at LightTable and (believe it or not) Chrome dev tools as prior art.
> In some form or another, all existing languages (other than joke langs) are in this space.
I was hoping there was going to be some insightful critique after that long preamble. This is similar to an "all languages are Turing complete" type nitpick that doesn't add much to the conversation.
If you look downthread, I missed an important bit of context where the goal is solving programming challenges, not general programming problems (which I misperceived). That’s a significantly more narrow focus to which none of my preamble or conclusion is applicable.
I agree with OP, not all languages are optimized for solving programming challenges (to be specific, recreational programming challenges) as they are optimized around different goals.
I tried solving AOC2020 as a means for learning golang. 6 challenges in, I gave up not because the challenges were hard but because it took longer to translate logic to code. It was no fun to write simple for loops, before getting into actual problem logic. Having to write a minInt function is like a distraction when you want to be focusing on the programming challenge. It is much simpler to use a programming language like Python that comes batteries included.
In this regard, I suppose functional programming can be quite expressive. If you can break the problem into functional units, it can be a pleasure to solve programming challenges using FP.
> 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!
> As far as I'm aware, there aren't any existing languages in this space.
In some form or another, all existing languages (other than joke langs) are in this space. That’s why we have programming languages. Ultimately they all prioritize some subset of “problems” that they optimize solving.
That said, in terms of instant feedback I’d look at LightTable and (believe it or not) Chrome dev tools as prior art.