Hi Nimmers,
I've put together a proposal for what might be the first accepted grant under the grants program made possible by Nim's partnership with Status to accelerate the development of Nim.
The proposal is to make Nim better suited for interactive programming by implementing support for hot code-reloading and then a REPL and a Jupyter kernel based on it. You can read the full-text of the proposal here:
https://github.com/nim-lang/Nim/issues/8927
Please leave your comments in the Github issue and vote whether you consider this project worthy enough to be one of the few grants awarded each year.
As no reactions here, maybe not everybody proceeds to the GitHub page, so some description:
The proposal is about live coding facility in Nim. Probably most know about such a thing (though probably as an idea), still maybe it can add some clearness. That is if you have a very stateful, long-running application, like a game or some complex GUI application, you may have, when debugging, to repeat many times the cycle of
. You may even develop special development-only means to get to that required state quickly (like via a special command-line argument or a configuration setting) or use some other hacks, just to practically enable debugging. And what you probably really want in such a case, is not to exit the program at all: just to change the code as the program runs, and see the changes. A WYSIWYG for programming. Yes, debugging can take hundreds (thousands?) times less, than it takes. And programming itself too. So far we imagine, "what it would result in, to change that value to that another?", and we can instead just see that. Yes, like adding a button to a window of already running program and the action for that button, not restarting.
But better imagine: after long running of a program, after lots of actions (we don't want to repeat them each time! and really even we cannot, too long! and we can know not exactly the conditions!), we get some misbehaviour; we don't have any logging there, because we did not anticipate that misbehaviour; and now, instead of investigating bytes and bits in a debugger, we just add that desired logging post factum and see what's going on there; and even then change a suspected cause of the problem and see if that's the case. With just recompiling the changed module.
Here's a video and some description of an implementation of live coding for c++: https://molecular-matters.com/products_livepp.html#video.
Looks for me this is the way programming will be done before long (the future that comes, as is Nim — perfect fits to each other?). Would be interesting to see other's opinions on the subject.