Eclipse E4: A Critique

At work, Iím developing on a large internal application based on the Eclipse Rich Client Platform, which is basically the foundations of the Eclipse IDE made available for everyone else, too. As platforms go, itís alright, I guess, but it does have its share of weirdness. For example, why do I have to dispose colors once Iím done with them!?[^1](#) But with a healthy amount of helper functions, itís all manageable.

[^1](#): For compatibility with 8-bit indexed displays. Since this is nowhere near a target for our app, I generally donít dispose colors.

Weíve recently finished porting the application from Eclipse 3.7 to the 4.x line (specifically 4.5, planning to upgrade to 4.6 once itís out). This may seem a bit late, considering that the first official release of that line, Eclipse 4.2, came out four years ago. After working with the new code, though, Iím starting to think that maybe weíre still too early. Eclipse 4, or e4 for friends, features a massive rewrite of some of the core parts of the platform. And I think that itís unfinished and in parts rather misguided.

Unfinished Business

Editors are gone, as are views, replaced with generic parts. I could get behind that, but gone as well are editor inputs objects. So telling an editor what file to open and making that decision persistent requires custom logic - and possibly a lot of that if you relied on the flexibility editor inputs gave you. You might see the MInputPart in the documentation, but apparently that was never implemented and is now deprecated. I think the only reason itís still in the documentation is to taunt people. Of course, even if it did work, an URI based scheme only brings you so far if you have an editor that is supposed to receive objects from many different sources.

Many classic services have no e3 equivalent. For example, the IFocusService lingers around, but itís very unclear whether I can rely on it once weíre e4 only.

No documentation

The documentation for new e4 specific stuff is largely missing or automatically generated and not helpful at all. I dare you to find any information in the documentation of MToolItem that isnít obvious from the method names. Whatís particularly missing is overview information: What do the different parts in the application model actually mean? Whatís the difference between a MPart and a MPartDescriptor, and which one do I need? Whatís the lifecycle of a MPart exactly? What is the point of context activation?

The best source of information are the rather terse Vogella tutorials, but these are task-oriented, not concept-oriented. If you want to do something that no Vogella employee wanted to do yet, youíre largely on your own.

Loose coupling. Like Spaghetti

I like the idea of dependency injection in theory, but Iím not sure about the practice. And I have no idea whether that is an Eclipse thing or not, but it still irks me.

The basic idea suffers from two problems: You want all dependencies passed in externally instead of getting them from some global nebulous set of singletons and what not. Thatís valid. But you also donít want gigantic constructors with 200+ arguments for complex classes. Not that you should have classes like that anyway, but a complex editor implementation can reasonably require access to most services Eclipse provides, even if it is just passes them on to helper objects.

The solution is more or less to put all that global state in a map, then pass that map as the argument to every constructor, and allow it to create new versions of the same map internally. Only they chose a more complex version that also has a lot of syntactic sugar, to make sure it runs really slowly. Eclipse has a reputation to maintain, after all.

As a result, you still have no clear idea what part of the application needs access to what unless you search for type names, and now you also have no idea where itís coming from. Itís not so much that itís bad per se, but it definitely does not realize the advantages that dependency injection was meant to provide.

And while weíre here already: The way event handling is done via dependency injection is just insane.

Horribly bad ideas

I honestly donít get the application model, and not just because there is no real documentation on it. I have no idea why itís here at all, what problems itís meant to solve, and how it thinks it has solved them. And most of all, I donít get why so many Eclipse developers are so damn happy about it. “Look at this”, they go, “I change the windowís title in the application model, and the windowís title actually changes! And I can even do thatÖ at runtime!” And then theyíre surprised when I donít applaud.

But hey, whatever, Iíve been able to write helper methods and helper classes to get around any problem in e4 yet. The real problem of the application model is that it seamlessly merges user state and declarative application code into one giant ball of mud. And then it makes that mud persistent, which is just as unpleasant as it sounds.

Because suddenly, changes in user state get the opportunity to conflict with changes to declarative application code. Will my new context menu show up if the user has moved any editors around? For that matter, will my old context menu continue to show up? Surprisingly often, the answer is no, and never for any good reason I could discern. By merging what absolutely had to stay separate, they built a giant bug-producing machine.

And they know it. The closest thing to an official recommendation is to simply disable persistent user state. Only during development, in theory, but they sure donít provide a better way to deal with the problem once I release an update of my app. In my opinion, this wins the very highly contested price for least user-friendly thing ever done in Eclipse.

Oh, thereís a workaround, but itís one that nobody will tell you about, and itís the most WTFy thing I ever implemented, to the point that I still canít quite believe that this is what it takes. But Iím doing it anyway: I wrote my own code for serializing the application model to an XML file and back, making 100% sure that I only touch the parts that the user can change (i.e. what editor is where), but not the parts that are declarative program code. Itís been a few months since I implemented this thing, and I still sometimes wake up in the night and shout “There must be something better! Some simple flag I missed somewhere!” Do drop me a line if you found it.


Finally, command handlers. The new way of writing them is good. Having the validation logic in the handler itself as opposed to an XML file somewhere is better. Good choices all around.

Less good: Why can I have only one handler per command per part? I kind of need several different “delete” handlers for different parts of some more complex editors, thank you very much, and I have only limited interest in creating one giant monster handler that contains the delete logic for absolutely everything. Of course itís possible to work around that; Iíve managed to work around every little thing in e4 except the application model weirdness so far. In this case, write one handler that creates an internal list of other handlers, then asks each whether it can execute and the first one to shout yes gets to do the job. But I donít get the logic that says I have to write stuff like that.

I also donít quite get why some handlers exist and others donít, but thatís less of an issue.

No tool support

Why is it that so many new things are released without good tool support? Do people somehow think thatís optional? I donít see it. For example, to port from e3 to e4, there is an awful lot of getting information out of one XML file, translating it, and putting it into a different XML file. Itís boring, tedious and straightforward. And the one and only tool I found for that is one I wrote myself (No; you canít have it. Nothing personal, but I have no idea what hoops Iíd have to jump through to get something developed internally released as Open Source here).

The tools that do exist regularly stop accepting copy and paste and have no useful search. Most of them arenít part of the platform proper, but require a separate download. It all feels very experimental. I went back to editing the XML files by hand.


Overall, e4 is still very far from done, and thatís frustrating. But in a few places, even the core is wrong or at least questionable. And while it looks like Eclipse 4.6 will solve a few issues Iíve been having (Generics for Databindings! Hooray!), they donít seem even interested in solving the big ones.

Agents of SHIELD retrospective

So I wrote this a while back, posted it elsewhere, then forgot about it, until I was reminded the day before yesterday that this wouldn’t be all out of place here, either. So let’s talk about a TV show that I found really disappointing once more: Agents of SHIELD.

At the start, I was really excited about it. Then I was disappointed. Then I got angry. Then it got better again, so by now my feeling is mostly “meh”. And what a big “meh” it is; Iíve been putting this off for more than a week after the final episode of season 1 aired and I still barely have the energy to get through this post.

The show certainly means well, although it really tries more to be a Joss Whedon show than a Marvel property. I guess the writers had prepared a checklist pretty much like the one I posted above and were trying their best to fast-track through it. This became very apparent later on when the characters basically outright stated “That bonding over a common enemy thing? Might as well do that now, nothing else interesting going on this episode”. And never forget that “the Bus”, their plane, is for all points and purposes the Serenity from Firefly. Similar looks, capabilities, identical internal layout including which character owns what space.

What it lacks is the depth and complexity that real Whedon shows have. For all of the characters, their motivations, strengths and flaws can be described in two sentences at most. Instead the show tries to keep our interest with layers of mystery and question after question. Lost has been getting a lot of shit for this, but there can be no doubt that Lost did it way better. The story of Coulsonís resurrection, for example, is in the end neither particularly complicated, nor does it mean much for his character both in how it happened or in how he reacts to it. Itís also kind of stupid. But in Agents of SHIELD, kind of stupid is probably the biggest compliment you can make, considering that the show is so very frequently extremely stupid.

For example, take the episode 0-8-4. How many trained Agents of SHIELD and peruvian military police does it take to stop one Land Rover filled with I guess about three or four insurgents? I donít know, but itís gotta be more than 6 and about 15, respectively, because they try and fail. Then there are things like where the “adorable quirky” (annoying) scientist guy gets to go out in the field with the actually competent person. Yeah, Fitz isnít field-rated, I get it. But are you seriously telling me heís never even seen a spy movie before?

It all works out for the heroes because the villains are just as stupid. Take the excavator thing: The bad guys didnít need an excavator to open the secret SHIELD truck; it had normal doors (with some boxes stashed behind to throw anyone who opened the doors of track, so clearly they werenít welded shut). They donít use the excavator to open the secret compartment within the truck either; that job goes to a blowtorch. And they paid for the excavator in gold bars, which seems hardly reasonable. Of course the gold bars can be traced back to the main villainís gold mine, something that a gold mine owner probably should have known. Oh, and the entire plot hinges on Malta not being a member of the UN or EU (it is, of course, a member of both organizations). This is some serious multi-level idiocy going on here.

Later episodes pick up the slack quite a lot, and at turns even make fun of themselves, for example when Skye reveals that her name (given to her at the orphanage) was Mary Sue, or my personal favorite: When Agent Hand sees all of Team Coulsonís incompetence and deduces they must have been Hydra all along.

But at that point the show was doing exactly the same thing as ĄCaptain America: The Winter Soldierď, and boy does it not hold up. I get that a TV show with a limited budget canít look as good as the Hollywood blockbuster, but the longer running time should allow it to have better human drama. It doesnít. Captain America wins on all fronts here with Cap as an all-around good guy who never actually becomes boring, an interesting friendship with Black Widow, inspirational speeches that actually work on me (and Iím a long-standing cynic) and real pain over the thing with Bucky. Even Falcon with his amazing lack of screen time has more personality than most of the Agents of SHIELD group.

Also, somewhere before there, I think Iíve kind of stopped caring. I mean, the final resolution to “how and why did Coulson get resurrected?” was “Nick Fury did it because Coulson is a nice guy whom everyone likes”. Seriously. And my reaction to that was “eh, could have been worse”.

Finally, to wrap this up: The show doesnít look that good. Donít get me wrong, it looks perfectly okay in a late 1990s kind of way. But we live in an age where Heroes, Lost, Breaking Bad or further out of the field Gossip Girl have established strong visual identities on TV. Whether it is through the choice of color, editing, or other things, these shows have character. SHIELD is, visually, less exciting than Bones or Castle.

In total: Agents of SHIELD is really not worth the bother. The later episodes are at least not offensively stupid anymore, but there isnít really anything else to get passionate about either. Season 2 has been announced, but Iíll probably skip it. Hereís hoping that these Netflix shows or Agent Carter do better.

DAG vs. Tree

I am wondering whether the data structure ďtreeĒ might be a giant mistake in the history of computer science. Almost everything that can be saved in a tree is really a DAG.

Some background: A tree is a data structure consisting of nodes, where each node has one or no parent (this is technically a forest; a tree has only one node with no parent). Each node has children; specifically the nodes that have that node as its parent. Circles are forbidden.

The best-known example for this are computer file systems. Each file is in a folder. That folder is in another folder and so on, until you reach the drive, which forms the root of the tree. Mail lists and some kinds of forums and comment systems also work like that: Each post is a reply to exactly one previous post (at most) and gets shown a layer below. However, tree structures predate computer science. The whole field of Taxonomy as well as linguistics, both with their habit of grouping things in families and sub-families and so on, do exactly the same thing.

Itís easy to process trees automatically, for example to find all children. You can also identify each child uniquely through a given path.

There is just one problem with them: Reality does not work like that. In most real-world cases things, can have multiple parents. A classic example: What folder does a file fit in? Likewise, in discussions, sometimes you want to reply to several posts that make similar points at once. In linguistics, languages donít really belong to one family exclusively, they have influence from lost of different ones.

To get around that, one either has to pick a parent explicitly, or split the object. Splitting works for discussions well, for files sometimes, for e.g. classification of car types not at all. In either case, information about the semantic relationships is lost.

The answer to that is called DAG, for Directed Acyclic Graph. The rules are almost the same as a tree, only a node can have more than one parent as well. An example: Media library apps like iTunes allow a song to appear in several playlists at once.

DAGs represent the examples here naturally. A file can be in two folders, for example. Since a tree is a special case of a DAG, itís also easily possible to represent the cases that actually are tree-like.

In reality many systems already include hacks to create DAG structures. For example, thanks to Hard links, most file systems actually are DAGs, they just donít show it that often. Symlinks, Aliases and Windows shortcut files all create a ďsecond-class parentĒ, which explicitly stores the removed relationships.

Another approach is through tag systems, where a file, blog post or similar can have an arbitrary number of tags. This structure is actually just a two-level DAG. That may seem like a solution, but since it isnít possible to form relationships between tags, and because many use cases of trees canít be modeled that way (for example discussions), it isnít a full replacement.

Admittedly, from a technical point of view, DAGs are much harder. For example: A tree is always planar, which means you can easily show it on a screen without crossing lines, something that is not guaranteed for DAGs. Enumerating all elements without repeating any is a lot harder. Objects can be reachable through two completely distinct paths - which is of course the goal, but it means you have to look at the graph to answer the question ďdo these two paths end at the same objectĒ, which is trivial with trees.

Most importantly, I know no really good UI to show and manipulate DAGs. For example, the opposite to a tree structure in forums is not a DAG, itís a simple list ordered by time, and the relationships between posts have to be shown manually in the text.

(Of course, this does not affect the use of trees in cases where end users donít see them, for example search trees, heaps and so on.)

What do you think? Due to too much spam, Iíve disabled the comments here for now, but you can reach me on Twitter via @zcochrane.

30 years of Mac

When I bought my first Mac in 2002 (an eMac with 700 MHz G4), I considered myself a late-comer to the party. Today, in most groups of Mac users, I am among the one who has been using one the longest.

Unlike the many people who are now posting about how they saw their first Mac and were instantly hooked, I sort of slid into the whole thing. The first Mac I ever saw was a PowerMac G4, still with pinstripes, owned by my father for layout work. It ran Mac OS 9, which was certainly different but didnít seem in any way interesting. That changed considerably with the second Mac I ever saw: An iBook G3, the white edition, running OS X 10.1. It was rather slow, there was barely any software, but I really liked it. Iíd like to say that this was because I saw the great vision and the things to come, but in reality, pretty graphics were probably the real factor. A big part of that were the free development tools: Project Builder and Interface Builder, these days both known as Xcode. Finally, I wanted iTunes and an iPod. Both were really, really impressive to someone who was used to the horrors of Winamp and burning CDs for portable CD players.

Itís been an odd ride since then. When I started, the transition from OS 9 to OS X was still in full swing. Then Apple switched to Intel, then iOS (or rather the iPhone OS as it was known back then) became a huge thing. Apple rumors used to be an important and often accurate source of information, but that scene has almost completely died. Perhaps because all the rumors that ran forever (Apple will switch to Intel! Apple will release a successor to the Newton! Apple is building a phone! Apple will make a mouse with a second button! Apple will make a tablet!) have ultimately proven true, but usually not in the way anyone expected.

Important for me: I learned basically everything I know about programming and software development on my various Macs. Itís still my biggest hobby, and its how I make money these days, and while I have no idea whether Iíd be elsewhere without a Mac, I know that without it, it would have been a lot less fun.

Agents of Shield - Checklist filled

So let’s see how that checklist works out in practice then. Oh yeah, spoilers:

  • A group of people that donít get along initially, but grow to become a family? - Yeah. Still working on that growing to be a family.
  • A scene where it looks like a tiny girl is in danger, but in reality sheís the one in control of the whole situation and the most dangerous thing all around? - Yeah. This time she’s evil. In a wider sense, the villain of the week is male but portrays that power reversal, too.
  • A ďonerĒ, meaning a very long shot where the camera moves to a space without cutting? - Not yet.
  • An episode where information is conveyed through music? - Not yet.
  • Beloved minor characters who die? - Not yet.
  • Characters in so much pain and angst that they can barely walk? - Yeah. Charles Gunn.
  • Pop culture references? - Oh yeah. “With great power comesÖ a whole lot of shit that you’re not prepared to deal with.”
  • Actors from previous Joss Whedon works? - Charles Gunn, Shepherd Book, the Serenity. And a discount version of Eliza Dushku.
  • A great sense of humor? - Hell yeah. “Sorry, the corner was dark, I couldn’t resist”
  • Horrible things happening to people in love? - still too early for that

Agents of S.H.I.E.L.D Checklist

Tomorrow, Agents of Shield1 will start. Itís a TV show set in the Avengers movie universe, focusing on somewhat more minor heroes. The promotional material has focused on showing action sequences and explosions. The images were of various people all looking strong and grim. In many ways, it sounds like you could skip it. Except for one thing: Itís the new TV series by Joss Whedon, the genius behind Buffy the Vampire Slayer, Angel, Firefly, Dr. Horribleís Sing-Along Blog, Dollhouse and, oh yeah, the Avengers movie.

So thereís a question: Is this a generic action thing, or is this the next in the series of awesome things by Joss? To make up my mind, Iíve made a standard Whedon checklist that Iím going to fill as soon as the pilot is available on iTunes. Beware: This includes spoilers for all the shows mentioned above.

Does Agents of Shield haveÖ?

  • A group of people that donít get along initially, but grow to become a family? (as seen in Buffy, Angel, Firefly, Dollhouse to a lesser extent, Avengers)
  • A scene where it looks like a tiny girl is in danger, but in reality sheís the one in control of the whole situation and the most dangerous thing all around? (the mission statement of Buffy, but also very notable in Avengers where Natasha pulls it off twice)
  • A ďonerĒ, meaning a very long shot where the camera moves to a space without cutting? (as seen in Buffy, Angel, Dollhouse, FireflyÖ basically everywhere. Avengers has its prime example in the middle of the fight in New York)
  • An episode where information is conveyed through music? (the musical episode in Buffy and Dr. Horribleís Sing-Along-Blog are the most obvious examples, but donít forget ďThe Hero of CantonĒ from Firefly)
  • Beloved minor characters who die? (Buffy does it a lot. Angel does it a lot. Firefly does it surprisingly often. Dollhouse does it. Dr. Horrible does it. Avengers does it, although the victim there gets resurrected for this TV show)
  • Characters in so much pain and angst that they can barely walk? (All of them)
  • Pop culture references? (For some reason theyíre missing in Firefly; the rest has more than enough of them)
  • Actors from previous Joss Whedon works? (Avengers kind of averted that, but Cobie Smolders was at least a friend, and Clark Gregg got roped into appearing into Jossís version of Much Ado About Nothing after Avengers was done).
  • A great sense of humor? (All of them)
  • Horrible things happening to people in love? (Avengers is still lacking that one. Be very afraid for Pepper in Avengers 2)

There are probably a few others that I missed.

  1. I am definitely not going to do all that punctuation stuff unless Iím getting paid for it. 


Iíve been meaning to post this last week, but forgot. Hyperloop is a proposed new transportation system designed by Elon Musk, which focuses on small capsules traveling at high (up to 1200 km/h) speeds through partially evacuated steel tubes. There is a proposal available online. I believe itís all crap, and Iím going to explain why.

Now, first of all, there is of course a chance that this blog post will look very embarrassing twenty years from now. One dismisses the founder of PayPal, Tesla motors and SpaceX at oneís own peril.

But on the other hand, itís not like this hasnít been tried before. Right from the moment the first trains appeared, people said ďI can do better than thatĒ and invented their own Ďimprovedí designs. The Wuppertal Schwebebahn is a rare example that was actually built and then actually worked (and still does). Hyperloopís approach in particular is very similar to a previous Swiss idea. However, that swiss idea did not have a compressor and was built in tunnels instead of elevated, and relied on much larger trains.

A more useful comparison is the Transrapid, a german high-speed Maglev train. It is beyond any doubt the worldís most successful high-speed Maglev train, because there exists one commercial installation, as an airport shuttle in Shanghai. Despite several decades of research and development, and the proof that the technology can work both in theory and in practice, the system has been ultimately abandoned and was really a waste of everyoneís money. Hyperloop is technologically very different from Transrapid, but many of the challenges are similar.

Can it work?

I have no idea whether the approach is actually workable. I seriously donít know enough about any of the involved technology to say so. So Iíll have to give Hyperloop the benefit of the doubt and say that it probably can work from a technical point of view.

A railroad is not an island

That doesnít mean itís a good idea, though. The proposal focuses almost only on the technology, and does not discuss at all how to actually build a useful transportation system. An example:

The calculation presents two different models: One that is for passengers only, where the capsules have an exterior width of 1.4 m and height of 1.1 m, and another larger one. The smaller one relies on gullwing doors and seats that basically have the passengers lie down. Its main advantage is that it is a lot cheaper. Its main disadvantage is that it is illegal.

The reason for this is that such a system isnít wheelchair accessible, because there is no space for a person seated in a wheelchair. We have thankfully finally gotten used to the idea that access for persons with reduced mobility is not something optional, but an essential part of preserving human dignity. It is neither realistic nor desirable to assume that the state of California would make an exception here.


Any actual transportation system (as opposed to a giant model railroad, which is what the current Hyperloop proposal shows) needs interfaces between it and the people who want to use it, or in other words, stations. These are not a thing that just happens, but rather an integral part of the overall design, and they require that you give them a lot of thought.

Hyperloop really doesnít. It gives a vague explanation of the proposed experience. However, it lacks any details. Will there be shops? Parking spaces? Will stations be located in city centers, or on the outskirts? What about connections to existing rail systems, trams, or buses? What about evacuation in case of a fire, or about people opposing the construction? All these are real, important and expensive concerns. Just ask the people building new transportation hubs in Stuttgart or BerlinÖ


All the people who try to reinvent trains sooner or later hit upon a simple fact: The standard railroad switch is totally amazing. It requires only the space for the two tracks, and only a very tiny part of the overall construction has to move. They can change directions in about ten seconds. Any monorail approach has to either replace a part of the track, or bend it to a new direction. The Wuppertal Schwebebahn I mentioned above replaces the track; the Transrapid bends it. Both take much more energy and time.

Hyperloop hasnít hit on that fact yet; reading the paper, it seems that the authors simply assume that switches exist, without thinking at all about it. That is dangerous, because a switch for Hyperloop may be the most complicated kind of switch invented yet. Not only does it require very large turning cycles, it also has to be completely air tight at either end, and you either have to keep the vacuum while it is switching, or restore it after youíre done. Switches are definitely necessary on this system, because there are several proposed spurs to minor californian cities.

Note that switches also have to be incredibly fast. Specifically, after a pod has cleared the switch, it must have completed its direction change before the next pod would have to start breaking in order to stop before the switch. This is because one cannot send a pod towards a currently changing switch, just hoping that it will be in a valid position when the pod arrives. This is completely unfeasible at the maximum 30 second distances between pods; one would have to group them by destination and leave a gap in between.


You just have to love the chapter on safety. Itís basically three paragraphs going ďyeah, this is basically safe, so thereĒ. There are no points on procedures or technologically, just notices that the track is completely enclosed, that trains canít be accelerated to unsafe speeds, and that there are no pesky humans interfering. That is completely unacceptable.

How is train separation achieved? You can, of course, easily send pods through a tube at 1000 km/h in two-minute intervals and just hope that they all come back out in the same order. The authorities might even allow it if you pay enough bribes and donít want to carry people. In real life, every capsule needs to be able to come to a controlled stop if the capsule before it does not clear the area it is currently at in time. If the system assumes thirty second headways at peak times, that means a capsule must be able to come to a complete stop within thirty seconds (because after that it would be where the stopped capsule is now). At 1200 km/h (= 333.3Ö m/s), that works out to a minimum emergency brake deceleration of 11.1Ö m/s, or slightly above 1g. In reality, youíd want some additional buffer, which only increases the forces. Those seat belts in the pods turn out to be absolutely essential. Note that the proposal includes no specification for the braking system whatsoever, only a cost estimate of more than $70,000.

All this assumes a totally safe communications system that works at these speeds and these distances. This isnít a technical impossibility, but it is not going to be cheap either. For comparison: The vehicle-side interface for ETCS, the new european train control system, comes to about 200,000 Ćper locomotive if you can find it really cheap.


The environmental impact discussion is even worse than the area on safety. It simply assumes that nobody in California will have any problems with the worldís highest pipeline passing through or near their back yards. That is rather optimistic. Bundling most of the track with a motorway is a nice solution, but not an option in built-up settlements, where other alignments need to be found.

While weíre on the topic of alignments: How will the system reach its stations? For normal high speed rail, that is easy: The tracks and stations are already in place. This is not true for any new system which needs to either cut through a lot of houses or build very expensive tunnels. The tunnel solution is favored for new high-speed rail stations in city centers, e.g. London St Pancras International. Like any tunneling, it has a tendency to drive the costs up significantly.


The capacity of the system is at the low end average for high-speed rail. The proposed smaller system has a target average of 840 people per hour; for rush hour, that can be increased by a factor of four (to 3360 people per hour). For comparison: The low end is about equal to what currently drives on the Paris-London Eurostar line, an altogether very under-utilized system. In Germany, the Cologne-Frankfurt high speed line (itself not exactly bustling with activity) has a capacity of about 2800 passengers per hour at the current timetable, although lack of trains may make that difficult.

However, trains scale much better. There is no particular reason why London-Paris canít see the same number of passengers as Cologne-Frankfurt, and both could easily deal with twice as many passengers, too. The upper end currently seen in Europe would be the french high speed network, which can see trains composed of two double-deck TGV units every three minutes in the best case. This works out to an average peak capacity of more than 20,000 passengers per hour. This is probably not actually sustained for an entire hour. Still, the system scales relatively gracefully to very high numbers of passengers, while Hyperloop has a hard limit not all that far from current standards.


The cost suggestions are incredibly ambitious, or in other words, not even remotely accurate. Missing are items like a safe communication and control system, switches, any sort of traffic control, station development and so on. The running costs have been completely ignored (other than amortization of the investment). Also ignored: Any cost for testing and system development. For the Transrapid, that cost was on the order of a billion euros.

I am also not convinced that the costs that have been calculated are accurate. The pod, for example, costs less than half of a modern regional-service DMU (those tend to cost more than $2 million a piece). While the pod it is smaller, it requires pressurization and a lot of new and untried technology. Perhaps a more useful comparison would be a business jet, which is also pressurized (but with a far lower pressure difference), small, and contains a lot of expensive technology. That makes the price for the pod seem even more unrealistic.


Hyperloop is an interesting technological toy, but it is very far from an actual transportation solution, and I am not convinced that it can ever get there.