kind of where Python is shining lately... competing interpreters, separately maintained static type checker.
Granted, I feel like I'm constantly battling the desire to have total control vs delegation :P
Here's a somewhat unrelated question, what's your personal approach to gathering ideas and making notes for working on something as esoteric as language design? And what are your thoughts on writing code that's meant to be read and is well documented, a la literate programming? (I enjoyed your good code section. I wish it was easier to find similar analyses.)
I keep stumbling across problems and ideas when I do programming.
That is the kind of main source of ideas, I write them down into worklist when I get them.
Or then I implement them straight away and see how it matters.
Then I also tend to explore interesting concepts in other languages and see if I can apply it into mine.
Programming language is a tool. You can't test it by other than using it.
Well-documented code means different things to different audiences. This is apparent especially with the code that computes hashes or programs relying on matrix or vector arithmetic.
But I'd say it is up to the person to learn what the code means.
I prefer documentation and code being separate, but hyperlinked.
Also I have the strategy that the code must come before the documentation.
And the documentation starts by explaining details of the code.
Going upwards until the things relevant to the user is documented well.
Although I prefer code and documentation separate, I think comments are still necessary.
If there are surprises in the code, that are surprises no matter what your general knowledge about the subject were.
They should be documented into the code into the comments.
Surprises such as variables that are not immediately used, or used from different files. Such that you can't be sure how it's used.
Overall the information about the data flow and structure in the program is important for understanding.
That has led to avoidance of OOP constructs, unless they have important role or a purpose.
But it is still preferable to minimize the kind of dataflow that would have to be documented down, or then it should be done explicit.
Readable programs are bit like readable stories, where the computer is the actor.
it cannot be an audience, because it doesn't understand the story.
For example, in a good system you leave decisions to late as possible, but it's in conflict with explicit data flow because explicit dataflow demands you from choosing carefully what you pass downwards into calls.
Also, regarding documentation, I find the abstractions and metaphors the author uses to think about the problem often are not documented and one is left trying to infer them from the details of the program.
And you're forced to arrive at the same understanding by following a distinctly different path of knowledge. Maybe like trying to learn calculus before algebra? In that there's an unknown hierarchy of abstractions and you start trying to understand them at a random location.
All the pieces are in place, I just need to organize it.
This is an interesting read: https://arxiv.org/pdf/1604.01290.pdf It discusses the implementation of the Dino language, which includes an Earley parser in its standard library. (Bumped into it reading about Marpa)
But in short: The first problem is, how do I make Lever better for live-programming?
The second problem is, is there a better way to associate documentation with the code?
The current model I am using is: have a documentation URL
when the module is done, I roll through the module names and annotate them with documentation reference.