Follow up to "The Unreasonable Effectiveness of C" - <AUTHOR> http://damienkatz.net/2013/01/follow_up_to_the_unreasonable.html <comment><USER2> > I used C++ inheritance, templates, exceptions, custom memory allocation and > a bunch of other features I thought were very cool at the time. Now I feel > bad for the people who have to maintain it.

I think this is right on the money. There are a lot of things you _can_ do with C++ (and other languages -- even C probably) that feel good at the time, only to learn later that they don't age well.

I've never seen it analyzed deeply why this is, but I suspect it has something do with how "fungible" the code is when you're done. Will your design let you make small design changes with relatively small and localized code changes, or has your complicated template/inheritance-based design "locked up" your code into a particular pattern, where changing any of the design assumptions requires "unwinding" a highly intertwined structure?

I don't know the rigorous answer to this question, so I design with various heuristics, which mostly boil down to some version of "this is getting a bit too complex or too highly leveraged." What I mean by "leveraged" is that some significant guarantee or invariant is achieved through a complicated contract between two different objects. I try to keep the design of every individual type/object as "flat" and unsubtle as possible; again vague terms, but I know it when I see it.

<comment><USER3> This is like insisting on driving around in a horse-drawn buggy because a car can crash at higher speeds. At this point I just ignore anybody trashing C++ that isn't offering any real alternatives. And no, C isn't an alternative for large scale app development.

<comment><USER4> Who gets to decide what qualifies as a "real alternative?" I have seen much larger applications written in Java than in C++; does that make Java a "real alternative?" C++ does not really have any technical advantages over "true" high-level languages (i.e. languages that don't force the programmer to deal with low-level details and whose support for low-level operations does not constrain high-level features), but it has plenty of disadvantages. Meanwhile, I cannot think of anything people do in C++ that I am unable to do in Lisp, although I can think of plenty of things people do in C++ that are unnecessary in Lisp and that only serve to make code more complex and more error-prone.

So there, you have two "real alternatives:" Java and Lisp. I'll also throw in Scala (basically it's what Java should have been to begin with) and OCaml. So what are you doing in C++ that could not be done in any of these languages?

<comment><USER5> > I cannot think of anything people do in C++ that I am unable to do in Lisp

The biggest technical advantage I've noticed C++ having over other languages is that library performance characteristics are documented as part of the portable language spec. I really miss that when I switch to other languages and have no idea if the builtin list class acts like a linked list or a vector or a deque or what.

Knowing that the algorithm you just built out of library components doesn't have a n^3 blowup on some platform is a correctness issue, not a premature optimization. I'm more comfortable that's not going to happen working in C++, and the culture and libraries around it than anywhere else.

Does CL specify that, as part of the specification and not just by convention? I'm having a hard time finding docs to that effect but I don't use Lisp enough to know where to look.

<comment><USER6> When I was doing heavy common lisp work, this was just a non-issue. If I wanted to understand how a library call would perform, I'd just press the magic button in SLIME to jump to the source code of the library routine and look.

This was much easier than manually tracing through the layers of template and preprocessor indirection underlying even simple STL constructs.

It is possible that this sort of standardization was vitally important given the incredibly poor quality of C++ implementations traditionally available, but in languages with better communities with higher standards for implementations and documentation, this really seems like a solution in search of a problem.

<comment><USER7> _"If I wanted to understand how a library call would perform, I'd just press the magic button in SLIME to jump to the source code of the library routine and look."_

That tells you how your implementation works. It tells you nothing about how other implementations (or the next version of your compiler) do things. The point is that, with C++, the standard proscribes the O(...) of algorithms.

Yes, implementations can and will be broken, but given that writing a C++ compiler requires planning, I think it is unlikely that 'wrong choice of algorithm' will make it into any deliverable (counterexamples welcome)

</comment></comment></comment></comment></comment></comment><comment><USER8> I hated and feared C for years. Then I finally learned it and fell in love with it. Now other languages seem like too much work. I'm only a hobby programmer so that devalues my opinion somewhat (insofar as I don't have to support large production systems or please committees), but one of the things I love about C is that once you have something working in C, you're likely done - if you need to go faster or better, then either your understanding of the problem or the algorithm you're employing is flawed, or maybe you need to do some bits of it assembler (DSP for example).

The other thing is that even though C is old it still work great. I don't know how you web guys keep up with so many 'frameworks of the month' and so forth. I took up C mainly because I was tired of things becoming obsolete before I had got around to learning them properly.

<comment><USER9> One of the greatest things about coming back to C from years of Ruby is that you can constantly tell yourself "I don't need to worry about performance because there's no way what I'm doing here could be worse than what Ruby was doing for me". It's hard to fully articulate the feeling but it's great; it's like a cure for premature optimization.

<comment><USER10> Is it possible to need C and not know it, or if I need it will I know it? Because I can't think of anything I'd use it for. You guys speak of it and other higher level languages as if you use them interchangably for the same tasks.

<comment><USER9> I use Ruby for things that deal with the web, for utility programs, and (most often) for software I'm not going to need to support long term, such as clients for bizarro network protocols I encounter on penetration tests.

I used to use C for everything else; I'd reach for Go first now, but I still love C.

One way to think about C vs. (say) Python is that it's like the relationship between an FPGA and an ASIC: you prototype in a high level language and you write C when you _really_ know _exactly_ what you need your program to do. C is not a great exploratory programming environment, but it is excellent when you have a specific plan.

<comment><USER11> And this is what I don't really understand. Python or Ruby are excellent in the domain you talk about, but I would always, always reach for C++ over C if given the choice. The C++ standard library for me alone makes this such a simple choice. A lot of C code to me just looks horribly ugly these days - stuff like:

      int compare(const void *a, const void *b)
      {
          return *((int*)a) < *((int*)b);
      }

Yuck.

<comment><USER9> On the other hand, the mechanism by which that code works is simple to understand and keep in your head at all times, and isn't inelegant. I find that very valuable.

<comment><USER11> Except it has absolutely no type safety whatsoever. With modern-style C++, you can do the same thing in exactly 1 line:

      std::sort(begin(array), end(array), [](int a, int b) { return a < b; });

Versus:

        qsort(array, MAX_VAL, sizeof(int), compare);

With compare as defined before. I mean, sure, it's just sorting and it's a tiny example, but to me it shows a lot about why I prefer C++ over C: typesafety, readability, reduced possibility of buffer overflows, reduced possibility of segfaults based on incorrect element access, speed thanks to code inlining vs function pointers...

<comment><USER9> I've coded in C since 1993, shipped commercial systems C code from 1996 through ~2004 (with an 3-year C++ interlude in there), and continued to write C code on projects from then today. In that time, the number of bugs I've dealt with due to the lack of type safety on a void* is: zero.

Lest you think I'm being cavalier about this, I've been writing professional Ruby since ~2006, and have since then been routinely aggravated by bugs that would have been mitigated by type safety. I buy type safety. But it's a continuum of value, not a core principle of development.

In idiomatic C code, void* is a way of dropping in and out of static typing, usually to pass values of arbitrary types to a generic container library or through a callback. The use of void* doesn't surrender type safety throughout the program. Idiomatic C code casts a specific type to void* at the call site of the function that handles generic types, and casts it back to that specific type the moment that library hands it back.

Of the arguments C++ devotees marshall against C, I find this one among the fudliest.

<comment><USER11> I guess we'll just have to agree to disagree then. Perhaps you are a far more conscientious programmer than many out there; the number of buffer overflow exploits would suggest so. C++ doesn't make you immune to such things, but it does give you the tools to make such things less likely to occur. Further, I like compiler-enforced type safety. For when C was created, utilization of void* was a brilliant idea. Language design has moved on since then, and as much as many people really hate template-based C++ code, I honestly welcome it in comparison.

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER12> I've recently realized that--at least to me--C is actually very much like Prolog. How? Well: Prolog is a fairly simple, Turing-complete language. For the things it's good for, it's _great_. But those things are few and relatively specialized. I _could_ use Prolog for general-purpose programming, but I wouldn't want to. With Prolog, the question is always "why Prolog?" rather than "why not Prolog?". Sometimes there is a good answer to this, but usually there isn't. I can also get some of the benefit by using a DSL embedded inside a more general-purpose high-level language.

I've thought this for a while, almost ever since I learned Prolog. Make no mistake: I actually rather like Prolog. But I haven't been using it very much. The recent revelation is that C has all the same characteristics. And in a similar way, while I still like C to whatever extent, I'm going to avoid using it unless I really have to.

On a mostly unrelated note, I agree that Rust looks very promising. It's the new language that I'm the most excited about, especially after being let down by Go. Also, I'm not quite sure why he thinks the Rust syntax is odd: to me it seems extremely C-like, with some nice improvements (like implicit returns).

<comment><USER5> Out of curiosity, what are you hoping to get out of Rust that Go let you down on?

<comment><USER12> The best summary would be that I want a language to replace C++ but more sane and functional. Go is more like a language to replace Java and is most definitely _not_ functional.

Essentially, I don't see why I would ever use Go over Haskell or OCaml. The main areas where Haskell and OCaml are ill-suited are the lower-level ones currently dominated by C/C++ and Go does not seem to address those very well. The main areas Go is doing well, like server-side code, are _very_ well suited to Haskell and OCaml and so I have no reason to drop down to a less declarative language like Go.

Rust, on the other hand, seems to be targeting C++ directly. It also doesn't hate functional programming. So it perfectly fills the C/C++ shaped void in my current toolbox.

<comment><USER13> Go is a language for young programmers who were perhaps brought up on Java or Python, but have discovered the "cat -v" mentality and are drawn toward it.

Or alternatively, for old C programmers who are well versed in the 'cat -v' mentality who have tasted a bit of Java and Python but simply cannot buy into those.

<comment><USER14> Correction. The "cat-v considered harmful" mentality.

