Finding Integration Win-Wins with Patch #195
Comments
|
To get us started on searching for win-wins, here are a few notes that Elliot and I discussed at each layer: RuntimeAt the runtime level, Patch development has been challenging because fighting with the scratch-vm is hard. It is old, big, and was never designed to be used for this purpose. It would be lovely if they could completely replace the Scratch VM with the Leopard runtime instead.
Having an additional use case for the Leopard library would push and pull on its design in interesting ways. It's not clear to me what the pros and cons of these new tensions would be. It's possible that expanding the ways Leopard is being used and deployed would encourage more accessible, reusable APIs that are better-designed for more use cases. It's also possible that these new use cases could distract from or compete with the existing set of Leopard design constraints. Personally, I'm inclined to believe that this would be much more of a net gain than a loss, but I don't have much reasoning–just my gut sense, which is not necessarily well-trained. Code EditorThis one is interesting. On the one hand, we are both building the same thing: A text-based code editor with JavaScript conventions. But we also have different goals. In particular, I think that Leopard being no-magic/its-just-web-development drives us towards mostly just neatly integrating existing tooling as-is. (For example, I've plopped in the Monaco text editor which powers VSCode and it is giving tons of benefits for free. No additional setup required.) On the other hand, Patch wants to design more custom-tailored (potentially magical) experiences, and ideally expose this customization functionality to users like teachers who might want to create custom experiences for their kids. This lends itself to choosing technology that provides less out of the box but is more tweakable, like the CodeMirror editor. One narrow slice I could see us easily collaborating on is costume and sound editing. Those things are nice to have integrated into the editor and would likely be the same between Leopard and Patch. In my mind, it's still a very open question about where we can find win-wins in the building of our code editors. Project Sharing/CommunityThere is lots to be explored here, but so far the only thing Elliot and I have touched on together is the fact that both of us will have to do content moderation (at the very least filtering out nsfw content) and there's room for sharing our learning or possibly even our infrastructure there. I think there's lots more room for discussion on this. I could honestly imagine the win-win opportunities here being a total dud or the most important thing we do. |
|
Hello! Elliot from aforementioned the Patch & BX Coding team here. Figured I pop in here with some more details on Patch. Patch's GoalsMake a student's transition from Scratch as easy, intuitive and fun as possible.Because of this goal, we fall much closer to the ✨magic✨ end of the spectrum of conversion as @PullJosh mentioned. An example of this is events. Leopard's method for event handling is to use a user-created trigger object to designate scripts that should run during certain event (e.g. Make teaching CS in-schools easierBecause we use Patch in BX Coding's summer camps, it has an associated curriculum. It starts kids in Scratch, then jumps to Patch and finally Python. We want to continue to build out Patch's educator features (in-editor explanations, clearer/custom error messages, lesson & curriculum builder) to begin allowing for use in in-schools environments. Critically, we want to build an editor that allows educators to decide how much ✨magic✨ they want to show to their students and also share this configuration with other educators. This is very similar to what exists in Replit right now, but--from what I can tell--they've shifted away from educational use cases. And, no other platform that I've found so far (could definitely be wrong about this) easily allows the sharing of editor configurations. If you're interested in reading more about our actual implementation, our repo is here (the documentation is admittedly a little out of date) and our live MVP is here. Will be following up with more thoughts on win-wins and potential challenges a little later, but in the meantime wanted to follow up with the above info! |
|
Hello! Totally not experienced with Patch before (although it looks awesome), but we've helped code Leopard and sb-edit. We have a little technical perspective! RuntimeLeopard provides bare utilities for a totally separate runtime than scratch-vm. However, compatibility with Scratch has been a huge goal from the start, since a lot of its magic comes from showing that your very own Scratch projects really will work when coded with plain old JavaScript! That magic would fizzle without good compatibility 😅 It sounds like it would be awesome if Patch could use Leopard as the internal "framework" which deals with all the nitty gritty of actually running the projects. But, if we're standing in for an existing implementation based on scratch-vm, we need to consider two different questions, IMO: 1. How much does Leopard still not support scratch-vm behavior? Would this have an impact on Patch?
2. Is Leopard a good fit as a "just slot me in" internal project runtime? Could it be? Does it meet Patch's needs?
We can't follow most of these dots up with relevant detail yet, because we don't have a good understanding of exactly which behavior Patch Worker is responsible for and is ready to take over from scratch-vm (and thus from Leopard). Generally, the more Patch takes responsibility for its own execution state, the more useful I think Leopard would be to it as a runtime library. I think Leopard should be really quite simple and provide useful interfaces for making things happen, like a ready-to-go game engine with convenient primitives, regardless if you're using Leopard's built-in control flow (with JS generators/yield, etc) or just hooking into its primitives from your own control flow (as it sounds like Patch would). I'd love to hear about what challenges Patch has run into when interfacing with scratch-vm, and how the team personally feels about the new(?) framework, with most execution functionality stripped out of scratch-vm and moved into Patch Worker. Does that feel like the right direction for Patch's runtime? Are there things you wish could be easier or nicer than they have been, or still are, with scratch-vm? I think sharing some of that would help identify how well Leopard could work as a library that helps Patch! Editor
Totally agreed. I don't know what direction you're feeling (@PullJosh) for these two components, but it would obviously be great to have them be nice and compartmentalized for easy integration into both editors, and I think there's a lot of room for making something basically accessible/tailored to any Scratcher while not being a 1:1 port of scratch-paint or scratch-gui audio editing components — if you're leaning towards DIYing paint and audio editor interfaces. This is just based on vibes, but I don't think there is a lot of reason to directly share technologies for the editor as a whole between Leopard and Patch. They have very different goals and would each probably benefit from having a focused team who gets to work with just their own code — not worrying about making sure they're figuring out the perfect prototypical interface to make something work for both Leopard and Patch, stepping on each other's feet, etc. I love the idea of a rather magical and highly-teacher-customizable editing experience, but that doesn't seem to be in the scope of what Leopard is focused on. These two editors also just have very different user audiences, so letting the editors be tailored on a very basic level to both seems fine. IMO the far bigger challenge is user playtesting and interface design, not technical implementation, so unless the editors share a lot of technical overlap, better to have the editor technical teams work independently of each other. Web-based IDEs are a pretty mature area of software at this point so if those teams have differing opinions on which libraries to use / how to integrate them, better that they can figure the right way out for themselves. (There can still totally be sharing of knowledge and experience here! I just think the editor codebases should be separately written and not directly related to each other.) Project Sharing/CommunityNot a lot of room for us to comment on this, sorry! It totally depends on what Patch's and Leopard's goals both are. I do think there's a lot more room for technical overlap between the Patch and Leopard websites / website tooling, though! It seems like it could be super reasonable to share not just moderation but technical efforts here, if they have a significant amount of feature / functionality overlap. |
|
@towerofnix Elliot can comment on this better than I can, but my understanding is that it would be best for Patch to handle all control flow of blocks. Essentially, Patch would own the triggers situation and would simply call things like I'm wondering about your opinion on how this would affect Leopard. I honestly don't think it would require very many changes. You listed a few: exposing events like when a sprite is clicked, providing better tools for long-running blocks (maybe async versions in addition to their generator counterparts?), etc. I'm thinking these changes would be almost entirely positive for Leopard. You? (Oh, also! When users write a Leopard project, the expectation is that each sprite they create will be a subclass of
I'm not sure either. Part of me is tempted to just embed the Scratch costume editor directly, but another part of me is very much not. Working with Scratch's libraries seems like a bit of a pain. Either way, I personally think that image/audio editing is not Leopard's core competency and it seems like the perfect thing to outsource to an existing component that exists somewhere on npm.
The more I reflect on it, the more I'm inclined to agree. The editor design seems like the place where Leopard and Patch differ the most philosophically, and it seems like there are meaningful differences in the tech stack (Monaco vs CodeMirror, for example) that make sense for each project. This may be a place to share ideas more than code. |
Scratch VM Challenges
The main positive of the Scratch-vm is it allowed us to bootstrap a reasonable MVP relatively quickly, which it has succeeded in that use. However, most of our struggles developing with the Scratch-vm is because of it's age and bloat. We were able to slim down the code base. There was a huge amount of functionality that was ripped out when we forked the repo and made the Patch-vm (mostly execution & threading stuff). But, the remaining code base is left oddly disjointed, dense, and still old! It doesn't have any typing, it does not use any of the new async/await js syntax sugar for async code, and still includes much more functionality than we actually need. As we were working towards our MVP last summer, we couldn't justify the dev time that it would have taken to clean up some of the tech debt left behind. So, for example, there's a package (I believe minilog) that scratch-vm depends on that has not been updated for 7 years. We couldn't get working with Vite (there were also a number of other older packages that were causing issues) so we had to just go with using webpack instead, which, while not the biggest deal, characterizes a lot of our struggles. Additionally, It just costs a huge amount of time to get new devs onboarded to the codebase. In summary, a lot of the appeal of the Leopard VM would be to simply improve our dev experience with Patch. Patch ExecutionThere is one final decision that needs to be made in terms of Patch's runtime is: how do we handle forever loops? Right now, we just convert this into a regular python
Currently the Patch worker does not handle this, because of our goal to make the block -> function conversion exactly 1:1. We hide a lot of the syntax magic that does this right now, but from the worker POV, it's just awaiting a promise and then resumes execution of the python code afterward its resolution. Other than this, Patch handles all runtime execution.
I believe so, we're wired into something analogous right now through the Patch VM
I'm not sure what you are referring to specifically here. Could you link some code or an example? Most likely, Patch worker couldn't handle it though. Supported Blocks
In terms of support, from what I can tell, you guys are ahead of us (other than the stop all block). I don't think this would be a huge issue for us. EditorI am also inclined to agree that right now there are no compelling arguments to collaborate on editors. However, I agree that
For example, it would be cool to have a single platform in which Leopard or Patch projects can be created. In terms of resources, I'd have to get a cost estimate from @PullJosh, but BX Coding would most likely be happy to cover hosting/deployment costs--especially if it's on AWS as we have a fair bit of credit on the platform. Patch & Leopard InteroperabilityI still can't let go how easy it was to integrate the pyscript library into Leopard. There has to be a way to easily to convert from Patch's simplified Python to a raw Python version that works out of the box within pyscript tags in Leopard. |
Scratch VM challenges (@ElliotRoe)Sorry to hear about the troubles there—and thank you for sharing that! It totally makes sense that the age and overall lack of "catching up with the times" would pose a lot of difficulties and inconveniences. We occasionally see signs of movement and progress on the Scratch dev team's part in bringing these things up to date, but they clearly have additional responsibilities. It'll only be done when it's done, and that's not now. Definitely makes sense that bringing it up to date yourselves just isn't in scope for Patch's efforts (it really is a big and slightly gruesome project). Patch execution (@ElliotRoe)Could you explain in some more detail why while (true) {
/* contents of the forever block go here */
yield;
}I'm especially curious why using one forever loop is OK, but multiple tanks your performance. The main principle to understand with Scratch multithreading is that it's not really multithreaded: within one "tick", "step", or "cycle" of the VM, scripts always execute in a determinate order, and only one is literally running at a time. If you are using multiple real threads (i.e. multiple web workers), then the analogy is to only pass control to one thread at a time, and always observe all results of the thread's execution until it reaches a yield point. At that yield point, the worker is no longer doing anything, and waiting for itself to be started up again—this is an idle state on the CPU, i.e. awaiting a promise/event/socket message, and shouldn't affect performance more than any other (This is also why Scratch's interpreter is literally single-threaded: if you're just going to observe all the results of execution immediately after the thread is done, and certainly never have two threads actually running simultaneously, then there's no reason to internally represent threads with separate literal threads i.e. workers. Of course, Patch could have its own reasons for doing this, e.g. compartmentalized state management for Python instances. But real-world multithreading is never necessary just to represent the behavior of Scratch.)
Yeah, that was a sort of obtuse description on our part! What I meant is that Scratch never runs two copies of the same script (under a specific hat block) at once. In general, if you have a script which runs "when space key pressed", then it will run all the way to completion, even if you try to "interrupt" or "duplicate" it by pressing the space bar while it's still running. It just ignores the second time you press the space bar. This is something that whatever controls which hat blocks get started needs to be aware of and responsible for. For example, if Leopard tells Patch "the user just pressed space, trigger all when space pressed hat blocks" then Patch is the one who needs to say, "OK, OK, but no, not the one that is already running. I'll start any any when-space-pressed hat blocks that are not running though." On the other hand, if Patch has already explained to Leopard what scripts exist, and Leopard can ask Patch which of those scripts are running, then Leopard can give Patch a more specific instruction: "OK, OK, I see that some of your scripts are still running in response to the space key. So, since the user did just press space, please start these specific other scripts, which I know are when-space-key-pressed, and which I also see are not currently running." The right approach depends on what level of responsibility Patch wants to take for project execution. Also, work is absolutely needed either way on Leopard's part, since we don't have 100% compatibility on this mark yet (for example in Scratch, "when key pressed" can't be interrupted, but "when this sprite clicked" can be interrupted, and we appear to treat them the same right now). Leopard, the Library™ (@PullJosh)
Oh, totally. We love this direction for Leopard and having a specific project to make sure we are able to support and be ready for is a great motivator and really helps us find direction for what Leopard's interfaces should be like. And do we think those interfaces should exist at all!? Yes, absolutely! IMO the project
Not to blow the air out of our own discussion, but I don't know how much effort is needed on these parts. Leopard's greatest focus has always been compatibility with Scratch. We're already almost all the way there, in that regard, but figuring out how to expose it in useful ways (and at differently useful levels of responsibility) may be challenging. We have some thoughts on practical ways to go about this, but in summary, we're pretty sure it's well approachable and a very worthwhile direction for Leopard itself, that it could be useful to Patch as long as Patch is ready to understand what Scratch's behavior is, what Leopard can provide, and incorporate the appropriate parts of Leopard into its own structure by combining the knowledge Leopard provides with the sense of scope of what Patch wants to (or needs to) be responsible for handling.
Totally! There is no reason Patch can't interface with Leopard (as it's written today, even) in this regard. The only thing that would need special care, AFAIK, is the |
|
@towerofnix I like where your head is at.
I really like this framing. As far as breaking Leopard down into modules that represent the different parts of Scratch's behavior that library users might want to hook into, it seems like in all of our discussions things are clearly breaking down into two separate pieces:
It feels like Leopard could be improved by somehow pulling these two pieces apart so that they can be used independently. |
Patch is a Python-for-Scratchers coding environment that shares many of Leopard's goals and challenges. I've been meeting with the BX Coding team (particularly Elliot) to share what we're working on and what we've learned, and we've been thinking a lot about where we can find win-win opportunities for collaboration.
The purpose of this issue is to discuss how the projects are similar, how they are different, and where there are opportunities for collaboration.
What is Leopard? Patch?
Leopard
What:
Why: To help Scratchers transition to JavaScript & web development.
How: By thoughtfully blending the concepts and conventions from each world.
Patch
The Patch folks can paint a more accurate picture, but I would describe Patch in the following way:
What:
Why: To make computer science education more accessible for both students and teachers.
How: I don't have a great "how" because I'm not on the team. But I will note that they are doing a very good job of focusing on curriculum development and teaching in the real world, not just building a tech tool.
Similarities & Differences
We are both building Scratch -> [language] transition tools. This leads to a lot of inherent similarities.
Leopard focuses on JavaScript. Patch focuses on Python. But the other differences are more subtle:
Searching for Win-Wins
I've been chatting with the Patch/BXCoding team, particularly Elliot, and Elliot brought up the idea of combining efforts and finding development win-wins between Leopard and Patch where we can.
There are essentially three layers of infrastructure that both projects are independently building at the moment:
At each layer, there are big philosophical and technical differences, but also lots that is the same.
The question for this discussion: Are there win-win opportunities where we can collaborate or share code/knowledge/infrastructure between Leopard and Patch?
The text was updated successfully, but these errors were encountered: