Category Archives: design

Why “Falcon Wing Doors” is a bad idea

Tesla’s new SUV, the Model X, has a very special back door design. They open like “falcon wings”, thus are called “Falcon Wing Doors”.


Although looking futuristic and may help with tight parking spaces, this design has several potential problems.

Delayed escape during accident

If an accident happens and there is a fire, how quickly can you escape? You will get quite trapped in a Model X. When the car loses power, according to Model X’s Emergency Response Guidethere is a very complicated procedure to follow before you can open the Falcon Wing Doors.falcon-wing-door-powerless

First of all, notice that without power, there is no way that the door can be opened from the outside. This means that the firefighters can’t help you much! If you are lucky enough–you are not injured, you are not scared, you successfully get out of the trap of the airbags, you have to do the following three complicated movements:

  1. Remove the speaker grill from the door.
  2. Pull the mechanical release cable.
  3. Manually lift up the doors.


How do you remove the speaker grill? Doh.. Honestly, having hammer and screw driver ready in a Model X may be a good idea ;-)

Reduced utility

  1. You can’t install a roof rack and carry a kayak. This makes this SUV (Sport Utility Vehicle) less useful than other brands.
  2. There can’t be bottle/utility holders on the back doors, because they will fall off when the doors open. As a consequence, back passengers can’t put their water, snacks or cell phones on the doors.

Vulnerability in weather


  1. When the doors open, the back of the car is almost complete exposed, on the sides and top. A good chance for rain and snow to get into the car in large amounts.
  2. When the doors open, dirt and snow that gathered on the roof can fall into the car.
  3. If the car is covered in heavy snow or ice, the doors won’t open. You have to clear the roof very carefully before the back doors can be opened.
  4. The long seams of these doors are more prone to leak problems. As the seals weather out, water could drip down from the roof.
  5. If dirt, snow, tree leaves or twigs gets trapped into the top seals, you may have trouble sealing the doors, and water will drip in.
  6. It will be tricky open/close the doors in strong wind. Wind may cause the doors to malfunction.
  7. Because the doors increased the car’s center of gravity, the car may shake quite a bit when the doors are open against strong wind.
  8. You can’t get in/out easily with half-open doors, but fully open doors will cause a big heat loss in a cold windy day.


Although the doors may help with parking in horizontally tight spaces, they are troublesome in vertically tight spaces. They may hit the roof in some garages, like this one. Even if the sensors prevented the doors to hit the roof, the back passengers may have trouble getting out through the half-open doors.

Indeed they are easier to open in horizontally tight parking spaces. But, how often do you park in such tight spaces? If that happens, can’t you just drop off the back passengers before pulling in? Can’t sliding doors provide the same benefits?

Mazda5, 2011

Manufacturing and maintenance

falcon-wing-door-machineryThe machinery of these doors is overly complicated. They are difficult and expensive to manufacture, prone to mechanical problems, and difficult to repair. Take a look at the news, and see how a legitimate supplier of hydraulic lifters to other famous brands (such as Cadillac) failed to meet the Falcon Doors’ ridiculous requirements.



Because the Falcon Wing Doors’ complexity, it increases the center of gravity of the car. This decreases the stability of the car and cornering abilities. Also when parking on uneven ground, the high profile of the doors make the car unstable.

Not beautiful or fancy

With this novel door design, the Model X doesn’t really look beautiful, friendly, or fancy. It looks like a Prius. It’s nowhere close to Ferrari, Lamborghini or McLaren. Notice that the “scissor doors” of the hyper cars don’t really have some of the problems of Model X’s Falcon Wing Doors.


The Model X (with the doors open) looks like a falcon, ready for an aggressive move. Not feeling friendly.

With these in mind, and the fact that Space X’s rockets are named “Falcon”, the Falcon Wing Doors feels more like an gimmick and over-engineering than a useful/beautiful design. There really is no need to make car doors looking like falcon wings.

Comments Off on Why “Falcon Wing Doors” is a bad idea

Posted by on January 20, 2016 in car, design


Some observations about Tesla’s Autopilot


After analyzing Tesla Model S’s various design problems, I was shocked again, this time by a popular video, showing Tesla’s autopilot nearly causing a frontal crash.

Some observations:

  1. Autopilot sees tree shadows on the ground, and mistaken them as obstacles. This may not be a right kind of road to use the autopilot, but in principle this could happen even if you are on a high way with trees or some other shadow-casting objects, such as clouds. The failure of distinguishing shadows from objects suggests that Tesla hasn’t done basic computer vision research, specifically, a subject called “image shadow removing”. I’m also doubting whether the autopilot uses stereo vision or colors at all.

  2. When seeing the tree shadow, autopilot tried to avoid it as if it were an obstacle. It didn’t brake (the speed remained at ~38mph). It steered the car to the left, trying to cross the double yellow line, nearly causing a frontal crash with an upcoming vehicle. This shows that the autopilot hasn’t ideas about basic road rules and correct emergency strategy. An experienced driver would brake instead of averting the obstacle without slowing down.