</comment></comment></comment></comment></comment><comment><USER15> Okay, say I'm gonna start using C more seriously: What library do I use for strings? Not fucking arrays of 8 bit characters. Real Unicode compatible strings with concatenation and comparison operations and all that good stuff. And if it works with a regex engine, that's nice too.

<comment><USER16> <http://site.icu-project.org/>

<comment><USER15> Hmmm....

> Strings are the most common and fundamental form of handling text in > software. Logically, and often physically, they contain contiguous arrays > (vectors) of basic units. Most of the ICU API functions work directly with > simple strings, _and where possible, this is preferred_.

Nope.

Though the UText API was promising... unfortunately, it is totally incomplete.

</comment></comment></comment><comment><USER17> I remember what scared me to death with C++ when I was using it with frequency was the potential to end-up with these horrible inheritance trees that could really bungle a project in so many ways. If you didn't take the time to really, really, really think through your class hierarchy you could really shaft yourself in a big way. Bacause of this, as life went on I started to really appreciate the idea of composition vs. inheritance.

For me C has always been an easy no-brainer go-to language to get things done, particularly so when performance was at stake. I've always thought that learning programming should start at the lowest possible level (yes, assembly), then move on to Forth, C and from there ideally Lisp before hitting Java for some OO love. With that kind of a foundation it's easy to learn and absorb just-about anything that comes your way.

<comment><USER7> _"I remember what scared me to death with C++ when I was using it with frequency was the potential to end-up with these horrible inheritance trees"_

I don't think you can blaim C++ for that. The time when 'we' hadn't learned the "composition over inheritance" lesson yet just happened to coincide with that of "let's write our framework in C++".

<comment><USER17> Maybe so.

</comment></comment></comment><comment><USER18> My thoughts on why C is effective:

Simple. An average C programmer can easily learn 90% of the language and use 80% on a daily basis. So C programmers can understand each other generally well. Although different projects usually have different styles, they are very minor differences.

Assembler friendly. You can link C code and assembler together with negligible overhead. Almost every performance demanding project has its busiest part written in assembler. Even though sometimes C is lack of a certain construct that you require, you can always implement it in assembler and connect it with C code (longjmp as a good example). Using assembler may seem to be contradictory to the first point, but remember only a handful of people need to work at such a low level, other people just use the C interfaces.

Reusable. C has a huge set of robust and portable libraries. Their authors are proven to be surprisingly disciplined.

However, we have to admit writing good C code is very hard. And I can see that less and less people will use it going forward. Steve Jobs' "trucks and cars" metaphor applies here too.

</comment><comment><USER19> If they would keep putting the extra effort in debugging the Erlang VM C code, the benefits of this debugging would be available to the entire community of developers using Erlang. Now they are in their small corner of the world and every bug they squash is just a bug of their project.

Overall it's worse for "the world" and better for them. This makes sense for commercial software but it's weird when you think about an open-source project. Just imagine if all the effort in porting Ruby/Lisp to Java/C++ or similar translations for big projects would have been invested in improving the VMs for these dynamic languages (yeah, most of these rewritten projects didn't have experienced C guys, but the OP certainly has and is one). _Is bug- fixing and hacking on compilers and VMs really that hard?_ (I never approached these problems in practice because I've never had to scale something that hard and squeeze that last drop of performance, so I'm really asking the question, it's not rhetorical).

</comment><comment><USER20> I'm with you 1000% percent here. The only language I ever encountered that could possibly have supplanted C was FORTH, and it was doomed by legions of Unix-trained C programmers once the hardware got good enough to support C.

<comment><USER21> What about Pascal? Seems like a simple, block-based language with the same functionality as C. Apparently, the only complaint against it is that its users like to eat quiche.

<comment><USER22> _"What about Pascal?"_

The type system, and control flow structures, were more strict and allowed less "abuse" (flexibility) than C. Strings were fixed-length arrays of chars, which was also less flexible than strings in C. Also people felt the begin-end block syntax less fashionable than C's {}.

Take a look at: <http://www.lysator.liu.se/c/bwk-on-pascal.html>

<comment><USER23> BWK's rant on Pascal is about as relevant today as a critique of original C (no prototypes, types defaulting to int, etc.).

In other respects (e.g. strong type safety) Pascal's approach "won", depending on your perspective.

</comment></comment></comment></comment><comment><USER24> I noticed that he didn't mention using some higher level scripting language on top of C. Is this an intentional omission?

<comment><USER25> I think it is covered by this part:

"If a big problem was C code in Erlang, why would using more C be good?

Because it's easier to debug when you don't lose context between the "application" layer and the lower level code. The big problem we've seen is when C code is getting called from higher level code in the same process, we lose all the debugging context between the higher level code and the underlying C code."

OT: My personal best experience with interfacing a higher level language with C from the debugging standpoint was a C+Lua combo, and even then it was far from optimal.

<comment><USER26> It's never optimal, and often, it's the source of truly infuriating bugs. Yet for all that, people don't say, "Hey, let's skip the middle man and just call libcurl or libxml or whatever _from C_. Because you know, these are _C libraries._ "

I think they don't do that because they've been told a hundred thousand times that C is for low-level bit fiddling, that manual memory management is impossible, that it's tedious and difficult to write, that it's a "systems language."

Honestly, if you haven't programmed in C since college, you should give it a try -- especially if you're on Linux. The tooling and library ecosystem of C is absolutely second to none, and there's an enormous community out there that consists of some of the smartest programmers you will ever meet.

I agree with you about C+Lua. I also notice that people who seriously do that are serious C hackers -- which, I suspect, is seldom the case with most users of Python and Ruby.

<comment><USER4> "The tooling and library ecosystem of C is absolutely second to none, and there's an enormous community out there that consists of some of the smartest programmers you will ever meet."

Conspicuously absent from this statement is, "the language features make you more productive," or, "smart programmers using this language are doing things people thought were impossible." The issue with C (and even more so with C++) is that the language features almost always work against you.

<comment><USER26> "smart programmers using this language are doing things people thought were impossible."

I think the fact that a great number of new, hip, who'd-have-thought-it-was- possible languages are written in C answers this one rather nicely. Not to mention hip new databases, hip new web servers . . .

"the language features make you more productive"

I think it's precisely this claim that is being called into question. I daily see new language features that strike me as literally marvelous. But when it comes to those features actually leading to increased productivity -- well, "ls /usr/bin" tells a different story about the productivity of people working in this language.

<comment><USER4> "I think the fact that a great number of new, hip, who'd-have-thought-it-was- possible languages are written in C answers this one rather nicely"

It's worth noting that writing a new language is not really something people think is "impossible." On the other hand, people take the languages that were implemented in C, and do things that nobody else thinks is possible -- things like logistics systems that save the military enough money in a few years to pay for the decades of research leading up to those systems. Sure, C is hiding underneath, but to claim that that means people are "doing things with C" is kind of silly (especially since there is no particular advantage to writing compilers or interpreters in C).

For what it's worth, this situation has been inverted: on Open Genera, there was a C compiler written in Lisp, and what it really did was to generate Lisp code from C code (i.e. it was "C-in-Lisp"). This had some interesting benefits e.g. C programs had a garbage collector in that system (the same as the Lisp garbage collector).

"when it comes to those features actually leading to increased productivity"

It is a matter of what you are doing. For example, I do a lot of work with boolean circuits (related to secure two-party computation, i.e. "theoretical crypto stuff"), and it is nice to be able to write something like the "x*y + z" and have that become this:

      (lambda (x y z) (or (and x y) z))

In C, what do I get? The macro system is not powerful enough to write a simple expression parser, I cannot overload operators, and there is no support for lambda expressions anyway. So instead of just worrying about the expression itself, what would happen in C (and I know this because at one time I was trying to write this code in C) is that I would have to implement a C function for each expression, spreading the code out and introducing new ways for things to go wrong (a second issue is that the values are not actually simple values; in C, this turns into a mess of pointers etc.). It is not that it is impossible, but I can say this: I am doing more now than I would have been doing in C, and I am not exactly new to writing C code (although the languages I programmed the longest in was actually C++; I am still perfectly comfortable with C, and to be honest I like C++ even less).

To be fair, this same argument applies to other high-level languages; Lisp is not exactly unique anymore in being very expressive, and other languages have things that Lisp is missing (like pattern matching, dependent types, etc.). My point is not that Lisp will change everything, though there seems to be a renewed interest in Lisp thanks to Clojure, but rather that high level languages absolutely do have a benefit. I suppose for most people, the easiest example is SQL: think about how you would write something as simple as an inner-join query if you could only use C (and then compare that to SQL).

<comment><USER26> _(especially since there is no particular advantage to writing compilers or interpreters in C)._

Do you _really_ believe there's no particular advantage to writing a compiler or an interpreter in C? Like, you could write it in Tcl or Perl or Ruby and it wouldn't matter?

<comment><USER4> I would not particularly want to write a compiler in Tcl, Perl, or Ruby; on the other hand, if I were free to choose, I would pick Lisp, ML, or Haskell over C for compiler writing any day. For what it is worth, I have written a compiler in C and I have written one in Lisp, and doing it in Lisp was far more pleasant.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER27> I like the way Alexander Stepanov, primary designer and implementer of the _C++ Standard Template Library_ (STL), decribed the _C Programming Language_ in an interview:

"Let's consider now why C is a great language. It is commonly believed that C is a hack which was successful because Unix was written in it. I disagree. Over a long period of time computer architectures evolved, not because of some clever people figuring how to evolve architectures---as a matter of fact, clever people were pushing tagged architectures during that period of time--- but because of the demands of different programmers to solve real problems. Computers that were able to deal just with numbers evolved into computers with byte-addressable memory, flat address spaces, and pointers. This was a natural evolution reflecting the growing set of problems that people were solving. C, reflecting the genius of Dennis Ritchie, provided a minimal model of the computer that had evolved over 30 years. C was not a quick hack. As computers evolved to handle all kinds of problems, C, being the minimal model of such a computer, became a very powerful language to solve all kinds of problems in different domains very effectively. This is the secret of C's portability: it is the best representation of an abstract computer that we have. Of course, the abstraction is done over the set of real computers, not some imaginary computational devices. Moreover, people could understand the machine model behind C. It is much easier for an average engineer to understand the machine model behind C than the machine model behind Ada or even Scheme. C succeeded because it was doing the right thing, not because of AT&T promoting it or Unix being written with it."

