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.
