peter-fogg

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.

So, to be all pedantic and stuff... You've always got unsafePerformIO, first off. This is used in Debug.Trace (https://hackage.haskell.org/package/base-4.7.0.2/docs/src/De...) to allow printf debugging in pure code. This is also used in some Haskell libraries to provide restricted effects in monads other than IO. But if you don't want to use unsafe* functions, you can always use ST to get direct access to mutable memory in a safe way. If you can runST within that interface, then you can present a pure interface to users.

    [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

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

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.

I say this as an Eagle Scout, and someone who had a great time as a Boy Scout from around age ten to eighteen. The Scouts are a great organization on a local level, where there's little bureaucracy, and most decisions are made by or with the boys. You gain a good sense of responsibility when you're the one in charge of overseeing all the camping gear for your trip, or planning an outing over a weekend. There's also a lot to be said for the personal growth that comes from starting as a ten-year-old, learning from the older boys, and then realizing at age eighteen that you're one of those older boys who is looked up to by the young ones.

However, the BSA at a national level is a pretty awful organization. They routinely discriminate against atheists and homosexuals. I'm an atheist myself, as were many in my troop. Again, at the local level this was fine -- nobody cares, provided the other members of the troop are sensible people (which, in my case, they were). But at the national level, any atheist is treated as a Godless Communist.

The same goes for gay boys and leaders. The BSA takes the delightfully antiquated stance of equating homosexuality with pedophilia, with no shortage of moral indignation at the idea that people could feel affection for those of the same gender. Until they do a bit of soul-searching and come into the 21st century, I'll have nothing to do with the national level of the BSA.

There's a few problems here. One is that "organ printing" in its current state is not at all the same as printing a cell. What would printing a cell even mean? We know how do things like create a cell's membrane and inject DNA into it, but as far as I'm aware nobody can print a ribosome (one of the pieces that converts DNA's "code" into proteins).

Secondly, it's important to know that DNA isn't even the assembly language of the cell, it's the ones and zeros. The idea of hand-coding DNA is simply absurd -- not because we can't synthesize the molecule, but because chromosomes are huge and we don't even fully understand what everything does yet. Imagine trying to read a program's binary, except some sections of the code are repeated, some are complete garbage, and some look a lot like garbage but are actually totally necessary. Now imagine writing that.

There's been some work done on genetic computation, using the the expression of fluorescent proteins as "output", but it's a long way from general computation. The idea of a "DNA compiler" isn't even possible yet -- noone has figured out how to represent XOR, which makes performing arbitrary computations tricky at best. And, as you might imagine, using cells as computers is slooooooow.

Looks like the repo has moved to a new Github account.

The Little Schemer is (in my opinion) the single best book on programming out there. It won't directly improve your MVC webapps or teach you enough of Scheme to write real software; be warned. What it will do is give you a fantastic introduction to recursive computation and all the mind-expanding ideas that go along with it. It's also great fun to read -- how many books do you have with space reserved for jelly stains?

Also worth looking into is Learn You a Haskell, which is available for free online. Haskell teaches you to have some discipline in code organization, in a way enforced by the compiler, and will also help you to find more abstract patterns in your code.

Finally, Clojure is a functional language that has somewhat more of an emphasis on practical programming than the above books. There are some good libraries for web development such as Ring and Enlive; I'd recommend rewriting an app you've already completed in another language as a good way to learn. That way, you can concentrate on the language and the way you express concepts, rather than the particulars of the problem you're solving.

Unfortunate, but true. I prefer to batch up my online reading time so that I can get through the denser articles and still have time to read the five minute blog posts.