Building a Compiler, Briefly

During the last meeting of the Toronto Haskell group, we briefly discussed the question of how to build a compiler, and in particular the problem that building a real one is a daunting task.

I've done a bit of digging into various approaches and guides. There are a lot of them, because every respectable CS curriculum needs a compilers course.

The one I find most intriguing is by Niklaus Wirth, the guy behind Pascal and Modula-2. In his "Compiler Construction" PDF, he guides you through building a compiler as a series of exercises in a bit over a hundred pages. Given that other texts run well past 500 pages, a tractable treatment is quite a relief. I get the impression you could work through the guide in 2-3 of weeks full time or perhaps a quarter as a side project.

That said, Wirth does make some simplifications for pedagogical purposes. The source language is Oberon-0, which is a pared-down version of Oberon, so almost but not quite a real language. The target architecture is a simplified RISC instruction set, with an interpreter that fits in a page. You build the compiler from scratch, rather than using tooling like ANTRL, parsec, or LLVM, which you'd presumably leverage in an actual implementation. And the treatment of code optimization is brief. So, choices were definitely made.

But all in all it is possible to make building a simple compiler the work of a couple of weeks rather than a months-long slog.

Joel Spolsky on Language Wars

Joel Spolsky is the CEO of Fog Creek, a software company in New York. He also blogs about software development on his website, Joel on Software. In one of his older posts, he addresses the question of what language and framework is best for web development, and drops some giant blocks of stone-cold sense right in front of you. 

Some choice quotes, condensed from the article:

Which Web Server (Apache, IIS, or something else) should we use and why? 

People all over the world are constantly building web applications using .NET, using Java, and using PHP all the time. None of them are failing because of the choice of technology.   

All of these environments are large and complex and you really need at least one architect with serious experience developing for the one you choose, because otherwise you'll do things wrong and wind up with messy code that needs to be restructured.

How do you decide between C#, Java, PHP, and Python? The only real difference is which one you know better. If you have a serious Java guru on your team who has build several large systems successfully with Java, you're going to be a hell of a lot more successful with Java than with C#, not because Java is a better language (it's not, but the differences are too minor to matter) but because he knows it better. 

Yes. Absolutely yes. There are several different solutions out there, all of them work, and the best choice is likely to depend on something other than a theoretical determination of which one would be best in Plato's world of pure forms, for any number of reasons:

1. You probably aren't building the system from nothing. You are starting with an existing system, and adding on to it. Using whatever language or framework the system is already built from is a big advantage, because the new stuff needs to work with the old.
2. You know something but not everything. A Java-based solution would need something very special indeed to do better than a Python-based solution, if you already know Python backwards and forwards but you've never touched Java. 
3. There is already a standard solution. Someone has already designated a language or framework as standard in your organization, hopefully after carefully weighing costs and benefits, but maybe not. In any case, using anything else would require an arduous process of argument and justification, and every day you spend on the fight is a day you could have spent designing and building your system.

Go read the article. Really. Giant blocks of stone-cold sense. Here's that link again.

Veronica Mars is coming back

Damn. How did I miss this? A KickStarter project raised more than five million dollars to bring back Veronica Mars and all her friends in a feature film.

Can't wait.

Is it just me, or is KickStarter one of the biggest new things on the internet since eBay?

What was the best decade ever in computing?

If we define "decade" as ten contiguous calendar years, I think it would be hard to beat 1968-77, which brought us:

1968 structured programming ("Go To Statement Considered Harmful")
1969 UNIX
1970 PDP-11, relational algebra
1972 C
1973 Xerox Alto
1977 VAX-11/780, Apple II

A little later, we had Ethernet in 1980 and the IBM PC in 1981.

How to Defend Against Zombies

I've been thinking about how a small community, such as the one seen in season 3 of The Walking Dead, should defend itself against the zombie threat. It's not a simple problem; in the film 28 Weeks Later, we see a well-equipped defense plan fail catastrophically.

To begin with, I think it is foolish to rely on any one mechanism. Any system can fail; we aren't omniscient. It is therefore important to have defense in depth -- multiple levels of (quite different) protection, so no one system has to work perfectly.

What I have in mind are four increasingly fine-grained levels of defense.

At the top is a town guard, responsible for protecting the entire community. They are organized full-timers responsible for securing the perimeter. They set up barriers; they patrol the surrounding area; they stand guard. They also make sure that anyone entering isn't likely to be infected. And finally, they have a well-protected command center that can communicate with other defense elements and coordinate a response if things go badly wrong.

The next level down is something like a very hard-core neighborhood watch, responsible for protecting smaller areas. Their mission is containing the problem if it is already inside the town and mounting an organized response. They might have alarm systems, barriers that can be moved into place to seal off the neighborhood, and specific plans for an armed response if the infected are already inside. They also have a means of communicating with the command center mentioned above, probably using handheld radios.

The third level of defense is at the household level. The goal here is to ensure that for most people, getting indoors and securing the entrances is realistically effective. That way, non-combatants can get out of the way, to safety. Most people would be highly motivated to do this, but many would benefit from at least some advice and some might need actual assistance. (This would not be optional, since a poorly-protected household is a potential source of more walkers, and as such is a danger to others.)

Finally, at the most fine-grained level, would be individual defense. It would be enormously useful if most people were not simply easy meat for the walkers, but could offer credible resistance at least one-on-one. To that end, make sure that all able-bodied adults have basic training in how to fight a walker, and encourage them to keep a weapon (a club or hatchet, say) handy.

Together, these four telescoping levels of protection keep out the walkers if possible, and enable the community to resist tenaciously if they have already gotten in.

Inward-Looking for a Reason

Ahmet Alp Balkan has some interesting things to say about about the internal development culture at Microsoft. In particular, he criticizes the engineers there for living in their own world and not paying much attention to outside tools and systems. I think he has uncovered a real phenomenon, but hasn't dug deep enough to uncover why it happens.

It's true that engineers who work for large technical companies don't typically pay very much attention to external tools. And there's a good reason for that.

Companies like this already have extensive internal ecosystems of tools. These tools were built to work together with other company systems, they adhere to various internal development standards, have teams dedicated to supporting and enhancing them, and are already known and trusted by other engineers and management.

For any problem you are likely to encounter as an engineer, there is typically an existing system that already does what you need, or close. This tool can quite probably be improved or reconfigured to do what you need with less effort than it would take to bring in an outside tool and make it fit internal expectations.

Because of this, the smart bet is usually to use or extend existing solutions rather than exploring and importing new ones. And really, just learning all about the internal systems is a job in itself, quite enough to sate the curiosity of nearly anyone.

Stop Talking About Resources

Once of the nastier terms in current management jargon is the word resources. It means people, in the sense of workers, employees, or staff. If a manager is talking to his director about the project being late because he doesn't have enough workers to do everything that needs doing, he might complain about not having enough resources to do the job.

This usage has two problems. First, resources is a very broad word. It could refer to time, equipment, raw materials, expertise, or labour. The reader or listener has to infer which of these is the actual problem. Second, resources is often used in the sense of natural resources, such as forests, minerals, fresh water, and hydroelectric potential. All of these are inanimate -- they are things -- which means that talking about people as resources is talking about them as though they were just plain stuff, like dirt on the ground. This is the very essence of dehumanization, which is a very bad thing indeed.

So, what to do? Avoid the word resources when talking about people. Say what you really need. Do you need more engineers? Librarians? Bricklayers? Be as specific as possible. If you absolutely must be more general than that, say you need people. And if you are so high up that it all fades into a general get-things-done-ness, say you need money.