USS McCain collision ultimately caused by UI confusion - <AUTHOR> https://arstechnica.co.uk/information-technology/2017/11/uss-mccain-collision-ultimately-caused-by-ui-confusion/ <comment><USER2> There was a ferry accident involving a similar transfer of control problem in New York harbor.[1] Ferries have a lot of maneuvering modes and directional thrusters, because they do so many dockings, and so they have a more complex control problem. The pilot put the system into a backup dumb mode while in cruise, then changed stations to where he could best see the dock while still in the wrong mode. Rammed the dock at 12 knots. 79 injured, 4 seriously.

This is bad design. All the controls that can steer the ship should be tied together and move together. How to do that was figured out decades ago.

The Navy still has this thing where they hate to give control of both speed and steering to the same person. The helmsman and engine room take orders from the officer that has the conn. But that officer doesn't actually operate the controls. Some enlisted sailors do. This dates from the age of sail and steam. Merchant shipping gave this up decades ago.

Back in the 1950s, the U.S. Navy built the USS Albacore. This was an experimental submarine to test out the teardrop-hull concept. It wasn't nuclear; it was just a test vehicle to see how such a hull form handled. It was expected to be more maneuverable than previous designs, so it was set up with aircraft-like controls. One person sat in the pilot's seat, strapped in facing forward, looking at aircraft-type instruments, and controlled all the maneuvering controls. It was a very agile craft.

The brass hated it. The person in the pilot's seat was really the one in charge. The officers were just back-seat drivers. To this day, the Navy sets up nuclear submarines so that different people steer, control power, and control buoyancy.

(The British in WWII tried to control aircraft with multiple people. As bombers got bigger, they wanted to put a senior officer in charge, but younger people were better pilots. So they had an "aircraft commander" back-seat driving, as well as a pilot handling the controls. This did not work out at all and was rapidly dropped.)

