5 ms·

One of the comments I always have when I see environments like this is that it looks really neat to have all these adjustable sliders and partial debugging and

One of the comments I always have when I see environments like this is that it looks really neat to have all these adjustable sliders and partial debugging and whatnot, but when you attempt to apply this to any truly useful program (ie: Anything that performs side effects) it really starts to break down if that side-effect isn't idempotent, like writing a file to a disk, or making a network call you really only want to make once, etc. Do you have any strategies for that, or is the idea that these features are really only for testing functions that don't cause those sorts of side effects?

deleted 10y ago
[deleted]
rtpg 10y ago
One way to work around this is to write programs that work in memory and have a button that manually triggers side effects So you do all your manipulations and then hit a "Save" button at the bottom which triggers the save to disk. Similarly if your input depends on a side effect (web resource?) You place a button on the top which will "start" your program. Of course, the programming environment can offer primatives (debouncing and the like) to help make this stuff easier.
voltagex_ 10y ago
I wonder if the debugger could be combined with a really good mocking framework. That seems like a good idea for a "live" testing framework. Maybe that's something that could be used to help prototype unit tests themselves.
chvid 10y ago
(First congrats on a great looking project and really good copywriting/teaser.) I think this sort of highly interactive environment is best suited for languages without side effects at all. I.e. purely functional language as you see it in a spreadsheet. Allowing any language (JS, Python and so on) gives problems with how to handle errors, show variable values that change over time, how to handle programs that take a long time to evaluate (or never evaluates), how to handle programs that modify the environment (i.e env.x = env.x + 1) and so on.

deleted 10y ago

[deleted]

rtpg 10y ago

One way to work around this is to write programs that work in memory and have a button that manually triggers side effects So you do all your manipulations and then hit a "Save" button at the bottom which triggers the save to disk. Similarly if your input depends on a side effect (web resource?) You place a button on the top which will "start" your program. Of course, the programming environment can offer primatives (debouncing and the like) to help make this stuff easier.

voltagex_ 10y ago

I wonder if the debugger could be combined with a really good mocking framework. That seems like a good idea for a "live" testing framework. Maybe that's something that could be used to help prototype unit tests themselves.

chvid 10y ago

(First congrats on a great looking project and really good copywriting/teaser.) I think this sort of highly interactive environment is best suited for languages without side effects at all. I.e. purely functional language as you see it in a spreadsheet. Allowing any language (JS, Python and so on) gives problems with how to handle errors, show variable values that change over time, how to handle programs that take a long time to evaluate (or never evaluates), how to handle programs that modify the environment (i.e env.x = env.x + 1) and so on.