There should be no public “beta testing” on such mission critical software. It needs to be perfectly safe before it can be released. Nobody wants to test such software with their lives. Putting complicated “warnings” or “conditions” on the software license, calling it “beta” and asking users to keep a hand on the steering wheel, can’t really get Tesla out of liability if someone is actually hurt.

Comments Off on Some observations about Tesla’s Autopilot

Posted by on January 16, 2016 in car, design


Design Flaws of the Tesla Model S


Many people admire Tesla cars. They think it is the car of the future. Although electric cars are environment-friendly, quiet and performant, I found the design of Tesla’s Model S particularly awkward and user-unfriendly, with potential safety problems.

Lacking physical controls

A major design problem of the Model S is that the designers put too much faith in the touch screen. There are so few physical controls. Almost everything is controlled by the touch screen. Take a look at the interior, it is almost bare. This hurts both the esthetics and functionality.

There is no switch on the dome for operating the sunroof (see picture). When people see a door or window, they expect a switch right next to it. Not the case with the Model S. You look up from the seat, and there is nothing you can press…


This “simplicity” comes with a cost. How do you open the sunroof? Answer: from the touch screen. You just tap the Control tab on the top, then tap the Sunroof tab to the left, and then you tap and hold a slide bar on the right, drag it down…


But this is not really simple. It just makes simple things complicated. It violates a very important design principle: Controls should be close to the objects that they control, and should be natural for people to discover and intuitive to use. The touch screen controls too many objects. It is overly multiplexed in functionality. It is nowhere close to the object it controls, and there is a deep path for finding the menu items. All of this makes the car confusing and cumbersome.

Compare with other cars, they usually have a dedicated switch for the sunroof, right there above your head. You pull it back and it opens the sunroof. You push it forward and it closes the sunroof. You push it upwards and it tilts the sunroof. The control is easy to discover, direct to access, and intuitive to use. Designers call this kind of design “natural mapping”, because the motion of the controller naturally corresponds to the motion of the sunroof.

Similarly in the Model S, there is no physical dial for the vent air, no physical switches for the head lights, fog lights, ambient lights, … You have to use the touch screen for all of those.

Central point of failure

From a system designer’s perspective, the Model S has a central point of failure. Because the touch screen controls almost everything, if it fails, you lose control of pretty much everything: sunroof, vent, door handles, windows, …

This indeed happened to some Tesla users. Take a look at this article. To quote the most important part of it:

“Just before the car went in for its annual service, at a little over 12,000 miles, the center screen went blank, eliminating access to just about every function of the car…”

Ergonomics not well thought out

I also noticed that when I sit back in the driver’s seat, the touch screen is not quite within my arm’s reach. I have to sit up a little and reach my right arm out. Because the screen lacks tactical feedback, you must look at it in order to trigger the correct button. This is not efficient or comfortable, and may not be safe when driving.

There is also a space-utilization issue. Underneath the touch screen, there is a flat surface.


This is the usual place where other cars put the shifter, coffee holder and utility compartments. For the Model S, it’s just a flat, wide-open space. If you put small objects in it, they will fly around, collide with each other, making noise as you drive. The platform’s position is so low, that you have to bend over to get things. This is a waste of the most ergonomically convenient space in the car–the space right under the occupant’s arms at a comfortable sit position.

Some users also reported that the coffee holder of the Model S are placed at a diabolical location, making it easily for the elbows to knock over the coffee cups. Thus some expert user DIY’ed his own coffee holder using a 3D printer…


Troublesome door handle

The Model S has a very special door handle design. At its rest position, the door handle retracts, flushing with the door surface.


As the driver walk close, the door handle extrudes, like a friend extending his hand, for a handshake.


Emotionally this is a nice design, but practically there are problems.

  • The shape of the door handle is a flat metal plate. This is not ergonomic or comfortable.
  • In cold weather, the door handle will be frozen in ice and not be able to extend. In this situation, you will not be able to open the door!

There have been discussions how to take care of the door handle in cold weather. Solutions includes:

  • Remotely start the car. Melt the ice with internal heat.
  • Pour hot water on the door handle.
  • Put hot water bag on the door handle.
  • Use a hair dryer.
  • Put a packing tape on the door handle. Peel the tape off to remove ice.

Now, maybe you have understood, why no other cars, from the cheapest to the most expensive, use this door handle design?

Reliability issues

Despite of its high price, the Model S has more than its share of reliability problems. Reports are saying, because of power system failures, two thirds of the early Model S cars can’t outlive 60,000 miles. Consumer Reports rated Tesla Model S “the most unreliable EV”.

