Archive | May, 2008

Teach the (other) controversy

31 May

My programming education began when I took a C language course at the local community college. I can still recall how strange I found the language’s rules about when I could and couldn’t use a variable (e.g. variables declared in one function can’t be read or modified in others), for it seemed to me this made writing programs far harder than they would be otherwise. Combine this confusion with the syntactical kruft of C and the fact that I took my instructor’s prohibition against global variables to mean never use globals (something I later learned real world C programs of non-trivial size don’t actually do), and the result was that I ended up totally paralyzed, baffled as to how programmers ever got anything to work. For these and a few other reasons, I basically abandoned programming entirely before taking it up again two years later, this time studying independently from books.

Somehow, some very basic ideas in programming just didn’t click upon my first learning attempt even though I now find these ideas very simple and clear. While my C instructor was mostly competent, he failed to focus on the vital ‘why’. Why does the language make me do this? Why is the syntax like this? Etc. Unfortunately, it’s too easy for learners to give up on ‘why’ because so few sources out there—teachers, books, blog posts—provide clear, accurate, complete answers to the ‘why’ questions (and far too many sources aren’t too hot on the ‘what’s or ‘how’s, either). Why do modern computers use 8-bit bytes? Why do we need to allocate memory? Why are exceptions expensive performance-wise? Many decent, working programmers out there simply have no idea how to answer questions like these. The really bad ones wouldn’t understand the answers or care if you tried educating them.

Recently, I’ve realized that the biggest, most common failing of programming education is the tendency to teach a technical matter as a solution in search of a problem—as a mechanism without a ‘why’. A great example is generics in Java, which are so convoluted that their explanation takes up a good quarter of a full treatment of the Java language. Absorbing all the subtle rules and asymmetries of Java generics typically distracts students from a critical understanding of why generics exist in the language in the first place. I would go so far to say that the fact that Java got on fine for many years without generics is the first and most important thing a student should know about generics. Only after well establishing what perceived problems generics were meant to address should students learn what generics are and how they work, and then it’s critical that this be followed up by exposure to dissenting arguments against generics.

You might assume confronting learners with controversy up front will lead to confusion, but on the contrary it gives a clearer presentation because it is more honest. Lies, hype, and wishful thinking tend to be incoherent and therefore perhaps impossible to be understood by anyone not already versed in the truth. Furthermore, teaching controversy has the benefit of putting students in a critical mindset, e.g. if the dominant languages of the day may harbor serious mistakes about which it’s OK to have your own opinion, maybe the whole basis of programming is neither set in stone nor out of reach for you to one day fully understand computing and to one day have a hand in directing the course of computing’s future development.

Wiki-whaaaauh?

25 May

Charles Simonyi—the Hungarian notation guy—has been dating Martha Stewart for the past 15 years.

Piled Heap of Poo

24 May

Anti-PHP screed #34019. For those of us who’ve only glanced at PHP, both interesting and distrubing.

My favorite bit, though, is an in passing quote from a C course the author took: “German Umlaute don’t work in C, so don’t use them”.

Look, ma, no lesson plan

21 May

Just about everything I described in my talk about what goes wrong in education goes wrong at nearly every step in this 10-minute video. I don’t mean to pick on this guy, but he’s the top Google video result for “python tutorial”, and that makes me sad. Sure, sure, I should forgive a high school student who is very likely just passing on his own miseducation, but his video makes a useful example of how tutorial-based programming education so commonly goes so very wrong.

Video of talk on Pigeon

18 May

Last month at LugRadio Live USA 2008 in San Francisco, I gave a talk discussing programming education and Pigeon, my learner’s programming language. Videos of all the talks at LugRadio Live are going up. Below is my talk, which you can also download. (I occasionally mumble a few key words. Sorry.)

The current status of Pigeon is that I still haven’t bothered to put the finishing touches on it for it to be actually usable, as I’m currently working on the material for students to learn Python after learning Pigeon. Until I give learners some plausible place to go after Pigeon, I figure I can put off finishing up Pigeon itself.

