As far as I remember (maybe Arnar or Úlfar or another of the authors would have a different memory, though) we just wanted a “cool cookie” name. We knew about the -oon/-on distinction and liked the sound of -oon.
I view it as a mild plus that the confusion around the name has educated so many about confectionery taxonomies.
If it helps to think about the issue, we have a (free, online) book that manages this transition, so we've thought about this quite a bit and one co-author has been teaching a Pyret -> Python flow for several years. [https://dcic-world.org/2021-08-21/part_intro.html]
Various flavors of a course based on "An Incremental Approach to Compiler Construction" [1] have most or all materials free online, some with excellent notes. Taught at UCSD, Northeastern, Swarthmore College:
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.
Nice! Something like this is super-important for user experience.
This is a problem we've thought a lot about with Pyret, and have different concrete solutions. Rather than use heuristics that turn long-running computations into errors, we capture continuations and yield to the browser periodically. This allows long-running computations to eventually complete, while allowing the user to fully interact with buttons and the page while it's happening. This generalizes to nice abstractions for functional event loops and ways to manage asynchronous APIs for novices.
The Doppio JVM and the Whalesong compiler for Racket have similar underlying approaches.
It's quite a bit of effort to work around this inherent limitation of the browser's evaluation model for web-based IDEs!
I've used this informally as justification before when renting housing and bringing my dog to work (she's a plain CGC).
I think there's value in having these be more recognized. I especially wish they were by airlines.
Note that this isn't the same thing as the issue with service animals, where credentials are at a totally different standard, and more important than where I can bring my pet.
It's worth mentioning that Pyret followed this path. It was originally a Racket #lang. Once we got the design off the ground and decided to primarily target the browser, we wrote a new implementation in JavaScript and Pyret. The tools in Racket (including ragg [http://docs.racket-lang.org/ragg/]) were invaluable in getting started quickly.
This archives the state of the system when we made the switch:
Cool to see Whalesong up here; it's worth pointing out the incredible effort put into making this really work for Racket, _including_ support for continuations. That is, you can compile a Racket program that uses call/cc and friends to JavaScript.
This is huge because with powerful control operators like call/cc, you can simulate pre-emptive multithreading within a browser tab. This gives the runtime:
- The ability to simulate synchronous functions backed by asynchronous library calls (e.g. apparently make a synchronous request to a URL from the program's point of view, but have it backed by an AJAX request)
- The ability to add a pause and/or stop button to an IDE within a browser tab, even if the program goes into an infinite loop
In fact, work on Whalesong (and a few earlier prototypes) more or less run the Racket-using parts of www.wescheme.org which 10s of thousands of students use each year.
Most x-to-JS implementations don't have this level of feature richness; Doppio and GopherJS are two that have similar levels of execution control.
I worked in the same office as dyoo while he was implementing Whalesong about 5 years ago, and learned a ton from him and from the system. Pyret and code.pyret.org directly built on some of the code for the "framework to program the web in functional event-driven style" in reactors (https://www.pyret.org/docs/latest/reactors.html). Whalesong's APIs for programmatically saving and restoring the stack inspired the ones we use in Pyret, as well.
My compilers course has all the lectures recorded, and has starter code for all the assignments provided. It provides all the parsers, and focuses on the backend, including memory management and various details of value representations.
This is just my materials, I don't have an associated platform with verification/certification. However, some folks from HN have previously done the course and emailed me after, and seem to have gotten some value out of it.
I think this has lots of potential. I have thought before that if I could make two changes to Slack (which I already think is pretty great), they would be:
1. Hitting "Enter" doesn't send the message. This encourages writing actual paragraphs in response, rather than sending fragments of sentences
that can be interrupted across multiple lines
because you're not really sure if you've finished your sentence just yet
oh and you thought of one more thing so everyone else please take this line into consideration as well
Of course, you might say "train your team to not do that." Sure. But I'd rather use a tool that doesn't require breaking (perhaps reasonable) habits. And if communication shouldn't be through short bursty chunks by default, why make that the easiest thing to do?
2. Make threads more of a default way to respond, and make thread comments first-class citizens. Presented with the UX of Slack, it's really hard to move yourself towards using threads because the easiest way to respond to things is to type and hit enter. Also, threads live in their own "All threads" space, not organized by channel. Thread comments aren't first-class citizens like regular chat is because they can't have files attached, be posts or snippets, etc, so sometimes it feels like I actually _lose_ functionality by starting a thread.
Twist looks like it has what I love about Slack – good for newbies to join in and see organized, curated history (I can't show new folks _my_ inbox labels and organization, or spin up a new channel on a mailing list for each topic we want to discuss), good for lurking on projects that aren't your own but are related, and has emoji responses for celebration, quick feedback, and commiseration.
I view it as a mild plus that the confusion around the name has educated so many about confectionery taxonomies.