Safety problems


On Jan 1 2016, a Model S caught fire for no obvious reason at a supercharge station in Norway. Firefighters were not able to put off the fire with water. They covered the car with a special foam and waited the car to melt down.

This is not the first Model S fire incident. There were already three such incidents. As compared to gasoline cars on fire, this is indeed a small number, but the reason why they caught fire is more mysterious. There doesn’t need to be accidents. The Model S can just start to burn mysteriously in your garage!

Unlike Elon Musk’s claims that Model S is very safe, the fire incidents should be taken seriously. Lithium batteries are known to be a fire hazard. Take a look at the fire incidents of the Boeing 787 Dream Liners and see why Model S fires shouldn’t be taken lightly.

Safety issue of the autopilot

Please refer to my new post on this issue.


Comments Off on Design Flaws of the Tesla Model S

Posted by on December 11, 2015 in car, design


Indentation-based syntax considered troublesome

Although the idea of layout syntax—using whitespace characters to delimit blocks—has been promoted by several languages (notably Python and Haskell), I think this kind of syntax brings more trouble than benefits.

It takes just one keystroke to produce a serious bug

In most languages a program’s format is determined by its meaning, but in a language with layout syntax, its meaning is determined by the format. This makes programs in layout syntax fragile because a tiny change in format could result in a serious error. For example, consider these two Python programs:

# correct definition
def member(x, ls):
    for y in ls:
        if x == y:
            return True
    return False         # correct indentation
# incorrect definition
def member(x, ls):
    for y in ls:
        if x == y:
            return True
        return False     # incorrect indentation

The second definition has been “derived” from the first by an inadvertent TAB key, which indented the return statement one more level to the right. While the two definitions differ only in one indentation, they produce totally different results.

Although this is just a minimal example, the bug may take quite some time to show up and be fixed. In order to prevent this kind of bugs from happening, I often find myself moving the cursor up-and-down in a straight line to check the alignment of the statements.

Let’s see why this bug cannot happen in a language which does not use layout syntax. We now invent an alternative syntax for Python, so that the pervious program looks like:

