stop obsessing about text and start exploring Math.
I didn't wanted to make you angry, i'm just playing around with snap! and trying to translate my ideas into it, I think that's the beauty of programming...
Why don't you respect peoples' ideas, even if you don't like them?
Sorry if I'm aggressive / defensive about blocks vs. text. Blocks are my passion, but all everybody is interested in is text. There's a reason I decided not to use things like "block specs" for syntax analysis: I wanted to divert the attention from what's written on the blocks to what the blocks mean.
(I guess if I were a bazillionaire I'd be prone to become one of those frustrated Bond-type former idealist-turned-super-villains ^^)
So built-in codification was just a moment of weakness and deserves deprecation?
I made codification after Brian took me to a robot race at UC Berkeley, and we wondered how we could support programming autonomous robots that need to be programmed in C using Snap.
I haven't been following the Snap releases, what is syntax analysis?
Do you not realize how long it took to make my reverse codification project? Do you not realize how much I've learned about recursive calls and learned how to use other primitives? This is depressing. I feel you have no care whatsoever about what other people think.
Wow.
We are having two different discussions. You want to talk about why dynamically created variables are a bad idea; I want to talk about why yelling at users is a bad idea.
You're right, Jens! There are better ways to create variables dynamically than the Variables library.
But, why do you totally blow your top about it?
The thing I hate, looking at kids' code, is seeing a chunk of code copy-pasted a dozen times instead of making it a procedure. That's what makes me feel like a failure. And when it comes up, I do try to teach the kid better. But I don't yell at them, and I don't exaggerate how terrible it is. And I definitely don't propose that we remove "duplicate" from the script context menu!
I think I know why you go ballistic about this: It's because you see the Variables library as an attack on blocks. But I don't think that's what users are thinking at all! And I point out that when you click "Make a variable" you get a text box, into which you type a variable name. Why is that not an attack on blocks? From a text-vs-block standpoint, the two ways to create a variable binding are equivalent.
No, what users are thinking is that making variables is an affordance of the language, and so they want it available to their programs. This is really the argument about Eisenberg's Law again! Or, since that'll set you off on another rant, let me put it differently: This is an argument about first classness. Users, not all of them but some users, want first class variables.
It would be an interesting experiment to make a GENSYM primitive that creates a variable and reports a handle to it, all without text, and see if users can use that in the circumstances in which they now use the library. You'd have to be able to drop a gensym handle onto the first input slot of SET, and you'd need a primitive to dereference a handle. That would be much less textish than your dictionary proposal, since dictionary keys are still text. I used to use gensyms a lot, in my youth, and I bet I'd use them in Snap! if we had them, although I don't have an application at the top of my head right now.
We should talk about blocks vs. text. You seem to feel that any time anyone wants to use text in a program it's an attack on your life work. I think that thinking that way just sets yourself up for disappointment. Sooner or later all our kids are going to get a job, or go to college to study CS, and they're going to find themselves programming in a text language.
The great, wonderful advantage of blocks is that we can use visual cues to make it easier to learn new ideas. I'm super proud of how much more understandable
is than (lambda (x) (+ x 3)). Or the list of blocks in Vee, so natural that we don't have to make a fuss about it when using Vee to teach recursion.
So yeah, blocks are great. But the ^F search feature is a real concession to text programming: using the keyboard is way faster than looking for a block in the palette. And that's okay! It doesn't undo your life's work.
But the point of teaching lambda in Snap! is that when they get out into the real world, our kids will have first class procedures as a tool in their toolkit, and that'll give them a big advantage over programmers who started with a mundane programming class. It's not that they're going to talk their bosses into letting them do the work in Snap!.
Okay, enough for now.
I'd prefer there were no textual names for variables; which is more an extreme position on the "textish-blockish axis/continuum" compared to Jens.
In my No-text world, a series of small images, resembling icons/emoticons/emojis, are used as variable names.
(more-than-you-want-to-know)
<Beginning of the more-than-you-want-to-know>
Namely, that is the world I lived in at age 5 when (in my ex-country) they used to send kids in the 1970s to an 'asthma children rehabilitation center' with no one (including the doctors and parents) having a slightest idea what '30 days' uttered by the 'grown-ups' as something trivial, with zero toys (let alone phones/chromebooks/notebooks that didn't exist yet), except the two books filled with series of small images, meant for a kid not knowing whether parents would come to pick up the kids after those 30 days at all.
I learned there how to imagine
anything without text and without numbers.
P. S.
With the change of perspective, my profile description has been updated to: "Imagining anything without text and without numbers is my superpower acquired at age five."
<End of more-than-you-want-to-know>
--
I share Jens' view on this and related threads. That's not to denigrate any flavor of "hacker", I've been various flavors myself. I just see Snap's mission as: seed and nurture interest in computing in youth while fostering good programming & thinking practices.
Low floor + No ceiling + Clean Expressive tools.
Blocks + Scheme + Actors?
For example, a library for self-modifying code might seem fun but will plant habits in learners that exacerbate the X-Y Problem. It's a mistake to go down such paths. Compare the nature of discussions over on Bootstrap or Pyret.
I'd much rather see Snap libraries like:
- compose shapes and costumes
- school math: basic algebra (please, a
let:-), plot composite graphs, do calculus (numeric, auto-diff, ...), other functions that transform functions (shift, scale, reflect, compose) - school data science: integrate with a data science tool like Codap (done in NetsBlox)
- school science: tools to model science, the world, even computation
- models (data types and functions) to make music
- physics for games
- the entire No-Walls space NetsBlox opened up
Macros might alleviate some use cases, and I hope we get them soon. And if someone still wants to work outside what the language offers at that point, perhaps just fall back to a JavaScript block?
Do you have any concrete ideas for the libraries? I could probably help implement some of them.
That would be great !
I'll start with declarative graphics. I can add others later; also already linked the data-science integration one to a working NetsBlox project.
https://package.elm-lang.org/packages/evancz/elm-playground/latest/Playground
You can try the code examples live at Ellie, here is the first one with 2 line boilerplate:
https://ellie-app.com/ghPrS7ZTjxda1
Should probably build on a separate library that allows these graphics to be drawn on sprites, and should limit to static graphics part of that lib (not try, at least initially, to do the declarative animation & interaction bits).
Grump. If you think you know a better way to program than some kid way, the thing to do is write an exemplary program and let kids see it. Not to lecture kids about how they're doing it wrong. For kids, there's no such thing as "doing it wrong." Kids aren't professionals. Whatever is fun for them is "right." This was a subtlety of Logo design; the language made it easy to program in ways we approved of, but we didn't lecture kids about those ways. Whatever a kid does is fine.
Well, wikipedia says it does have practical uses...
If you, guys, missed something, Snap v7 has built-in "parse by block", "join", "run", and "call" to work with the dynamically created code...
I prefer to call this feature a reflection
A language supporting reflection provides a number of features available at runtime that would otherwise be difficult to accomplish in a lower-level language. Some of these features are the abilities to:
- Discover and modify source-code constructions (such as code blocks, classes, methods, protocols, etc.) as first-class objects at runtime.
- Convert a string matching the symbolic name of a class or function into a reference to or invocation of that class or function.
- Evaluate a string as if it were a source-code statement at runtime.
Also example of languages
|5.1|C#|
|5.2|Delphi / Object Pascal|
|5.3|eC|
|5.4|Go|
|5.5|Java|
|5.6|JavaScript|
|5.7|Julia|
|5.8|Objective-C|
|5.9|Perl|
|5.10|PHP|
|5.11|Python|
|5.12|R|
|5.13|Ruby|
|5.14|Xojo|
I agree, Brian. And I did not mean to lecture any kid. If some facility is in a library or in the language proper, and a kid uses it, lecturing that kid is not the answer. In Jens' comments I saw more frustration at a library than at a kid, but that's just my guess.
Snap leadership is the guardian of Snap's mission and should accordingly decide what to include in the language and its libraries. And to prioritize candidates on both. That is as much about what to leave out as what to include. We trust Jens & you with both.
It's what this block does:
[scratchblocks](split ((\ :: operators stack) :: grey ring) by [blocks v] :: operators)[/scratchblocks]
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.