</comment><comment><USER28> I started out with Visual Basic about 10 years ago, as an introduction to programming it did it's job well. I then moved on to C/C++ as I started my MSCS. It was great for doing implementation of algorithms and image processing. Working relatively low level, optimizing for speed and handling garbage collection yourself.

As I started my professional carrer I went on to Java, and I've never looked back. The environment is great - I know how to implement algoritms and persistence-framework myself, but that's not what I'm getting paid for. There's always some high quality open source library/framework I can use. And sometimes when I need the "unreasonable effetiveness of C" I will interface with one of it's applications via JNI, I've done this several times: ImageMagick, ffmpeg, OpenCV, etc. I also onload a lot of the performance critical tasks to systems written in C/C++ like MongoDB, Redis etc. But Java can be fast as well, just ask Cassandra and Solr/Lucene.

Java allows me to get my job done, quickly and effectly. And to write well structured, understandable code that most likely will be understandable in decades to come.

</comment><comment><USER29> Of course the C language and compilers are so simple, and C sits at such a low level (right above assembly) that few things can go wrong in it (compiler bug) or under it (cpu bug). As people jokingly say, C is just a high level assembly language. If one tried to re-invent a language with C's properties, one would come up with C, again.

For these reasons, I too expect C to remain the most performant and reliable _high-level_ language baring any major change in computer architectures.

