- I can see why this had taken you three hours to make.
I agree.
Okay, "mistrust authority." This isn't something only hackers believe; it's a central principle for anarchists. (I'm an anarchist on odd-numbered days; on even-numbered days I'm a Marxist.)
If someone tells you to do something, or not to do something, there should be a reason. I run into this all the time in the web-design world. "They" say I'm supposed to say <strong>foo</strong> rather than <b>foo</b>. Why? It's hard to touch-type "strong" and spell it correctly, whereas it's easy to type "b", and they mean the same thing. Maybe there's a reason, but nobody's told me about it; they just yell at me. Conversely, there is a reason you shouldn't set a text's foreground (font) color without also setting its background color, but nobody does that right.
At Lincoln-Sudbury there were plenty of kids who had homemade master keys to the school, and I made one too, because it was pretty common for me to come to work on a Sunday and want to use the copier in the locked office. Eventually I got yelled at for this, to which I replied "you're welcome; I'm happy to put in unpaid hours on the weekend preparing for my classes." But nobody stole anything.
In fact, we gave kids keys to the computer center. This was part of a solution one of my colleagues proposed to two problems we had. One is that the floor would fill up with paper. (We always laughed about the idea that computers were going to eliminate paper, remember?) It got to the point that the janitors refused to clean the room. The other problem was that no matter how early I got to work, there was always a line of kids waiting for me to let them in, and they'd never let me go home at night. Larry's brilliant idea was to use these problems to solve each other. We invented the Computer Center Users Society. The Society held weekly meetings and was responsible for making the room work, setting policies about what to do when one kid had a terminal reservation but was playing games, while another kid had an English paper due tomorrow and needed to edit it. And specifically, the Society was collectively reponsible for keeping the room neat. (I always hoped kids would just learn to clean up after themselves, but no, what they did was write a program to go through the membership list, announcing each day whose turn it was to clean the room that afternoon.) In return, the kids got keys to the room. This let me come to work (relatively) late. Supposedly the night watchman kicked everyone out at 11pm, but once in a while I'd arrive in the morning and find a kid asleep on the couch. I confess it took me a long time to learn that that meant something terrible was happening in the kid's family.
Edit: Okay, yes, LS was a school in a rich Boston suburb, 20 miles out, and maybe it wouldn't have worked in a poor school. But maybe it would have!
Every parent knows that "because I said so" is bad parenting, even though we all resort to it when pushed to the limit. This is the sense in which authority should be mistrusted: the invocation of authority instead of having reasons for rules.
One time the open public space next to the elevators on the floor of Soda Hall sprouted a sign saying "This space is reserved for faculty, staff, and graduate students only." The sign was a response to a hackathon that happened one weekend, during which people left a mess in the space. So I tracked down the sign to the professor who ordered that it be posted and complained. And my complaint was successful; the sign's arbitrary restriction was replaced by two rules: "faculty, staff, and graduate students have priority in the use of this space" and "Please clean up after yourself when you use this space." Those were reasonable; the original wasn't. (A self-assigned part of my job at Berkeley was to safeguard the interests of undergraduates, who really were treated as second-class citizens much of the time.)
The idea of authority is complicated. There are at least two kinds of authority. One is the authority of position: I'm in charge here, because I own the space or because I'm employed by the owner to run it. Or, sometimes, just because I'm an adult and you're a kid. This is the kind of authority that should mostly be questioned. ("Sorry we hurt your field, mister.") Another kind is the authority of expertise. You want to learn about computer programming; I know a lot more than you do about it. So when I tell you something about programming, you should pay attention. (That doesn't mean I'm always right; despite being an expert, I'm only human and can make mistakes. And I can confuse my personal preferences with objective truth, so maybe you should pay a little less attention to what I say about Flat Design than you should about most other things.) The authority of expertise is legitimate.
And there are times when even the authority of position is legitimate. If I'm teaching at LS and the fire alarm goes off, I'm going to start giving orders and expecting to be obeyed, not because I'm an expert at emergency evacuation but because in that situation someone has to be in charge and the buck stops here. In an emergency there's no time for a democratic discussion from which a collective policy emerges; we have to react right now and so I'm going to tell you what to do and you're going to do it.
Ursula LeGuin's critique of the military, in The Dispossessed, is that they operate in emergency mode all the time. And the reason is that if the military allowed democratic decision-making, nobody would go out to kill or be killed. They have to use the authority of position.
It's really very ironic that I find myself being the moderator of this forum, because all my instincts are to let people do what they want. And I would, too, letting the forum software bubble people up to moderator status, if (as for the other issues raised earlier) we didn't live in a hostile world, in this case, a world in which we have to worry about child molesters. (As an aside, although far too many kids are molested, the molesters are almost always people they know, with parents in first place. The odds of being molested by a stranger, which is the case everyone worries about, are vanishingly small, although nonzero. And our users are old enough, I hope, not to make arrangements to meet a stranger over the net without their parents around. Back in the day, I got to meet a bunch of Scratchers f2f, which was great, but it was on neutral territory with their parents present.)
So, when Jens says you shouldn't program in a particular way? You should pay attention, because it's Jens, and he's the world's most qualified Snap! expert. But you should always question authority; you should want to know why he says what he says. Maybe he's confusing his personal preferences with objective truth, or maybe he has reasons you can understand. But you should insist on the reasons.
Okay, so much for the Hacker Ethic. Now on to the core point of this discussion: Is hacker culture elitist? Do hackers make things hard to understand on purpose? I think the answer to the latter question is clearly "no"; the ideal is that anyone should be able to get things done the first time they get in front of a computer, and should be able to learn gradually how to get more done. After showing my 61A students the Alan Kay video about user interfaces, I would show them these graphs:
The horizontal axis is the complexity of the task you're trying to do, and the vertical axis is the degree of wizardry required. For traditional operating systems, you had to be pretty wizardly to do anything, but then you could gradually learn to do more and more until you were a full wizard. In the original MacOS, the great innovation was that anyone, knowing nothing except how to move a mouse, could do quite a lot without needing to become a wizard -- but then you'd hit the wall, and suddenly you had to be a full wizard, reading all 20 volumes of the MacOS documentation at once.
What's desired, but didn't exist when Alan gave that talk, is a system on which you can get a lot done right away, as in MacOS Classic, but when you get beyond that level of complexity, you can grow into it slowly, as in DOS or Unix. And now we have that, in systems such as MacOS X, which achieves the merged behavior by a literal merging of systems, with the Mac user interface built on top of a Unix system (netBSD) that's accessible to the user -- who, by the way, also has root access, unlike the case on Apple's phones and tablets. And in the free software world we have user interface layers such as Gnome built on top of Linux.
And that's how I feel about Snap!. Yes, we should do our best to make it possible for everyone to do what they want without knowing anything about Snap! innards, but we should also have the humility to know that we're not going to succeed, and we should make it possible for people to program solutions to their problems, preferably without having to resort to JavaScript. And one way to do that is to make sure that anything you can do in the UI you can also do in your program. Or at least that should be the default assumption, and if some UI thing is really dangerous to put in a program (not just contrary to some authority's ideas about programming style), then you can make an exception.
I should acknowledge that I am not a Snap! hacker. I have hardly any idea of how it works inside. I'm enough of a hacker in general that I can read the JS code, although I don't really speak JS, and figure out how things work as I need them. But I'd much rather not have to do all that just to get into or out of presentation mode. I guess this is because I'm old; I figure I've paid my dues in dealing with incomprehensible system code.
Whoa! You wrote a veritable essay in response, and a fascinatingly gripping one! Thank you, Brian.
Back when I was a LaTeX user (I stopped in 1992) I remember being told to use \emphasize instead of \italic and I was told the reason "they" say it and it stuck with me ever since. \emphasize (and presumably <strong>) is used to convey intentions rather than a particular way of satisfying an intention. In some contexts perhaps one wants to use color or a different font to emphasize something. While \emphasize behaved the same as \italic - it left open the option of customising it differently in the future.
I sometimes define procedures that just directly call another procedure only to provide a more abstract name for the operation so I can have the option to provide a different implementation later.
My memory of the 9th floor of the MIT-AI lab (1973-1980) was that, yes, people were categorized as "lusers" (that was the preferred spelling since the assumption was that most users were losers). Even graduate students were often considered lusers - mostly because we too often reported system bugs that were bugs in our code instead.
But I also remember the lab as being a meritocracy - degrees, background, gender?, etc didn't matter - only one's technical knowledge and skills mattered in categorizing us.
Maybe rename the topic to make it seem less alarming to people who are ignorant of the other meanings of the word hacker?
I think the view was everyone was equal in that they were able to prove themselves technically competent and be considered a "winner". But there was no sense in which everyone was considered equally competent.
P.S. Why does this forum discourage multiple replies? When I tried to post this it said to wait for others to post.
How about "Should Snap! support hackers (in the old sense of the word)?"?
To avoid spam against a targeted person I think.
The forum software thinks it's smarter than the users in all sorts of ways. It has built into it a particular model of what conversations should look like, and tries to do automated moderation based on that model.
Just hit the escape key when it nags you.
It's true that nobody cared what degrees you had. But I think if, say, you showed up in a jacket and tie you'd probably have to clear a higher bar to be declared a winner.
The big problem is that it was extra hard to break out of the loser category. (I remember "luser" as being applied more as a generic term than when discussing a specific person, but I'm getting old, so who knows.)
Couldn't resist ... 
It seems to be a quite common way of thinking, right now.
I guess. But, there are two cases. (1) The user has a disability that makes boldface not work for strongness. In that case, you can just change the definition of <b> to do something else. (2) Boldface does work, but you want to use blinking for strongness and use boldface for some other purpose. In that case, you shouldn't; people approach your document with a shared understanding of what boldface means and what italics means, and if you adopt some screwy other convention, people will have a hard time reading your paper.
(By the way, in the case of italics I have to learn at least three different tags to get italics the way they want me to: <em> for emphasis, <cite> for book titles, and I don't know what I'm supposed to say for foreign phrases such as ipso facto.)
PS Four cases; sometimes you want to start the chapter with a whole paragraph in italics, or have a paragraph or several in italics because someone other than the main narrator is telling a story.
Thank you bh for this book, very interesting
I did say it's ironic that I find myself moderating the forum...
By the way: It would be wonderful if they lived by that principle.
The original theory of the web was that servers provide content and clients provide formatting. The server sends data, with a minimum of formatting, and it's the user agent that formats, knowing the user's preferences about everything.
But then the big rich corporations came along, and they wanted to control what their pages look like (not least so they can include advertising), and people invented CSS, and servers send out pages full of formatting (half of which I can't read because they change the font color without also changing the background color), and all that's left of the original division of work in which the server sends data and the client formats it is this one relic and fetish about <i> and <b>.
A third case: (3) a font color change is preferred for emphasis at a website but for color blind readers they still want to fall back on italics or bold. The emphasize command can be customised appropriately but it would be wrong to change italics to blue for non-color-blink readers.
I found it particularly bizarre that it suggests that instead of several replies you should combine them all into a single reply using multiple quotes and @ mentions.