Personal Rapid Transit (yeah, the People Mover thing at Disneyland)

17 May

How’s this for blogging on the cheap? Below is a paper I wrote for English 101 a while back. I’ve reworked it slightly (removed the silly Chicago citations), but it retains the stilted prose and mechanical structure of any good My First Research Paper. In any case, I’m fond of its clarity. Perhaps in some future post, I’ll follow up with a lengthy discussion of the political and aesthetic obstacles keeping PRT’s from being taken seriously.

In 2002 in the United States, approximately forty-three percent of the oil we consume—making sixteen percent of the total energy we consume—is consumed by personal cars and light trucks. In the same year, cars and light trucks accounted for thirty-three percent of the carbon dioxide, fifty-one percent of the carbon monoxide, and thirty-four percent of the nitric oxides emitted in the United States. Were Personal Rapid Transit (PRT) systems built in America’s large- to medium-sized cities, America could greatly reduce its use of energy for personal transport and reduce its air pollution.

In a Personal Rapid Transit system, vehicles for two-to-four persons travel on a fixed track. The vehicles always travel one way down a particular length of track, only changing course at bifurcations in the track which resemble freeway off-ramps; two pieces of track might merge into one, like a freeway on-ramp. In most PRT designs, the track is elevated off the ground to make traffic interference a non-issue.

At many small stations along the track, passengers pay their fare and enter the first empty vehicle waiting in line; the station track is a detour off the main track to allow traffic to by-pass the station without stopping, just like freeway on-ramps and off-ramps allow traffic to flow uninterrupted. The vehicles are controlled by their own individual computers, using a small command vocabulary: ‘go’, ‘stop’, ‘take the left/right track’; each vehicle receives its macro-level directions from a central network, e.g. ‘go to this station’, but the set of micro-level actions necessary to carry out that directive are left to the individual vehicle. The central system is responsible for distributing unused vehicles to stations where they will most likely be needed based upon projected traffic patterns. PRT designers consider any kind of stoppage or slow-down in the system as a failure and not to be tolerated as part of normal operation; a properly implemented PRT system would never have traffic jams except in isolated cases. At worse, an influx of demand should only result in waits to board vehicles. (Here’s a nice graphic of the whole thing.)

How the vehicles are propelled varies greatly among different PRT designs. In the PRT design of prominent PRT proponent and designer, J. Edward Anderson, an engineer and former professor at the University of Minnesota, a linear induction motor in the vehicle is powered from the track. Some propose supplementing the track’s power supply by having the track double as a place to put solar panels.

The first reason a PRT system would save significant amounts of energy compared to cars is that the vehicles are significantly lighter. Small vehicles don’t need the acceleration of larger ones, and when powered from the track, they aren’t further weighed down by fuel. Similarly, the smaller volume and lower traveling speed of the vehicle reduces the comparative amount of drag.

Another reason a PRT trip consumes less energy than the same trip in an automobile is that PRT’s typically travel at lower cruising speeds, thus requiring less energy to maintain speed. For safety reasons, most PRT designs propose a speed between twenty-five and forty miles-per-hour; while safety at greater speeds is most certainly possible, greater speed is not as desirable as you might think because the lower travel speeds are made up by the vehicles never stopping on route between origin and destination.

That PRT vehicles only accelerate up to speed once per trip is the most important factor in why PRT’s consume less energy. In a typical car trip, the many accelerations from a dead stop account for a disproportionate amount of the energy consumed even though they only account for a small fraction of the time and distance traveled.

Because the vehicles are powered from the electrical grid rather than gasoline or diesel, there is zero local pollution. This does not solve the problems of air pollution—energy is only as clean as its total amount of emissions at the point where it is both generated and emitted, not just where it is emitted—but prospects for producing clean energy at electrical plants are much more promising than the prospects for our automobiles.

