There is actually a community of ~20000 people using some forms of this: codeforces.com. The most used approach are lots of macros in C++ to completely modify the language. One popular alternative is https://cpeditor.org/.

For example, look at how Benjamin Qi does it: https://codeforces.com/contest/1446/submission/98447974

The actual code is at the bottom. Here is a sample of a submission to a problem harder than your usual AoC second part:

  int main() {
   setIO(); re(N,M);
   str A,B; re(A,B);
   F0R(i,N+2) F0R(j,M+2) mx[i][j] = -MOD;
   int ans = 0;
   R0F(i,N) R0F(j,M) {
    ckmax(mx[i][j],mx[i+1][j]);
    ckmax(mx[i][j],mx[i][j+1]);
    if (A[i] == B[j]) {
     dp[i][j] = 2;
     ckmax(dp[i][j],mx[i+1][j+1]+4+i+j);
     ckmax(mx[i][j],dp[i][j]-i-j);
     ckmax(ans,dp[i][j]);
    }
   }
   ps(ans);
  }

Oh, another side project I'm working on: a "high touch" music recommendation service. Like Pandora, except your recommendations are chosen by a real person instead of an algorithm. Downside: you get far, far fewer recommendations; upside: you can tell your recommender exactly what you want, exactly what you did or didn't like about a track, etc.

Beta-testing it with some friends and family now; we'll see if it grows into anything real!

This sounds very cool. I recently thought of another approach for song recommendation due to necessity i.e.: based on how a song sounds. There are genres but they're way too generic. Other methods like similar artists, what else people who've likes a song love etc doesn't always work. Not sure how streaming services recommend but I don't think they do what I want.

I know, how something _sounds_ is subjective but I was thinking something along the lines of how Shazam app does. If they can compute a song signature and compare it against a library, it should be possible(?) to find top 10 closest neighbors.

BTW, I'd love to test your app if that's possible.

I have done something similar in a Lua IDE: http://notebook.kulchenko.com/zerobrane/live-coding-in-lua-b.... The IDE actually supports live coding with several Lua toolkits (Love2d, Moai, Gideros, and others; here is an example with Love2d: http://notebook.kulchenko.com/zerobrane/live-coding-with-lov...

This is such a cool idea. The gap between the "aha" moment of a programming challenge and the implementation is high for me since I don't get to code very much anymore. Can't wait to check it out!

Yes, agreed. I recently went through AOC2020 and found that much of the actual implementation was actually quite a chore, even though many of the problems seemed quite simple. Granted I was using C++: https://github.com/areading314/adventOfCode2020

> I should have instant visual feedback showing me how the input is affected by this change

Like LightTable? Might want to check that out if you're not already aware of it. I don't know if it's gone anywhere in recent years or has inspired any similar features in other editors.

Ah, I remember when LightTable launched -- my dad (huge Clojure fan) was over the moon. Even today he's still trying to convince me that I should just use Clojure. :P

One idea I started building and never finished was "pseudocode as code".

The idea was to have a compiler for pseudocode used in CS books in place of real code.

There are a few small differences (eg. using = vs :=) but most books and interview-preparing materials use a C-like notation.

Then I started reading papers written by language researchers (which use haskell-like pseudocode) and realised the size of the task at hand.

Probably trying to please only CS students / people doing interviews would still make for a fun hack.

I've worked on a few similar projects, and in this case I'd recommend trying to write your syntax however you want, but implementing it as a transpiler to Python.

That way you always have access to the Python libraries, for competitions where you need to show your code it'll be easier, and there are already a lot of optimisations.

That said if you're primarily doing this for fun- go wild with the implementation.

You should have a look at q/kdb. Once you get comfortable with the language, you can write some very complex code very quickly - part of the reason is the compactness of the language, but also due to the functional, loop-free style which uses the right primitives.

For the IDE part, you can look into the Language Server Protocol spec and write an implementation for your language. Would then work with most editors like VS code, vim, etc. out of the box and remove the leg-work of making the rest of the editor.

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.

FWIW I finished AoC 2020 in Go -- but I had 5 years' worth of helper functions to prop me up: https://github.com/lukechampine/advent

> 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?

> 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!

Haha, that's on me -- I probably should have written "competitive programming" in there somewhere. Cheers!

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!

Imo, good REPL integration is the thing to take from Lisp, not necessarily the syntax (although I'm a fan of it). See CL with SLIME.

I remember looking at a textbook for scientific computing, seeing what I thought was pseudocode, and later learning it was Julia.

Have you given any thought to this being used in place of pseudocode in white papers? If the language is much easier to translate problem into code, it is probably good at conveying ideas for documentation or teaching. My naive assumption is that would be a more useful focus than IDE tooling.

That's an interesting idea, but I think it wouldn't be a great fit. Reason being that, in the interest of speed, the language will need to include some irregular or unintuitive syntax and idioms. It goes without saying that pseudocode shouldn't require a manual!

SQL anyone? High level language, immediate feedback mostly, does the low level optimisation for you, you can performance tune with indices where needed... :)

I'm also very interested in this problem. Have you explored other paradigms to specify the program outside of text?

As in, visual programming? I don't have a ton of experience with that, but my gut says that once the problems reach a certain degree of complexity, it would hurt more than help.

Or, how about vocal programming? I wonder if, in practice, dictation might be faster than typing? :)

Yes, recently I've been interested in visual programming paradigms like scratch. After all Python was originally supposed to be a teaching language. Maybe in 2030 the newest generations will find text files archaic and not expressive compared to new types of visual, vocal, or even "video" animated languages.

Is there a way to follow your progress?

Is the code for this available somewhere to look at?

Not yet, but once it's capable of solving most AoC problems, I'll throw it on GitHub and ping you!