Debating this fact would be the same as debating whether assembly is the most performant and reliable _low-level_ language or not. Of course it is. (Preemptive reply to the doubter: as an example my 64-bit assembly implementation of MD5 is 75% faster that a 64-bit C implementation: <http://www.zorinaq.com/papers/md5-amd64.html> )

And of course, performance and reliability don't always need to be #1 priorities, therefore, as the author says, "most every popular language has uses where it's a better choice."

<comment><USER30> Computer architecture has already changed, with today's PCs having many logical processors. And indeed C lacks any direct affordance for parallelism. Good old pthreads are hardly adequate for many tasks compared to facilities in other languages. Yes, you can implement most of the needed features in C, but often without the grace or safety available elsewhere.

<comment><USER31> C11 adds thread and atomic op support: <https://en.wikipedia.org/wiki/C11_%28C_standard_revision%29>

</comment></comment></comment><comment><USER32> That is one hell of a résumé.

<comment><USER33> Definitely! Of course, argument from authority is still relatively weak in situations where experts disagree, and that's definitely the case with programming languages. We can each find our gurus -- Damien Katz, Rich Hickey, Rob Pike, John Carmack, Mike Acton, Slava Pestov are some of mine -- but there's no absolute truth in programming debates. The best we can hope for is to share interesting insights, motivate them as clearly as we can, and then agree to disagree, each biased by our distinct experience.

</comment></comment><comment><USER34> In academic circles, many struggle to understand why people are still using C for large projects, other than the special cases of operating systems, embedded systems, and code that must execute very quickly - e.g. within the gaming industry.

The main argument against using C seems to be that C is at too low a level of abstraction, which leads to low productivity and buggy code.

For example, pointer arithmetic might sometimes be useful, but it doesn't seem like something most developers should be exposed to anymore.

I have some sympathy for this argument, but wonder what others think?

\- The right tool for the job?

RS

</comment><comment><USER35> Interesting that among the other languages he mentioned one did not find Fortran or ML, which, I believe, were the go-to examples of C-beating languages in the discussion of the initial piece.

</comment><comment><USER36> His argument now seems to be that you have to use C for speed. In my experience that doesn't necessarily hold true anymore, given modern computer architectures and what JIT compilers are capable of. I have several times written something in a modern language and then convinced myself that I could get a large speedup if I instead wrote it in C, only to discover that the speed benefits were minimal at best and would require an exorbinant amount of exquisite hand optimization to increase further.

</comment><comment><USER37> Can't really argue with anything specific here, but this and the last article's general premise seems like, "if you have a choice, you might want to go with C for these reasons...". The problem is, I can't remember the last time I had any practical choice between C and a higher level language. I'd love to use C more, but the decision is almost always made for me by a client, or a useful framework/library that only exists in language X, or a platform, or a boss.

</comment><comment><USER38> >I don't know a lot of what's out there on the horizon, and there are some efforts to create a better C.

Are there any efforts to extend C to add very simple/light objects, and perhaps string handling?

<comment><USER39> C++ and Objective-C started with this goal.

Objective-C started as a pre-processor for C.

<comment><USER40> So did C++.

</comment></comment></comment><comment><USER41> It is so funny in these debates to see people always mixing languages with their default implementations, as if they were the only one available for the language.</comment>


WWII Propaganda Popularized Myth That Carrots Help You See in the Dark (2013) - <AUTHOR> https://www.smithsonianmag.com/arts-culture/a-wwii-propaganda-campaign-popularized-the-myth-that-carrots-help-you-see-in-the-dark-28812484/ <comment><USER4> It's fascinating how wartime propaganda assumes a life of its own. Another common myth spread by the English as a means of demeaning the leader of their then French enemy during the Napoleonic Wars was that Napoleon Bonaparte was short when in fact, and according to most contemporary descriptions, he was of average height. Yet to this day a cottage industry has been built around Napoleon's height that even persists to the present through our language - <USER2> "Napoleon Complex".

<comment><USER5> My understanding is that Napoleon was of average height for a peasant, but was short compared to well-fed officers.

<comment><USER4> I believe the consensus was that he was approximately 170cm (5'7") which was, contemporaneously, fairly average. There is a surprisingly large number of Google hits relating to why he was perceived to be short but none that offers a definitive answer. The most compelling is that he was constantly surrounded by large bodyguards which gave the public the impression that he was not tall.

<comment><USER6> > he was constantly surrounded by large bodyguards

This (and indeed, the Coldstream Guards more generally) appear to be a recurrent problem for French leaders:

[https://s-i.huffpost.com/gadgets/slideshows/237977/slide_237...](https://s-i.huffpost.com/gadgets/slideshows/237977/slide_237977_1211552_free.jpg)

</comment></comment></comment></comment><comment><USER7> Thread from 2017: [https://news.ycombinator.com/item?id=13690676](https://news.ycombinator.com/item?id=13690676)

And a nice weird carrot thread from 2009: [https://news.ycombinator.com/item?id=1191190](https://news.ycombinator.com/item?id=1191190)

</comment><comment><USER8> I don't think the article quite connects the dots.

As I understood it, it was mainly for homefront consumption, to encourage kids to eat their veg. Pilots are cool ergo they can make veg cool, so the theory goes.

</comment><comment><USER9> The article discusses the "victory gardens" which are quite interesting to me. Gardens I know of in the US zone 6 (without grow lights that help start the season early) are productive a few months of the year. Early spring you get leafy vegetables, but the bulk comes July/August and wanes in September. This schedule certainly doesn't seem like a major help in war time, so did they do something else? Preservation, better soil so food lasted longer,different planting varieties that produce spring - fall?

<comment><USER10> All food used to come from those growing periods. I think you grew certain kinds of tubers that could be stored over winter in a root cellar or made into preserves.

If you look at the picture on Wikipedia, potatoes and onions and carrots are prominent: [https://en.m.wikipedia.org/wiki/Victory_garden](https://en.m.wikipedia.org/wiki/Victory_garden)

That said I don't know the answer and I'd be curious what they did in winter in wartime.

<comment><USER11> Preservation is largely unnecessary. If a garden provides say 1 month of food for a family, then that family buys less food for that month. Being self sufficient was possible, but takes significant labor and land.

<comment><USER10> This sounds plausible, but....you couldn't just "buy" more food into the economy in winter. You had to store it somehow.

A victory garden would let other farms concentrate on more storable foods though, if the gardens accounted for greens in summer.

But actual victory gardens had storable foods, I think.

<comment><USER11> That was already happening.

Large scale agriculture was already set up to do long term preservation. People normally eat storable foods every month. Bread for example generally does not last long, but it's made from grains that could have been harvested 2+ years ago. Modern preservation methods can push that to 10+ years at minor cost.

That said, canning and other food storage was common. It was simply not a major focus of victory gardens. Otherwise the focus would have been on potatoes and other easily preserved foods not vegetables.

</comment></comment></comment></comment></comment><comment><USER12> My mother remembers getting lightly boiled potatoes which were let to cool, put on a stick, then sprinkled with sugar. (Korea in the 50's.) Unlike the little girls in the picture, she says she was delighted to get one of those.

With regards to WWII and night vision, the Imperial Japanese Navy (IJN) at the time had the most effective non-radar night fighting training and techniques. Some of the worst defeats dished out by the IJN to the USN were due to their excellent night fighting and an over-reliance by the US on nascent RADAR technology.

[https://www.youtube.com/watch?v=XWEEHOKcTnA](https://www.youtube.com/watch?v=XWEEHOKcTnA)

That said, the US radar-laid guns were a game changer. In some interpretations of the Battle off Samar, the US destroyers created such a high density of hits, that Vice Admiral Takeo Kurita mistakenly identified those ships as cruisers and mistakenly identified the whole group as much stronger, which ended up saving the landing force.

<comment><USER13> Radar-guided guns had the practical effect of doubling the firepower, due to more accurate shooting. This is an absolutely enormous advantage.

</comment></comment><comment><USER14> I heard the counter that Germany had ground based radar and would develop airborne radar later, so the propaganda was not helpful. Can somebody answer?

[https://en.wikipedia.org/wiki/Radar_in_World_War_II#Germany](https://en.wikipedia.org/wiki/Radar_in_World_War_II#Germany)

> In February 1943, a British bomber containing a H2S radar was shot down over > the Netherlands, and the 10-cm magnetron was found intact. In short order, > the secret of making successful magnetrons was discovered, and microwave > radar development started.

> In June 1941, an RAF bomber, equipped with an ASV (Air-to-Surface Vessel) Mk > II radar, made an emergency landing in France. Although the crew had > attempted to destroy the set, the remains were sufficient for the German > Laboratory for Aviation to discern the operation and its function. Tests > indicated the merits of such a radar, and Wolfgang Martini also saw the > value and tasked Lorenz to develop a similar system.

<comment><USER15> During the Battle of Britain (1940) the Brits used a radar network to track German planes and successfully concealed the existence of the network from the Germans (using the carrot propaganda and other means).

The stations of the radar network were a string of about a dozen wooden towers, each about 100 feet tall, situated along the east coast of Britain. If the German knew that they were radar stations, they probably would have destroyed them and prevented Britain from rebuilding them. Without the radar network, the Royal Air Force probably would've been destroyed in the Battle of Britain, and the Royal Air Force was the only thing preventing the Germans from invading across the English Channel.

So if it helped keep the Germans ignorant of the British radar network until the Germans gave up trying to destroy the Royal Air Force in September 1940, it was monumentally helpful regardless of what happened after September 1940.

<comment><USER16> > the Royal Air Force was the only thing preventing the Germans from invading > across the English Channel.

Apart from the Royal Navy, of course. I think the general consensus now is that Germany couldn't have sucessfully invaded the UK, even if it had won the Battle of Britain?

<comment><USER15> Naval ships are essentially artillery platforms that can reach 10 or more miles inland, but over the first 3 or 4 years of thewar the Royal Navy never dared to use these platforms against any of the coastlines (Norway, Northern France, Germany itself, Poland) occupied by the Germans except when they had to cover the evacuation of their Expeditionary Force at Dunkirk and except for a few small raids relying on the element of surprise. (What they did instead was to use subs to land commandos on the coast.)

And of course by D-Day the Luftwaffe had been mostly destroyed relative to what it was in 1940.

So, no, I tend to doubt that if the RAF had been destroyed, the Royal Navy could have prevented the German army from making a crossing of the English Channel.

<comment><USER17> > _Naval ships are essentially artillery platforms that can reach 10 or more > miles inland ...._

Naval ships also are just a bit useful for control of the sea; indeed, historically that's been arguably the foremost purpose of the navies of island nations such as the UK and U.S.

If the Germans had tried to invade Britain, the Royal Navy would have thrown in every last ship it had to attack the German troop transports in the Channel. (I'm paraphrasing Herman Wouk here.) The RN ships would have been extremely vulnerable to U-boat and E-boat attack there, of course (just as the U.S. Navy and RN are worried about in today's Strait of Hormuz). The RN would also have been vulnerable to air attack (as the British, U.S., Dutch, and Japanese navies learned at terrible cost in the Pacific War), especially if the Luftwaffe had previously gained mastery of the skies over the Channel. But as the saying goes, desperate times call for desperate measures.

<comment><USER15> If they had gained air supremacy over the Channel, the German's first move probably would've been to start shelling the southern coast of Britain using a low-value naval asset. If the Brits send in a warship to stop the shelling, attack it with the Luftwaffe. If the Brits don't send a warship, keep on shelling with the goal of preparing a segment of the coast for the landing of German troops.

The Luftwaffe had about 2600 planes in 1940 and the ability to build as many airstrips as they pleased all along one border of the Channel. What do you think the chances were of a British ship or task force's surviving a single mission into the Channel? I agree with what you're saying that the Brits would've been willing to risk their entire Navy to stop an invasion of the homeland (which BTW was the original reason for the creation of their Navy centuries ago) but would that have been enough? (And if they lost most of their Navy, would they have been able to continue to feed their population? Remember that the Brits were dependent on food from overseas.)

If some power wants to attack a US aircraft carrier, they face the formidable task of finding it first. On the open ocean this is very hard: during the Cold War, the Soviets deployed an _entire constellation_ of satellites for the sole purpose of locating US carriers in the North Atlantic (then transmitting the location to their submarines and long-range bombers). I mention this because the reputation for awesomeness earned by the British Navy before WW II was earned mainly in unconfined waters; against air power and subs, it is much less powerful in the confined waters of the Channel.

Also, look what happened to the British Pacific Fleet the next year when it dared to sail within range of Japanese aviation assets. And I think that happened in unconfined waters.

<comment><USER18> Check out this actual war game they conducted in 1974 where they concluded that the invasion would have been a resounding failure.

[https://en.wikipedia.org/wiki/Operation_Sea_Lion_(wargame)](https://en.wikipedia.org/wiki/Operation_Sea_Lion_\(wargame\))

<comment><USER19> That says they assumed a Germany with no air supremacy yet.

<comment><USER18> Based on the simulations they ran according to historical data, they concluded that the Germans would have thought they had air supremancy even if that was impossible, even with the Germans continuing to bomb RAF bases long after they switched to cities.

Honestly, I figured the GP would get a kick out of reading about a hypothetical war game of the scenario they envisioned.

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER20> Relevant QI part: [https://youtu.be/0PzNDMCT0rg?t=1495](https://youtu.be/0PzNDMCT0rg?t=1495)

EDIT: Actually, a better relevant QI part: [https://youtu.be/7Quyte7zN70?t=228](https://youtu.be/7Quyte7zN70?t=228)

</comment><comment><USER21> The last image of Disney carrot characters is absolutely terrifying.

</comment><comment><USER22> Britain was really good at running propaganda during WWII. I once read how they used radio to change the public support and opinion about Iranian King (Reza Shah) by telling fake and often scary stories about how he treated his people because he wasn't taking a side on second world war and Iran was neutral. After running the propaganda British and the Soviet invaded Iran to secure their oil fields as supply lines for allies and they replaced the king easily.

<comment><USER23> Can anybody explain to me how British & France culture felt about colonialism post-WWII? Especially for France, I would have expected that "being invaded and exploited by a foreign nation" would suddenly take a completely different moral outlook, but no, they resist Algeria separating. Why?

Semi-relevant Wikipedia:

 _When Britain reached out to the US asking for help in the war, the US offered help contingent on Britain decolonizing post WW2, and that agreement was codified in the Atlantic charter. The decolonization of Britain (post war) also meant that US and other countries would possibly have access to markets to sell goods that were previously under British Empire-which was not accessible to them then[86][87] To bring about these changes, the establishment of UN following World War 2 codified sovereignty for nations, and encouraged free trade. The war also forced the British to come to an agreement with Indian leaders to grant them freedom if they helped with war efforts since India had one of largest armies.[88] Also, following WW2, it was untenable for British to raise capital on its own to keep its colonies. They needed to rely on America and did via the Marshall Plan to rebuild their country._

<comment><USER24> It's always different when YOU'RE the colonizer/invader bringing civilization.

The French tried harder than almost anybody else to maintain their colonial empire. The Vietnam war would have been several orders of magnitude less likely to have happened if France just granted French Indochina independence.

The independence of Algeria was also extremely traumatic for France (De Gaulle was almost assassinated by Pieds-Noirs (white french born in Africa)). It's a fascinating story that involves storied history that gets ingrained into your culture. Keep in mind, Algeria was a full department of France (but the nonwhites had less political power), so it'd be a lot like a state or province leaving in other countries. You might very well think it'd be disastrous socially and economically, not to mention absorbing the people who wanted to remain part of the country it's leaving (which is what happened, a lot of bitter french whites and natives headed to France, but never felt truly at home). It's best to just read up here: [https://en.wikipedia.org/wiki/Algerian_War](https://en.wikipedia.org/wiki/Algerian_War)

The British _wanted_ to keep their empire, but they were broke after the war. There were some futile attempts to keep what they had left (see the Suez crisis), but it rarely panned out. Most attempts at managed decolonization resulted in white minority-declared independence in places like Africa (See Rhodesia and South Africa).

There were several other attempts to maintain their colonies by more minor European powers that were invaded during the war as well, such as the Dutch (Indonesia), and Belgium (Congo).

<comment><USER25> And the US involvement in Vietnam independence was closely tied to the US _needing_ France for a united NATO front against Russia (at least in the beginning). Without US support for keeping IndoChina, France was threatening to not be a part of NATO.

So when someone tells you "This was happened because of X", you ignore what they say as these conflicts are _always_ complicated and have a long history.

</comment></comment></comment></comment><comment><USER26> FWIW, severe vitamin A deficiency _does_ harm eyesight. But past a certain healthy level it doesn't help.

<comment> GuB-42 Same idea for vitamin C.

Vitamin C deficiency cause fatigue but eating large doses of vitamin C won't help you stay awake. In fact, it is unlikely to do anything at all, you will just piss all the excess off.

<comment><USER27> Vitamin A is actually worse because it is fat soluble, not water soluble like Vitamin C. If you consume too much Vitamin A, you don't pee it out, it gets stored in your fat cells. And because it stays in your system it can build up to toxic levels and you get hypervitaminosis.

Fun fact, there's a drug to treat severe acne called Accutane (isotretinoin). It's really for the severe cases of acne, because there are a ton of side effects (see [https://en.wikipedia.org/wiki/Isotretinoin#Adverse_effects](https://en.wikipedia.org/wiki/Isotretinoin#Adverse_effects) ) and if you get pregnant while on it there will be severe birth defects. Anyway, this drug is a retinoid, which means it is essentially just large doses of vitamin A.

<comment><USER28> > If you consume too much Vitamin A, you don't pee it out, it gets stored in > your fat cells. And because it stays in your system it can build up to toxic > levels and you get hypervitaminosis.

Not long back I heard about this happening to a small child.

Apparently, he and his mother had immigrated to the United States from - <USER3> - a former Eastern European country. She didn't speak english, and wasn't familiar with certain customs and such here, so when one day they went inside a CVS or Walgreens, when her son asked her for some gummy candies, she purchased a bottle of such for him.

Well - you can see where this is going.

The woman had no idea that such candy here in the US wasn't sold in bottles, and that what she had purchased was gummy vitamins. Her son ended up eating the whole bottle. Over a couple of weeks or so, she ended up getting him multiple bottles which he ate, until he became sick and she took him to the hospital.

From what I recall, the doctors treating him weren't sure what was happening, because they had never seen the symptoms or such - but ultimately they figured out what happened, and treated him for hypervitaminosis. He survived and is supposedly ok condition today.

Sadly I can't find the original article I read, but it was over a year ago, IIRC. My details may be wrong, but the overall gist isn't from what I recall: That a new immigrant mother to the US, who didn't speak or understand English, purchased what she thought was candy for her child and it turned out to be vitamins which caused an overdose where she had to take him to the hospital.

<comment><USER29> [https://www.youtube.com/watch?v=mZ6nREONy_4](https://www.youtube.com/watch?v=mZ6nREONy_4)

</comment></comment></comment></comment></comment><comment><USER30> An earlier discussion 2 years ago:

[https://news.ycombinator.com/item?id=13690676](https://news.ycombinator.com/item?id=13690676)

(No, not a dupe, link given for interest purposes.)

</comment><comment><USER31> I thought that was something Minecraft came up with</comment>


U.S. seizes $800k shipment of Xinjiang products made with human hair - <AUTHOR> https://www.axios.com/us-china-forced-labor-products-human-hair-69da26c5-2d01-4bad-a2b2-8c944f6d0a70.html <comment><USER2> I wonder what DNA testing of the hair would turn up. In fact, I wonder if they've already tested samples and that's why they are making such an extraordinary claim.

<comment><USER3> To test it, you'd need DNA from a sample of detainees, I doubt they have that.

It's pretty suspicious though, 800k worth of human hair? It disgusts you, I hope.

In other news, President Trump agreed with Chairman Xi that his concentration camps were "the right thing to do" as long as Xi continued to buy soybeans from American farms!

Art of the deal!

</comment></comment><comment><USER4> Are they trying to imply that the hair itself comes from Xinjiang prisoners or just that the wigs are made by forced labor ?

</comment><comment><USER5> > "If this highly suspicious, 13-ton shipment of human hair indeed turns out > to be linked to the Uighur concentration camps, then this is a new low — > even for the Chinese Communist Party — and they will have to answer to the > world community for their actions," National Security Council spokesperson > John Ullyot tells Axios.

> Numerous female survivors have said women's heads were shaved when they were > admitted to the camps.

I don't even know what to say about this, if it's true.

<comment><USER6> It didnt bother american companies all that much 80 years ago [https://www.grunge.com/111619/companies-ties-nazi- germany/](https://www.grunge.com/111619/companies-ties-nazi-germany/)

<comment><USER7> And slavery didn't bother people 200 years ago. What is your point?

</comment></comment></comment><comment><USER8> I was honestly imagining a sweater or something...</comment>


Ask HN: Do you use Docker in production?  At scale? - <AUTHOR>

Most of the praise I've heard about Docker thus far has come from developers.  But what happens after the images have matured past the development stage and are ready for production?
I'm interested in hearing from Docker users who are putting it into production, both in cloud (virtualized) environments as well as bare metal.  What are the benefits?  What problems have you run into, and what solutions did you devise?  How are you doing day-to-day management and performance analysis?
When answering, if you could tell me the scale at which you've implemented them in production, that would be helpful: it's one thing to run a 10-node service at 10 requests per second; quite another to run a 1,000-node service at 10,000 requests per second. <comment><USER2> You're in luck. I just posted a blog post on this >> [https://realpython.com/blog/python/docker-in-action- fitter-h...](https://realpython.com/blog/python/docker-in-action-fitter- happier-more-productive/)

I'm working on a nice delivery solution as well that you can just push to.</comment>


Delicious is about to lose a bunch of users - <AUTHOR> http://thenextweb.org/2008/07/29/delicious-is-about-to-lose-a-bunch-of-users/ Delicious is switching to a new system, and put on a tutorial for its users to maintain their account, my guess is that a large part of its users won't return after the switch and will turn out to be 'sleeping' users. <comment><USER2> I remember talking to a guy who worked full-time for an ISP and did nothing else but handling dead people accounts. They kept charging these people who NEVER logged on and never complained. They had special mechanisms to ensure these people wouldn't be bothered with mail (since they were often literally dead) so they could keep charging them...

</comment><comment><USER3> But were they really users if they're just "sleepers"? Depends how you define them - I would call them account holders.

In the mobile telecom industry, they use a metric of "users who made a phone call in the past 90 days" and similar for each service (SMS, internet, etc). This negates any inflation of subscriber figures from Pay as You Go kind of billing who may use a SIM card once a year.

</comment><comment><USER4> "Lose a bunch of users" just for having to log back in? Give me a break.

<comment><USER2> Wanna bet?

<comment><USER5> Every time someone clears their cookies they have to log back in. If someone is such an apathetic user of the site that they can't even log in, they'll stop using the site the next time they clear their cookies anyhow. All Delicious is doing, in effect, is clearing everyone's cookies at once. I'm sure there will be a slight dropoff, but this article exaggerates.</comment></comment></comment>


Getting There from Here - How should Obama reform health care? by Atul Gawande - <AUTHOR> http://www.newyorker.com/reporting/2009/01/26/090126fa_fact_gawande

<comment><USER2> +1, not for the politics but his commentary on reforming a system. Although, I'm not too sure it's necessary - I feel as though most staunch idealists get ignored when it comes time to actually make the decisions.

I recommend checking out Gawande's _Complications_ for anyone interested in more of his writing.</comment>


The Zipper Rule on German Roads - <AUTHOR> https://www.ozy.com/immodest-proposal/german-roads-are-smarter-than-yours/60839 <comment><USER2> This is not really specific to Germany. Zipping is also used in e.g. in The Netherlands and Belgium. It's been required by law in Belgium since 2014 and has been campaigned in The Netherlands since 1989 (apparently).

Also, having lived in Germany for five years and having been in 'Stau' for many times, Germans are also not terribly good/efficient at it. Typical problems: people switch to the lane that is supposed to zip when traffic is going faster, which is obviously counterproductive; and not leaving openings for people to zip.

It's probably still better, but it would be far more effective if all drivers would actually cooperate.

<comment><USER3> In my experience, zipping as described here - when getting onto the highway - isn't done properly in NL. People still try and force themselves onto the highway or other lane as soon as possible. My colleague called it "eerste blokjesangst".

Just keep going for a bit further, use the whole road, and make sure you're matching speed with the rest of traffic, instead of making them (unknowingly) slow down to let you in. Also keep in mind you ARE allowed to overtake slower traffic on the on-ramp, so if there's a truck there, just pass it on the right, then merge.

<comment><USER4> Usually, it is safer to merge behind the truck.

<comment><USER5> Not sure about that. Trucks generally have very powerful brakes and can stop faster than you'd expect. Crashing into the back of a truck can be catastrophic.

<comment><USER6> I'm a Part-time truck driver.

Truck do have big powerful brakes, (newer ones with disk-brakes are really awesome) but it still takes a LONG time/distance to slow/stop 80,000lbs from 100km/h. Kinetic energy is a real bitch.

There are videos of new volvos with 'automatic emergency braking' that is impressive to watch; but that isn't real-world.

In the real world during a 'panic stop' the trailer brakes lock up and the trailer starts bouncing. If you are lucky the tractor wheels don't lock up, but while you have slammed on the brakes, you are still steering and trying to avoid hitting anyone.

316ft for a car vs 524ft for a truck.[1] Almost twice the distance.

And that does NOT match my real-world experience. I'd say on average it takes 3x-4x the distance to stop a rig.

[1][https://www.hg.org/legal-articles/stopping-distances-for- com...](https://www.hg.org/legal-articles/stopping-distances-for-commercial- vehicles-28265)

</comment></comment></comment></comment></comment><comment><USER7> Tom Vanderbilt's _Traffic: Why We Drive the Way We Do (and What It Says About Us)_ contains the same conclusion that late merging leads to less congestion because of fuller utilization of available lanes. Related reasoning supports the London Underground's Holborn Station experiment to encourage escalator users to stand on both sides, rather than the customary stand-to-the-right, walk-to-the-left.

[https://www.amazon.com/dp/0307277194](https://www.amazon.com/dp/0307277194)

[https://www.nytimes.com/2016/06/13/world/europe/a-london- sub...](https://www.nytimes.com/2016/06/13/world/europe/a-london-subway- experiment-please-dont-walk-up-the-escalator.html)

<comment><USER8> The stand right, walk left tradition here usually works well, and it's not like the left is empty for a lack of walkers.

Maybe it's cultural or depends on how eager to walk people are as to utilization factors.

<comment><USER9> Standing is denser than walking, so the throughput is greater (at the cost of latency, for those who would walk). I believe the station only encouraged the break in tradition at peak times, when there are significant numbers of people waiting to get on.

<comment><USER10> > Standing is denser than walking, so the throughput is greater

Doesn't this depend on the walking/standing density ratio and walking speed/escalator speed ratio?

Let say the walking density is 1/2 of the standing density. If the walkers walk at the speed of the escalator (i.e. their speed relative to the ground is 2x the speed of the escalator), then the throughput is the same.

<comment> frosted-flakes Holborn's escalators are over 23 metres tall, as tall as a six or seven storey building. Very few people will walk up the entire escalator, essentially limiting utilisation to 50%.

</comment></comment></comment></comment></comment><comment><USER11> Sweden has the same laws, but everyone still merges early because some sense of "fairness" kicks in, and people don't understand that they're making any queuing worse by not utilizing all available road surfaces.

I've stopped caring about other people's sense of fairness in these situations, and I always use the empty lane and merge late. The law is on my side, and people can glare and honk as much as they like. I just saved five- ten minutes of not queuing, they could too if they all learned to drive correctly.

<comment><USER12> As a Brit, I always merge early due to the sense of fairness. However, this is strongly enforced by the nature of road signs, which show, say 500m ahead, a diagram with an arrow on the right merging to the left.

All it would take would be a consistent change of sign showing merging in turn at lane-merge to change this behaviour

<comment><USER13> This is the sign for a zipper merge in Germany: [https://www.swr.de/-/id=22217882/property=gallery/pubVersion...](https://www.swr.de/-/id=22217882/property=gallery/pubVersion=1/d6vtby/r.jpg) (the text says "zipper merge, no sooner than in 400m"). But we also have the arrow sign you describe, albeit with the same text as the other one: [http://www.steine-und-erden.net/se501/reissver.gif](http://www.steine-und- erden.net/se501/reissver.gif). It would be interesting to conduct a study on whether there is a change in behaviour depending on which sign is used.

<comment><USER12> That would be perfect.

The odd thing is that you do see _very_ occasional zip-merge signs in the UK, which tend to reinforce the idea that zip-merge should any be used in exceptional circumstance.

</comment></comment></comment></comment><comment><USER14> This sounds good in theory, but it works less than one out of four times. (no negativity bias included) There's always someone not following the rules, which in human nature automatically grants every observer to do the same. Following local news right now it seems people aren't even capable of "Rettungsgasse" (leaving a corridor for emergency vehicle access in traffic jams) anymore, a concept also encoded in law here. Sincerely, a German who's on the Autobahn on almost daily basis.

<comment><USER15> Strange. I see it working in practice 80% of the time... I'm on the road a lot, too. "Rettungsgasse" is something that regained popularity in the last years due to strong media push.

<comment><USER16> For what it's worth, foreigners driving there may not be aware of the rule. I tried as hard as I could to be a conscientous, informed road user before my first trip to Europe (studied signs, rules of the road, etc.) but still got an angry motorcycle cop whacking my mirror in France because I thought emergency vehicles would pass on the shoulder and had moved over to allow this, not in this Rettungsgasse (or the French equivalent)

<comment><USER2> What makes it worse is that the rules differ, even in EU countries. In Germany you have to make a 'Rettungsgasse' when there is a traffic jam, whereas e.g. in The Netherlands, emergency services use the 'vluchtstrook' (outermost lanes not used for traffic) in such cases.

<comment><USER5> Except where they've decided to let regular traffic use the vluchtstrook to drive on. Some roads you just need to be aware that you might need to make room for an emergency vehicle coming between the lanes.

</comment></comment></comment></comment></comment><comment><USER17> I've heard of the zipper merge in the US too, many cities and states recommend it. I much prefer the zipper merge and I've always done it before I knew the name. Some states are even putting up signs about it.

Minnesota[1]. Other states[2]. My home town[3].

[1][https://www.dot.state.mn.us/zippermerge/](https://www.dot.state.mn.us/zippermerge/)

[2][https://www.fleetowner.com/driver-management-resource- center...](https://www.fleetowner.com/driver-management-resource-center/magic- and-mystery-zipper-merge)

[3][https://www.ajc.com/news/local/gridlock-guy- transportation-o...](https://www.ajc.com/news/local/gridlock-guy- transportation-officials-urge-use-zipper-merge/BaKOEqwrhAD0597B5fSssM/)

<comment><USER18> This has seemed so obvious to me forever, but I remember two instances very clearly that illustrate how much people generally hate it in the US.

Once, (in Pennsylvania) there was construction coming up, with maybe still half a mile until the actual cones to merge. This one guy in a massive truck didn't like that people were using both lanes so he straddles his truck across both lanes causing no one to be able to pass on either side.

Second, (in Colorado) there were signs that construction was coming up in a few miles, and the right lane would be closed. So, I was riding in the right lane, passing a massive line of cars in the left lane, getting flipped off the whole time, only to find out there was no closed lane. The signs just hadn't been taken down yet. So I was being flipped the bird because I was using a lane that was fully open.

I think people just don't like feeling that other people are "getting ahead of them", in life in general, and especially in traffic.

</comment></comment><comment><USER19> I get why zipping vs. early merging causes shorter traffic jams, but I don't get why it would be more efficient in terms of speed. If 50 cars can pass the bottleneck per minute, 1000 cars will always take 20 minutes, no matter if they cue in one or two lanes? Wether a jam is 1 or 2km in length only matters if there is an exit blocked by it, right?

<comment><USER3> The problem with early merges is that there's no way people that merge in are at highway speeds when they merge, causing everyone behind them to have to slow down, which eventually can cause traffic jams. Just use the whole lane, make SURE you're going the same speed as the rest of traffic. The confusion there is that because of an existing jam or slowdown, people are already at a matching speed at the start of the on ramp. Or so they think.

<comment><USER20> >The problem with early merges is that there's no way people that merge in are at highway speeds

If you drive anything reasonably modern and not grossly overloaded/under- powered you can plant your right foot and be going traffic speed (or close to it) by the end of all but the smallest on-ramps. Most traffic is not made up of box trucks and panel vans so there is no technical limitation that prevents zipper merging on most on-ramps most of the time. Going close to traffic speed makes it a lot easier to merge but a lot of people aren't comfortable doing it that way.

</comment></comment></comment><comment><USER21> I can't believe this is even debatable. Near my house there are a couple of lights where the road opens up to two lanes before the light, then after the light narrows back down to one lane.

Obviously people should zipper off before the light to load both lanes evenly and get as many people through the light before it cycles. Then after the light everyone should go forward and re-merge back into a single lane again.

Yet people will stubbornly pile into the left lane before the light leaving the right mostly empty then play games blocking people from merging in after the light.

Well, that's when they actually move through the light in a timely manner if not distracted from texting while stopped at the light :/

<comment><USER22> Maybe they feel the right lane is only for people turning right?

<comment><USER23> Then it would be a right turn only lane...

<comment><USER24> Yes, we have roundabouts where this happens. I also see this at the interstate on-ramp by my office.

There is a long lane, often backup up past a stop light and then it goes to 2 lanes for about 50 yards before the light that lets you turn left onto the interstate.

Nobody ever turns from the rightmost lane, everyone stays in the left lane. When I use the right lane and pass people I get angry reactions, people trying to block me from merging back in, and a couple times people cursing at me and following my car.

Luckily I'm a big guy who's not easily scared.

</comment></comment></comment></comment><comment><USER25> In the UK I had someone almost try to crash into me when continued along a totally empty lane 200 yards before the merge point, while everyone else was queueing in one lane.

So stupid.

I actually think that roadworks people could fix this fairly simply though without requiring people to think. Instead of closing one lane and keeping the other open, close half of each lane - create a new single middle lane, then people won't be able to queue in the "right" lane.

After everyone is in single file you can shift them wherever you want.

Here's what I mean: [https://imgur.com/a/rCw4vJ7](https://imgur.com/a/rCw4vJ7)

<comment><USER26> Based on your description of the scenario I'd think the driver in question considered you a "queue jumper", and their fury at what they perceived as your objectionable driving would cause them to act unsafely.

I see similar things from time to time on a road I use frequently. In cases where it's very busy and both lanes fill up then merging in turn tends to happen quite well, but when there's only moderate traffic and it's queuing in one lane then events such as that you describe may occur. Perhaps some signs saying "queue in both lanes" and "merge in turn" at the appropriate points on the road might improve things.

</comment></comment><comment><USER27> It's funny that the article states it doesn't happen in the UK, but according to the highway code you are are supposed to. Many people seem disagree with that and like to queue but should read their highway code [https://www.rac.co.uk/drive/advice/driving-advice/zip- mergin...](https://www.rac.co.uk/drive/advice/driving-advice/zip-merging/)

<comment><USER28> That's what I was confused about. The article says we don't do it in the UK but then describes what we call "merge in turn"

<comment><USER27> Yes, but I can believe people not seeing it being applied. A lot of people don't like it for whatever reason. Only ignoring it seems to create (or worsen) the problem in the first place

<comment><USER29> At least on motorways, this is because more often than not you will be going too fast to do this safely by the time you run out of lane. Most drivers will be conditioned by that experience to expect it unless they can see evidence to the contrary. This is also why the signs indicating lane closures will usually be half a mile or more before the actual closure. When the traffic is slow moving to start with people do tend to merge in turn.

</comment></comment></comment></comment><comment><USER30> Where I live there is a very strong culture of politeness and kindness in driving. For instance, I often see (and do it myself) that someone has let a person in who is trying to pull out of a hard-to-leave business driveway, with no hope of reward, just out of a sense that other people have helped you out in the past so now it is your turn.

In a recent construction on my way to work they put in two lanes where there was one, which must merge within a hundred yards to get over a narrow bridge. Filling both lanes and zipping would increase the capacity at that location, no doubt. But few drivers do it. Are others worried, as I am, that it would be part of a change in the overall driving culture, normalizing cutting ahead?

That is, could zipping be a local optimization that leads to a global suboptimization, an overall decrease in how reasonable it is to drive around here?

<comment><USER31> Same here (Scotland). I think the tendency to queue and not fill both lanes is out of a misplaced sense of fairness - you can't help but feel very judged if you run right up an empty right-hand lane all the way to a merge point. Because you really are queue jumping, even if it's the collective fault of all the drivers who created the queue in the first place.

It needs public education to get people over this suboptimal behaviour.

On a tangential note, what's up with everyone everywhere saying "my God, drivers in [where I am] are the absolute worst"? They can't all be right.

<comment><USER32> Norms change slowly and queueing is a strong social norm. But if it's actually tought in driving schools or even made into law then we can usually overcome it.

This is like how it's pretty natural to let people out of a lift or a train before you enter, regardless of who waited longest. It's just not efficient to get people in before others go out. So we are tought to let people out first.

</comment></comment></comment><comment><USER33> In many cases the lanes weren't designed for zipper merging or drivers "zipper merge" at inappropriate places. Zipper merge is great! But not all merging is to be a zipper merge- this is constantly abused, and perhaps justified in the minds of offenders under the guise of the zip. A lane, such as an entrance lane, that terminates is a good time to zipper merge. But many many times, in Minnesota, people use any lane that allows them to cut to the front of the line. Regardless if that causes a massive slowdown as they leave the relatively free flowing lane and "zipper merge" - match speed of the slow lane. Articles would do well to mention the finer points before ushering us to 10% gains... maybe.

<comment><USER34> Glad to see lane design mentioned, it's a key component. In most zipper merge opportunities there is a predominant lane and another lane that is ending, leading to the idea of a 'right' and a 'wrong' lane which precludes intuitive zipper merging. If lane design (even just the markings) were such that both lanes were equal prior to the merge, zipping together would seem the most natural thing to do whether signposted or not.

</comment></comment><comment><USER35> If the culture is early merge and you choose to late merge you will be skipping the line and people will resent you for it.

If I see an opertunity to late merge I will often choose to stay in the late merge lane, but match speed with the traffic in the early merge lane, then zipper when I have to. People notice that I haven't cut anyone off or skipped the line, and people usually fill in behind me and I'm able to transform an early merge queue into a late merge queue.

You shouldn't late merge if it blocks a thruway. If a single lane highway has a backed up exit ramp then exiters should join the queue as soon as possible instead of late merging and blocking the highway.

</comment><comment><USER36> A US driver and it may not be the law but the zipper move is certainly the norm in my area.

Again an article making a generalization about the US without recognizing how large it is and the vast differing cultural norms and laws between states and regions.

<comment><USER37> I've also had the pleasure of driving in multiple states. The zipper merges seems to be true everywhere that I've been. Even the purportedly terrible Orange County and LA drivers user zipper merging.

The one thing that I have noticed is that people are more likely to do early merges and zipper merges together. Well, not the same person, but I may see it in the same area. The early mergers _usually_ don't block traffic waiting for opening. It's usually that they see the gap in traffic and take it immediately.

<comment><USER38> Southern California drivers certainly aren't terrible, and if that's a reputation they carry among outsiders it's probably because they're more aggressive (efficient) and leave less space than those from parts of the country where real traffic doesn't exist.

<comment><USER37> They absolutely aren't terrible. I do think some SoCal drivers can be a little over aggressive to the point where it is unsafe, and this tends happens with multiple lane changes to make an exit. No matter where you go, you'll have adrenaline junkies in coupes and on bikes weaving around cars, distracted drivers, rubberneckers, and fender-benders that refuse to move to the shoulder.

</comment></comment></comment></comment><comment><USER32> I'm living temporarily in spain and notice something similar: they basically don't use the inner lane in roundabouts. So people go 3/4 of a lap on the outside lane which can be clogged while the inside is empty.

<comment><USER39> Exactly the same problem in Portugal.

People tend to stick to the outside lane as they feel that if they go on the inside lanes they won't have the opportunity to move to the outer lane when they are near their intended exit due to other cars being on the outer lane.

IMO this stems from lack of education (driving lessons are not adequate) and the fact that everyone's looking after themselves (i.e not respect for other road users (which also explains the ludicrous speeds on the roads, road rage, queues, etc))

<comment><USER40> I hate roundabouts, at least partly for this reason. Whenever I'm taking anything other than the first exit, I'm moving round just praying that no- one's going to join or drive up alongside me...

(And don't get me started on driving lessons. Here, in the UK, they're an absolute joke!)

</comment></comment></comment><comment><USER41> Kiwis have this rule, signs saying "Take this tip: merge like a zip!" (think of it said in a happy kiwi accent). Driving in Australia without the rule, merging gets personal quickly.

</comment><comment><USER42> This rule exists in many European countries, but afaik it only applies to situations when the lane is blocked or stops there, so all cars have to move into one lane. It's totally OK however to not let into the lane people who're using an empty lane on purpose to pass by others and jump the queue. If the car has the road in front of it to continue moving, so they don't need to switch the lanes, you don't have to let them in.

<comment><USER43> > t's totally OK however to not let into the lane people who're using an empty > lane on purpose to pass by others and jump the queue

In Germany, this behavior is explicitly forbidden by the law.

If there is a merge, one car of each lane has to go through the merge each time.

That is, if you are at the end of the lane that gets merged, and you let one car pass, then you have the right to go and merge next. The next car in the other lane must yield, if they don't and there is a crash, it's 100% their fault.

This is so that the lanes that merge get used to their maximum capacity. If the intent were for cars to merge earlier, they would just have made these lanes shorter.

<comment><USER42> Absolutely, but only if there's a merge of lanes. If this is just the empty lane that people use to get to the front of the queue, like when there's a traffic jam to enter the highway and some cars are trying to cut the line, then you don't have to let them. I'm aware that this is not a common problem in normal countries like Germany where drivers generally behave well, but if you ever find yourself waiting in a line somewhere in Italy or say in Balkans, you'll often see cars trying to push past you by cutting the queue using empty and service lanes.

</comment></comment></comment><comment><USER44> It's not just drivers who don't let someone from the empty lane 'cut in' \- there are those that stop completely and let in 3 or 4 'poor sods who were stuck on the wrong lane'. This breaks the system just as badly! The trick is to merge 1-1 as fluently as possible or you've broken everything.

</comment><comment> mark-r I see a lot of talk of fairness to justify the urge to merge early. This is ironic since zipper merge is the fairest of all, if you can only get everybody to adhere to it. Nobody can get ahead if both lanes are full and moving at the same speed.

</comment><comment><USER45> To encourage this behavior, why not put a stoplight in the middle of the road at the merge point?

Just like the ramp meters that limit cars entering the freeway. But instead a dual light that encourages zipper merging via offsetting green signals for each lane.

<comment><USER46> A full stoplight requires a full stop which defeats a lot of the benefits of a proper zipper merge where traffic just keeps flowing with no stops.

In a more general sense on a highway any time a car comes to a full stop you have the chance to create a phantom traffic jam as the stop travels back along the incoming stream of cars.

[https://static1.squarespace.com/static/5005afd7e4b0a6953320b...](https://static1.squarespace.com/static/5005afd7e4b0a6953320bf3f/t/57c6ceb69de4bb8747981006/1472646990392/?format=750w)

<comment><USER45> [YIELD || GREEN] alternating lights then

<comment><USER47> There is no Yellow-Green traffic light in germany. There is only Red, Red- Green, Red-Yellow and Red-Yellow-Green.

<comment><USER45> I'm speaking more about hypothetical new lights in the USA, Germany, or elsewhere in the world.

</comment></comment></comment></comment></comment><comment><USER48> I can see the comment in the post about the UK; I am used to this practice in a lot of EU countries I go; in the UK however, they don't do this and the amount of roadrage there is quite staggering. I do not drive there but when I am in taxis/Ubers, the amount of honking, cutting in, swearing, (racial) insults and flipping the bird I have not seen in other countries. Ofcourse mostly in/around large cities but I have seen it in tiny villages too; enough anyway for me (YMMV) to think it is not an anomaly.

Not sure where all that anger comes from but I am happy that a hardly ever saw it in other countries where I drive or take a taxi.

<comment><USER49> Try driving in Bucharest or Athens for a bit and the UK will seem positively polite.

<comment><USER48> I drove in Bucharest a few months ago; I did not notice this. But might well be as this is all anecdotal anyway; I have been in the UK many times, I have been in Bucharest once (I did not like it compared to other cities in RO).

</comment></comment></comment><comment><USER50> Once self driving vehicles are the norm, such rules would become default.

</comment><comment><USER51> New Zealand has some 'Merge like a zip' signs. I've not seen them in Australia but people do know the rule. They just don't follow it all the time.

</comment><comment><USER52> I've never actually seen this work in practice, so maybe i'm missing something: Isn't the overall flow of traffic defined by the speed of traffic within the narrow section? E.g. if the speed limit and actual speed of traffic in the one- lane construction zone is 45mph, how people merge prior to that point should be irrelevant. The same number of cars are going to get through at the same rate.

<comment><USER53> From my experience, the speed is most often lower at the merging zone then in the following stretch of road. So overall througput could be improved by a more strict merging regime.

</comment></comment><comment><USER54> I independently rediscovered this driving in Southern California. It's the obvious fair and efficient solution for two lanes merging.

What most Americans have a hard time understanding is that German driving school, or Fahrschule, requires the student to master these "advanced" techniques. Unlike in the USA where if you can operate the throttle and the brakes you're good to go.

</comment><comment><USER55> As an Australian driver: hahahahhahahhahahah you got Buckley's, mate. No f ___ ing way am I letting you in. Get f ___ ed

As an English driver: < _extreme tutting_ > get to the back of the queue like everyone else!

As a Cambodian driver: we are all stuck in a sea of motos, and being on time for anything is unimportant. Of course you may merge into my lane.

<comment><USER56> As an Australian driver I like to use what I call the "Robin Hood Rule" \- steal from the rich, give to the poor.

What that means is if someone tries to push their way in, I will block them off.

If someone is stuck and trying to get out of a side road / park, I will always let them in.

<comment><USER57> I think this is a dangerous approach, as the more aggressive drivers are more willing to play chicken and risk a collision. of course I follow the same rule myself.

</comment></comment></comment><comment><USER58> I personally have never seen more efficiency on the road than Manila. Merging is just on an entirely different level in the Philippines. I would recommend going of course (not just to observe their driving) but there is no shortage of YouTube videos of traffic/Driving in Manila.

<comment><USER59> Or other countries in SEA, for that matter. The way to cross the road, as a pedestrian, in Cambodia is this: Close your eyes and, with one hand raised, walk across the road at a steady speed. Traffic will flow smoothly around you. Any attempt to avoid traffic by walking faster/slower will confuse everyone and lead to accidents.

</comment></comment><comment><USER60> I've always thought this would be best. I recently saw signs instructing people to wait to merge in Duluth MN when I was visiting for work. People weren't abiding by the signs though and continued to behave in the normal random way they typically do when merging.

</comment><comment><USER61> This is also the rule in the US, isn't it? Maybe just Washington?

[http://mynorthwest.com/474290/washington-traffic-law- reminde...](http://mynorthwest.com/474290/washington-traffic-law-reminders/)

<comment><USER62> The article mentions Washington and Minnesota (and other unspecified states) are trying to encourage it.

I certainly see it sometimes. I also see people preventing it sometimes by straddling both lanes.

<comment><USER63> Lane straddling doesn't prevent people merging via the zipper rule. Rather, it prevents people already on the road from moving over to the merging lane, shooting ahead of a bunch of people, then merging again (slowing down everyone else by adding to the merging traffic). It's one of those behaviors where whatever convenience that person gets is greatly outweighed by the cumulative cost to everyone else.

Actually lane straddling doesn't even work to prevent someone from using the zipper rule. It prevents people from passing other people on the right (nobody should be passing anyone on the right most of the time anyway). But it doesn't prevent someone from merging into the other lane when the time comes. As long as you're pacing yourself vs. the speed of the traffic in the lane you want to merge into, everything's fine. Using the zipper rule doesn't mean you race ahead of everyone before merging, if anything it means waiting a little bit longer and maybe even merging behind a car you would otherwise be tempted to merge in front of.

<comment><USER63> I'm not normally one to complain about downvotes but I literally cannot imagine how any of what I wrote was remotely controversial. Like I'm trying to look at it with different interpretations and perspectives and I'm just not seeing it. I've seen hotter takes in DMV driving guides. I'd be very curious what the disagreeing opinions are and why. For the record, I've never straddled lanes, I was just explaining why people do it.

<comment><USER64> In the ideal scenario of lane straddlers, everyone trying to enter a particular lane at a particular point has to do so at the end of the line of people already waiting to enter. The right hand lane is completely unused and therefore the length of the line is double what it needs to be, possibly so long that it interferes with other intersections.

In the ideal scenario of zipper merging there is no free right hand lane to shoot ahead in: it is completely filled with people that are alternately taking turns with the other lane to enter the merged lane. The queue is half the length in this case then the prior case. The lane straddler doesn't feel taken advantage of since everyone is entering the queue in the first available location (left or right).

Lane straddlers perform an illegal maneuver (I assume intentional driving in two lanes is illegal in most countries) to pre-empt the more efficient usage of the road. Their righteousness is unjustified: the person that would otherwise pass them in going to the front of the lane would be increasing the utility of the road. They would be more considerate by entering the lane they are blocking and going to the front themselves.

</comment></comment></comment></comment></comment><comment><USER65> Somewhat related, I wish people would learn that, when turning right or left onto a two or more lane road, you are to turn into the lane nearest you and never the far lane. This way, a car facing you can turn onto the same road at the same time.

</comment><comment><USER66> For people who prefer videos - [https://www.youtube.com/watch?v=cX0I8OdK7Tk](https://www.youtube.com/watch?v=cX0I8OdK7Tk)

<comment><USER67> I don't get it: why not just put all the cars on one lane then ?

<comment><USER68> In a case of a highway it might not be as beneficial, but imagine a city with lots of road intersections. If you put cars on two lanes and merge, you have half as long line of cars. In case of one lane scenario, the cars might block the previous intersection for other cars.

<comment><USER67> In a city, you won't have this problems, as traffic will jam at the first road work it encounter anway. Besides, how do ones plan to make all those people collaborate ?

It all seems very theorical and not that useful.

<comment><USER69> The drivers should know to leave just enough space in front of them for the car on the other lane to merge. Having to stop for a merge makes everything slower. It takes longer to accelerate so longer to clear the jam. Ideally one lane slows down and leaves some spaces between the cars, and the other one merges 1 to 1 without anyone ever having to brake to a full stop.

And I see this working every day since where I live the rule applies. Of course there will always be the occasional smart guy who rides in the ass of the car in front in order to not let anyone pass and save 1-2 seconds at the price of causing everyone behind him 10 times the delay. This forces the cars trying to merge to come to a full stop, then forces some of the cars on the other lane to fully stop in order for the merging cars to be able to accelerate and merge.

</comment></comment></comment></comment></comment><comment><USER70> I try to follow the zipper rule when getting on the freeway. The problem I run into quite often in CA (and the thing that frustrates me the most in urban driving) is when people behind me on a highway on-ramp cut across the solid white line to "get ahead". That then forces me to have to slow down while they pass so I don't ram them from the side. If you factor in other through-way cars already in the lane, this can really congest merging and you get major backups in the rightmost lane.

A similar event comes to mind when you come across someone sitting in the left lane going under the speed limit but completely unaware or bother for the people passing them.

So I guess my point is, while these are great in theory, they don't really work in practice without buy in from the herd (I use herd as this problem can be framed in a similar light as vaccinations and herd immunity).

<comment><USER71> Yes, this is one of those concepts which works much better for everyone, _if_ everyone else drives like a German driver.

In the US, when you get to the end of the merge region, most people in the continuation lane will blast by at full speed, leaving no room to get over. I have to sit at the end of my lane, stopped, until I see a gap, and then floor it. That's worse for safety, fuel efficiency, wear and tear on my drivetrain, my own transportation time, and overall road throughput (everyone blocked behind me).

This is a "boil the oceans" type solution. All you have to do is convince everyone to do it.

Here, we can't even get people to stop blocking the box. The SPD is making short YouTube videos with "PRO TIPS" like "Bus lanes are for buses" [1] and "Don't stop in the street" [2]. The average driver is not at the point of thinking about higher level strategy like merge location yet.

[1]: [https://www.youtube.com/watch?v=s_62iDA5Z-s](https://www.youtube.com/watch?v=s_62iDA5Z-s) [2]: [https://www.youtube.com/watch?v=S3dUj6-Kx5k](https://www.youtube.com/watch?v=S3dUj6-Kx5k)

<comment> frosted-flakes Merging onto a freeway from an on-ramp is different, and zipper merge doesn't usually apply. There's a reason the merge zone is 300-500 metres long (where space permits), and depending on the region, clearly marked with a dashed line. It's up to you to match the speed of traffic, then signal your intention to merge before merging into a gap in traffic. Some on-ramps even have metering lights to space out incoming vehicles to make this process smooth. The only time other vehicles should have to change their speed is in heavy traffic, when a gap might not exist.

<comment><USER71> > Merging onto a freeway from an on-ramp is different, and zipper merge > doesn't usually apply.

I'm not talking about merging onto a freeway from an on-ramp. (I'm told the relevant law for on-ramp merging right-of-way varies by state, in the US.)

> The only time other vehicles should have to change their speed is in heavy > traffic, when a gap might not exist.

Heavy traffic is the only time a zipper merge might be relevant in the first place, no? In light traffic, just get in the correct lane whenever you want. It doesn't affect anyone else no matter where you do it.

In fast heavy traffic (when drivers aren't leaving the requisite 4 seconds between cars), there's no reasonable gaps into which to merge. Signaling my intention doesn't change anyone else's behavior, and I don't have the guts to sneak my car into a 20' gap at 60mph. Even if I make it, if the driver in front taps the brakes even slightly, we're all going to have a real bad day.

This is a perfect example of how you can't just transplant one aspect of German driving, in isolation, to American highways. On the Autobahn, nobody's driving full speed for an extended length of time at only 1-1.5 car lengths behind the car in front of them. It's reasonable to say "just merge into the gap" because they leave a gap to merge into.

</comment></comment></comment></comment><comment><USER72> I never listen that this is a law here (Spain) or mandatory. But is what usually people done here.

</comment><comment><USER73> Excellent book that mentions this as well as other counterintuitive facts about driving: [https://www.amazon.com/Traffic-Drive-What-Says- About/dp/0307...](https://www.amazon.com/Traffic-Drive-What-Says- About/dp/0307264785/ref=asc_df_0307264785_nodl/)

</comment><comment><USER74> It's sort of a nice thing that people choose nice over efficient.

<comment><USER23> No it's not, and often being "nice" instead of doing the correct and predictable thing while driving is extremely dangerous.

</comment></comment><comment><USER75> Or just ride a motorcycle and do whatever you want wherever you want whenever you want. ;)

</comment><comment><USER76> We do this in the US in many places. The difference is we don't need a law for every common sense rule. And for some road configurations, strict adherence to the rule wouldn't make sense.

<comment><USER77> Alternating merging yes, but many people probably don't wait until the last possible opportunity to do so. Some merge as soon as they can and think late- mergers are trying to cut ahead.

<comment><USER78> That's because a lot of people like me don't/didn't know about the zipper merge and asscoiate it with 1 lane exits where assholes try and merge into the backed up exit lane after flying by everyone else in the other non queued lanes and thus blocking other lanes.

<comment> mark-r There's no worse feeling than realizing the backed up traffic in the right lane that you've been buzzing by was waiting for the same exit you need. I hate being "that guy" but sometimes ignorance catches you unaware.

<comment><USER78> Totally, that's why I let people in at the start of the queue and get more aggressive about not letting in people the further I get into the exit lane queue. I still let in people but the further into the queue I get, the less permissive I am because if you fucked up, then accept the fact that you will have to miss your exit and reroute back to your destination and hopefully you won't be that asshole next time and enter the queue early.</comment></comment></comment></comment></comment>


Isomorphic JavaScript - <AUTHOR> https://github.com/isojs/isojs

<comment><USER2> I'm not quite sure to understand what this repo is for. Can you explain?

<comment><USER3> A manifesto from somebody who thinks that the JS players will ditch backwards compatibility and write a new language still named "Javascript" that will "fix what's wrong" with JS....

<comment><AUTHOR> There's nothing wrong with JS, the language, IMO. Quite the opposite, while JS has matured, the tools haven't. Backwards compatibility causes more friction and issues than those it solves. I'm suggesting we design solutions that aim for the future, not the past.</comment></comment></comment>


Secret Fears of the Super-Rich - <AUTHOR> http://www.theatlantic.com/magazine/archive/2011/04/secret-fears-of-the-super-rich/8419/

<comment><USER2> Publication date April 2011. Previous submission with more than 200 comments:

<http://news.ycombinator.com/item?id=2364922></comment>