Please do not use the getters/setter library. It will probably vanish in the next release.
Grumble. Of all the settings the library knows about, two are otherwise available through primitives:
What's so terrible if the project knows its name? Or the user's native language? Or if it turns on presentation mode? Even a user preference such as plain prototype labels is something I could imagine changing in the middle of a presentation in which sometimes the focus is on the editing process and sometimes on the resulting definition.
This library does need updating for v7. I should have done that earlier but other libraries needed updating, too. I'll do it. I'm interested to hear why some particular setting is dangerous, but I think your sweeping rejection is unreasonable. I'm sorry we're having this fight in public, but you started it.
some settings have been deprecated altogether and are no longer supported at all, e.g.
- "Retina display support"
- "Prefer smooth animations"
some settings have been demoted to be removed in the future, because they have now become part of the core language on the same level as HOFs:
- "Inheritance support"
- "Hyperblocks support"
and some trigger the project to be serialized and deserialized, which makes all scripts - including the currently active one - terminate, which contradicts Snap's execution model:
- "Set language"
- "Zoom blocks"
- "Flat design"
some settings can be used to make it hard to impossible to read the code or even to interact with it:
- "Presentation mode"
- "Stage size"
- "Stage scale"
- "Input sliders"
- "Execute on slider change"
- "Keyboard editing"
- "Visible stepping"
and some can be used to sniff user data, especially in combination with XHR:
- "User"
On the larger scope of things I am a fierce opponent of what you construe as "Eisenberg's law", because it represents the very essence of a destructive, elitist and overall antisocial hacker culture, exactly the kind of stuff that's going on in this forum a lot. Snap is different from most programming languages, because you can only open projects in Snap itself. The IDE is both the runtime and editor of Snap projects. Snap projects are meant to be open and shared. Sharing code is at the heart of Snap's pedagogy. That's why it is important that Snap itself guarantees to place the reader of code in control, not the author. If a kid or a teacher opens another kid's Snap! project, Snap will not ever prevent them from stopping a script, from returning from presentation mode to edit mode, from switching to a blocks category or sprite, from turning off the annoying clicking sound or input sliders, or to choose whichever design, blocks zoom and language the reader is comfortable with.
Snap! projects have control over what's going on in the stage. Everything else is controlled by the human sitting in front of the computer. That's being respectful to a community of learners sharing enthusiasm and knowledge with each other. And that's what the "H" in HCI stands for.
Thank you for giving a meaningful answer instead of just an edict.
I said a couple of messages ago that the library needs updating for v7. But for that matter I don't know why Inheritance Support and Hyperblocks Support are still UI options either! (Especially since, as you often point out, runtime checking of those options slows things down.)
I can see your argument for not wanting to set language, zoom, or flat design. (Not quite sure why we have flat design as a UI option either, but never mind...) But that doesn't argue against letting a program read those things.
And, really, even if a program wants to write them, if its author doesn't mind taking the hit, who are we to tell them not to?
But in all the above cases, I can see your point.
But in the group of things starting with presentation mode, the one I personally use most, I really hate the idea that we have to restrict truly useful options because kids can be annoying with them. Kids can be annoying, and will find a way. That's a cost of working with kids, but it's just the downside of the big benefit of working with kids, which is their unstoppable creativity.
In the context of working with teachers and curriculum writers, we've been putting a lot of effort lately into allowing program authors to rearrange the layout of the World. If it's useful for them, it'd be useful for kid programmers. too. If a kid gets obnoxious about it, we ban him.
Well, I'm a proud product of "hacker culture." I don't feel destructive, elitist, or antisocial. On the contrary, I've spent my career bringing the fruits of hacker culture (which include Lisp and Smalltalk) to the masses. I do feel that people should be able to understand and control their technology through and through. I can't stand that "my" cell phone obeys Verizon, Samsung, and Google more than it obeys me.
And that's the founding principle of Smalltalk! Everyone at PARC talked all the time about how important it is that Smalltalk is written in Smalltalk, so that users can reprogram it to behave how they want. I bet that means you can write Smalltalk programs that go into something like presentation mode, basically overlaying a full-screen window over everything. And still, Smalltalkers are encouraged to understand and control their environment, by programming, all the way down to the metal.
And that doesn't detract at all from the fact that Smalltalkers are also encouraged to collaborate and share their work.
And, Jens, you believed this too, back in the BYOB days, when you built a block notation for the underlying Smalltalk code! That's basically the equivalent of JS Function in Snap!.
So I don't get it.
The anti-social part of the hacker culture I'm referring to is making it hard for others to follow your ideas. Putting effort and creativity into excluding others, making them feel inferior and inept. Yes, recently we've put more effort into making Snap scenes and projects more customizable, and we've often talked about how this is giving me great headaches. But at least those settings are visible, explorable and malleable through the GUI, and no script can lock you out of that. Guaranteeing a reliable and predictable user experience for everybody from novice to expert, from kid to teachers is a foundation for democratizing computing education for all, not just for those who all too eagerly get excited over seemingly "advanced" concepts that more often than not turn out to be elitist mirages ("ringifying result values").
Users can control what's going on in the stage. That's their space. The Snap IDE isn't. It's the platform for everybody. It's what makes Snap an educational environment.
Even in its heyday Smalltalk never reached (ordinary) schools in significant numbers, and never was adopted by even a fraction of Snap's user numbers. Smalltalk only ever was used in big industrial enterprise projects, and by the time Squeak came around the rest of the world had moved on to Java and later Python. Smalltalk's design back in the 80's and 90's made it impossible to be used in high schools (except, maybe, for a super-tiny faction of extremely dedicated idealist educators who could've taught anything), precisely because every single program in Smalltalk represented a fork of the whole programming system including the IDE and everything. We're all trying to avoid the perceived shortcomings of our favorite languages out of frustration that they didn't catch on widely. For all my fervent love of Smalltalk and Squeak its fundamental design flaws and shortcomings as an educational programming language have been an element of trauma guiding the design of Snap.
Can you cite any instances of this among adult hackers? I've never known anyone to behave that way. I think you are building a huge structure of argument on top of a somewhat antisocial behavior by a few Snap! kids that stopped when we made it clear we wouldn't stand for it.
My point about the teacher features is that they allow programmers (the curriculum developers) to establish the environment for users, and you put up with that (although it took a big struggle for both of us).
Okay, I have to defend @warped_wart_wars. Perhaps you haven't noticed, but every day he's been cranking out creative projects, your kind of projects, about Perlin noise and stuff like that. In between that, he works to stretch his mind with the beginnings of lambda calculus. And in between that, he does his best to be helpful to users with questions. And yeah, he's also interested in pursuing the fine points of Snap! syntax, about which he sometimes makes mistakes. Just what is your objection? He's trying too hard to learn? He knows about transfinite cardinal numbers? There's a huge difference between a misunderstanding and an "elitist mirage." I think you ought not to pick on kids, least of all this one.
So, I keep giving examples, which you keep ignoring, of why I find it useful to program the IDE, not to obfuscate it, but to teach about it. I'm a little insulted that that counts for nothing in the face of your fury at a radically misunderstood hacker culture.
It isn't actually Perlin noise, and it was remixed from someone else's project.
Yeah... I have a lot of inspiration all the time for Snap! projects.
While I'm on Brian's side is this discussion I want to point out something about HCI. HCI isn't only about the GUI. As extreme an example, I can imagine creating an interface that uses speech input and output instead of menus for customising the IDE (particularly good for the visually impaired). Or a program that customises the IDE for users with poor motor control. A good programming language/IDE should be capable of supporting expert users trying to make variants of the IDE.
Yes, the word hacker has also acquired this second meaning but I prefer this one:
I assume that's only partial and some parts of Smalltalk are still written in non-Smalltalk (instead implemented by the VM), right? (I think this is an obivous yes but I'll ask this question anyway)
Yes, but really very little of it. That was a point of pride for them.
I wouldn't want to rule this sort of argument out in principle, but, you know, there are people in the Scratch community who say that about us: that first class procedures are an esoteric, elitist idea that will get in the way of regular kids learning Snap!.
So it can't be a blanket principle either way. We should be open to the possibility that some esoteric feature might be too esoteric and will drive kids away, but on the other hand we have a pretty good track record about teaching kids functional programming, OOP, hyperblocks, machine learning... I haven't been convinced yet that there are any fundamental limits. (Maybe quantum computing, based on the heuristic that if I don't understand it kids won't either.) Looking forward to Snap! 12.0 in which multiple inputs to a procedure are computed on separate cores of the user's computer! :~)
As for a super-consistent UI being necessary to avoid driving away kids, seriously, aside from the fact that I think it's ugly, why do we have flat design? I've had questions from teachers (admittedly, not as flexible as kids) about why some kid's screen doesn't look like the pictures in the curriculum. And we expect users to navigate list view vs. table view.
I promise that no matter what features we do or don't have in Snap!, some kid will figure out how to turn his friend's screen upside down -- and his friend will survive.
I used to love and glorify Levy's "Hackers". Brian is mentioned in it! Then I realized that Margaret Hamilton also is. Do you remember how Margaret is portrayed in "Hackers"? This changed my mind.
Squeak really was written entirely in Squeak itself including the VM. The VM was compiled from C which was generated from "codifying" a subset of Smalltalk that mapped 1:1 to C, which John Maloney and Dan Ingalls called "Slang". They could simulate the VM all inside Squeak, edit, test and debug it in that subset of Smalltalk, and then generate the C code from it. That's how they ported the VM to any platform.
Aargh! I just lost a three-hour-long reply to this! Boo!
I'll get around to rewriting it...
Of course Snap! should support hackers! Snap! should not support exploiters. I do see why this block poses a risk but is also useful in projects. I will miss it:(
I read that too. Am I the only one who doesn't see the story about Margaret Hamilton as clearly black or white?
Also half the problem was the secrecy of the “The Midnight Computer Wiring Society” which runs counter to the hacker culture.
Did they strive for equality of all programmers, but in the process they became 'more equal' than other people/Hamilton; similarly to how in the Orwell's Animal Farm the leninists vanguardists, portrayed as pigs, became 'more equal' than other animals; or, even earlier in history, French jacobin revolutionaries?
Okay, I'll try to recreate what I said that got deleted.
Yes, Levy's book is too celebratory.
When it came out, my critique was that what he calls the "Hacker Ethic" is really more of a Hacker Aesthetic. The distinction comes from Kierkegaard, who presents a dialogue between two people, an ethical one and an aesthetic one. Their two points of view are contradictory, and according to Kierkegaard there's no way to choose between them by logical reasoning. (This is in response to Kant, who does think he can prove rationally that you should be ethical.) Instead, Kierkegaard falls back on faith: You should be ethical because God.
Anyway, there's nothing about ethics, really, in the so-called Hacker Ethic. Rather, it's a statement about the working environment hackers want. I'm not sure whether it's from Keirkegaard or someone else that I got the idea that young people are naturally aesthetes, and that ethics is an achievement of maturity, and in particular of having children and obligations to them.
And Levy's heros were all young--kids, really, still.
MIT-AI, which is where Levy mostly got his ideas about hackers, was far from a perfect society. The reason I'm in Levy's book is that I complained to him about how quickly and easily people were categorized as "winners" or "losers." This is obviously socially poisonous, and failed even in its own terms: Gerry Sussman was widely considered a "loser" when he arrived at MIT, not entirely without reason, but clearly he transcended the category. So it's not a big surprise if Margaret Hamilton was also miscategorized, especially since, yes, there weren't many women among the hackers.
The story about Stu Nelson breaking the PDP-1 isn't anything to celebrate. But in his defense, that computer was the one designated at MIT for students to play around with. The designation didn't mean that it was okay for students to break it, but it was maybe less not-okay than it would have been on a machine designated for real work. Also, Nelson must have been very young, because after he discovered the AI lab he would have been working on the PDP-6 rather than the PDP-1; there he would have learned that the proper hacker etiquette for midnight changes (and midnight is the time for system changes, because during the day people are doing real work on the machine) is that when you're finished with your mod, you go to sleep in the machine room so that if something goes wrong with your work, people can wake you up to fix it. (It's also the case that Nelson thought a lot of himself; his login name at the AI lab was "n", one of two single-letter logins.)
Let me tell you a better story. In the summer of 1968 I was a volunteer at the New York headquarters of Eugene McCarthy's campaign for President. There was a problem with the telephone switchboard; I forget the details. But I fixed it. I didn't ask anyone's permission first; I just did it. What's more, my fix wouldn't have worked for someone using the switchboard differently from how we used it; it was a kludge, working around the broken part instead of replacing it, because I didn't have the parts to replace it with. What's more, I knew what the right way to fix it was, but I also knew that my way would get the board running again quickly. Then I called the phone company Repair Service, to get them to send someone out to fix it right. (As it turned out, the repair person they sent didn't bring a wire wrap gun, even though I told the Repair Service operator to make a note that he'd need one, so he ended up not fixing it right either.) That's how to be a hacker.
Hacking is about wanting to know how things work. And you find out how things work by taking them apart. Allison Parrish is unfair, in that talk @kinestheticlearning posted, in equating that with believing that the whole is the sum of the parts. To say that the whole is the sum of the parts is to make a mistake about levels of abstraction. I mean, of course the whole is the sum of the parts; what else could it be? But that's a low level of abstraction. At a higher level of abstraction there can be emergent phenomena that arise from the system. When you're thinking about how the system interacts with the society of which it is a part, you want to think at the system level of abstraction. But when it breaks down and you want to fix it, then it's the sum of its parts, because you have to think at the implementation level of abstraction.
About misogyny and Margaret Hamilton: Yes, the hacker community was overwhelmingly male (although there were a few exceptions, such as Radia Perlman and Margaret Minsky). But we're talking about the late '60s and the '70s; the non-hacker technical world was also largely male and sexist. (Anecdote: while I was an undergraduate -- class of '69 -- we had a tour of DEC corporate HQ at the mill in Maynard, organized by some student group. The official DEC tour person brought us to the room with the semiautomatic wire wrap machines. You wanted a wire from this terminal to that one on the circuit board backplane. So the machine told the operator what color wire to select, because wires were color coded by length, and the machine knew the path length from here to there. Then the machine positioned the board so that the first terminal was in front of the operator, who would wire wrap one end of the colored wire onto that terminal, then the machine would move the board so that the other terminal was in front of the operator, who would wire wrap the other end of the wire onto it. (There were fully automatic wire wrap machines, and DEC had one of them, but they were super expensive, and the bean counters decided it was a better use of money to get semiautomatic machines and pay semi-skilled workers to run them.) The tour guide proudly told us that they preferred to hire women for these jobs, because women had the patience to do this boring work, more so than men. This was DEC's way to bring women into the technical workforce. And it was bean counters, not hackers, who made that decision.) The misogyny of engineers in general was terrible, but you can't hang it on hackers specifically.
Okay, time to go down the controversial bullet points of the Hacker Ethic. First point: "Access to computers should be unlimited and total." Remember that we're talking about a time when computers were expensive, and individual people could afford either nothing at all, or, much later, only little eight-bit toy machines on the order of the Apple II, which couldn't really do much. A minority of engineers had access to the big machines, which belonged to big institutions. So the point about access to computers doesn't mean that I should have access to the machine on which your bank records your account information, but rather that I should have access to a machine on the level of the machine your bank uses, a serious computer on which I can learn serious computer programming. So, at MIT-AI there were no passwords; anyone could use the machine, and in the early days anyone could create an account and store files there. (Eventually the system became too popular to keep providing disk space to anyone, and also, embarrassingly, there was a hard limit in the software to the number of disk accounts.) At SAIL (the Stanford AI Lab) there were accounts with passwords, but anyone could create an account, and you could configure your account so it didn't require a password if you log in from a terminal physically at the lab.
And yes, if people wanted to learn about some other system to which access wasn't free (in the sense of open to anyone), sometimes they'd break in. But the point wasn't to do damage, it was to learn. This was before the invention of malware! And before life-critical computers were on the net. The Internet didn't exist; there was just the Arpanet, open to computers belonging to the military and to military contractors (which included most CS research labs, at the time, before NSF took over major funding of CS research). And the military knew better than to put the computers that operated the weapons on the Arpanet.
But the slogan also means that if you do have access to some system, it should be total access. And I still think that! It burns me up that "my" cell phone obeys Verizon, Samsung, and Google more than it obeys me. I want root on my phone! I don't want it badly enough to break its security, because these days we are in an environment full of enemies, which wasn't true back then; the worst we faced were teenagers showing off. But the world full of enemies is at least in part the result of bad engineering decisions, made at the highest levels at Google and Facebook.
And it doesn't surprise or annoy me that among Snap! users there are some who want to know everything about how it works, down to the metal. That's how it should be! Of course people want to understand it. What's annoying, sometimes, is when kids blindly copy other kids' Javascript code without understanding either the code or the constraints of the system in which it runs, and expect us to debug their resulting problems. They want the status of a hacker without putting in the work to learn enough to deserve to be called a hacker. But even that annoyance isn't a big deal; it's a stage some larval hackers go through before they get serious.
On to "all information should be free." This slogan, too, needs some qualification in an age in which personal information about individuals is a prized commodity on which companies such as Google and Facebook make their entire income. Back then it meant information about systems and their innards, although such personal information as people willingly stored on MIT-AI and SAIL was generally world-readable. As one notable example, Andy Moorer kept his phone list (what would now be the contact list on his phone) at SAIL, and it included the phone numbers of the members of the Grateful Dead, along with a paragraph addressed to any third parties reading it saying "Please don't bother the Dead. If you need to get in touch with them for some reason, ask me about it first."
Fairly late in my time at SAIL, in the '80s I think, we had our first crisis about personal information. The system kept track of when you last logged out, and that information was made public by the FINGER command. You could say FINGER BH and it'd tell you either "bh is logged in from room xxx" or "bh last logged out at time yyy." This was useful information, because it'd tell you what phase I'm in, and when I'm likely to be back online. But a user pointed out that the lab administrators could also use it to keep track of how many hours employees were online, and this was a violation of their privacy. This was an "oh yeah huh" moment for me. We removed that feature from FINGER.
But here's a story about system information, the kind of information that slogan is really about. Back in the days before everyone had a cell phone (before anyone had them, I guess) there were coin telephones in public places. You could put in ten cents for a local call, or more for long distance. In the early days they were three-slot phones (separate slots for nickels, dimes, and quarters), and then the Bell Labs engineers produced a single-slot machine that figured out by itself what coin you gave it. They published an article in the Bell System Technical Journal, which was mainly intended for other Bell System employees but was also a bible for phone hackers, explaining the benefits of the new phone over the old one, including a table listing all the practically valueless foreign coins that the old coin phones thought were nickels, dimes, or quarters. Well, for a long time most of the coin phones in the field were the old kind, and hackers could make free calls on them using the coins in that table. Why did the (grownup, non-hacker) engineers put that information in the article, and why did the (grownup, really non-hacker) BSTJ editors print it? Because information should be free, that's why. Because security shouldn't work by keeping secrets about how a technology works. "Security through obscurity" works for a while, but it's not a good security policy. Good security works by telling the bad guys everything there is to know about the system, and making it so that information doesn't let them break in.
Knowing how a system works isn't about trying to break the system; it's about understanding the system. One time I was traveling from Boston to New York by train with Peter Samson. A minute or so after we pulled out of an intermediate stop, Peter said "We're going to arrive two hours late." How did he know? Because right after leaving the station, the train switched onto another track from the one it usually took, a track that went by a longer route. (Presumably there was something blocking the regular track further along.) And he was right! I was super impressed. That happened because Peter was a train hacker.
And this is why we publish the Snap! source code in a Github repo for all the world to read. Information should be free.
More to say, but I'm going to post this so it doesn't disappear and then reply to myself.