Re: non-update of RedyCode
- Posted by petelomax 1 month ago
- 474 views
I may be hopelessly romantic, but I think there'll always be demand for languages that human programmers can write in, and if it's only for the pleasure of doing it. And it may be easier to write some things yourself, than to explain to an AI what exactly you want to have done? (Btw, might not AI tend towards directly generating machine code, instead of being burdened with human desire to understand what it writes?)
I would say not (to machine code/understanding) for two reasons. Firstly, the current AI we have is essentially just a regurgitation of a summary of inherently flawed SO posts, and while it is a perfectly decent and jolly helpful starting point, the reality is at least 99% of everything it spits out is either flawed or missing something. Reading and understanding the code will often identify mistakes you'd simply never find just by testing, and of course significantly help you compose that "Ah but" message to get the AI to do better. Secondly, the task in hand is more often than not adding a feature to some existing program, and copy/pasting it in yourself, rather than getting AI to re-generate the full application + new bit. Plus there is the whole "learn/redesign as you code" part of programming which means you're never going to get the first prompt perfect anyway.
Locating bugs ... Though I only remember it vaguely after 30 years, I still mourn the loss of MS Basic PDS (not Visual Basic!), which in the mid-90s had a console IDE that combined editor, interpreter, debugger and compiler, let you set stop points and triggers to halt execution, let you continue executing line by line, let you continue from any line in the code, and let you not only observe the values of whichever variables you were interested in, but also change them. Now, to have that for Phix ... Ok, just dreaming. :)
A new and better debugger is high up on my wish-list. What I'm after right now is a prototype: disregard/fudge all the low-level "impossible" stuff, and provide a source code snippet/variable values/line numbers and everything else artificially. Don't even think about parsing the source, or actually executing anything, just fake it all. Of course the prototype won't actually do anything except follow a pre-determined script, and if there is any complexity it will be how detailed you want to make that script: forward/reverse execution (like I said, stop worrying about "impossible"), to branch or not to branch, step over/into, edit variables, resume on a different line, and so on could/should all be emulated. One other thing I want is to "abandon" the current debugging session and on restart (optionally/potentially after externally editing the source code or restoring some data files) automatically "replay" things to get back as close as possible to where we just were.
It would be spectacularly brilliant for a debugger to analyse a specified ex.err file and (with a little help) get you within earshot of where it is about to go wrong as expediently as possible, ie/eg right click ex.entry == "trap here when this set". [By "script", I mean you're (probably) going to have to tap the keyboard to get it to advance, but it doesn't actually (need to) make any difference whether you hit return, space, 'x', or whatever.]
Hint: reverse execution is impossible, but a new debugger could easily keep a mini-history of things it has already displayed, and when that's not enough it's "restart and stop a little earlier" time. Likewise "hot reloading" ===> "restart".
(I have studied this a little bit, and one thing I can state is that I have no plans to do anything whatsoever about non-deterministic execution, other than force such problems to be solved, as now, by asserts and studying the ex.err file.)
Incidentally, I do not consider use of rand() to be non-deterministic, but instead something a smart debugger should be able to sidestep by saving the initial get_rand() value and later invoking the appropriate initial set_rand().
Likewise it should be perfectly able to fake the results from time() and similar to keep a problem reproducible, no matter how slowly or quickly the programmer single-steps through the code [as long as it "saw it happen" at least once].
The one thing you probably won't like is it has to be a GUI, and right now I've got to finish writing the GUI that I'm going to use to write the prototype with.
I am planning the new debugger can be runnable standalone and embedded in the replacement for Edita.
