Lately I’ve been thinking about the adverse impact of cars on our landscape. Most familiar are of course oil use, pollution, noise and traffic. Less commonly discussed are things like:
- fatalities, injuries and accidents compared to other forms of transportation
- miles of pavement in the form of parking lots and roads which contribute to stormwater issues
- the sprawl of suburbia enabled by widespread car ownership.
But beyond even these things, I’ve started thinking about:
- the primacy of cars and trucks over pedestrian and bike traffic (is it a natural condition to fear for your life walking across a road?)
- the space taken up by the industries supporting or necessitated by a car-ful society (dealers with oceans of parking lots for their unsold vehicles, mechanics and gas stations)
- the wasted time of police monitoring vehicle traffic.
- how people can feel stranded and isolated if they do not have a car to travel the ever-increasing distances from where they live to where they need to be to work, socialize and shop.
There are surely more.
This line of thought started early this spring when I found Car Free Cities via a comment on Colin Beavan’s blog. It described a plan for urban life that eliminated the need for cars (and trucks and buses). The stated goals of the car-free plan reclaiming urban space for people rather than vehicles, restoring social fabric and quality of urban life, with an eye to environmental benefits and energy efficiency.
I should note right away that this is only a design for cities. As the author JH Crawford states, there is no clear, desirable solution for eliminating cars and trucks in rural areas.
Design Metrics
There is an extensive list of design metrics that Crawford lists in his book to inform his design. Some of the broader aspects of the results are:
- A reference design that comfortably supports 2 million people working and living.
- Walkable mixed-use districts connected by mass transit depots at the center of each. A topology of districts that maximizes public transportation efficiency.
- Streets limited to pedestrians, bikes, with permits for low-speed electric vehicles, and when necessary emergency and construction vehicles.
- Ample green space within a short walking distance from every front door.
- An average building height of 4 floors, of varying unique architectures.
- Freight and mass transit handled below-grade by separate subway lines
A Car Free Athens
The idea looks radical, but reasonable. It tries not to make too many decisions about how we lead our lives aside from three: transportation, density, and green-space. There are suggestions and implications within about energy generation, urban social life and more, but these are ideas rather than prescriptions.
Athens has no subway (it has a growing bus system), a vibrant downtown and a lot of suburbs. It’s major roads are actually already laid out radially which could be well suited to adapting it to the reference topology Crawford presents. So I started delving into what I could find online for maps and reference data. My goal was to hew closely to the plan advocated in the book, and so I wanted to understand what existing infrastructure and institutions could be accommodated, and which would have to go.
I mapped out the existing hospitals and schools, historic districts, bodies of water and took into account where metro stops could line up with existing roads, where they would be immediately useful even before the city went fully car free.
I found that I couldn’t quite get all the schools to fall within the urban districts using the reference topology, but those which did not make it in were few. I should also note that my current house would not fall within the diameter (just barely) of the carfree city design. Likewise the historic districts didn’t line up well with the plan for the car free districts, but in truth most if not all of these historic homes are single-family units of no more than two stories -– it is unlikely they would provide the necessary density as advocated by the car free plan. Crawford advocates green space surrounding all the urban districts, and with good cause, but exceptions could be made for the sake of historic preservation.
One of the major stumbling blocks for building a subway system as advocated by Crawford is Athens’ topography. If you’ve been to Athens you’ll know it’s fairly hilly in places. As one example, from the center of downtown to the river there’s an elevation change of 53 meters over a 700 meter distance. That 7.9% grade is far steeper than ideal grades for a railway which do not exceed 1%.
Grade separation (keeping different modes of transportation from interfering with each other) is paramount to an efficient mass transit system. Ideally (for issues of weather cover and train automation) the whole system would function best underground. However, given the extreme changes in elevation around downtown there may need to be some compromises. These would probably be done at either extreme; burying some of the highest elevation subway-stops deeper underground than would usually be done, and having the subway emerge onto an elevated track over some of the deepest valleys.
An Aside - The Walmart District
Stages of Development
Putting aside for the moment that Athens isn’t even currently considering a subway, what could the stages of development be to transition the city to the car free plan?
I think I would start with making downtown progressively car free. It is already a heavily pedestrian environment, given that the UGA campus is just to the south of Broad Street. It would help acclimate people to car free living. The many parking lots could be turned instead into more shops with living spaces on the upper floors.
Ultimately I would look to make the north-south streets into pedestrian right-of-ways (bikes allowed but with caution), and the east-west streets as bike-ways (with ample room on the edges for pedestrians, of course). I’d probably start by turning College Ave into a series of plazas, intersected by the east-west roads, as this is the heart of downtown. Next the city could limit downtown delivery vehicles to blocks of time in the morning and night, similiar to Lisbon’s Bairro Alto area.
The other item that could be changed early on is to rezone the areas that would become car free districts to allow for mixed use and to allow a building height appropriate for the desired population density.
The biggest undertaking would be to begin building the subway. Securing the rights of way for the trains (both passenger and freight) will probably be as big an issue as finding funding for the system as a whole. That sort of work ought to begin immediately, as you do not want people investing in and building on space that will ultimately be reclaimed for the transit system.
The subway will have to be built in stages, if for no other reason than that Athens does not have the population to merit as extensive a system as laid out in the reference topology. The city’s population is just over 110 thousand, a mere 5 percent of the suggested city in the book. Whether it makes more sense to develop one of the 3 subway lines at a time, or start on them all from the middle out and extend them as the population merits it, I do not know. In either case, while the ends of the line or lines are under construction, the subway can begin to operate on the finished sections by shuttling back and forth until a loop is complete.
The other subway question is when to introduce the “metro freight” concept, where all goods coming into and leaving the city are transferred by standardized shipping containers on a below-grade rail system. Getting people out of their cars and into mass transit is only half the equation. We will still be saddled with the noise, pollution and safety risks of surface vehicles if we do not have an efficient and desirable way to move goods around. I would suggest that this won’t be viable until at least a few of the "utility districts" proposed in the car free plan are implemented, complete with a well developed intercity rail link for freight.
Intercity rail for passengers will need to be addressed as well. For the forseeable future there will still be a large number of commuters into metro-Atlanta, and it would be a shame if they had to take the subway out of the edge of the city only to have to get in their car and drive the rest of the way in. A commuter rail link has been a long time coming, and it’s unclear when that will finally come to pass.
Other Considerations
While working through the car free idea I’ve gathered a number of ideas and considerations not mentioned in Crawford’s writings:
Passages for wildlife: each district is connected to its neighboring district by a boulevard for bike/ pedestrian/ emergency vehicle traffic. Since the rest of the district borders on green space, it would probably be wise to engineer wildlife corridors under or over these roads.
Private outdoor space: something I am used to as a resident of suburbia is private outdoor space to cultivate as I choose. Is this something that is inherently impossible in a city? Is my gardening/landscaping hobby not compatible? Would we need to be able to afford a "country home" to indulge in these hobbies? Does that leave this activity only available to the wealthy?
Subway station designs: Having been an architecture student in a past life, I’d like to think that we could make subway stops that are bright and full of natural light, rather than feeling like caves. Crawford’s plans puts the metro stops under the main boulevard running through each district. This may be an efficient use of space, but limits the sort of architecture possible to make them inviting spaces.
Hospitals: Crawford mentions locating hospitals in the middle of the green space within each subway loop. I would rather see that remain green space and instead see clinics built in each district.
Planning: It might be a useful planning tool to have a heat-map of the age of all buildings/locations in the existing city. Both for historical preservation and for individual sentimental value, it may be hard to persuade citizens to raze older structures as part of the reorganization of the city. It could bias districts to include these areas rather than leaving them in the designated green areas for reclamation.
It seems to me that legal fines, late fees, or other sorts of punitive charges paid to municipalities, states or the federal government ought to go into a rainy-day or special projects fund. This would force government to budget based on taxes and other more regular and predictable sources of revenue. This would have two obvious benefits:
- It would help the government to save for either hard times or worthy special projects that would otherwise be too costly.
- It would take away the monetary incentive behind levying fines and focus more on the appropriateness of the punishment.
That second point is the important one. If the motivation for enforcing rules is to bring in operating revenue for government and law enforcement (the seizure of drug money to fund the purchase of policing equipment, for example) rather than simple justice, the metrics for which issues to focus on become skewed.
Reversing this, without the monetary incentive the importance of the infraction itself becomes the metric for enforcement rather than the cash benefit.
That seems a much more just way to apply the law.
The Making of Pod::Literate
Some time ago I encountered the concept of Literate Programming. I was intrigued by the idea but never really explored taking up the practice. I don’t really remember why, though it probably had something to do with a lack of tuits and no obvious support for it in my main language, Perl. I also was not really at a point in my programming career where it would have occurred to me to implement tools for Literate Perl.
I was reacquainted with it more recently when I started to learn Haskell, which has native support for literate programs. Haskell is a language that has some intrinsic appeal for me that I can’t quite put a finger on, but again between not having yet grasped the Haskell mindset and not having time for a new project I let that slip by too (I suspect the former will not occur until I have time for the latter).
More recently I’ve been on a DRY (Don’t Repeat Yourself) kick in my day-to-day programming. Of course I’d always practiced DRY to some degree, but lately I’ve been getting more insistent with myself that I really keep on top of duplicate or near-duplicate code.
This probably came to a head when I read Steve Yegge’s rant about code-base size. The code base for my main project is large enough that I don’t visit all it’s layers, nooks and crannies on a regular basis. The main problem of code maintenance as many programmers will attest is memory loss. Our own, that is. Remembering why you wrote code they way you did when you haven’t seen it in a week, much less months, is a major hurdle when returning to it. The two solutions I see to reduce the effects of memory loss are solid documentation and reducing the amount of code that needs remembering in the first place. Naturally, I chose to look at the latter.
Dispensing with Boilerplate
I imagine that any programmer who takes DRY seriously will at some point take a hard look at “boilerplate code”. More incantation than instruction, boilerplate code tends to have a very low signal to noise ratio; most of the code is instead there to make the compiler happy.
Being Perl, most of the boilerplate code was of my own making. So I hacked and refactored and experimented with shorter ways of expressing the same intent (another story for another time) and made some good headway towards weeding out the verbosity of my code, without sacrificing (and in some cases enhancing) clarity.
As all good things must be taken to extremes, eventually I started eyeing some of the standard Perl incantations and wondered about doing away with them.
First, library files (modules) in perl must have a final statement in them that evaluate to true in order to compile. I am not clear on where this legacy comes from, but the convention to make sure all is well with your module is to append a “1;” at the end of the file to keep the compiler happy. A whole whopping 2 characters, but it wasn’t adding any meaning to my code, and I aimed to remove it.
Second, best practices recommend coding under “strict” mode, and at least during active development, under “warnings” mode as well. This makes the Perl interpreter the least tolerant possible of your errant ways, and I take these best practices to heart. In fact, the forthcoming 6th version of Perl makes “strict” the default state, so rather than pronouncing strict mode at the top of every file, you instead only declare when you intend to be naughty by explicitly shutting off strictures. I (and many others) are impatient for Perl6’s arrival, and I decided I wanted this little bit of code reduction here and now.
A Preprocessor
These got me thinking about writing a preprocessor. I didn’t want to give up strictures, and I needed the compiler to accept my modules, but I also did not feel it was doing me any meaningful good adding these incantations to each of my files. The “1;” for the module was legacy nonsense and the strict and warnings pragmas were policies I’d rather set once across my whole project rather than for each file. So I figured I could add these in programatically.
At about this point I ran across the literate programming idea again. I figured that as long as I was already running my code through a preprocessor, I may as well have it convert my code from a literate style at the same time. I can’t really recall what I ran across that brought it up, but by some route I found myself reading an older article by Mark-Jason Dominus, Pod is not Literate Programming about how POD lacks certain key features of a literate programming system. He pointed to noweb as a language agnostic tool for Literate Programming, but for some reason that did not appeal to me. I thought, well, this is Perl! There must be something on CPAN.
And indeed there were several attempts on CPAN at implementing Literate Perl, but none addressed one of MJD’s core issues with Pod, which was that it doesn’t let you rearrange your code from human-reading order to compiler-reading order.
The closest I found to what I wanted was Audrey Tang’s Filter::LiterateComments. She chose a style very much in keeping with Haskell’s notation, which is unsurprising given her background with the language. But being a source code filter it never had a chance to do code reordering, and on its own it would not be able to create typeset documentation.
Pretty Documentation
Now that I was committed (in both senses of the word) to writing a preprocessor, I wanted to one-up the typesetting question by prettifying the code as well as the explanation in the documentation. I knew there had been some work done with PPI to do syntax highlighting, and I had already decided to rely on Perltidy to enforce code formatting conventions. Further, I recognized that there were several perl operators written in ascii (such as -> and =>) that were really just stand-ins for untypeable symbols. I figured in the interest of legibility I ought to replace them with their intended entities in the documentation.
So the plan involved extracting each code block in the source code, running it through perltidy, then PPI::HTML, and then doing a search-and-replace on operators that were stand-ins for more legible symbols. That way something like this:
sub dump_code {
my ( $parser, $extension ) = @_;
my $source;
<<replace anchors with code snippets >>
$source .= "use strict;\n" if $parser->{_use_strict};
$source .= "use warnings;\n" if $parser->{_use_warnings};
$source .= join(
'',
map( { $parser->{_code}{$_} }
grep { defined $parser->{_code}{$_} }
@{ $parser->{_code_sections} } )
);
<<source code amendments based on file type>>
return tidy( $source );
}
into this:
sub dump_code { my ( $parser, $extension ) = @_; my $source; «replace code anchors with code snippets»
$source ⋅= "use strict;\n" if $parser→{_use_strict}; $source ⋅= "use warnings;\n" if $parser→{_use_warnings};
$source ⋅= join( '', map( { $parser→{_code}{$_} } grep { defined $parser→{_code}{$_} } @{ $parser→{_code_sections} } ) ); «source code amendments based on file type»
return tidy($source); }
For the curious, the above modified source is marked up to be highlighted via css, but this blogging software does not allow for embedded stylesheets. When I move to another platform I will restore the syntax highlighting. I use a stylesheet that looks like this:
span.comment {
color: #6a6;
}
span.structure {
color: #999;
}
span.word {
font-weight:bold;
}
span.keyword, span.core {
color: #449;
font-weight:bold;
}
span.symbol {
color: #c94;
}
span.cast {
color: #d60;
font-weight:bold;
}
span.magic {
color: #a72;
}
span.single {
color: #77f;
}
span.words, span.double {
color: #55f;
}
span.match, span.substitute {
color: #339;
}
span.operator {
color: #555;
}
Bootstrapping
As a tool for literate programming, naturally I wanted to be able to write the library itself as literate perl. The dilemma of course, is that the literate format can’t be executed until it’s translated into regular Perl. What I found was that I had to first develop the code in a non-literate style, and get to a point where I could process literate perl. At that point I could then run the "compiled" non-literate version on the new literate copy of the module in order to get a runnable version of the newest code.
Where To Go From Here
The system I have written works well, but there are still a few things I need to do before I can release it to CPAN
- It cannot at the moment create a linked TOC for the headings in the documentation
- The preprocessor does not spit out a pure POD version of the docs, which is what CPAN wants for module documentation. Indeed, the literate documentation isn't really even the sort of documentation CPAN users are looking for. It may mean putting the overview documentation in a separate pod file, or marking a certain portion of the literate document as appropriate for extraction for use on CPAN.
- I actually need to write a bit more of the documentation. While the Pod::Literate module and the literate preprocessing script are written in the literate style, there are still some longer code sections that I have not augmented with appropriate documentation.
- Similarly I have not written any tests. Running it on it's own source code has been a pretty good test in itself, but I know I will get frowns from the community if I ship without a good test suite. For the tests-first segment, I'm sure I'm already getting those frowns.
As part of my efforts to learn more about functional programming in general and Haskell in specific, I chose a small project that was tangentially related to the work I do in my web programming work at Enterity. If anyone out there knows of a built-in for converting from Int to Hex and back again, I'd be much obliged. I didn't see anything skimming the standard libraries via Zvon.org
module Main where
import System.Environment
import Char
import List
main :: IO ()
main = do args <- getArgs
case ( args !! 0 ) of
"encode" -> putStrLn ( encode $ concat $ tail args )
"decode" -> putStrLn ( decode $ head $ tail args )
-- --------------------------------------
encode :: String -> String
encode str = concat $ map encodeChar str
decode :: String -> String
decode "" = ""
decode (c:cs) = case c of
'%' -> fromHex( take 2 cs ) : decode( drop 2 cs )
otherwise -> c : decode cs
-- --------------------------------------
encodeChar :: Char -> String
encodeChar c =
case isLegalChar c of
True -> c : ""
otherwise -> '%' : ( toHex . ord ) c
isLegalChar :: Char -> Bool
isLegalChar c = any (c==) ( [ 'A' .. 'Z' ] ++ ['a' .. 'z'] ++ [ '0'..'9' ] ++ "-_.!~*'()" )
-- --------------------------------------
toHex :: Int -> String
toHex 0 = ""
toHex x =
let rem = x `mod` 16
in toHex( ( x-rem ) `div` 16 ) ++ [ toChar rem ]
fromHex :: String -> Char
fromHex hx =
let a = fromChar $ head hx
z = fromChar $ head $ tail hx
in chr( a * 16 + z )
-- --------------------------------------
toChar :: Int -> Char
toChar x = ( [ '0' .. '9' ] ++ [ 'a' .. 'f' ] ) !! x
fromChar :: Char -> Int
fromChar x = case findIndex (x==) ( [ '0' .. '9' ] ++ [ 'a' .. 'f' ] ) of
Nothing -> 0
Just y -> y