Unlike other solutions for reducing the pollution and energy consumption of personal transport, PRT systems don’t gamble upon uncertain future advances in technology. Electric-powered, hydrogen-fueled, and bio-fueled cars—the prospects for making these technologies economical (or, in some cases, work at all) are unknown. The problem is that science is not magic: some of these technologies may simply turn out to be dead-ends. Of course, the PRT idea hasn’t yet proven itself either, but the engineering required to make the system work consists wholly of combining well-understood technologies. For instance, probably the greatest area of uncertainty surrounding PRT’s is how such systems will handle heavy traffic loads. Though Anderson and other researchers have performed statistical analysis, this is the sort of thing where the details can only be worked out given a real-world system.

The closest analog to this kind of work is the writing of a computer operating system: an important component of an operating system is its “scheduler”, the code which allots processing time to the many programs running at one time on your computer; if the scheduling algorithm is not well-designed, human users will feel their system is unresponsive, and time-sensitive tasks (interactive games, audio, video, and so forth) will lag and stutter because their programs aren’t getting processor time often and long enough to do their jobs on time. The academic literature produced in the 1970’s and 1980’s on scheduling algorithms, while hardly worthless, turned out largely to be wrong (or at least inadequate) when multi-processing operating systems finally arrived to the masses in the 1990’s. So too will research on PRT traffic patterns be flawed until we have real-world systems to observe and tinker with. Still, that such kinks in the system can be worked out is a better bet than a “Manhattan Project” for energy, where engineers would be working on the edge of our understanding of how the universe works. Just as faster-than-light travel may simply not be possible, sufficiently efficient and green car motors may not be possible, so it would be foolish to stake our future entirely on the prospect of sufficient advances in automobile tech.

The failure of the United States to successfully adopt mass-transit in most of its cities is widely attributed to Americans’ dislike for riding mass transit. The usual objections to mass transit largely don’t apply to a PRT system, as it offers these advantages over other transit systems like buses and light-rail:

  1. Because PRT track is much smaller than light-rail track and PRT stations are much smaller than light-rail stations, the construction of PRT track and stations is much faster and less obtrusive and requires less man-power.
  2. PRT stations can economically be placed at short intervals along the track (one at every half-mile in Anderson’s design), meaning a station is much more likely to be within easy walking distance of passengers’ departure points and destinations.
  3. The system can operate around the clock, and passengers never need worry about train or bus schedules.
  4. More often than not, an empty vehicle will await passengers when they arrive at their departure station; even in peak hours, waits for vehicles should rarely be longer than a few minutes.
  5. No driver or other staff need be employed per vehicle, as with buses and trains.
  6. PRT’s occupy less land than light-rail systems, and consequently, they are less visually intrusive and free up space for other purposes.
  7. The vehicles travel non-stop between origin and destination, never picking up other passengers or requiring passengers to make a transfer.
  8. PRT vehicles produce far less noise than cars, let alone buses or trains.
  9. Passengers in a PRT have a private car to themselves, so they can relax, read, talk on their phones, use their laptops, or do their makeup while in transit without consideration of other passengers.
  10. Despite the lower cruising speed, transit by PRT would be significantly faster than by other mass transit systems because of its (usually) low waiting times, the non-stop travel, and the fact that origin and destination stations are likely closer to passengers’ points of travel.

Even with all these comparative advantages to current mass transit, PRT’s still must compete with Americans’ fondness for cars. Fortunately, transit by PRT is in many ways even more appealing than travel by personal car.

  1. Passengers in a PRT don’t have to drive, allowing transit time to be used for entertainment, chatting, or work.
  2. Passengers don’t have to find parking or pay for parking at their destinations.
  3. In a city with a PRT system that covers a wide enough area, more people can live without the cost and hassle of owning, licensing, insuring, and maintaining a car; at the very least, families could get by with fewer cars.
  4. On the whole, PRT’s would be much safer than other forms of transportation, as there are only three plausible safety concerns: malfunctioned vehicles breaking or stopping unexpectedly, vehicles not breaking when entering a station, and collisions at merge points. To mitigate these possibilities, the proposed cruising speed for most PRT’s is below forty miles-per-hour; also, sensors on each car engage the breaks when the car ahead is detected doing something abnormal, removing human delay and error. These factors greatly reduce the frequency and severity of accidents, especially compared to what we tolerate today on our roads.
  5. A PRT would increase the mobility of those unable to drive: the young, the elderly, and the handicapped (in Anderson’s design, the vehicles provide easy embarking and disembarking of wheelchairs).
  6. PRT’s offer quieter rides for their passengers and create significantly less street noise.
  7. Transit by PRT would be faster than car trips for routes with many traffic lights and stop signs along the way.