def member(x, ls) {
    for y in ls {
        if x == y {
            return True
    return False

Given the correct definition, can you imagine how you could reproduce the bug with just one keystroke? It is almost impossible. To see why:

  1. The return statement can never get into the loop with a change in indentation.
  2. It takes at least two edits and one movement in the editor to move the return statement into the loop. There are two alternatives to choose from:
    • Cut return False. Move the cursor into the closing curly brace of the for-loop. Paste.
    • Delete the closing curly brace of the for-loop. Move the cursor beyond return False. Insert an closing curly brace.

Either way, you must be deliberate and precise in order to reproduce the bug. Otherwise the parser would have complained (for example, if you just delete a closing curly brace).

However, the situation is very different with layout syntax, where one TAB key press produces the same amount of change as the above three operations. The change happens quickly and the program remains grammatically correct, obscuring the presence of a bug.

The situation is a little better for Haskell, because incorrect indentations often cause type errors and the programmer will be alerted, but fundamentally the problem still exists.

Unconvincing advantages

It is often claimed that layout syntax has the following advantages over curly braces:

  • Your programs become a lot shorter because less curly braces are used.
  • You write less clutter such as curly braces and semicolons, and that beautifies your code.

I found that neither of the two advantages convincing. For the first part, Python and Haskell programs are indeed several times shorter than equivalent Java or C programs, but this cannot really be creditted to layout syntax.

We need to have some blank lines even in a Python or Haskell program, between definitions and sometimes in the middle of a block. The blank lines naturally denote groups of statements. So if we count the number of additional lines introduced by curly braces, we will find that there aren’t many. Curly braces also naturally denote statement groups, so not only they don’t look bad, they are helpful.

In Python and Haskell, it is the semantic features (pattern matching, first-class functions etc.) that make the programs short, not layout syntax. If we had an alternative syntax of Java which uses layout, then Java programs would still be several times longer than equivalent Scala programs. Java programs are longer not because they use curly braces, but because they don’t have things such as first-class functions, so they have to use some tedious design patterns.

Second, layout syntax does not really save “clutter”. Even in a language with layout syntax, we may still need to write almost the same amount of (if not more) clutter. The following is a random piece of code taken from the current release of GHC. We can still see lots of curly braces and semicolons in it. I guess layout syntax actually caused trouble, so the authors of GHC decided that they will just write curly braces.

tcInstanceMethodBody skol_info tyvars dfun_ev_vars
                     meth_id local_meth_id
             meth_sig_fn specs
                     (L loc bind)
  = do  {       -- Typecheck the binding, first extending the envt
        -- so that when tcInstSig looks up the local_meth_id to find
        -- its signature, we'll find it in the environment
          let lm_bind = L loc (bind { fun_id = L loc (idName local_meth_id) })
                             -- Substitute the local_meth_name for the binder
                 -- NB: the binding is always a FunBind

    ; (ev_binds, (tc_bind, _))
               <- checkConstraints skol_info tyvars dfun_ev_vars $
          tcExtendIdEnv [local_meth_id] $
              tcPolyBinds TopLevel meth_sig_fn no_prag_fn
                 NonRecursive NonRecursive

        ; let full_bind = AbsBinds { abs_tvs = tyvars, abs_ev_vars = dfun_ev_vars
                                   , abs_exports = [(tyvars, meth_id, local_meth_id, specs)]
                                   , abs_ev_binds = ev_binds
                                   , abs_binds = tc_bind }

        ; return (L loc full_bind) }
    no_prag_fn  _ = []      -- No pragmas for local_meth_id;
                        -- they are all for meth_id

Better ways to save clutter

Even if we do hate curly braces, there are better ways to reduce or even completely eliminate them. For a trivial “solution”, we could just use a dim color for curly braces and semicolons in the editor, so that they are less noticeable.

Better still, we could use a structural editor that lets us manipulate the AST (abstract syntax tree) directly. Those editors could provide several options of denoting blocks. You can switch between colored blocks, curly braces, or nothing at all. You can switch the look of your code at any time, instantly. People have implemented such editors, for example this editor designed by Kirill Osenkov.

Re-indentation hassle

In a language that doesn’t use layout syntax (Java, C, Scheme, …), no re-indentation is really needed when the code changes. The programmer can move a block of code by a simple copy-and-paste and continue solving the real problem. Re-indentation can always be done later and can be done automatically.

But in a language that uses layout syntax, re-indentation is mandatory, and worse, it can only be done manually. Layout syntax completely disables any editor’s auto-indent function. One may think that we might be able to invent a smarter editor that can auto-indent code for those languages. This is simply impossible. This is evident in the analysis of the above example. The two programs differ only in indentation, but they have completely different meanings. Both are grammatically correct programs and the editor has no way to tell which is the one you want unless it can read your mind.

Some people say that because those languages have advanced semantics, programs are so short that we don’t need to re-indent code very often. But experiences prove to me that the need for changing and rewriting code can never be eliminated. Writing code is like writing a book, you can always find pieces that need change or even complete rewrite. Usually changes in the following category will cause re-indentation:

  • Scope changes. There are lots of examples in this category: lifting an internal function to top level or push a top-level function into an internal function, surrounding a block with let-bindings, loops, conditional statements, try-except or lifting a block out of them, factoring out duplicated patterns, lifting “invariant code” out of recursion, … to name a few. These will necessarily change the indentation of a block of code, and each line needs to be re-indented.
  • Align code. For example in Haskell, when we align the arrows (->) of a case expression or the equal signs (=) of a function definition, we will notice that we have to re-indent most of the right-hand-sides, because they often contain multi-line expressions but the editors (for example, Emacs’ align-regexp function) only move the lines that contains the arrows or equal signs.
  • Renaming. We seldom choose the best names on the first shot, and good names make programs self-explanatory, so renaming is a very important and commonplace action. But in the following simple Haskell program, if we change the name from “helloworld” to “hello” and don’t re-indent the rest of the lines, we will get a parse error.
    helloworld z = let x = 1
                       y = 2 in

    Because the code becomes the following after the renaming, and the second line will no longer be aligned to “x = …”, and that confuses the parser.

    hello z = let x = 1
                       y = 2 in

    A similar thing happens when we lengthen the name to something like “helloworldcup”. Try it yourself. From this example, I hope you see how simple things are made frustratingly complicated by layout syntax. If you haven’t been convinced, try adding more lines to the above let expression.

The interruption from re-indenting code is usually not just one or two seconds, but often tens of seconds, even minutes. The programmer has to put down real problems at hand and turn to the mind-dead re-indenting job. This disrupts the “flow”, which is essential for producing creative and elegant code.

Layout syntax considered harmful

I believe that syntax, although an important aspect of natural languages, should not play a significant role in programming languages. It has already brought us too much trouble and frustration and wasted too much of our energy.

Syntax has prevented lots of new design possibilities in programming languages. You may have heard language designers say: “Hey this is a nice feature, but the syntax of my language hasn’t any room left for it.” Layout syntax pushes to this direction even more. It forces us to consciously and constantly think about syntax, drawing our attention away from semantics design. It poses certain constraints on how code must be formatted, and makes a language even less extensible. Thus I think layout syntax is the most troublesome type of syntax.

Comments Off on Indentation-based syntax considered troublesome

Posted by on May 8, 2011 in design, programming languages, syntax