peter-fogg

OK, let's talk about parsing.

The article claims that parsing isn't necessary with structured editing. We're working on some abstract data structure representing our language's syntax. This might be an AST, like any programming language in common use today, or maybe in the future we've thought up some better way to represent programming languages within the compiler/interpreter. Since we're working directly with the AST or whatever, we don't need to parse! We just do whatever actions the programmer wants do over on our data structure.

Now, let's talk about how parsing works in your language of choice in 2015. We're going to take a string, and we'll turn it into a representation of our program. If we're lucky, our language implementation isn't awful, and our parser will be a function from some sort of Unicode-encoded text into an AST. OK, maybe our input is ASCII or some other text encoding, but the point is the same. Either way, we're taking some keypresses from the programmer, and turning them into a data structure representing the program.

Let's abstract a bit. Maybe in the future we don't use keyboards. Instead, we have whatever peripheral you like. This peripheral is capable of sensing some sort of action from the user, and turning it into actions within the computer. So now, our parser is a function from some user action to a data structure representing the program.

This sounds an awful lot like "we just do whatever actions the programmer wants do over on our data structure". The question is, how do we figure out what the user wants? The answer is, we parse it! It doesn't matter if we're parsing text or not. We will always need some way of determining the programmer's intention from the signals we get through their peripheral device. Viewed through this lens, the camera requires a parser just as much as the keyboard does, just as much as the mousepad does, just as much as the microphone does. We will always need a way to convert the unstructured thoughts of a human programmer into the formal language of a compiler's internals. Regardless of what representation we choose for any part of this process, it's going to be subject to the article's quote:

> This situation is a recipe for disaster. The parser often has bugs: it fails to handle some inputs according to the documented interface. The quoter often has bugs: it produces outputs that do not have the right meaning. Only on rare joyous occasions does it happen that the parser and the quoter both misinterpret the interface in the same way.

Ruby and JS are both Turing-complete languages (as with just about any other programming language you'll ever use), which means that one can simulate the other. The simulation might be messy, complicated, or slow, but it will still work. In this case, Ruby and JS are close enough that it can be done without too much trouble (see the compiled JS).

It's worth remembering that a large portion of blue-collar criminals are arrested for possession of, say, a small amount of marijuana. There's a big difference between mugging someone and lighting a joint.

I believe only one of the listed people are the creators of languages (Rails is a framework, jQuery is a library).

Not to be contrarian or anything, but why isn't Pamela Fox mentioned in the title? Seems odd that she's the only omission from the photos on the front page.

Doesn't seem to be working in Firefox 25 on OS X.

    [00:06:34.535] SyntaxError: Using //@ to indicate source map URL pragmas is deprecated. Use //# instead @ http://ajax.googleapis.com/ajax/libs/jquery/1.10.2/jquery.min.js:1

    [00:06:35.468] Use of Mutation Events is deprecated. Use MutationObserver instead. @ chrome://divxhtml5/content/script.js:109

Chrome is good, though.

But in a situation like that, you could just annotate the type. In Haskell:

    add :: Int -> Int -> Int
    add a b = a + b

That 90% can have boyfriends, too, you know.

It's underspecified anyway -- we need to know about the motion of rabbits, the troll, the density of black holes, etc.

Thank you. If we accept discrimination of minorities as inevitable, then it will be.

Yes, none of the teams you've worked on have needed any explicit bans on behavior that's considered unacceptable in society. That's because you've worked on teams with adult humans (maybe assuming here), who don't need to be told the rules. High school kids still need some reminders that there is a normal way of interacting with others, like not suggesting that the only girl in the class be relegated to the kitchen. A bit of extra regulation is absolutely called for among teenagers.

That being said, your general point is good -- absolutist policies like zero-tolerance rarely work well, simply because human behavior is complicated and difficult for the policy maker to predict in advance.