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 <goo...@steltenpower.com> 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 elm-discuss+unsubscr...@googlegroups.com. > 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 elm-discuss+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