Aside from direct benefits for passengers, a successful PRT that reduces car traffic would thereby increase quality of life by reducing the amount of noise and air pollution and allow the diversion of resources from road maintenance. After a number of years, cities may even begin reducing the width of existing roads and the size of parking lots, reclaiming space for sidewalks and other purposes. Asphalt surfaces capture heat in hot weather, leading to heavier use of air conditioning; reducing the amount of paved surface in our cities would lead to a surprisingly significant reduction in energy consumption.

Other hidden costs of our roads include traffic cops, traffic courts, traffic accidents, traffic reports, traffic schools, traffic lights, traffic engineers, traffic signage. In particular, there are often over-looked societal and economic costs just associated with parking: parking structures and the extra parking lanes on the sides of streets not only must be built and maintained, they take up prime real-estate. Perhaps least obvious are the psychological tolls, such as the aggravation of finding parking or the danger of cars (even when we’re not in a car ourselves, most of us must be wary of being hit by a car just twenty steps from our doorstep).

Of course, operation of a PRT will introduce many such hidden costs of its own, not all now foreseen, but on the whole, they seem relatively modest. For instance, emergency crews and equipment will be needed to occasionally clear malfunctioned cars and rescue stranded passengers. The track and vehicles themselves, of course, will need upkeep. And so forth.

In the last thirty years, several attempts at constructing PRT systems failed, mostly due to lack of funding and political support and inadequacies of the day’s computer and electric-engine technology. As of yet, there is no PRT success story, and until there is, municipalities and governments won’t take the idea seriously. At the moment, two PRT’s are scheduled to start operation in 2008: the “ULTRa” system at Heathrow Airport in London and another system at the International Finance Center in Dubai. By proving itself in a localized capacity, hopefully the PRT idea will begin to see adoption as a city-wide transit system.

UML sucks

16 May

Everything said here.

I’ll just add that pictorial representation of code is fundamentally flawed because it inevitably means drawing a bunch of boxes and connective lines all over the place. Just as there’s no one true way to distribute your functions and classes in text, there is no true optimum 2D layout for boxes representing functions and classes. No algorithm does this layout well enough to not need human reworking. Every good diagram of any complexity you’ve ever seen, whether of code or of a subway system, has been heavily hand-massaged if not entirely hand-generated. Even if you had a decent algorithm for layout, the layout it computes might change radically each time you add a box or connection, which would be disorienting in the same way as if someone were to rearrange your workspace behind your back. A big part of what it means to be comfortable with a codebase is knowing where most things are. How familiar can you ever be if the codebase gets constantly scrambled? The only solution is to have the coder position all the boxes and draw the connections manually, but this will just mean that systems will get uglier and uglier as they grow and that refactoring the layout will grow more and more painful.

Text to some degree has these problems too, for you have to decide which file to put a function or class in, and you must then decide how to order the functions and classes of each file. But in text, you aren’t burdened with the stylistic choice of how to draw connections: everything has a proper name, and you make connections by using the proper name, end of story. Making connections pictorially is only simple if you stick to straight lines, which typically makes the diagram much harder to read than were the connections cleverly grouped and routed along the cardinal directions. Text code with many connections is complicated but readable; diagrammed code with many connections is complicated but totally unreadable. The whole point of diagramming code is to visualize connections, to see the shape of a design, but past a rather low level of complexity, the visualization is too much to mentally process.

In sum, stick to code for code. Use diagrams only for broad communication, and use them only when they are understood to be lies.