The VB6 IDE, in the 90's, had a great feature where you could arbitrarily drag the execution point around. It was incredibly useful for basically zero iteration time for development. Add a breakpoint, step over your code, and if something went wrong, drag the execution point back a few lines, fix it, and try again.
This seems like a holy grail for IDEs. Why was this feature lost in time, or have I been using the wrong IDEs?
It's worth noting that Stopify itself isn't an editor or IDE as the title suggests.
Stopify is a JavaScript -> JavaScript compiler, implemented as a Babel transform, that enables pausing and restarting control operators for JavaScript programs.
A lot of the comments note the rich history of systems for debugging and execution control. Stopify's goal is to enable those kinds of systems, efficiently, while constrained by the browser's execution model.
WOW. I was not interested at all in this the way that the title implied but now that you describe what it actually does, this does indeed look useful.
The first line of the description should probably be scrapped. The interesting bit about this is not at all the fact there is an editor. Maybe it should be mentioned as a footnote but not as the lead-in.
> it deosn't mttaer in waht oredr the ltteers in a wrod are, the olny iprmoetnt tihng is taht the frist and lsat ltteer be at the rghit pclae... it doesn't matter in what order the letters in a word are, the only important thing is that the first and last letter be at the right place
By the way, the name describes the product _exactly_. The infrastructure enables stopping functionality in JavaScript programs. It stop-ifies them. Hence Stopify.
Y'all, the primary goal is meant to be a compiler infrastructure, not a user-facing product. The reason we have the demo site set up is to show people that the infrastructure composes with a bunch of existing compilers pretty seamlessly. In a perfect world, Stopification is integrated into the existing compiler back-ends and this site essentially disappears. So stop worrying about the name.
Wow I forgot about those. Templating in general sucks, it’s just so hard to create something that makes a program accessible and has safety for user generated content.
Not really. Naively doing something like that will kill performance, not to mention that you have to be really careful not to mess up inserting setTimeout calls.
Stopify reifies the runtime stack and occasionally yields to the browser through a setTimeout call. Once the yields back control, it can restore the stack and resume computation.
It depends on the source language. We have done extensive benchmarking. For example, on Python the median slowdown is 1.4x. PyJS doesn't use all of JavaScript's features and we can exploit that to improve performance. Our worst slowdown is when the source language is JavaScript itself because we can't make simplifying assumptions. (Median slowdown is 20x.)
These are slowdowns on a cheap ChromeBook. We also have results from the four major browsers on a desktop machine.
But note that the Stopify portion is completely optional and composes onto the end of an existing JavaScript compiler. So you can offer a faster-but-no-stopification mode versus a slower-but-with-stopification mode. While modes can be annoying, the point is that you don't have to be forced to pay this price due to the Stopify infrastructure. In contrast, a language like Pyret has the stopification built into its back-end, so you always pay the price (for now), whether you want it or not.
All the selectable languages compile to JavaScript. Stopify takes that JavaScript output and makes programs stoppable, steppable, etc. Therefore, each demo is a composition of two compilers: (1) a third-party X-to-JS compiler and (2) Stopify, which compiles JS to stoppable JS.
This seems like a holy grail for IDEs. Why was this feature lost in time, or have I been using the wrong IDEs?