Ken, I understand your concerns, and it's certainly a no-brainer that parametrization is at the very core of abstraction. And again, I'm not saying we're not going to add it. But as a first measure, without introducing any new concepts or new blocks to Snap!, we have two (well, there's always more, but for argument's sake let's reduce them to two) ways to let other programs interact with Snap! projects:
-
encourage other programs to inject JavaScript code, and force Snap! project writers to include lots of JavaScript function blocks in their code. This is the current state of affairs, and obviously it's not working very well even for professional programmers and research professors This also has the downside of not being future-stable, because we never know what people end up writing in their JS functions, so who knows what might break in the next release?
-
add hooks for outside applications to interact with Snap! projects without requiring Snap! project writers to learn anything new or to include any magic blocks. This way those "hooks" (what I magnanimously call the "Snap! API") are just a few "blessed" functions that I can easily guarantee to keep working whenever we change something, encouraging 3rd-party investments in their platforms.
The way I see it there are questions of granularity. When we wish to pass data into a Snap! project from another program or platform, what is it we're after?
Use Case: Interactive Applet
The use case I'm imagining is not so much peer-to-peer communication between different Snap! instances, although in the long run that's a dream I haven't given up on, the use case is some learning / MOOC platform that does not necessarily teach programming. Such a course, say, on the subject of Climate Change, might wish to embed little interactive simulations, games, quizzes etc. which are really easy and quick to create in Snap!. I'm imagining those projects to be embedded in presentation mode without the ability to see the blocks or edit them, just like an applet. This is what I'm trying to address with the "API" right now.
Of course the MOOC platform would want to get back some result, e.g. the percentage of questions answered correctly, or the time needed to complete a simulation etc. These metrics are often kept in projects' global variables anyway, called "score" or "lives". There might also be a platform which keeps track of a highscore. So that would be something useful to pass into a Snap! project before starting the game. It's those kinds of configurations I have in mind that would open up Snap's usage across the web.
Use Case: Aided Programming
There is, of course, a set of much more demanding use cases, that include going meta on Snap's projects to facilitate learning CS and programming. For those use cases I'm imagining Snap's editor to be the "applet", not so much the stage. Use cases could range from Parson's problems to full-blown BJC programming assignments. This is the realm of forks like Thomas Price's iSnap. Here the granularity of actions to log, parameters to pass, scripts to programmatically create etc. is much, much higher. That's what we want self-reflection, introspection and macros for. And, yes, of course I might want to let an outside "controller" call arbitrary functions passing arbitrary data. This is not what the set of functions I threw in last night and this morning addresses. But I don't think we're making any decisions right now that wouldn't let us add those in the future, do you?
I guess the question I'm interested in right now is, do you think that the proposed set of features will come back to haunt us some day, or are they orthogonal to future features?
Anyway, great discussion!