No traveling!? I think this should be called the Archeological Debugger. :)
On Mon, Dec 5, 2016 at 1:35 PM, Nick H <[email protected]> wrote: > Thanks for sharing your thoughts! > > The "time split" you describe actually used to be a feature of the time > travel debugger. But judging from Evan's comments on elm-dev, it doesn't > sound like it is going to come back. For example: > > (Source > <https://groups.google.com/forum/#%21searchin/elm-dev/status$20update%7Csort:relevance/elm-dev/5Tm5_x7AfyQ/a5Kj8TNeCAAJ> > ) > >> In the old debugger, you could go back in time, and then choose a >> *different* future. >> >> This works *within* Elm, but as soon as you are interacting with a >> database or JS or a server that *doesn't* know about time travel, you >> are can introduce all sorts of subtle bugs. It's like in the time-travel >> movies. It doesn't really work if you think about it. >> >> So I think the new version well let you go back, but only let you >> "resume". Basically, you can travel to the past, but you can't change it. >> You are just an observer, and when you are done looking around, you come >> back to the present. >> > > > > On Mon, Dec 5, 2016 at 5:49 AM, Ruud Steltenpool <[email protected]> > wrote: > >> Hello all, >> >> What I tweeted and was unsurprisingly not clear to @rtfeldman (of Elm >> fame): >> >> interactiveProgramming >> +eventRecorder >> +timeTravel Debugger >> +ifThen timeSplit >> +refactorTool finding similarities >> =enactLikeCoding? @rtfeldman >> >> Let me try in slightly longer form: >> (me = doesn't code much at all, thinks a lot about >> data/structures/working together/design) >> >> Hopefully there's something in there for you smart routined >> coders/designers) >> >> Interactive Programming to me means: your code and variables stay in >> memory even when the end of the code is reached. When you add something >> afterwards, the code will continue. REPL is a flavour. I could imagine >> also being able to PAUSE, CHANGE code somewhere in the middle, RESUME. >> >> Event Recorder: all (user?) events are logged >> >> Time Travel Debugger: You can time travel through state, see what >> variables you had with what values at any point in time >> >> If-Then Time-Split, let's just call it time split, or parallel universe: >> Flow through code is not just 'one straight line through time', but the >> route is dependent on values through If-Then, Case-Switch, etc. So if >> you travel back in time to a point before such a decision and change a >> value and see how the code goes from there you will not only get >> different values, it will even give a new flow through your code. Maybe >> a Time Travel Debugger already support keeping (in parallel) the part in >> future you're changing aka doing differently in parallel, if not, I >> think it should and the next bit hopefully explains why >> >> refactor Tool finding similarities: what if your coding environment >> facilitated a more experimental style of coding, learning and improving >> while doing probably doing some coding along the way that is not nearly >> the quality you need as an end result. When the tool shows you >> similarities as you type, it helps you structure your code. Then it's >> less bad to repeat yourself, cause the tool helps you to >> DontRepeatYourself in the 'final' version. >> >> Maybe with all that in place maybe you can get to something I call >> enact-like Coding. It's sort of a mix of getting the specs right, >> prototyping/implementing and user testing: A potential user interacts >> with your 'GUI canvas' and you code, while talking about what it should >> do. While you log his/her actions (and maybe record the audio/video of >> your meeting together) and build a prototype that can be very simple as >> you're right there (in reality or over appear.in) to explain it. After >> the meeting you and your colleagues turn the prototype into an alpha >> version and then have another meeting with the/a user. As certainly for >> the first meeting you probably need the person in charge of the money >> describing your task, this will force him/her in the role of the user, >> thereby making him more open to proper usability/user-friendliness. >> >> Also makes me think of the only bit of 'start-to-end pair programming' I >> did almost 25 years ago: >> I was typing the algorithm, next to me someone interrogating me about >> what things meant and what was going on and I told him 'shortcuts' I was >> taking to later fix so I could keep my higher-level train of thought. He >> typed that all on his completely unrelated system, so it took more >> manual labor to combine than it would take nowadays >> >> bonus: the system shouldn't care too much about where you change your >> system, change CSS, DOM-state, HTML, javascript, some other file/state >> >> It feels like there are some similarities with git, build on that where >> possible >> >> Hoping this wasn't a complete waste of your valuable time, >> >> Kind regards, >> >> Ruud >> >> PS: Hoping to finally code something in Elm during Christmas break >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Elm Discuss" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> For more options, visit https://groups.google.com/d/optout. >> > > -- > You received this message because you are subscribed to the Google Groups > "Elm Discuss" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "Elm Discuss" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
