Hacker News new | past | comments | ask | show | jobs | submit login
The Best Place to Build a Subway (acm.org)
16 points by amortize 17 days ago | hide | past | favorite | 14 comments



I observe that being able to build great infrastructure is when you have the good fortune of having financial, political, and social forces that incentivize it. That doesn't occur a lot these days. It also takes foresight to build up a reserve of these, because projects are so easily cancelled.

One surprising thing I learned about the Japanese (Tokyo) metro system and its complexity, and yet punctuality and adherence to precise schedules:

The Tokyo metro system didn't get as good as it is because of someone's simple desire to have a really nice metro system, or some theoretical love of schedules.

It became so well-timed and complex because it had to be. Due to the constraints of land and existing infrastructure, there was no other way to serve as many people as demanded train service than to build stacks and stacks of rail networks, and have them operate (and interoperate between lines efficiently) down to the second -- in order to be able to cram that many trains into one space.

Versus in other places, people would say, those requirements are so ridiculous, there's no way a metro system could ever be built to work!

Sometimes, the constraints produce progress. (Of course, this is subsidized up the wazoo in Japan, but not crazily compared to other major metro areas.)


I mean it can get overly ridiculous. Stress over schedule adherence was considered a major factor in a Japanese train crash that killed 100+, and injured 500+: https://en.m.wikipedia.org/wiki/Amagasaki_derailment


A lot of this feels "citation needed". Unlike streets, building software that can scale up is not necessarily more costly - often it means a cleaner architecture that yields benefits from day 1. The examples of cut-and-cover BART and freeway widening are in direct opposition to each other - sometimes we use a cheap construction approach that involves disruption, or an expensive one that reduces it. It's telling that the author doesn't even see anything unusual in the idea that no expense should be spared for the roads, but subways should be built as cheaply as possible.


I wonder what the authors thoughts are on the Moscow Metro. Schematic map: https://upload.wikimedia.org/wikipedia/commons/1/14/Moscow_m...

Seems like a bunch of concentric circles with lines going away from the center.

I have never been to Moscow, but it seems like an interesting success story of planning infrastructure projects properly.


For the context of this thread, a better representation of the Moscow Metro would probably be this one

https://en.wikipedia.org/wiki/Moscow_Metro#/media/File:Mosco...


If you ever have the chance to visit, do check out the Moscow (or any Russian) metro. They're beautiful, functional, cheap and always expanding.


Looking at this plan reminded me of how these plans never convey a sense of scale, and how you have to learn that when exploring the city. The Paris Metro has a similarly looking density of lines and stations: https://upload.wikimedia.org/wikipedia/commons/2/2b/Carte_M%...

In Paris it takes you 3-5 minutes to walk between mostly any of the stations of one line. Coming to Moscow I was somewhat surprised to find that the stations can be 30-45 minutes walking distance apart.

That all makes sense of course, given the population density structure of the cities and the mix of inner-city and suburban trains. But it's kind of hard to take that from these kinds of plans if you don't already know the city, and every station is evenly spaced apart on paper.


That's a diagram, not a map.


Beijing has same thing and those circle lines seem usually like waste of time unless you are going to opposite corner (like from NE to SW)


All these comments are about subways when the article is actually about software engineering.

You all missed the point.


> You can't easily build infrastructure where it's crowded, and you can't afford to build infrastructure where it's not crowded.

Isn't "easily" and affordable" pretty much the same thing? Surely you can build subway pretty much anywhere, it will just cost you where it's crowded. He is basically saying you can't afford to build infrastructure anywhere - no matter if crowded or not crowded, which is quite dumb.


I think by saying "you can't afford to build infrastructure where it's not crowded", he actually means that it's not affordable because the ridership will be too low, so it's not really viable in that sense.


I understand what he wanted to say, but it is same in the end - where it's crowded it is expensive to built and cheaper to operate, where it is not crowded it's vice versa, but in the end you end up with both being not affordable by his quote, so there is no difference between them really, they are both not financially efficient.


> Many of these massive projects have incurred various costs and challenges. In the 1950s and 1960s, the Fillmore redevelopment targeted a largely black part of town. A 36-block area was torn down including housing, a distinct lifestyle, and a world-famous jazz community. Most of the previous occupants could not afford to return.

> In many cases, these huge, multi-decade redevelopment projects bring new life to part of a city, but sometimes we can't foresee what we're going to lose.

This is disingenuous, and shows how little the author understands about the history of American urban development. In many cases the purpose of redevelopment in US urban environments has been to push out people of color. To say that gentrification was an unforeseen consequence of redevelopment is just wrong. Gentrification is often the entire point of redevelopment by city officials.

They should read The Death and Life of Great American Cities by Jane Jacobs or read The Power Broker by Robert Caro.

To be completely serious, this article reads like someone had some ideas about urban development, did absolutely no research, and then talked about those ideas like they were some kind of expert. I don't understand why the ACM would publish something like this.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: