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.
