Think "12 Monkeys" instead of "Back to the Future"! On Mon, Dec 5, 2016 at 12:57 PM, Duane Johnson <[email protected]> wrote:
> 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. > -- 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.