[1] [https://www.ntsb.gov/news/press- releases/Pages/PR20140408c.a...](https://www.ntsb.gov/news/press- releases/Pages/PR20140408c.aspx)

<comment><USER3> User interfaces have gone backwards decades in quality.

Look at your car radio in a 90's car. You didn't need to look at it to figure out how to push the radio button, turn the volume, anything. You could even adjust the bass on the fly with a bass knob instead of navigating to your "eq" menu to do it.

Now, you've got to look away from the road, realize what "mode" your in, you can move the menu around to the "audio" section, then "fm", then select a channel. And of course, it's a touch screen so there's no tactile feedback. But at least it's got PRETTY ANIMATIONS!

My Toyota Corolla will blast audio out of the speakers _as it boots_ but the _volume knob_ doesn't respond till it completely boots up. So you may start the car and have 5-10 seconds of blasting radio that you can do nothing about. GREAT JOB GUYS. A volume knob that needs to boot.

This is what was considered not only acceptable, but a "Feature" in a modern vehicle with hundreds of millions of dollars in investment and NOBODY thought to see if the radio interface was actually... efficient? It's not like people interact with the radio/music console in a car on a regular basis...

Or my 2001 Jetta. It was one of the earlier cars with "climate control". What that actually means is that to set it to heat, you have to tap the "plus temp" button a literal 20-30 times to get it into "HI" to force heat on. And then the day warms up and on your drive home you want AC? Tap it 20-30 times on the "minus temp" button. There was no knob for AC temp. They gave you 1 degree precision on a car that couldn't guarantee 10 degree temperatures. Additionally, the volume control for the car had digital buttons. That's right. Enjoy pressing up/down 50 times. No ability to rapidly change volume. So when you switch radio stations or to casette/cd and the volume is highly different you have to sit there pressing the button over and over. But, even then, at least these were BUTTONS that you didn't have to look away from the road to use. They had little tactile notches on them so you could feel around for them.

<comment><USER4> Don't get me started about TVs. When I grew up our family TV turned on in seconds, and pressing channel up/down reacted in tens of milliseconds.

<comment><USER5> To be fair, you weren't getting near-instantaneous full HD quality broadcasting with DVR support on your TV back then.

<comment><USER6> The problem is that there's no reason one couldn't design a TV that had both full HD and zero boot time with instantaneous channel switching. The reason such TVs don't exist is simply engineering laziness.

<comment><USER5> > The reason such TVs don't exist is simply engineering laziness.

If your answer to the question "why can't a billion dollar industry provide me with instantaneous channel switching?" is "because they are lazy", you are severely misguided (at the very least!). There are hundreds of extremely talented engineers working full-time on these problems. If the solution were as easy as you propose, the issues would be solved.

> zero boot time

That's not going to happen, ever, but I'll assume you meant "faster" boot times.

Probably. Keep in mind that your average set-top box likely goes through a more complex secure boot process than most electronic devices you would ever interact with. Why? Because if people can run arbitrary firmware on a set-top box, your cable company would lose a shit ton of money.

> instantaneous channel switching

You are bound by the latency required to demodulate a signal being broadcast from some satellite ~30,000 km away from the receiver, decrypt the resulting stream, and finally decode it, all _on the fly_ so you get a nice, continuous, stutter-free full HD broadcast.

I am no expert, so there is probably way more stuff happening behind the scene that someone else could probably shed light on. The point of my comment was to demonstrate that things can sometimes be more complicated than they seem at first glance.

<comment><USER7> The distance to the satellite has nothing to do with it. You're using big numbers to exaggerate the problem.

Decrypting and demodulating have be as fast as the data is coming, otherwise the delay would grow until you never saw the end of the show. So that's not the reason either.

<comment><USER8> Yes, the MPEG-2 decoder in your TV needs to be fast enough to keep up with the transmitted data rate, but that doesn't mean that it has instantaneous stream startup times.

Your TV doesn't have the information it needs to start displaying MPEG-2+ATSC A/53 video for as long as 700ms. It needs to buffer quite a bit of timing information and at least an I-picture frame before it can start displaying anything: [http://www.bretl.com/mpeghtml/startbuf.HTM](http://www.bretl.com/mpeghtml/startbuf.HTM)

Not only that - the overall standard has tight timing tolerances to keep video arriving at the encoder/transmitter in-sync with audio/video leaving the decoder in your TV. It's not like MP3 streaming where every client has its own buffer size and time to start playing depending on network conditions, bitrate, etc.

Having a reliable buffering process to keep receivers in-sync is a feature, not a bug.

<comment><USER6> And the way to solve this -- at least for the case of consecutive channel surfing -- is to have multiple decoders and multiple buffers. It's simply precaching.

<comment><USER8> Eventually you're going to run into RF limits, especially if the signal is coming in over the air.

You're sure this is engineering laziness? How much extra would you pay for a TV with faster channel changing?

<comment><USER6> I'd pay extra for it. I'd pay even more for a TV that didn't spy on me and that couldn't update its firmware without my consent. But I'm probably not the target consumer.

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER9> The _real_ cause of the collision was poor seamanship and failure to follow the COLREGS on the part of the bridge crew of the destroyer. Most specifically they were seriously in violation of Rule 6: the Safe Speed Rule

[http://navruleshandbook.com/Rule6.html](http://navruleshandbook.com/Rule6.html)

      Every vessel shall at all times proceed at a safe speed so
      that she can take proper and effective action to avoid
      collision and be stopped within a distance appropriate to
      the prevailing circumstances and conditions.

The USS McCain was traveling at over 20 knots at the time of the collision, through a very crowded area at the entrance of a traffic separation scheme. If they hadn't been traveling at this obviously excessive speed they would have had the time to think, and to work through little UI issues like the one described here.

<comment><USER10> The path to a disaster has been compared to a tunnel [0]. You can escape from the tunnel at many points, but you may not realize it.

Trying to find the 'real cause' is a fool's errand, because there are many places and ways to avoid the outcome.

I do take your meaning, reducing speed and following well established rules would have almost certainly have saved them.

0\. PDF: [http://www.leonardo-in- flight.nl/PDF/FieldGuide%20to%20Human...](http://www.leonardo-in- flight.nl/PDF/FieldGuide%20to%20Human%20Error.PDF)

Amazon: [https://www.amazon.com/Field-Guide-Understanding-Human- Error...](https://www.amazon.com/Field-Guide-Understanding-Human- Error/dp/0754648257)

<comment><USER11> I've never heard the tunnel analogy. Seems odd, since tunnels generally only have one entrance and one exit...

In a lot of fields where the stakes are high and mistakes are costly (aviation and emergency services are the two I'm most familiar with) the analogy used is a chain. Break any link in the chain and you prevent the event.

[https://www.aopa.org/asf/publications/inst_reports2.cfm?arti...](https://www.aopa.org/asf/publications/inst_reports2.cfm?article=4401)

<comment><USER10> It's the perception tunnel. There are many branches, but only one route is followed. In hindsight, you can see all the branches and call out everything that went wrong.

<comment><USER12> Normally that is called "tunnel vision".

[https://en.wiktionary.org/wiki/tunnel_vision](https://en.wiktionary.org/wiki/tunnel_vision)

 _(figuratively) The tendency to focus one 's attention on one specific idea or viewpoint, to the exclusion of everything else; a one-track mind._

</comment></comment></comment></comment></comment><comment><USER13> It's not just boats that have safety-critical UI design problems. The avionics in airplanes are becoming so complicated that managing the avionics is almost more difficult than flying the plane.

I'm a private pilot who has been flying a Cirrus SR22 for twelve years. In that time it has gone through two major glass cockpit avionics revisions. In the first revision, called the Avidyne, the autopilot was either on or off. In the current revision, called the G-1000, the autopilot can operate in two modes: AP mode, where the autopilot is actually flying the plane, and FD or flight-director mode, where the autopilot does all of the calculations to figure out where the plane should be flying and displays a target on the primary flight display, but the actual control of the plane is still in the hands of the pilot.

If the plane is stable, it is _very_ easy to get fooled into thinking the autopilot is flying the plane when in fact it is not. There are only two visual indicators that tell you if the autopilot is actually flying the plane: a small green LED on the autopilot console, which is down near your right knee, and another small annunciator on the primary flight display. It looks like this:

[http://is3.mzstatic.com/image/thumb/Purple71/v4/9a/36/ad/9a3...](http://is3.mzstatic.com/image/thumb/Purple71/v4/9a/36/ad/9a36ad6e-3ab6-a48c-3f67-d5318ba1f66b/source/552x414bb.jpg)

The autopilot indicator is indicating AP mode in that image. See if you can spot it.

It has happened to me more than once that I thought I had the autopilot engaged when in fact I had only turned on the flight director. I predict that one of these days someone will die because they made this mistake in instrument conditions.

<comment><USER14> Is there a purpose to the display being so colorful? If AP were the only green thing and the others were monochrome it would stand out more.

<comment><USER15> Most of the colors on that display have a rationale. For example, on the speed tape on the left, the white, green, and yellow colors all map to colors of a standard airspeed indicator. That the course (CRS) is green instantly tells me I'm navigating by a ground-based VOR, not GPS (which would be magenta). Same with the green diamond on the right by the altitude indicator. The waypoints at the top are all GPS-calculated, therefore also magenta. At the top, the green radio frequency is the one you'll transmit on. The blue airport icons in the Nearest page (bottom left) indicate towered airports (matching those found on standard aeronautical charts).

(In case it's not obvious, I've got a few hundred hours behind the G1000. AMA.)

<comment><USER16> Do you have any opinion on the G1000 (and subsequent Garmin flight decks) vs competitors, such as Avidyne Entegra?

My feeling has always been that the Garmin UI was somewhat clunky and suboptimal, possibly because they tried to keep it similar to the UI of previous smaller devices (such as the GNS 430); a bit like if the iPhone hadn't come along and we'd still scroll by putting our finger on a little arrow in a scroll bar on mobile devices.

My impression was that other manufacturers had a better UI, but somehow didn't make it in the marketplace.

<comment><USER17> I think there's some truth to your GNS 530 theory... Pilots are not typically that interested in stylish/modern UIs, and they're not thrilled when a familiar UI changes. There are so many features now that it's a challenge to find room on the PFD. I'm curious, which other UIs do you prefer? What do you think of the G1000 NXi?

<comment><USER16> > which other UIs do you prefer

Well, I haven't flown other glass cockpits. I just find the G1000 clunky and a bit unintuitive, that's why I was wondering whether there are still viable and possibly better competitors out there.

</comment></comment></comment></comment></comment></comment><comment><USER18> Militaries are good at making horrible UI. :-) I used to work at early warning radar, that should notify our tops about incoming ICBMs. When there's a target, classified as "suspicious" or "something that's going to fall onto {our, neighbour} territory", the following happens: \- very loud sine 1200Hz tone starts sounding \- the only output device, "fast-printing device", starts dumping hexdumps of internal structures to long 10cm wide paper (like toilet paper). \- the whole chain of command start yelling to each other (downwards), demanding data and info about the target.

So as the last person in that food chain, you're in the middle of panic, 1200Hz are drilling into your brain, damned thing prints hexdumps, and you need to apply binary shifts and ANDs, convert from floating point hex to decimals and pray that there's enough paper in damned FPD.

I could never imagine worse UI, it's strange that we didn't start WW3 in those conditions.

<comment><USER19> "Militaries are good at making horrible UI."

This is extremely applicable: [https://hackernoon.com/why-the-dmv-website- sucks-2f27a367baa...](https://hackernoon.com/why-the-dmv-website- sucks-2f27a367baa9)

Disclaimer: it's an article I wrote about why government software contractors suck at their jobs.

</comment></comment><comment><USER20> A key occurrence during this mishap:

0127 The Officer of the Deck ordered course to the right to course 240T, but rescinded the order within a minute. Instead, the Officer of the Deck ordered an increase to full speed and a rapid turn to the left (port). These orders were not carried out.

0129 The Bosun Mate of the Watch, a more senior supervisor on the bridge, took over the helm and executed the orders.

I've witnessed multiple similar situations on a warship (imminent loss of extremely critical systems), and had to forcibly push the watchstanders out of the way to do their job for them. Many people are going to freeze when the SHTF, and there may be no prior indication.

Major attaboy to the BMOW who saved many of his shipmates. Given the incident angle of collision, many more would have died from a perpendicular collision.

<comment><USER21> I don't know which one is more bizzare here - the story itself, or the barrage of "this is due to bad UX" comments in this thread.

So I guess if this warship fired all its rockets away, "due to bad UX", and destroyed a small nation, I guess the comments would also be about a bad UX. Oh crumbs, the "check status" button was so close to the "start armageddon" button. Perhaps we should submit a meek complaint to Microsoft or something.

"Commander Alfredo J. Sanchez, "noticed the Helmsman (the watchstander steering the ship) having difficulty maintaining course while also adjusting the throttles for speed control.""

So... we gave the control of a warship to some guy that... has some difficulty navigating through the straits that like 1M of ships go through every day, without problems. Mind you, this is the navy that is supposed to be highly trained to deal with real-world issues such as naval blockades, pirates, and even wars.

It does not make sense at all. Allegedly there were some cuts to funding for navy. Maybe someone is trying to make a point. I do not know, this is just unexplainable. Certainly nothing to do with just "bad UX"

<comment><USER16> The problem is that you can't "fix" humans. They'll make mistakes. Aviation is as safe as it is precisely because it moved past the "pilot error! that guy just made a mistake, how can one be so stupid" attitude evinced in your comment.

You have to look at the entire accident chain, and at the entire system, including training, supervision, redundancy, and, indeed, UX.

<comment><USER22> Good UI makes the effort of doing the 'right thing' very little, and the effort of doing the 'bad thing' as costly as possible.

Design (in my opinion) is planning out what good and bad things are for a given tool and determining how to express that through the UI.

<comment><USER23> > Design (in my opinion) is planning out what good and bad things are for a > given tool and determining how to express that through the UI.

I disagree with the premise you have that the designer deciding what is good and bad is the whole or even the right story. I think I might agree with the implication that a system should make doing cognitively difficult/safety critical things easy but there is no possible way to plan for all eventualities, that's why we have 'intelligent' controllers in ultimate charge.

One day we might have artificial intelligence in charge but we're not there yet.

So instead of the goal of good UX being the designer planning out what is good and bad, it is much better to design a system that reduces cognitive load but presents information about the current state of the system in the most obvious and intuitive way possible. It should do everything it can to make sure the operator understands the current state of the system.

In terms of operating complex physical systems like ships and aircraft the ultimate goal of designing control systems is to simultaneously take as much of the burden off the operator as possible but present all information needed in order to bring the system back to an _understood_ state as rapidly as possible following deviation from that state. This is the only way to maintain _control_.

It's reasonable to try and make it difficult to get to a state that is 'uncontrolled'. But it's imperative that more credence is given to getting a system back to an understood state once the controller finds them self in one that's not understood. It may get to this state in a way the designer didn't plan for, so getting out of it has to be incredibly quick and easy.

Personally, I put more stock in getting the system in an understood state than a controlled one as from there it's easier to return to control. Without understanding the state of the system it's easy to make further mistakes.

</comment></comment></comment></comment></comment><comment><USER24> Amazing that someone would design in multiple steering wheels, only one of which is active, and no big indicator to make it super-obvious which one it is.

Also amazing that there's a mode where moving a control sometimes controls all engines, sometimes just one.

<comment><USER25> > Also amazing that there's a mode where moving a control sometimes controls > all engines, sometimes just one.

This is a fallback in case the primary rudder fails. You can still shift left or right, but you will take more time and it will be far less precise than using the rudder.

This is also valid for aircraft, where not only the rudder can be compensated but also the elevator (aka up/down) by simultaneously modifying the power of all engines. You can see a list at [https://en.wikipedia.org/wiki/Flight_with_disabled_controls](https://en.wikipedia.org/wiki/Flight_with_disabled_controls).

<comment><USER26> The UI issue being that ganged control should have been the default, but separate control was instead.

</comment></comment></comment><comment><USER27> Everyone in the chain of command in 7th fleet (from ADM Smith on down through the captains and those standing watch) should have been separated and potentially prosecuted for negligence. UI confusion would be an excuse for an untrained civilian being put on the bridge and told to run the ship, but not for professionals, and obviously many systems failed for this to happen. When the military runs well, it runs on accountability -- there's been a serious shortage of that, especially above O-6, for a long time.

"Retiring" without losing rank doesn't cut it.

<comment><USER28> From what I hear the Navy has been very diligent about accountability. There are problems you can't really hard-ass yourself out of.

<comment><USER29> Multiple crewman have died from multiple preventable errors in multiple incidents. I haven't heard about any firing squads for COs? Normally we Americans are so enthusiastic about severe penalties? Watch-keeping and safe navigation are _boring_ , so officers need extra incentive to pay attention to them!

<comment><USER26> "Preventable" doesn't mean "preventable by harsher discipline".

<comment><USER29> Haha this has got to be a reference to theWarOnDrugs...

<comment><USER26> Not _intentionally_. But now that you mention it...

</comment></comment></comment></comment></comment></comment><comment><USER30> Actual naval experts in HN notwithstanding, I think it's worth remembering that a little knowledge, at times, can be a dangerous thing. This is true of many topics on HN that are only obliquely related to software engineering. Silicon Valley has earned a great deal of confidence by disrupting other industries by out-thinking their experts, but perhaps we should temper that confidence a little, least it becomes hubris...

Bottom line, if we're going to dismiss experts, I think we should be armed with a little more than the knowledge we garnered from an internet article.

</comment><comment><USER31> Aside from the lack of clarity about which station has control over what, which should be made _really_ obvious, with additional warnings when someone sets a control input on an inactive station, this seems bizarre to me:

 _While the Ship 's Control Console has a wheel for manual steering, both steering and throttle can be controlled with trackballs, with the adjustments showing up on the screens for each station._

I've never been on the bridge of a ship, but I've operated a lot of vehicles including boats, ATVs, snowmobiles, cars, bulldozers and once, an army Blackhawk helicopter simulator. These very disparate vehicles had one thing in common: there's a relationship between the position of any movement-related control and the movement commanded, and there are stops at the limits of control input.

Trackballs do not have either property, and I'm having trouble thinking of advantages they might offer in this application.

<comment><USER32> I have been on the bridge of a ship, as an Officer of the Watch in the Royal Navy.

Ships have both open loop and closed loop control systems. Closed loop is the normal mode of operation, but there are open loop systems to fall back to. The procedure tends to involve sending someone down to the rudder to communicate back the actual angle of the rudder.

The difference between a warship and a most other vehicles is that you can't simply stop a warship and get out. You need to be able to fight even if you've lost the feedback loop from the bridge to the rudder. For the comparison to the blackhawk, in a ship you can at least do something about mechanical failures in control systems.

</comment></comment><comment><USER33> _The Navy 's investigation found that both collisions were avoidable accidents. And in the case of the USS McCain, the accident was in part caused by an error made in switching which control console on the ship's bridge had steering control_

So, basically this was a reprise of the AF 447 crash at sea, where lack of clear command authority combined with a maddeningly poorly-thought-out UI resulted in a serious accident with loss of life.

At least they didn't have genuine malfunctioning hardware on top of everything else, the way the Air France crew did. They just thought they had a malfunction.

<comment><USER34> >So, basically this was a reprise of the AF 447 crash at sea, where lack of clear command authority combined with a maddeningly poorly-thought-out UI resulted in a serious accident with loss of life.

I don't want to take this off on a tangent, but this theory of the AF 447 crash keeps getting repeated online despite the fact that the accident report did not conclude that the UI was a factor.

If it's got to the point where the pilots have lost track of who's flying the plane, are ignoring the (audible) "dual control" warning, and are making conflicting control inputs, the plane is probably going to crash anyway. Linking the sticks physically has potential safety downsides in addition to safety upsides (e.g. in the case where one stick gets stuck, or a incapacitated pilot holds it in a particular position).

See e.g. here for further info on sidesticks and safety:

[https://aviation.stackexchange.com/questions/14027/sidestick...](https://aviation.stackexchange.com/questions/14027/sidestick- safety-concern)

<comment><USER35> I'd call it an interpretation, not a theory. But clearly the conflicting inputs was a UI problem, and while there may be tradeoffs, a better UI could have prevented the AF 447 crash.

<comment><USER36> Basic airmanship could've prevented the crash too. The pilot-in-command got a stall warning and pulled back on the stick, climbing to 38,000 feet.

That's not a UI issue, it's a forgetting one of the most fundamental rules of flying issue.

[https://aviation.stackexchange.com/questions/1418/what- happe...](https://aviation.stackexchange.com/questions/1418/what-happens-when- an-airplane-stalls-and-why-do-pilots-practice-it)

<comment><USER37> You normally can't stall an Airbus aircraft, except in cases where the flight mode changes as it did in this situation. This was a huge part of the problem, an emergency occurred and the pilots were effectively flying an aircraft they hadn't flown before.

Fully pulling back the stick is what you'd normally do in an Airbus to gain altitude. It's guaranteed not to stall the plane.

<comment><USER36> > Fully pulling back the stick is what you'd normally do in an Airbus to gain > altitude. It's guaranteed not to stall the plane.

I'd love to see some documentation on "pull back in a stall". In fact, this is all I could find:

[http://www.pprune.org/tech-log/415373-new-airbus-stall- recov...](http://www.pprune.org/tech-log/415373-new-airbus-stall-recovery- procedure.html)

</comment></comment></comment></comment></comment></comment><comment><USER38> >At this point, everyone on the bridge thought there had been a loss of steering. In the commotion that ensued, the commanding officer and bridge crew lost track of what was going on around them.

now add to that picture (according to your historical preferences) a salvo of the 10 inch battery from an enemy battlecruiser 10 miles away or 2 Moskits rushing at 2.5x Mach ... blaming UI is just so childish and lame. Like our Sun executives blaming market conditions back then 10 years ago when everybody else had already been enjoying the boom for a few years.

</comment><comment><USER39> Maybe I'm too late or too simplistic, but why do ships and aircrafts have so complex control systems in normal functioning modes at all?

Why can't layman ship commander like me just tell the system to be "there" in specific time via hand-drawn or standard route? If my engines malfunctioning, or steering lost it is one thing, but if everything is okay, can't a simple swipe-to-sail iphone app just coordinate all ship controls to "be there in 3m08s" in most effective way according to the safety rules?

Now it seems like all the precise counters and sensors are passed to slow, biased, narrow-focused and error-prone device that is my mind to get goal- related feedback. And this device happens to be proud of being it. As a programmer, I just can't understand it. Do commanders quickly solve unsolvable differential equations in realtime or what?

<comment><USER40> Although I think ship control can definitely be made more user-friendly, what you are asking for is of similar complexity as a self-driving car.

<comment><USER41> Looks more like an aircraft's auto-pilot. It's not something that would look for obstacles, read signs, or take any kind of input from the environment besides current position.

</comment></comment></comment><comment><USER42> Sometimes having too much money is worse than not having enough. With a tighter budget, you have to wonder if such an extravagantly over functional interface would be created.

<comment><USER43> I've seen hundreds of millions (!!) wasted at a university on a program of software projects that failed miserably.

Having too much money allows for unproven, complicated or arbitrarily selected solutions and more bureaucracy that introduces Tragedy of the Commons mediocrity and diffusion of responsbility to address higher-level risks.

</comment></comment><comment><USER44> My friend's boat is a dual engine diesel, 78ft, two stories. It has a controller where you set a course and a computer controls the throttles and rudder. On the very choppy lake of the Ozarks, this is a handy feature.

You're telling me a million dollar guided missle destroyer _can 't_ do this?

<comment><USER29> Everybody come to the beautiful Lake of the Ozarks, where you too can be menaced on narrow inland waterways by giant overpowered wave-making monstrosities like that of 'exabrial's friend!

At least you won't have to worry about uncontrolled USN vessels...

<comment><USER44> HAHA :D

I took a 5mi trip up the channel on jet skis on memorial day weekend. Holy smokes, I thought I was going to die. The channel chop is no joke!

</comment></comment></comment><comment><USER45> The headline is clickbait, and directly contradicts the report's conclusions. The article says as much ("While the report lays the blame on training"), but by that point you've already clicked.

But look at that bridge schematic. There were TEN PEOPLE in that room, and they couldn't keep an eye on the radar, raise a collision alert, radio the other ship, etc. They just completely lost it.

The John McCain was put in a state of complete confusion by a simple control error they themselves made, while cruising along a commercial shipping lane, at peace. How would they have handled an enemy attack?

</comment><comment><USER46> There were multiple causes. The article makes this clear, but the title to the HN post implies there was only one main cause.

The UI should be fixed. There should be a process for helmsmen to report problem UIs.

And of course training. But you can't really train for situations that you don't fully understand, and the people designing the UI are really the ones who need to put the hard work into understanding all these possibilities.

</comment><comment><USER47> On a related note, it occurs to me that UI/UX for car navigation systems and cell phones is an actual life-and-death matter.

Maybe we should treat it differently.

</comment><comment><USER48> Even specialised UIs need to be intuitive. You should need to know the domain (navigation), but not the specifics of everything the UI can show.

The problem with this kind of thing is people are sent on a course, which gives everyone a false sense of control and understanding. Clearly the crew didn't understand it, leading to a panic and wasted time.

</comment><comment><USER49> A billion dollar ship seems like the kind of place it's worth having real physical controls and indicator lights for functions like this.

I get why auto makers love touchscreens, because buttons, knobs and lights are comparatively more expensive than adding another menu entry to the touchscreen, but that's not the case in an expensive ship.

</comment><comment><USER50> Alan Cooper observes in his book Inmates are Running the Asylum than the majority of non-terrorist related airline disasters are caused by bad UI.

Not instrumentation as such, but the modern version of it which is the "interface."

One example he cites is a pilot selecting a destination beacon using a "simple" drop down menu. 2 possible options, similar in name and adjacent on the alphabetized list are deadly in difference. One is the correct orientation, the other takes the plane directly into the side of a mountain.

Given the state of confusion that is modern UI design, this revelation is not too surprising.

</comment><comment><USER51> UI flaws have hit the Navy before, with even worse consequences [1].

[1] [https://en.wikipedia.org/wiki/USS_Vincennes_(CG-49)#Iran_Air...](https://en.wikipedia.org/wiki/USS_Vincennes_\(CG-49\)#Iran_Air_Flight_655)

<comment><USER52> Nothing I see in that article (or anything else I've seen about the incident) attributes it to a UI issue.

Not all errors made by users are the fault of the UI.

<comment><USER51> You're right: nothing in that article mentions the UI.

I learned about the incident in my computer ethics class in college (along with Therac-25, etc).

Quickly-skimming, it looks like Cracked has a decent writeup of the UI issue specifically [1].

[1] [http://www.cracked.com/article_19776_6-disasters-caused- by-p...](http://www.cracked.com/article_19776_6-disasters-caused-by-poorly- designed-user-interfaces.html)

<comment><USER53> Because that website is cancer if you don't have an ad-blocker, I'll quote the relevant text:

> The screen showed the operator what objects were detected on radar, and if > he clicked on an object, it would track it. But if the operator wanted to > get more information about the object (in this case, by listening in on its > radio signals) to find out what it actually was, he had to move a separate > cursor and click on the object again.

> It's clumsy and unintuitive, and it made it really easy to forget which > thing they were highlighting at any given moment -- the operator can be > tracking one object and have it display the information for a completely > different one because he forgot to move the other cursor. It's the kind of > user interface that wouldn't make it out of the testing phase of a cheap > browser game. And it cost the passengers of the plane their lives.

> That's because the operator in the USS Vincennes thought he was listening to > the incoming aircraft (the Airbus full of innocent people), because that's > the thing he selected, when he was actually receiving signals from a parked > F-14 several miles away, because that's where his other cursor was.

> Granted, the transmissions alone wouldn't be reason enough to shoot down a > plane: They'd also have to think that it was moving like an enemy aircraft. > Unfortunately, the stupid system made that mistake pretty easy, too. Instead > of telling the operators at the Vincennes if the approaching plane was > ascending or descending, the system just showed them the present altitude on > a smaller monitor. The operator had to write down or memorize the altitude, > wait a few seconds, then ask again and mentally compare the two results to > see if the aircraft was going up or going down.

> Because of this, a calculation error led an operator to report that the > Airbus was descending toward the USS Vincennes, like a combat aircraft > would, when it was probably getting the hell away from them as fast as > possible.

</comment></comment></comment></comment><comment><USER54> > The report found that the McCain did not have the right type of watch on > duty for navigation in congested waters and that watchstanders' training was > insufficient. But there was never a warning signal from the Alnic of > impending collision or a change of course by the merchant in an effort to > avoid the collision. "Despite their close proximity, neither JOHN S MCCAIN > nor ALNIC sounded the five short blasts of whistle required by the > International Rules of the Nautical Road for warning one another of danger," > investigators found, "and neither attempted to make contact through Bridge > to Bridge communications."

What a comedy of errors.

</comment><comment><USER55> The headline is inaccurate. While the design of the bridge leaves a lot to be desired (in the eyes of laymen), the real issue is an incredible dereliction of duty by 7th Fleet and the USN in general in terms of training and staffing.

</comment><comment><USER56> I've been on the bridge of many commercial ships including giant yachts and cruise ships during trafficked maneuvering. They never have that many personnel involved on the bridge. Maybe that is part of it?

</comment><comment><USER57> Alan Cooper wrote some books about User Interface design and this really reminds me of his books and talks.

When you cross a car with a computer, what does happen?

When you cross a ship with a computer, what does happen?

Ship steering and management was developed in hundreds of years, than comes the computer and changes everything in some decades ... no wonder, that some friction happens.

I am not anti computer, because I am a developer myself, but you must be very carefully in designing these things. I even see it in our modern cars and cell phones ...

</comment><comment><USER58> "His theoretical insights are grounded in an extended analysis of ship navigation—its computational basis, its historical roots, its social organization, and the details of its implementation in actual practice aboard large ships.":

[https://mitpress.mit.edu/books/cognition- wild](https://mitpress.mit.edu/books/cognition-wild)

</comment><comment><USER59> Shouldn't it have some kind of automated collision avoidance that would have at least given an optional course correction?

<comment><USER60> I sail regularly in the waters where this occurred. They are extremely crowded with large ships, small fishing boats, and more.

The Navy ship was moving at 12 knots which is relatively fast in the local context. Not only does this open them to a violation of the Safe Speed Rule discussed in another comment, it means that any automated course correction would have a decent chance of putting them on a new collision course with a different boat. Perhaps even a small one their radar will not see.

The solution is to slow down. This is well known in nautical practice: if things are not going your way, slow down. If you are not sure what to do, slow down. If you are unable to control your vessel, slow down.

</comment></comment><comment><USER61> I would be interested to see how much liberty the contractors who develop these systems are given. Are they given a rigid spec by the Navy and expected to implement it exactly or are they given a general proposal which allows them to iterate on UI from lessons learned from previous accidents caused by confusion.

</comment><comment><USER56> Good maritime discussion on gcaptain

[http://forum.gcaptain.com/t/of-course-we-all-knew-this-it- wa...](http://forum.gcaptain.com/t/of-course-we-all-knew-this-it-was-the- navees-fault-twice/46496/2)

</comment><comment><USER62> I'm sure we've all read "The Inmates are Running the Asylum" by Alan Cooper.

</comment><comment><USER63> Reminds me of the book "Set Phasers on Stun" which details stories of poor designs that caused deadly disasters. An essential read for anyone designing these types of systems.

</comment><comment><USER64> It's not necessarily the UI that must have been confusing, it might have been that these modes of operation are inherently confusing.

</comment><comment><USER65> Pretty sure all collisions are avoidable.

</comment><comment><USER66> There was a big ferry accident involving a similar transfer of control problem in the New York harbor.

</comment><comment><USER67> not surprised

</comment><comment><USER68> Nope; No, just not at all:

UI Confusion is never "ultimately" the cause for accidentally killing people through poor operation of a $2 billion piece of military equipment. A UI may suck, many do, in or out of the military. So, training. and then more training.

I don't have a high stakes job, but if I allowed code-completion to drop tables, commit the change, delete the backups, and then burn down the building... well, that's not on the UI, that's on me.

So unless we're talking MS Word Clippy-- and I think the article would have mentioned that-- UI can't take the fall on this.

Besides: It began with the Helmsman sending all control instead of just throttle control to the Lee Helm station. That mistake isn't explained as a UI issue, it's glossed over, but everything came from that initial screw-up. Sure, afterwards there was confusion, but even then, "OMG WE LOST ALL STEERING INCREMENT THE IDIOTIC PANIC OPTION VARIABLES!" isn't really an acceptable response. How about, calmly, "Helmsman double check that control assignment if you please <insert navy jargon cliche />"

<comment><USER69> Interestingly, this is the opposite of the direction much of the tech industry has been moving with post-mortems.

\- [http://firstround.com/review/this-is-how-effective- leaders-m...](http://firstround.com/review/this-is-how-effective-leaders-move- beyond-blame/)

\- [http://code.hootsuite.com/blameless-post- mortems/](http://code.hootsuite.com/blameless-post-mortems/)

\- [https://codeascraft.com/2012/05/22/blameless- postmortems/](https://codeascraft.com/2012/05/22/blameless-postmortems/)</comment></comment>


Thanks HN: That time you saved a bunch of lives - <AUTHOR> http://tumblr.amitgupta.com/post/65865424421/why-scott-blaine-is-great

<comment><AUTHOR> Hacker News was incredibly kind to me two years ago when I was diagnosed with Leukemia (AML). Many friends' posts made it to the front page here:

\- [https://news.ycombinator.com/item?id=3083770](https://news.ycombinator.com/item?id=3083770)

\- [https://news.ycombinator.com/item?id=3149337](https://news.ycombinator.com/item?id=3149337)

\- [https://news.ycombinator.com/item?id=3297091](https://news.ycombinator.com/item?id=3297091)

After about a hundred days of friends registering & campaigning, chemo, drives, press appearances, Twitter, Facebook, and Tumblr posts, I found a donor:

\- [https://news.ycombinator.com/item?id=3482119](https://news.ycombinator.com/item?id=3482119)

HN played a huge part in making that happen. I want to say thanks not just for me, but for all the others that gotten helped through our efforts in the past two years alone.

Reminder: It's easy to register, and easy to save someone:

\- [http://bethematch.org/Support-the-Cause/Donate-bone- marrow/J...](http://bethematch.org/Support-the-Cause/Donate-bone-marrow/Join- the-marrow-registry/)

<comment><USER2> Awesome, be neat to know how many lives were saved this way overall! I also registered because of you!

I still have this great idea that NBMR/marrow.org should partner with 23andme.com, but I didn't get anywhere trying to contact someone at marrow.org about it (though I wrote you to ask for your contact there and sent an email, thanks for quick reply!). Still think it could be awesome and save a ton more lives (gist of the idea was they both need to run DNA sequencing, and 23andme could offer a discount or something to anyone who also agrees to register for marrow donors list), but someone told me the sequencing needs may be different for each of their needs, and perhaps they already considered the idea themselves... but in case you know anyone else to talk to about it, would be awesome to get more people off the sidelines with a small 'bribe' :-)

<comment><AUTHOR> Thanks so much for registering!

Agreed it'd be awesome to get them working together. Anne Wojcicki had reached out and I had a call with her and a couple other folks at 23andme during my 100 days isolation period after the transplant.

They seemed interested, I'm not sure how far it got. I'm guessing privacy issues/conflicting priorities got in the way, but I'll drop her a line to see if they're still thinking about it.

</comment></comment></comment><comment><USER3> One of the things I learned on HN back when Amit's story first came up was that many people who register as donors for a specific person end up declining to make a donation when they get contacted in a different context a few months/years later, and that's really a shame - so huge kudos to Scott for going ahead with this after all that time, because that's a crucial part of the equation.

</comment><comment><USER4> One more thing gay people aren't allowed to do [unless they're on a serious dry spell or they're celibate]. :(

<comment><USER5> Yeah, that was the first thing I checked for as well. Note that the restriction is specifically on MSM, not 'gay people'.

There is a growing body of medical groups pushing for a relaxation of the indefinite deferral period for MSM, including the American Red Cross and America Blood Centers. The deferral period in some other countries is less strict, down to a year in the EU.

<comment><USER6> One year is hardly progress unless it takes in to account people in monogamous relationships.

</comment></comment></comment><comment><USER7> Note that Canadians should check out OneMatch [http://www.onematch.ca/](http://www.onematch.ca/)</comment>


An Artificial Intelligence Developed Its Own Non-Human Language - <AUTHOR> https://www.theatlantic.com/technology/archive/2017/06/artificial-intelligence-develops-its-own-non-human-language/530436/?single_page=true <comment><USER2> No bites eh? Okay then I guess I will weigh in. Maybe if I assume the "HN user who knows everything about this particular subject" voice, it'll poke a bit of conversation out of someone else who like me doesn't want to talk to an empty room but is happy to consider points someone else has made.

If anything this demonstrates the opposite of what the article was stating. The chatbots weren't smart enough to develop their own language, they were ignorant enough of how english works to corrupt it while still keeping it 'in- bounds' of their existing rules.</comment>


The medieval marvel that most people miss - <AUTHOR> http://www.bbc.com/travel/gallery/20170427-the-extraordinary-angel-roofs-of-england- <comment><USER2> Not accessible from within the UK..

We're sorry but this site is not accessible from the UK as it is part of our international service and is not funded by the licence fee. It is run commercially by BBC Worldwide, a wholly-owned subsidiary of the BBC, the profits made from it go back to BBC programme-makers to help fund great new BBC programmes. You can find out more about BBC Worldwide and its digital activities at www.bbcworldwide.com.</comment>


Cocktails for programmers - <AUTHOR> https://github.com/the-teacher/cocktails_for_programmers/blob/master/cocktails_for_programers.md <comment><USER2> The title "Cocktails for programmers" gives me the same feeling as would the phrase "Leaf blowers for stamp collectors".

Yes, a stamp collector might use a leaf blower, but it would not be relevant to collecting stamps. On the contrary, using a leaf blower _while_ collecting stamps would be… inadvisable.

<comment><USER3> Agreed.

Further reading: [http://old.ryanfunduk.com/culture-of- exclusion/](http://old.ryanfunduk.com/culture-of-exclusion/)

<comment><USER4> I can appreciate not liking the brogrammer phenomenon, and not being interested in conferences that are so party-focused, but this guy really has a huge bug up his ass about other people enjoying themselves. "I'm not interested in 'partying hard', I want to talk with like-minded people about subjects I don't necessarily get to talk about at the office." Well, guess what, you can't force people to sit down and talk nodejs with you if they want to drink instead. Sorry the world isn't the way you really really want it to be.

The guy seems to be interpreting a lot of his examples in the worst possible light, too. Example: Q: Is there space set up for hacking? A: We have done this for previous conferences, but to be honest people were having too much social fun to really take advantage of the space. Translation: Y U NO DRINKING!?

That's a stupid translation. They set up hacking space before and very few people used it, so they didn't bother this time. You have your cause and effect backwards if you think this means they're trying to force you to drink.

Or: "Perks for working for them include dental coverage, and 'weekly happy hour'. Those who don't want to participate in getting sloshed regularly... need not apply?"

Jesus, dude, settle down. You've taken a perk of employment and turned it into a statement that if you don't drink you're not welcome? Please let go of your persecution complex. I know it's really fun to be indignant that others encouraging you to have a good time is so totally unfair, but it's really no different than people saying "No seriously, The Wire is fucking fantastic! You have to watch it!"

Interacting with humans isn't that hard if you allow yourself and others to actually act like humans.

<comment><USER2> > you can't force people to sit down and talk nodejs with you if they want to > drink instead.

Apparently, if you give most technical conference attendees the option (and venue, drinks, transport, etc), they _will_ opt for going drinking in environments not suited for conversation. If this happens, I interpret it as a _failure_ of the conference organizers. Why? Because their job is to organize a _conference_ , not a party. If they want to leave some time for people to party (or pray, or go skinny-dipping, or windsurfing, etc.), then they can do so. However, to _actively encourage_ people to be non-networking and to not talk (usefully) about the actual conference topic is, in my view, an anti- pattern of conferences.

<comment><USER5> Perhaps your idea of what a conference is, and what is well-suited for it, does not mesh with observed reality. Maybe that sort of conference just is not for you (I know your idea of a conference is not for _me_ ).

I've got to say though, even _heavy_ drinking has never stopped me from having technical conversations with people, even in crowded bars...

<comment><USER2> (I think you are reading into my comment something I did not write. I do not know what you think my "idea of a conference" would be.)

I have tried to have technical conversations at parties and in bars with people I know to be interested in and knowledgeable in the topic. It's basically impossible.

Firstly, the loud music and other conversation makes it very hard to hear what they're saying, and the things said therefore tend to be simplified into what can be said simply in short words.

Secondly, they are often drunk and/or more interested in talking about beer or something than the topic they presumably are at the conference to advance. This is, of course, understandable; they're not _expecting_ to have anything whatsoever to do with the conference topic at the party, since nobody else is, either.

Thirdly, there are no whiteboards to use as discussion aids. It's also quite dark, and it's often cramped so you can't easily show somebody something by moving around. Basically, bars and party rooms are not exactly conducive to productive discussions. (In the past there would also be no internet and, further back, no computers, but that has thankfully become a non-issue these days.)

<comment><USER5> My issue is this line: _" Because their job is to organize a conference, not a party."_

You are saying that conferences should not be like parties, because conferences are not like parties. You are just using your restricted definition of conference (not like a party) to support what you think a conference should be (not like a party). My take on it is that some conferences _empirically do_ have many similarities to parties. This doesn't make them 'not conferences', so saying _" their job is to organize a conference, not a party"_ is setting up a dichotomy that doesn't actually exist.

If that isn't your sort of conference, then no problem, not everything is for everybody. _Personally_ I prefer more intimate technical conversations over a beer, a bar napkin, and a cellphone than sterile professional presentations in front of a whiteboard. Obviously you do not, and that is perfectly fine as well. There is room in this world for both; there is no reason to discourage one or the other from existing.

<comment><USER2> > You are saying that conferences should not be like parties, because > conferences are not like parties

Not quite.

What I am saying is that conferences and parties have different goals. The goal of a conference is to advance the field. The goal of a party is to have fun. The goal of a conference is not advanced by organizing a party, nor is the goal of a party advanced by organizing a conference.

A conference _can_ (and perhaps _should_ ) have many elements of a party in it — evening social activities, perhaps even in a bar where alcolhol (gasp!) is consumed. All of this may be perfectly fine. But, these activities should be organized with _the goal of the conference_ in mind.

However, what many conference organizers seem to do is fill the days with talks, (while minimizing the time between talks to fit as many as possible), and then on the evenings they try to organize the best _party_ they can think of. The best _party_ , mind you, not the best _socializing activity_ , which might have advanced the networking in the field, but the best _party_ , whatever the tastes of the organizers and/or the prospective attendees.

This makes the conference a series of undiscussed talks in the daytime, followed by a series of usually pounding party keggers at night. The talks can be watched at home if they are filmed, and the parties can be had locally, too. There is no reason to attend these kinds of conferences. Unless, of course, you are _already_ connected and go to any number of conferences a year and meet all the same people — your party buddies.

<comment><USER5> > _The goal of a conference is to advance the field. The goal of a party is to > have fun. The goal of a conference is not advanced by organizing a party, > nor is the goal of a party advanced by organizing a conference._

That is nothing more than your _personal take_ on what a conference _should_ be. The reality is that many conferences _aren 't_ like that. It is no skin off your back if other people have a different idea if what a conference should be, and implement their vision of a conference.

Nobody is saying you have to go enjoy a party-like conference, and all I am saying is that you in turn should not tell other people that they shouldn't.

<comment><USER2> I still think you see me through some kind of tinted shades which makes you think I am saying things I am not saying.

However, I have run out of ideas on how to explain myself in yet other ways.

EDIT: I think now that we are having a word definition debate here. When you say that "many conferences aren't like that", then I would call those themed parties, not conferences.

<comment><USER5> You're saying that conferences should not place too much emphasis the party aspects, because that is not the purpose of a conference. Right?

Well I'm saying that I think that is too imposing.

It would be like me saying that bowling alleys should be careful not to place too much emphasis on drinking, because the purpose of a bowling alley is to compete with others at rolling a ball at things. Who am I to say that others shouldn't think that the purpose of bowling is to drink with friends while occasionally rolling a ball around? I shouldn't impose my idea of the purpose of bowling on other people.

I hope it is clear what I mean.

<comment><USER2> I think you are doing the same faulty comparison you made with board games in another comment. The purpose of all those activities (party, board games, bowling) is _to have fun_. I'm saying that the very definition of a conference is that it has a different goal. Conferences can (and _should_ , by all means possible) be as fun as possible, but _with the goal of the conference taking slight precedence_.

Since having a party-like atmosphere will make people come to the conference, by all means conferences should have them. But one should keep in mind that the party-like atmosphere does not obscure or negate the purpose of the conference in the first place.

<comment><USER5> _" I'm saying that the very definition of a conference is that it has a different goal. ... the goal of the conference taking slight precedence."_

So long as you realize that this sentence is just a statement your own _personal_ opinion, not some sort of universal truth about conferences, then I don't think we have any issue. The goal, or purpose, of a conference is something for organizers and participants to decide for themselves.

(The answer to _" You think maybe I should write a long-winded self- aggrandizing blog post about this culture of exclusion?"_ is _" No you should not jlgreco, because that would make you (even more of) an insufferable cock."_)

<comment><USER2> Well, I guess it comes down to what the definition of "conference" is, I suppose.

<comment><USER6> Yes. That's why he opened his initial response with "perhaps your idea of what a conference is [...]"

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER7> Malibu, Crème de Menthe, Jager, Triple Sec, Vodka & Coke, Kahlua. These seem like cocktails for programmers... earlier in their careers, shall we say.

<comment><USER8> My wife is a bourbon/whiskey snob. She mocks me when I make a jack and coke.

<comment><USER7> (a) your wife is awesome, (b) I too am a whiskey snob, (c) there's really nothing wrong with Jack Daniels or for that matter with jack & coke, (d) there is something wrong with mixing vodka and cola and calling it a cocktail.

<comment><USER9> there are many things wrong with Jack Daniels.

<comment><USER10> But the good thing about it, unlike its superior rival George Dickel, is that JD is not owned by Diageo. It's a pity that I have to boycott Dickel because of that, but I'm not giving my money to those assholes.

EDIT: and yeah, rayiner's wife is awesome :)

<comment><USER11> That's a lot of brands to boycott, including, sadly Guiness.

<comment><USER10> Unfortunately yes. But there is lots of good stuff outside the Diageo umbrella :)

</comment></comment></comment></comment></comment></comment></comment><comment><USER12> A good cocktail showcases and highlights the component spirit(s) to make a more interesting and (hopefully) tasty drink.

Unfortunately when cocktails are based on nasty components, they often end up trying to disguise the spirit with sugary mixers like fruit juice or coke.

If you're interested in cocktails and don't mind diving in the deep end, try an authentic Sazerac:

[http://www.esquire.com/drinks/sazerac-drink- recipe](http://www.esquire.com/drinks/sazerac-drink-recipe)

Remember: the point is to highlight the primary spirit, so start with something good: [http://www.anchordistilling.com/spirits/old-potrero- straight...](http://www.anchordistilling.com/spirits/old-potrero-straight-rye- whiskey)

<comment><USER10> +1

Felten's book ( [http://www.amazon.com/Hows-Your-Drink-Cocktails- Drinking/dp/...](http://www.amazon.com/Hows-Your-Drink-Cocktails- Drinking/dp/157284101X) ) has a good overview of all the classic cocktails, and in general is an interesting read. I have yet to try the Sazerac, having 3 bottles of rye at home... Shame :(

Also, the "original" pre-rye Sazerac was done with Cognac, gotta try that at some point as well.

</comment></comment><comment><USER13> It's missing the BASIC:

        10 tequila
        20 GOTO 10

<comment><USER14> A beginning programmer will think that's an infinite loop, but anyone familiar with tequila will know better.

<comment><USER15> It'll run until the stack overflows.

<comment><USER16> But gotos don't add a layer to the... oh. Oh, I see.

</comment></comment></comment></comment><comment><USER17> Gotta chime in here because I do this professionally.

This is why people don't like cocktails. These are seriously terrible. I wouldn't serve any of these, ever.

I don't want to be overly negative here, but no number of pull requests will fix this. Rather than try to salvage these, I will offer take out anyone who's interested and introduce you to a bunch of the top folks in the food and drink biz. There's really not a friendlier group of people, and learning about wine and spirits is a lot of fun.

<comment><USER18> I disagree that "this" is why people don't like cocktails. That's a very broad statement, encompassing thousands of (existing) drinks that are great. I think it's more of a taste preference and has little to do with bad prior experiences. If said people are basing the totality of drinking cocktails based on their first go at it, there may be a bigger problem there.

<comment><USER17> Over here ([https://news.ycombinator.com/item?id=6374955](https://news.ycombinator.com/item?id=6374955)) you say, "I never quite acquired a taste for more refined liquors."

Why not? I'm afraid you haven't had anything good. There's no reason you shouldn't like "more refined" (good) products if you like the bad ones. Also, it's not just the quality of the product. For instance, Jaegermeister is a quality product, but the drink he makes with it is arbitrary. Would you like a tomato, peanut butter, and mustard sandwich?

The offer stands. Take me up. I'll buy you a drink.

<comment><USER18> I have a very insensitive palette, which is probably to blame for apathy when it comes to variation. Most coffees, liquors, other drinks, tobacco products, and even foods taste almost exactly the same to me, despite consuming different brands/combinations/recipes of all of them for years, whereas my peers have developed discernible tastes when it comes to such things.

Or it could be as you say and I've never really indulged in what could be considered truly superior products. Sometimes I'm not really sure.

I will indeed. I'm curious if it's just me.

<comment><USER19> Honest question....are you a tobacco user? If so, that explains it. I am, and also have an insensitive pallette. Never notice it except in those "quitting" passes.

</comment></comment></comment></comment></comment><comment><USER20> So, PHP is the one where they mix all of the ingredients in your liquor cabinet together and top it with a raw egg, right?

<comment><USER21> I was thinking that the recipe for PHP would be: 1\. Drink entire bottle of tequila 2\. Vomit into a dirty glass 3\. Drop glass

<comment><USER22> As a PHP developer who likes tequila. I'm down for this.

<comment><USER23> drink(tequila) or die();

<comment><USER24> Come on, man.

        drink($tequila) or die();

<comment><USER25> So close...

        drink($tequila) or die("Vomiting...");

</comment></comment></comment></comment></comment></comment><comment><USER26> The C#, it turns out, is the same as a Java but with a finer stock of liqueurs. The recipe for C#.NET however, is proprietary and no one can quite explain why one in a thousand makes you ill, or why the bottom of the glass seems to fall out sometimes.

<comment><USER27> In which way C# and .NET is proprietary?

WCF, WindowsForms, EntityFramework are proprietary. But nobody in sane mind will use them.

<comment><USER28> I am proficient in all three of those technologies.

I was about to object... but yeah, you're pretty much spot-on. I still say that, except for the omgwtfbbq databinding stuff, Winforms was a fine technology for its time. It's just that its time is past and MS doesn't ever update anything, they just abandon-and-replace with something horribly baroque.

EF is my definition for "so close, and yet so far".

I have no idea what the heck happened with WCF though. Seriously, I can't even find the kernel of good ideas that got corrupted in the process of implementation like I can with those other two.

<comment><USER27> WinForms - in fact is OK. It's just old.

WCF and EF - "oh noes". My eyes are bleeding with just one look at this.

Microsoft can make something simple and brilliant as TPL, but on other side we have such overengineered behemots as WCF and EF.

</comment></comment></comment></comment><comment><USER29> Another cocktail is the "Tschunk", which is hugely popular with hackers here in Germany. See the recipe here: [https://entropia.de/Tschunk](https://entropia.de/Tschunk) (the main ingredient, a carbonated, caffeinated soda called "Club-Mate" is difficult to source outside of Germany, though).

<comment><USER23> Hackerspaces around the world tend to figure out how to get it. It's hard to get in Poland, and yet in Hackerspace Kraków we have a crate ;).

<comment><USER30> It must be the unofficial beverage of hackerspaces -- the one in Canberra, Australia has an old glass-door refrigerator case full of it, and the empties line the back wall: [http://www.flickr.com/photos/wil5oncle7us/8764800032/in/pool...](http://www.flickr.com/photos/wil5oncle7us/8764800032/in/pool- makehackvoid)

<comment><USER23> It is.

[http://hackerspaces.org/wiki/The_Club_Mate_Pattern](http://hackerspaces.org/wiki/The_Club_Mate_Pattern)

</comment></comment></comment></comment><comment><USER31> Awesome idea. My friends at ActiveState had a release party and went to the bar to celebrate over drinks. One of the guys ordered a round of shots for the group "12 shots please, half Tequila and half Jager" The waitress took him literally and brought 12 shots, all with half Tequila and half Jager.

The release included a GUI version of an existing command line tool because a certain customer wrote in saying "F&*k this DOS prompt BS, I want a GUI".

We now call this awful shot "The DOS Prompt"

</comment><comment><USER32> I don't see a campari one, :D but here goes my daily cocktail:

1\. half glass of Campari bitter. 2\. Ice 3\. orange 4\. a shot of water-soda

(never use tonic or white wine, if you like it a bit more alcoholic then use some cava or champagne [sprinkledwine])

<comment><USER33> Campari and soda is a fantastic drink. Refreshing and not super high in alcohol, yet bitter instead of cloying and sweet. For future reference, since it looks like you are not a native English speaker, the phrase for non- Champagne champagne is "sparkling wine."

<comment><USER32> Thanks for the tip! the correct word in italian is "prosecco"

[http://en.wikipedia.org/wiki/Prosecco](http://en.wikipedia.org/wiki/Prosecco)

</comment></comment></comment><comment><USER34> Ruby, Python and Perl... So nothing strong at the moment?

</comment><comment><USER35> C is pure vodka, hard, powerful and without any flavor.

Assembly is pure ethanol.

Still thinking how would VHDL be... thinking about raw sugar cane to make your own alcohol from there.

<comment><USER36> I think VHDL would be like a chemistry lab. You could create ethanol pretty easily. You could also make a lot of other things.

</comment></comment><comment><USER37> Each to their own, these all look undrinkable though!

<comment><USER38> Change some ingredients and A/B test them.

<comment><USER39> With initial recipes like these, you'd quickly reach very low local maxima.

<comment><USER40> git history serves as a Tabu list, and different people's tastes will serve as a stochastic breakout. If lots of people have a go it will de-facto be a particle swarm tabu. Even with a single starting point there's a good chance of global optimisation.

</comment></comment></comment></comment><comment><USER41> Nice... tomorrow will get "Python" for start I think the result will be "Memory Leak" and party will be over after "Epic Fail" :)

</comment><comment><USER42> Lacks a non-alcoholic option, for programmers who need to do programming.

<comment><USER43> Are you referencing: [http://xkcd.com/323/](http://xkcd.com/323/) ?

</comment></comment><comment><USER44> Hex on the beach.

Sorry.

<comment><USER45> In a big-endian glass.

</comment></comment><comment><USER46> This is nonsense. I'll have a Jameson on the rocks, please.

<comment><USER47> Jameson, aka the whisk(e)y for people who don't like whisk(e)y.

It's smooth, soft and pleasant, nothing like the nasty, grating stuff they produce in Scotland. A favorite of mine, for sure.

<comment><USER10> Scotland has 100 distilleries in 5 major whiskey-producing regions with their own traditions. There is really no such thing as "scotch", they are all different, so this generalization is wrong.

</comment></comment></comment><comment><USER48> I suppose 'brainfuck' would be a Absinthe mix of some sort

<comment><USER49> Absinthe + pear juice is great. Also absinthe + energy drink of some sorts. Though somewhat good absinthe is necessary for it as fake/cheap brands are really horrible.

<comment><USER50> Can you recommend some good ones, preferably ones that are available in the US? I've heard good things about North Shore's Sirène...

<comment><USER49> I can't, sorry. I'm in Europe and drink mostly local ones. But you might check this out for hints [http://www.reddit.com/r/absinthe](http://www.reddit.com/r/absinthe)

</comment></comment></comment></comment><comment><USER51> Now I want a bartending robot with it's own drink-mixing DSL.

<comment><USER52> It appears there's a bartending robot in the works:

[http://www.kickstarter.com/projects/partyrobotics/bartendro-...](http://www.kickstarter.com/projects/partyrobotics/bartendro- a-cocktail-dispensing-robot)

Now you just need an R2 to deliver them. ;)

</comment></comment><comment><USER53> Nice ideas, though I think java is sorely missed here,

<comment><USER54> Rum & Coke: simple, gets the job done, and packed with regret.

<comment><USER53> I was hoping for coffee based :P

</comment></comment></comment><comment><USER55> While not themed after languages and such, I keep a gist of my favorite cocktails I either want to try or the recipes me and my friends have come to enjoy: [https://gist.github.com/dylan/6093669](https://gist.github.com/dylan/6093669)

My engineering pals think me using a gist to store recipes is funny... :P

<comment><USER56> [http://forkthecookbook.com/](http://forkthecookbook.com/)

<comment><USER55> Very nice.

</comment></comment></comment><comment><USER57> I am turning 33, give me a Memory Leak please!

[https://github.com/the- teacher/cocktails_for_programmers/blo...](https://github.com/the- teacher/cocktails_for_programmers/blob/master/cocktails_for_programers.md#memory- leak)

</comment><comment> vezzy-fnord Hmmm...

First we had the 'how to shoot yourself in the foot in X language' jokes.

Now we'll have jokes about what cocktails different programming languages would be. Not bad, I might compile them in a page some day.

</comment><comment><USER58> I'm surprised there isn't a "java" with some sort of coffee +liqueur.

or

Lua Kahlua.

</comment><comment><USER59> Hmmm... so I the recipe for Befunge would be: 1. Pour a pint of beer 2. Pour a shot glass of vodka 3. Drop the glass into the beer 4. Drink quickly 5. Start flowing in all directions

</comment><comment><USER60> Reminds me that webtender is still going strong.

The younguns at work were terrified of its layout and design when I showed it to them but it's a solid site.

</comment><comment><USER61> C# would need to be citrus-y (C and sharp). It would go very quickly but might take a while to build.

</comment><comment><USER62> Why not specify the amounts in centiliters? All the amounts end with 0 anyway.

</comment><comment><USER23> Any ideas for Lisp drink?

<comment><USER63> The bartender hands you the bottles and the shaker, do it yourself.

</comment></comment><comment><USER64> I really like Long Island Iced Tea, what about other hackers?

</comment><comment><USER65> So according to logic, assembler is pure alcohol?

<comment><USER66> Minimal frills I would think

And then there's machine code - industrial alcohol

<comment><USER65> Did you mean Methanol which is like alcohol but toxic.

</comment></comment></comment><comment><USER67> More useful is Mojito Cocktails [https://github.com/yahoo/mojito](https://github.com/yahoo/mojito)</comment>


Career Advice: Scott Adams, Creator of Dilbert (2007) - <AUTHOR> http://dilbertblog.typepad.com/the_dilbert_blog/2007/07/career-advice.html <comment><USER2> I remember this when it was first published - I wish I'd followed that advice 10 years ago.</comment>


Google to Open-source VP8 for HTML5 Video - <AUTHOR> http://newteevee.com/2010/04/12/google-to-open-source-vp8-for-html5-video/

<comment><USER3> This is _awesome_ news. No patent encumbrance means Firefox will support it. Terrific performance means the rest of us will actually use it. Google backing the technology means Youtube, with their unfathomably large proportion of the world's video content, will support it.

Sweet.

<comment><USER4> How would it benefit Google to re-encode every video on YouTube into VP8?

<comment><USER5> Why is everybody talking about recoding? Can't they just keep the current videos as they are and encode new things in a different codec? As far as I know all the old H263 videos on Youtube have never been recoded. And why would they? Recoding H263 to H264 would just degrade quality.

<comment><USER6> I understand what you're saying, and I'd love to be educated if you know more about the topic, but aren't they both perceptual encoders? Ie, wouldn't the parts of each frame they're identifying as unimportant be quite similar?

(I'm quite certain I'm wrong on this point, but I'm interested in learning why)

<comment><USER7> Each encode removes information from the video. No matter how nice the encoders are, the video quality will degrade every time.

<comment><USER6> I understand the sentence, but what I'm trying to understand is why the information removed is (significantly) different - since they're both perceptual codecs, there should be a large overlap in what is removed from the output.

Eg, take a frame which has a solid chunk of blue. Codec 1 removes some of data to make things more consistent and then compresses it. Codec 2 looks at the output of codec 1, sees the consistently large blue area, doesn't see any info worth removing, and compresses it.

<comment><USER5> I don't know all the maths behind it, but try saving a JPG, close it, open it, save it again, repeat a few times. You'll see quality degrade every time you close it. My guess is that the lossy compressors try their best to preserve the previous compression artifacts, but in doing so they introduce more compression artifacts.

</comment></comment></comment></comment></comment></comment></comment><comment><USER8> Kudos to Google for being smart enough to realize that an open web is a win for them in the long run and for having the guts to compete on the strength of their products and not on platform/api lock-in. Obviously it's still an uphill battle to get this adopted across the board but they're setting the right example here.

<comment><USER9> _At launch, On2 went so far as to claim that it could provide "50 percent bandwidth savings compared to leading H.264 implementations."_

Considering the amount of bandwidth Google spends on streaming YouTube content, this move is far from altruistic. The more viewers adopt a bandwidth- superior format, the less terabytes of data to stream, the less the cost of running YouTube. They have absolutely no benefit from any kind of "platform/api lockin" to H.264 or any other video standard, only that there are less bits to stream.

I don't see how it's an "uphill battle" to convince anyone they should use a free standard instead of paying million of dollars in licensing fees per year. I'd expect Microsoft to ship this instead of H.264 in the next major IE, and, if this comes with a good and open hardware interpreter, Apple to follow soon after.

<comment><USER10>
      Considering the amount of bandwidth Google spends on streaming YouTube content, this move is far from altruistic.

Who cares? Companies are allowed to make the world a better place without having to self-flagellate themselves. Google could easily have just paid the H.264 licensing fees and told Mozilla to toss off, or even built VP8 support into Chrome and used YouTube to force-feed it to the world. They chose to cooperate, and should be praised for that.

      I don't see how it's an "uphill battle" to convince anyone they should use a free standard instead of paying million of dollars in licensing fees

Several companies, most notably Apple, have already spent what must be millions of dollars on licensing fees and hardware. Regardless of which is a better long-term choice, it can be very difficult to reverse that much momentum. Not to mention the hundreds of millions of non-consumer multimedia equipment which is designed to use H.264.

Additionally, VP8 does not have much application support yet. It'll take a while for codecs to be written, debugged, and distributed to users. There may be significant lag time before VP8 displaces Theora among F/OSS users, or H.264 on OS X.

<comment><USER11> They chose the path that would lead to the fastest adoption of the technology which lowers their bandwidth costs. Keeping the technology Chrome-only is against their financial interests.

Apple and MS pay yearly licensing fees for H.264. As soon as they adopt VP8, they can stop.

<comment><USER12> Apple and Microsoft are among the H.264 licensors. I think they don't pay any licensing fees:

<http://www.mpegla.com/main/programs/AVC/Pages/Licensors.aspx>

</comment></comment></comment></comment></comment><comment><USER13> This is basically a done deal, fwiw. Other folks who I've talked to in a nda- ish sort of manner have been expecting to not support OGG long term, and instead support VP8 as the "open standard." It's an open secret in industry circles, and this I think confirms it. Can't wait till next week.

</comment><comment><USER14> Are there any chips out there that do hardware decoding of VP8? That's a critical path item to get Apple on board - they've learned from Nintendo; battery life is too precious to sacrifice for a mere codec.

<comment><USER15> VP8 support is currently mostly nonexistent. It's currently just a minor proprietary codec that almost no one cares about or uses. Of course, Google certainly has the money and resources to fix this relatively quickly if they really want to.

</comment></comment><comment><USER16> Ok I am going to say it: I think this finally secures a big big future for Chrome.

It will now be the only browser to support all three of the main codecs - <USER2> Google will control one of the two open source / royalty free ones (indeed it's arguable that status may be more secure that Ogg Theora because, simply, Google are likely to aggressively defend any submarine attacks).

All told - great news.

<comment><USER17> And don't forget that Chrome was the first to come up with one process per tab, and they also ignited a cut-throat JS performance race.

Also clean design with native widgets on supported platforms and overall crazy fast (when I boot my computer, Chrome is the first app the starts).

Mozilla should be worried.

<comment><USER18> What is this mozilla you speak of?

(Being an early adopter since phoenix, already moved to chrome and never looked back)

</comment></comment></comment><comment><USER19> Is it possible for existing H.264 hardware decoder chips to be used to (even partially) help decode VP8? Or will we see a new generation of chips that does H.264 and VP8?

<comment><USER20> Potentially. Theora activists keep repeating that "there's no such thing as a hardware decoder; they're all programmable DSPs", but in addition to programmable hardware you also need the desire and resources to actually implement VP8 decoding firmware for all these different chips.

<comment><USER21> (Odd, in all the HTML5 video debates on HN, I hadn't heard that argument from Theora supporters before.) Most of the hardware decoders in smartphones are programmable DSPs; e.g. TI's OMAP3 family. But there still are plenty of chips out there that use fixed-function h.264 decoders, e.g. TI's DaVinci family. The fixed-function ones are smaller, cheaper, and probably lower power.

<comment><USER22> TI's DaVinci family includes programmable DSP and ARM based solutions and you can buy various 3rd party software implementations of codecs such as H.264 to run on them.

[http://focus.ti.com/dsp/docs/dspfindtoolswresults.tsp?sectio...](http://focus.ti.com/dsp/docs/dspfindtoolswresults.tsp?sectionId=3&tabId=1620&familyId=1300&toolTypeId=65)

</comment></comment></comment></comment><comment><USER23> This is pure speculation but maybe Google uses VP8 in order to negiotiate a better licensing fee once h.264 isn't free anymore. MPEG-LA would think twice about loosing Youtube as a customer. This would go against Google's "Don't be evil" but getting the world to accept yet another video codec will be an uphill struggle, even for Google.

</comment><comment><USER24> Surely making the codec open source isn't in itself that interesting, considering that x264 and FFmpeg form a high quality, open source codec for H.264? It's not the code, but the spec that matters in spreading adoption of VP8. (Of course, publishing the code would create a de facto spec).

More interesting still is the patent issue. VP8 is still effectively irrelevant unless Google announces they've performed a patent search and found VP8 to have no known patents covering its methods (or at least any that might incur licensing fees). After all, it was the patent issue with H.264 that bothered Mozilla.

<comment><USER25> x264 is a codec implementation, not a codec standard. The x264 source code is free, but what it produces isn't (at least in the US). Rumors are VP8 will be free on both counts.

As for the patent issue, Google has no doubt done this during its ~9 months of due diligence while buying On2. Not saying that issues won't come up, but Google apparently felt comfortable with the situation.

</comment></comment><comment><USER26> As the article points out, the big wildcard is Microsoft. I don't see what logical reason Microsoft has for skipping VP8 other than the anti-Google animosity, but that has led to illogical decisions on their part before.

<comment><USER27> I haven't tried this in IE for a while, but can't we do something like push down an ActiveX control or plugin to render this video with IE pretty trivially? It would simply become part of the magic incantation web developers would use to embed video.

Flash did not obtain its dominance by coming installed with IE.

Unless Microsoft actively moves to block it, I don't know that Microsoft's explicit support is actually that interesting.

<comment><USER28> /Flash did not obtain its dominance by coming installed with IE./

That's exactly how Flash won its dominance. It was installed by the PC manufacturers (HP, Apple, Dell, &c) into IE5 and IE6 until it had overwhelming market presence.

Adding video support later on cemented the position, but it was strippers and steaks (for HP, Dell, Apple, &c execs) that won Flash its position.

</comment></comment></comment><comment><USER29> Can VLC decode VP8? Is there a sample video anywhere that I could download?

<comment><USER30> There is a sample video of On2 on this page: [http://video.golem.de/audio- video/2857/on2-vergleich-h.264-u...](http://video.golem.de/audio- video/2857/on2-vergleich-h.264-und-vp8.html) Text basically says that those are crops of FullHD movies.. keep in mind that this movie is from On2, so its validity is at least questionable ;)

<comment><USER29> It does look much better, but I'd love to see the same done by an independent source.

</comment></comment></comment><comment><USER31> This may not solve the problem, as companies like Apple, Microsoft, Adobe, Nokia, etc need to get on board as well. They are likely to continue the same arguments they raised against Theora; most importantly that VP8 is still vulnerable to patent extortion despite being independently developed. It's probably too much to ask for Google to provide indemnification from patent lawsuits, but hopefully they've at least done some work to help assuage these concerns.

<comment><USER32> Adobe is already shipping VP6 as a part of Flash Player, so VP8 should not be a problem. Maybe that is what Google will get for integrating Flash into Chrome, that made news few weeks ago.

MS, Apple and Nokia will be harder nut to crack, because all three of them are patent owners in H.264 portfolio. Nokia may cave when Youtube switches, maybe even MS, but Apple users will have life slightly more difficult for a while.

</comment></comment><comment><USER33> How does this relate to Google's funding of ogg/theora for mobile codecs? [http://google-opensource.blogspot.com/2010/04/interesting- ti...](http://google-opensource.blogspot.com/2010/04/interesting-times-for- video-on-web.html)

Given that theora is based on On2's VP3, could there be enough similarity in the codecs that the theora DSP code is useful for quickly getting VP8 going?

</comment><comment><USER34> Is anyone besides me worried that Steve Jobs is going to say "they tried to kill the iphone, so we will never adopt their evil standards!"? Is the animosity between google and apple enough to stifle development?

<comment><USER35> I think YouTube is enough to drive consumer demand, whatever Steve says.

<comment><USER36> YouTube runs h.264 for iPad and iPhone connections.

<comment><USER37> Google runs YouTube.

</comment></comment></comment></comment><comment><USER38> So we have a video codec. But which container is it put in? MP4? MKV? FLV? And which audio codecs are used? Vorbis? AAC? MP3?

</comment><comment><USER39> This is INCREDIBLY great news and something I've been waiting for to hear for ages. Well done Google!

<comment><USER39> .. or rather "well going-to-do Google"!

</comment></comment><comment><USER40> This is huge. Great news for the Open Web.

</comment><comment><USER41> I'm not seing any confirmation from Google for now or any other sources. This is probably going to happen anyway, but for now I won't take it as a sure thing.

<comment><USER42> It's kind of funny how having false publicity for it now has probably amped up expectations enough that Google would look bad if they _didn't_ follow through.</comment></comment>


Why is import a Python keyword? - <AUTHOR> http://akaptur.github.io/blog/2014/03/16/pycon-prep-import-is-a-keyword/ <comment><USER2> > As far as I can tell, the main argument against an import function is > aesthetic. Compare: "from random import bar" to "bar = > __import__('random').bar"

I agree.

A stronger pro-aesthetic example might be:

        >>> from xml.sax.saxutils import escape    -vs-
        >>> escape = __import__("xml.sax.saxutils").sax.saxutils.escape

As another aesthetic, this is much more complicated with __import__:

        >>> from itertools import repeat as _repeat, chain as _chain, starmap as _starmap

and requires an intermediate variable to reduce import resolution overhead.

(That example is from itertools/__init__.py . The ctypes/__init__.py also has a similarly complicated import-as .)

</comment><comment><USER3> For the common cases of "import foo" and "from foo import bar", having a keyword avoids repeating the module/function name, as in "foo = import('foo')" and "bar = import('foo').bar".

Ignoring this detail, "import" could be simply a function, like "print" and "exec" in Python 3. And with lazy evaluation, even statements could be made into function calls: "if(True, 42, 1/0)" would evaluate to 42 without causing a ZeroDivisionError. The same can be done for assignment: "locals().__setitem__('x', 3)" instead of "x = 3". Keep this up and programs might start to look like this:

        define('fac', ('x',), product(range(1, x+1)))

Which is basically a copy of Lisp:

        (defun fac (x) (product (range 1 (+ 1 x))))

</comment><comment><USER4> One thing which isn't immediately handled is `from foo import *`. There's not really any way to put all of the symbols in `foo` into the current scope with the function syntax.</comment>


This CSS shorthand would be so good - <AUTHOR> https://imgur.com/a/6gFCQu8 <comment><USER2> So your breakpoints have to be ... those exact pixels to use that shorthand?

</comment><comment><USER3> Sure, until you need to add a new breakpoint

<comment><AUTHOR> You could still use the normal way for edge cases, if that's what you mean. I'm not sure adding a new breakpoint would be much less work the old way?

<comment><USER3> No, I mean if your entire codebase is written this way, adding a breakpoint somewhere in the middle of the pack now requires editing every rule that uses this shorthand otherwise the values after the corresponding breakpoint will apply to the wrong breakpoints.

        /* before */
        width: 10px | 20px | 30px | 40px | 50px

        /* after */
        @media (min-width: 360px) { /* here I added a new smallest breakpoint somewhere */ }
        /* ...elsewhere in the stylesheet */
        width: 5px | 10px | 20px | 30px | 40px | 50px
        /*     ^ every rule using the shorthand now needs a new value at this slot */
        /* if you forget to align the slots, you will break every existing layout */
        /* code written the normal way does not suffer from this regression */</comment></comment></comment>