I Watched All of the Chrome Dev Summit 2017 Videos - <AUTHOR> https://redfin.engineering/i-watched-all-of-the-chrome-dev-summit-2017-videos-so-you-dont-have-to-9b62a593c3cb <comment><USER3> > _It's difficult to convince to most web developers to accept these limits, > especially if you don't anticipate selling a lot of products to "emerging > markets" nations. Hitting Google's recommended target often requires a > ground-up rewrite, discarding well-loved JS frameworks._

That's why their target for "emerging markets" devices is _five whole seconds of JavaScript compilation_ , which would hardly be considered acceptable on a device five times as expensive, but that device is not five times as fast on a given core, it's probably something more like one and a half or two, maybe two and a half if you include faster main memory and caches.

Added: I once worked on an ecommerce site where I told my team early on that we would probably do worse than we planned if we built and tested on the latest iPhones and Galaxy devices, and was vindicated basically every week after a certain point. It was so bad that, on 802.11ac WiFi connected to a gigabit downlink with about 15ms round trip latency to the servers, the homepage would take about 10 seconds to display anything at all on an iPhone 6s, and another 8 seconds to finish loading the visible content. Unbelievably, more than three quarters of that time was spent parsing and compiling JavaScript. You don't even want to know what happens when you try to open that site on anything slower than a late 2015 flagship device.

<comment><USER4> After hurricane Maria hit Puerto Rico, I had to drive 15 minutes to get mobile signal. Every website except HN and Gmail (html version) was too slow to load. This experience has lead me to reconsider my opinions regarding performance.

<comment><USER5> Gmail on my AMD FX-8370 at 4 GHZ with 32GB RAM (and 60 MBit connection) takes... 5 seconds to load.

Gmail (HTML)... takes 0.5 seconds. (And about the same on my Netbook with a Celeron)

Guess which one I use? It's like the entire world has forgotten what productivity is.

<comment><USER6> On the other hand, once you are in gmail, everything is literally instant, opening the next email is faster than many desktop clients. It's designed for longer use, not drive-by. How long does it take to open a new mail in gmail lite? Do you have autocomplete on contacts and keyboard shortcuts for navigation and labeling?

</comment></comment></comment></comment><comment><USER7> Organizer of Chrome Dev Summit here.

Please do keep sending feedback and thoughts through on how can keep improving.

In terms of session length, I can see that being an issue. We had strict union regulations, and a lot of content to get through and I took the decision for more but shorter length talks that we can expand with textual content after the event.

We also tried to keep the theme for day 1 to everything we've learnt in the last year, so what is the new minimum bar for web experiences, how to load them quickly and how we've done it in the real world with commerce and media experiences and wordpress and pwa.

On day 2 I wanted us to showcase where we think the web could be heading in the next year, specifically with more of a focus on developer experience (devtools etc, polymer, lit etc)

Not saying we hit all those goals, but I do feel pretty happy with the event as a whole.

<comment><USER8> Hey, thanks for taking feedback!

As someone who was invited to attend - I really wished the talks were more low level and technical. I'd really enjoy talks about how things are implemented in Chrome, how the underlying APIs (for PWAs for example) work and so on.

<comment><USER7> We are talking about that for next year.

We need to do a better job at audience segmentation because we have ranges from senior dev to student, and CxO's etc and that's roughly why we stay a tad higher level with a lot of case studies.

We might end up with different days or different events for the audiences.

<comment><USER9> I wish to voice the opposite view from OP: I love the fact that you stay at a 'higher level'. My primary focus when watching these talks is knowing the current state of chrome, and some information directly from the source on what you worked and will be working in the future.

Because of this, I want to say thank you _precisely_ for not giving more lower-level details in your talks.

<comment><USER7> :) thank you - it's a balance...

</comment></comment></comment></comment></comment><comment><USER10> Regarding lit-html, which I wrote the majority of, lit-html is not a new framework, but simply a template library. This is called out specifically in the talk.

> You can wrap lit-HTML in WCs, just like you can wrap React components up as > WCs, but you gain nothing from it.

This isn't true either. lit-html has no component model, so by using it to implement WCs, you get a component model.

> it'll be in direct competition with Polymer, Angular, Svelte, Skate, and > Stencil

A template library is not in direct competition with Web Component base classes/frameworks, but can be used by them. It's already integrated with Skate, will be integrated with Polymer soon, and Stencil is looking into using it too.

<comment><USER11> Author here. I must begin by saying that lit-HTML is really interesting, and I hope it does well. It will be particularly exciting if Polymer 3 or Polymer 4 or whatever primarily uses lit-HTML out of the box.

> lit-html is not a new framework, but simply a template library.

Nobody wants to be called a framework, do they? For years, React developers insisted that it was nothing but a "view" layer, because everybody knows that "frameworks" suck.

> lit-html has no component model, so by using it to implement WCs, you get a > component model.

I think you mis/underestimate the extent to which you have a component model already. What you already have is the equivalent of React's "functional components," where the component is nothing but its render method.

> A template library is not in direct competition with Web Component base > classes/frameworks, but can be used by them

It's great that WCs let you interop with all WC-based frameworks, but some folks will avoid lit-HTML in favor of Stencil's JSX approach, or in favor of Svelte's Vue-alike HTML components, or more generally to decide whether to _observe_ changes and respond to them or whether to regenerate the UI as a function of state.

Interop doesn't mean you're not in competition.

<comment><USER12> > I think you mis/underestimate the extent to which you have a component model > already. What you already have is the equivalent of React's "functional > components," where the component is nothing but its render method.

When we (Polymer folks) think of a component model, we think of a lifecycle. Being notified when you boot up, when you're activated, when you're deactivated, and when the state you care about changes. React has that, Web Components have that, lit doesn't.

Agreed that there's a lot of baggage on the term `framework`, it's probably a good idea to taboo the word and break it apart into the pieces that we care about. IMO that's:

        - how big is the cost of adding the dependency – mostly this is
          the size of the library
        - how big is the ecosystem of code that it can play nicely with
        - are there well documented best practices
        - is there a complicated black box of internals that do a bunch
          of magic, or is it composed of small modular pieces that can
          be understood in isolation

</comment></comment></comment><comment><USER13> "Specifically, they'd like you to use Polymer. The problem is that the Web Component API is really unpleasant to use directly, especially compared to React. That's really holding Polymer back in the framework marketplace. Other WC-based frameworks like Svelte, Skate, and Stencil abstract away from WCs, treating them as a compilation target."

That argument feels like a non-sequitur. Polymer's API is different from the Web Component API, so even if the Web Component API would be unpleasant to use directly, that is not a criticism of a different API (in this case the Polymer API). Polymer's API is "similar" to the native Web Component API though, but it's designed to be easier to use than the native API.

<comment><USER10> Polymer's API _is_ the Web Components API, with some helpers added for reacting to property changes, augmenting templating and a few others. Polymer is simply a base class for your elements that sits between HTMLElement and your component class.

But I don't really get the "Web Components APIs are unpleasant" line of criticism. The WC APIs are just the element constructor, connectedCallback, disconnectedCallback, attributeChangedCallback and what methods and properties you define on your component. These lifecycle methods are nearly identical to what you get in React and just about every other framework. If those don't have unpleasant APIs, Web Components don't.

<comment><USER11> Author here. It's not just me saying that Web Components are unpleasant. In the article, I linked to Sam Saccone of Google saying that the WC developer experience is significantly worse than React's developer experience.

[https://twitter.com/samccone/status/914528725852663808](https://twitter.com/samccone/status/914528725852663808)

"This of course is coming from someone who has used web components every work day for the last 2 years. Hard to ignore the DX gap that exists."

To which Alex Russell, also of Google and one of the architects of the WC API, replies, "Who's ignoring it?"

There are certainly some developers who compare and contrast Polymer and React and prefer Polymer, but it's fair to say that the vast majority of developers who have made this comparison have preferred React's developer experience. Even Polymer's advocates seem to be holding their nose and using it because they appreciate the long-term promise of Web Components interop.

Why? It's hard to say exactly, but I think it has to do with React's guarantees that the UI will be a pure function of state. Lots of nifty React features emerge from that. Polymer components make no such guarantees.

I'm actually pretty enthusiastic about lit-HTML as a way to close the gap. We'll see how it goes.

<comment><USER10> Sam's tweet has no specifics, neither does your article, about which APIs are painful. Care to add any?

<comment><USER14> This article: [https://medium.com/@emilrmoeller/grow-with-the-browser- learn...](https://medium.com/@emilrmoeller/grow-with-the-browser-learn-web- component-fundamentals-86c2b1c8ac08)

"To do this automatically" is followed by dosens of lines of tedious bolierplate. And that's _for a single most common use case of adding a property, and an attribute that are synced_. It's then followed by yet more boilerplate for adding a custom event.

A lot of stuff here: [https://jeremenichelli.io/2017/10/the-web-components- experie...](https://jeremenichelli.io/2017/10/the-web-components-experience/)

To quote:

To achieve pretty basic mutations on small components, children references and data manipulation there's a lot of heavy lifting that really compromises the developer experience.

And it's a big deal, since developer experience is one of the reasons why React or Vue are widely used in production.

Also, web components being included in a magical global store difficults declarative and deterministic views or any other concept which hangs on a visual map of dependencies like code splitting.

UNFORTUNATELY THE DEVELOPER EXPERIENCE OF BUILDING AN APPLICATION WITH WEB COMPONENTS TODAY IS QUITE PAINFUL SAM SACCONE

—- end quote —-

<comment><USER10> I replied in general below, but I'll take some extra time to respond to the complaint about getters and setters.

Any JavaScript class that wants to define observable properties has to define a getter/setter pair.

Manually, this usually looks like this:

        class C {
          get foo() { return this._foo; }
          set (foo(v) { this._foo = v; this._somethingChanged(); }
        }

From the part of the article you reference, you're complaining that Web Components don't "solve" observable properties. This is because in JavaScript there are already ways to do this with with getters, setters, Object.defineProperty, and while that does involve some amount of "boilerplate" there are helpers for both Web Components and plain classes that will create these properties for you.

I really don't see why it's a valid criticism of Web Components that they don't magically solve this problem when it's just the way JavaScript works. Of course frameworks like Angular solve this problem by generating accessors for you - _but so does every major Web Components library_. They all include some way of letting an author declare observable properties and syncing them with attributes. Given that the end result in DX is exactly the same as with other frameworks, why the ding on Web Components? Why are Web Components held to a higher standard and expected to "fix" JavaScript?

To show how absolutely easy this is, and how off-base the DX complain is, here's how easy a Polymer 2 + TypeScript element is (TypeScript just to use decorators, which will be standards JS someday...)

        class MyElement extends Polymer.Element {
          @property({notify: true, reflect: true}) foo: number;
        }

That will create an observable property, fire a "foo-changed" event and set the "foo" attribute when it changes, and listen for the "foo" attribute and deserialize it to the foo property when the attribute is set.

Even without decorators, this is pretty damn easy to do, and the first thing any Polymer developer learns:

        class MyElement extends Polymer.Element {
          properties = {
            foo: {type: Number, notify: true, reflect: true}
          }
        }

Other Web Components libraries like Skate and Stencil include their own way of declaring properties, just like other frameworks like Angular and Ember do.

The second article is also comparing raw Web Components with no helpers to a framework that's full of helpers. You could just as easily saw JavaScript has a broken DX if you tried to do React-style components without React. The higher expectation for Web Components here is kind of ridiculous, to be honest.

<comment><USER14> > Javascript > you complain about objects > don't magically solve > raw WCs vs > helpers

etc. etc. etc.

And then you wonder why I'm so set against WebComponents. Because you (and Rob Dodson and other WebComponent proponents) are entirely blind to how bad WebComponent APIs are. I dunno, maybe your goal isn't to "sell" WebComponents, but to sell Polymer.

WebComponent API is bad not because "we complain about how Javascript objects are". We complain because WebComponents API is _horrendously bad_ , and that was a _deliberate design choice_.

Current line of defence is "oh, it's just low level API" or "oh, it's just how Javascript is", both of which are at best patently false.

Here's code to create _one single property with one single synced attribute_. One. single. property/attribute pair. One.

          set transitionDuration(value) {
            this.setAttribute('transition-duration', value);
          }

          get transitionDuration() {
            return this.getAttribute('transition-duration');
          }

          static get observedAttributes() {
            return ['transition-duration'];
          }

          attributeChangedCallback(name, oldVal, newVal) {
            if (name === 'transition-duration') {
              // do something
            }
          }

There is no reality where this is good API design. There is no reality where "this is how objects work in Javascript" is an excuse.

This is objectivly bad API design. Bad developer experience. However, you and all other webcomponent proponents completely ignore this fact, and dismiss any and all complaints out of hand.

Of course you do. You've got Polymer to promote [1]. If WebComponents had better APIs, there would be no need for Polymer, would there. Because here's how Polymer solves the problem, despite this being "oh, that's how Javascript works".

        static get properties() {
            return {
              transitionDuration: {
                type: Number,
                readOnly: false,
                reflectToAttribute: true,
                observer: 'methodName'
              }
            }
          }

Oh. My. God. This is doable without any excuses about how Javascript works? Really? Who would've thunk it?

[1] Hell, even in your "rebuttal" of criticism towards _WebComponents_ here's what you write:

> To show how absolutely easy this is, and how off-base the DX complain is, > here's how easy a _Polymer 2_ \+ TypeScript element is

Were we talking about the bad DX of Polymer? No. You are totally entirely absolutely blind to the fact though. Because in your mind WebComponents === Polymer. And, sadly, for all intents and purposes it's true.

 _edit: removed some erroneously pasted code_

<comment><USER13> "maybe your goal isn't to "sell" WebComponents, but to sell Polymer."

The goal of Web Components are to sell a interop layer that is supported by many (or even all) frameworks. It's not supposed to be a framework that has the best developing experience.

The Polymer API is better than the Web Components API. The Polymer API is more high level than the Web Components API. This is not by mistake, it's by design. The higher level the Web Components API is, the more difficult it is to use by a large number of wildly different frameworks.

"We complain because WebComponents API is horrendously bad, and that was a deliberate design choice."

I don't think it matters much to be honest, because developers should use frameworks, just like they are using frameworks at the moment.

"Here's code to create one single property with one single synced attribute. One. single. property/attribute pair. One."

You need a "synced attribute" only for some frameworks, not all. Also, your example is misleading, because the two last methods are only needed to be defined once, so if you want 2 synced properties, the total number of methods is 6, not 8.

"Bad developer experience."

Use a framework.

"If WebComponents had better APIs, there would be no need for Polymer, would there."

The risk is too high to use the Polymer API for the Web Componenets API. In addition, the more complex the API is, the more likely it is for the browsers not to implement the API. It's better to have a simple native API and provide different frameworks for a good user experience.

"Because in your mind WebComponents === Polymer."

Or maybe he thinks that frameworks should be used, as intended.

<comment><USER14> > The goal of Web Components are to sell a interop layer that is supported by > many > Or maybe he thinks that frameworks should be used, as intended.

Translation: instead of providing a good DX we're going to sell Polymer

> The Polymer API is more high level than the Web Components API. This is not > by mistake, it's by design.

Indeed. By crappy design with horrible developer experience

> The higher level the Web Components API is, the more difficult it is to use > by a large number of wildly different frameworks.

Hmm... How about "let's reduce the need for and dependency on multiple frameworks"? When will that ever be a goal?

> You need a "synced attribute" only for some frameworks, not all.

Surprise, Polymer's API provides a possibility to define that.

> Also, your example is misleading, because the two last methods are only > needed to be defined once, so if you want 2 synced properties, the total > number of methods is 6, not 8.

Oh. Right. 6, not 8. I wonder if I ever complained about the number of methods required? Nope, what I complained about is _the amount of tedious boilerplate you need to write to implement the most basic and common of things_.

If I need 1 more synced property/attribute pair, I will need:

\- 1 extra setter

\- 1 extra getter

\- 1 extra item in the attributes list

\- 1 extra if clause in the callback.

>> "Bad developer experience." > Use a framework.

How about: platform provides a well-designed API that doesn't require a framework for the most basic and common functionality?

As an example:

\- DOM APIs are horrible, and quickly devolve into tedious error-prone boilerplate

\- jQuery API is amazing

\- Does this mean that DOM APIs _suddenly_ become developer friendly? Does this mean they are beyond any criticism?

Same with WCs

<comment><USER13> "Hmm... How about "let's reduce the need for and dependency on multiple frameworks"? When will that ever be a goal?"

That's not a realistic goal, because there's no common agreement on the framework API. If there were, every framework would have the same API already.

"Surprise, Polymer's API provides a possibility to define that."

Your point being?

"Oh. Right. 6, not 8. I wonder if I ever complained about the number of methods required? Nope, what I complained about is the amount of tedious boilerplate you need to write to implement the most basic and common of things."

You're not intellectually honest, so I will stop this discussion.

<comment><USER14> The moment I call you out twisting my words, you call me intellectually dishonest. Suit yourself. This entire discussion shows the actual intellectual dishonesty of people who defend WebComponents.

> Your point being

You, and others are completely entirely blind to the fact that:

\- WebComponent API is horrible DX

\- WebComponent API can be made better _within the platform_ , without the need to rely on third-party frameworks.

However, if the goal is not to push WebComponents forward, but to sell Polymer to as many devs as possible, it's not surprising.

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER15> I attended the event in person, and overall enjoyed it. But I keep wondering: is the reason Google wants us to squeeze our file sizes and page load time down to the bare minimum because they want to maximize the bandwidth available for more and larger ads?

<comment><USER16> No, it's a much larger existential threat. It because they're fighting to keep the web competitive with native apps. The more that the world shifts from the web to native apps, the less people use their web search engine.

<comment><USER17> And yet Google refuses to allow web apps / PWAs on their Play store.

<comment><USER7> We don't refuse or disallow. We just don't take an arbitrary URL and list it in the store automatically.

We announced Trusted Web activities [https://developers.google.com/web/updates/2017/10/using- twa](https://developers.google.com/web/updates/2017/10/using-twa) which give you a fullscreen surface for web content in an Android App in the store and allow you to offer more integration with the Android operating system (protocol and scheme handling, quick links etc)... I do think this is interesting, I worked on the Chrome Web Store when it launched and the number one complaint was that the experiences "were just bookmarks" and I think Trusted Web activities give us a chance to experiment with deeper web integrations on the host platform before we are able to standardize it.

<comment><USER17> Trusted web activity is not the same as a PWA. They are not cross platform. Why can't PWAs go through a similar getting process to apps to get onto Play?

<comment><USER7> The process of getting apps onto Play, is to create an Android app... so I'm not clear on what you mean. Someone will create the tooling that will automatically create this.

Trusted Web activity is just a general way to launch you PWA fullscreen from an Android actitivy.

<comment><USER17> How does that jive with the fact that Play also has books and movies? Those are not Android apps. There is absolutely no technical reason that Play couldn't also serve as a discovery and installation (i.e. icon on the desktop) mechanism for PWA-compliant applications. Users would never know the difference.

</comment></comment></comment></comment></comment></comment></comment><comment><USER8> If they'd like us to start building progressive web apps - they should pull- request webkit with PWA APIs.

Safari doesn't have those because Apple doesn't see them as a priority - <USER2> after talking to Apple engineers who work on Safari it turns out that it's mostly because it isn't prioritized and not because they don't want the feature.

It's not _that_ much work either on their end.

If I knew I could get PWA capabilities on an iPhone - I would definitely consider PWAs for replacing native development entirely.

<comment><USER7> Service Worker and Manifest are in development in Safari. It's quite a significant amount of work to land the APIs

It's not as simple as just forcing it in. SW can require deeper integration with the OS and network stacks that we don't have the ability to change on iOS or macOS.

<comment><USER8> Thanks for answering. You are correct that they are under development but they're moving pretty slowly and I got the feeling contribution would be really appreciated.

For example, `fetch` in service workers - caching and request intercepting could really improve the "default" iPhone experience in PWAs.

I realize that getting this request is annoying (Build a feature in another browser) but I really think it could significantly push the web as a whole.

It would also be great to see the Chrome team fix some of the more annoying bugs in the existing APIs (WebRTC has some really annoying ones).

<comment><USER7> Re: web rtc .. yes... And getting the screen share API in would be nice too.

Re: helping. I think we have some engineers supporting our predictablity efforts on WebKit (i.e helping to smooth out edge cases) but I don't think we are working pushing larger features in...

</comment></comment></comment></comment><comment><USER18> > It's the Google Payment API. After replacing Google Checkout with Google > Wallet, and then replacing that Android Pay, the docs have the audacity to > call it "The newest way to pay with Google."

> The Google Payment API only works in Chrome on Android

Why does Google even bother making this?

<comment><USER19> Chrome for Android is the most popular browser in the world, so it's certainly worth bothering, even if it's not a desirable thing for them to be doing.

</comment></comment><comment><USER20> At least Google addresses the problems we have with Internet in countries/continents like e.g. Afrika or Philippines.

Really... it's a whole different world if you only have 500Kbit/s download rate and you can see easily who has done their homework good to address countries with slow internet and who did not. Some websites will get completely unusable in this areas! And you will find out that Opera Mini is your new best friend.

Only want to mention one heavy media company which has done a near perfect job: Instagram. This app is even blazing fast with slow internet. Well done, really.

</comment><comment><USER21> Given that Chrome apps are on their way out, a nice demonstration of Progressive Web Apps would be to make Gmail into one to replace the functionality of Gmail Offline.

</comment><comment><USER22> Are there any good examples of progressive web apps? I made a web app recently that had to work offline for use as a visitor display...I looked into service workers for this (there's a Webpack plugin that helps) but they seemed complicated plus difficult to debug. It seems like you have to be careful you don't lock your users out with a service worker bug because now a browser refresh might not do the same thing for everyone now.

<comment><USER7> [https://outweb.io/](https://outweb.io/) and [https://pwa- directory.appspot.com/](https://pwa-directory.appspot.com/) have collections of progressive web apps. They all have differing levels of offline support based on their needs.

</comment></comment><comment><USER23> > Dan from Automattic came up to say that their closed-source Jetpack plugin > for WP also offers preliminary PWA support.

Closed source?

[https://github.com/Automattic/jetpack](https://github.com/Automattic/jetpack)

[https://github.com/Automattic/jetpack/pull/7963](https://github.com/Automattic/jetpack/pull/7963)

</comment><comment><USER24> Service Workers creep me out, but maybe I'm in the minority. I don't want web pages to be able to execute code if I'm not actually on their page. To be honest, I don't even want most apps to background refresh on my phone.

</comment><comment><USER25> Why should I use service workers to cache urls as opposed to using checksum urls with cache control (I.e. script.hz15cbsj.js etc...)

Unless my site can actually do something offline, service workers for caching is just an extra headache

</comment><comment><USER26> as someone considering if I should adopt service workers or just wait for the next shiny thing can I just ask - if service workers were on iOS today, would any of you still have other reasons NOT to adopt it? thank you in advance

</comment><comment><USER27> If they want PWAs they should stop promoting and encouraging native apps.

<comment><USER28> PWAs are not supposed to replace native apps just to augment today's web apps.</comment></comment>


Cloud9 IDE - The Javascript IDE, by Javascripters for Javascripters - <AUTHOR> http://www.cloud9ide.com/ <comment><USER2> It's a logical next step. However, given the integrated nature of 95% of all JS development (CSS/HTML/...), I'm not quite sure whether it's a particularly _good_ idea as well.</comment>


Always Be Experimenting - <AUTHOR> https://medium.com/better-humans/45732d922db9

<comment><USER2> As a data nerd, and scientist myself, I love to see so many people talk about how they apply the scientific method to business and starting something new. There are even businesses out there all about making landing pages to see which get more traffic etc. Dig it!</comment>


Crimea - <AUTHOR>

Does Skype still work there? ,I've read that it will stop working on February 1st <comment><USER2> It does at the moment. Some of our external developers are located there which is now beginning to be a problem but Skype hasn't had any issue so far.

<comment><AUTHOR> Thanks,I'm hoping I can still put money on my girlfriends visa debit card as well

</comment></comment><comment><USER3> yes it is working at my end</comment>


Musician Who Lost His Arm Plays Piano Again with AI Prosthesis - <AUTHOR> https://blogs.nvidia.com/blog/2017/12/28/ai-prosthesis-skywalker/ <comment><USER2> This reminds me of Paul Wittgenstein (brother of philospher Ludwig)[1]. He was a concert pianist who lost his right arm in WWI and the commissioned a bunch of piano music playable with only the left hand, including works by still- famous names like Ravel and Prokofiev. My personal favorite is Korngold's [2].

More recently, there is Leon Flescher, who was a highly-renowned pianist until he lost the use of his right hand in the 60s. Amazingly, he got it _back_ 40 years later and has enjoyed recent success again as a two-handed pianist.

[1] [https://en.wikipedia.org/wiki/Paul_Wittgenstein](https://en.wikipedia.org/wiki/Paul_Wittgenstein) [2] [https://www.youtube.com/watch?v=bGulyl8bzgQ](https://www.youtube.com/watch?v=bGulyl8bzgQ)

<comment><USER3> Some famous (ish?) modified versions of Chopin's Etudes were written by Godowsky. His mission appears to have been to make Chopin's hardest pieces just a bit harder, including the Revolutionary for the left hand only: [https://youtu.be/X2nMUwdh1Wk?t=2m41s](https://youtu.be/X2nMUwdh1Wk?t=2m41s)

<comment><USER4> Woah

</comment></comment></comment><comment><USER5> Typically these "futuristic" prosthetics are still relying on myoelectric sensing and a lot of wishful thinking. It's nice to see some meaningful progress in more detailed sensing technologies. This actually seems promising.

<comment><USER6> This was a hot thing a few years ago. These guys still seem to be around:

[https://techcrunch.com/2013/06/05/thalmic-labs- raises-14-5m-...](https://techcrunch.com/2013/06/05/thalmic-labs- raises-14-5m-to-make-the-myo-armband-the-next-big-thing-in-gesture-control/)

[https://www.myo.com](https://www.myo.com)

</comment></comment><comment><AUTHOR> Once these are working well will factory workers be able to attach a third and fourth arm for extra productivity?

<comment><USER7> The brain has a couple of regions (the somatosensory context, the primary and supplementary motor cortex) with maps of the body. You'd need to add the limbs to those maps. Brains have enough plasticity to re-allocate the area responsible for limbs or fingers by a minor amount, but nowhere near enough to add a new limb, at least in adulthood.

<comment><USER8> I'm not so sure that's true.

People who use a tool for a long time report the tool feeling like an extension of their body.

Also, try this thought experiment - try to flap your wings. I know you don't have any, just try to activate them anyway. Do you sense yourself trying to move "something"? Your brain clearly is able to map anything it wants.

<comment><USER9> For the technology specifically covered in this article, all they are doing is reading the muscle activation of existing muscles, and then mapping to the prosthetic's actuators. The "twist" in this story is that sensing is done with ultrasound instead of EMG (better signal to noise if you can throw enough compute at it), and I believe some cool deep learning tricks to map sets of muscle actuations to prosthetic motion "better".

In order for this approach to work, a nervous signal has to travel out of the brain, and at least into the brain stem. In these cases, they actually have to get all the way to a giant amplifier (your muscle) in order to detect it.

When your talking about your brain imagining to flap your wings, unless your brain has mapped your swings to your lats, traps and delts, you're not sending any actual motor signals out of your brain and we can't read it. If it is mapped to your lats, traps and delts, then you're actually moving those muscles right now. If we used a system where we tried using your lats, traps and delts as points to control prothestic wings, then you run into the problem of what do you with your wings when you're not trying to use those muscles as a wing controller. In other words, you'll get a modal system... which are tricky. You'd basically have to switch off parts of 'baseline human' functionality at a time to get your 'human+' stuff.

<comment><USER10> We have useless muscles in outer ears though. Maybe it is possible to repurpose them.

</comment></comment></comment></comment></comment><comment><USER11> It is progress, and it is very impressive but the title is a bit misleading.

I think there is still a gap between what is being demonstrated to fully "play piano again", in the context of playing piano professionally as a musician.

For composition it can be still very valuable.

</comment><comment><USER12> What really frustrates me when I watch this kind of demonstrations with bionics is the delay and inaccuracy between desired action and the real effect. I know it's not that simple, but from my perspective since the desired actions are transmitted through our nerves at 100 m/s and we can send an message thousands of kms away in milliseconds, I think there is always space for improvement. I am curious which is the real bottleneck in all the process.

<comment><USER13> As you can see in the video [https://www.youtube.com/watch?v=HjW1kIt5iQg](https://www.youtube.com/watch?v=HjW1kIt5iQg) there is some latency. Weinberg and Barnes are working to fix that, but I don't know details. Weinberg said he wants to gather more data from more users so the arm is more useful to more people.

<comment><USER12> But why should one rely on the termination of the nerves instead of the implating an electrode on the main cortex which controls the motor activity? Can't they translate directly the actions from the energy flow at that level?

</comment></comment></comment><comment><USER14> how hard would it be to translate the movements to midi? I'm guessing there would be some way to capture the signals the prosthesis and characterise the mapping from movement to midi.</comment>


Unshaky: A software attempt at fixing the butterfly keyboard's "double press" - <AUTHOR> https://unshaky.nestederror.com/ <comment><USER2> I remember writing a timer-based switch debouncing routine for my microcontrollers class in undergrad.

Too bad people have to resort to homebrew hacks like this to fix their $1500 laptops.</comment>


No... You fix it  - <AUTHOR>

" Mercurial versions 1.7.x and up require the configuration of Certification Authorities (CAs). Error messages of the form:
warning: code.google.com certificate with fingerprint b1:af: ... bc not verified (check hostfingerprints or web.cacerts config setting) "
Why can't you just take care of this at your end ... Why force users to deal with it ... <comment><USER2> <http://mercurial.selenic.com/wiki/BugTracker></comment>


Pros and Cons of Nim - <AUTHOR> https://onlinetechinfo.com/pros-and-cons-of-nim/ <comment><USER3> While I rather like nim as a language, there's a few more cons that need to be considered for any real use of the language:

\- It has a bus/lottery factor of 1. The vast majority of all the changes were done by Araq and I have very little faith that the language would survive without him. This is even more pronounced with Zig (mentioned in comments here).

\- It has had some very embarrassing bugs after the 1.0 milestone. Most of them were specific to Windows (e.g. [0]), which casts a lot of doubt on its cross-platform promise. Multiple times in the last year, when debugging a nim program, it turned out that the problem was in the language/standard library.

Now, these might not be reasons enough to not use nim, since it's a lovely language when it works, but a pro/con list should be honest.

[0]: [https://github.com/nim-lang/Nim/issues/12315](https://github.com/nim- lang/Nim/issues/12315)

<comment><USER4> > \- It has a bus/lottery factor of 1.

What was Rusts early years like? Was it one developer for the first part?

I'd imagine this is not a big deal in the early days, where the benevolent dictator is as much the language as the project itself, not all technology adoption happens on the same timelines. Matz with Ruby took a long time to become super popular, Rich Hickey with Clojure seemed to be a powerhouse even as that found quick adoption before stalling.

<comment><USER5> When Rust 1.0 was released it had in the order of hundreds of developers doing work here and there.

When Rust started as a hobby project it was a one man effort, but it was also a project with ~1 user. It grew developers before actually growing users, and for a while, it had more developers than users.

<comment><USER6> Rust is design by committee with complicated and large syntax area and to solve one problem of memory safety created a mountain of borrow checker syntax and a steep learning curve.

So only time will tell if BDFL based language comes up like Linux or design by committee like language. Right now Rust is not that significant like Nim and Zig so all have a chance to come up.

Once there are substantial software written in them like C or C++ than only will know, right now among modern language only golang and Swift reached that stages as being significant systems programming language in spite of GC. Indeed I doubt if Rust will be as revolutionary as Lisp or Haskell or Smalltalk in terms of contributions for the development of compilers and language designs.

<comment><USER5> Not bad for a bot, tell your master that your coherency levels are well down.

</comment></comment></comment></comment></comment><comment><USER7> He missed two that I think are really important.

1\. Arraymancer [https://github.com/mratsim/Arraymancer](https://github.com/mratsim/Arraymancer)

2\. The new version of the garbage collector understands move semantics to optimize its reference counting so unlike Rust where you have to deal with it yourself Nim will handle it for you at the expense of a reasonable amount of memory. [https://youtu.be/yA32Wxl59wo?t=855](https://youtu.be/yA32Wxl59wo?t=855) Watch the whole video for more context if you care.

I think it's a really nice language, too many pragmas but still really nice.

</comment><comment><USER8> I love Nim as a language. I do not love the Nim ecosystem. It is too sparse. Even now there isn't a good web framework that folks can use in production. Jester is ok but it doesnt inspires the same kind of confidence that Echo, Fiber etc would do. Jester still doesnt have its own web page marketing it.

I really think that the folks behind Nim need to focus on getting some killer apps in the ecosystem and in marketing them. That's all Nim needs. Just some useful tools wrapped in a nice package.

</comment><comment><USER9> It occurs to me that the although they were aimed at different uses cases the language that's actually closest to Nim today is Julia. Python-like syntax, compiled to native code, significant meta-programming capabilities, some native support for concurrency. The biggest difference seems to be the approach to types, since Julia is a dynamically typed language (with optional type annotations) and Nim is statically typed, but Julia's type systems is powerful enough that in practice the difference may not be so big.

Anyone out there who has used both and has more observations?

<comment><USER10> Last I checked, Julia is not AOT compiled, and some people don't like Julia's startup time.

For numerical computing however Julia wins hands own purely based on the community and libraries.

<comment><USER11> Julia can be AOT compiled, though it's still experimental progress is being made quickly.

</comment></comment></comment><comment><USER12> Oh!

I have another use-case; first-class (easier-than-others?) cross-compilation support.

I had to build a one-off tool that was a a glorified "curl wrapper" with validations, for Windows; on a Mac. Wrote a simple nim script, cross-compiled for Windows, and it's been fine and dandy for a year now :)

I'm sure other languages support this (golang?), but Google's SEO suggested nim-lang.org

<comment><USER13> This, for sure. For my work I wrote a dynamic library in Nim. The library is loaded by an application written in C, and I needed it to work on both Windows and Linux (Windows for customers, Linux for myself and the server back-end). Setting up a Docker container that runs the entire build and integrates well into the existing build-system we had was fairly straight forward. All Nim needs to cross-compile is a C compiler that can do it (in my case that was MinGW). So now I'm happily running the same Nim dynamic library compiled to both a DLL and a .so.

<comment><USER14> To confirm, that's two dynamic libraries, right?

<comment><USER13> Yes, it's compiled into two different libraries. Nim hasn't magically made cross-platform dynamic libraries. But the code for both libraries is the same, just compiled for two different platforms.

</comment></comment></comment></comment><comment><USER15> I'm a big fan of Nim, but I really wish it supported cyclic type declarations in separate files and out-of-order functions without forward declarations. As it is, I'm constantly structuring things around those limitations. Big projects often end up squeezed into a single huge file (or a few huge files).

<comment><USER16> consider `include` instead of `import` if you want to break things down to smaller files.

Also, I'm with Araq on this one -- in my experience, every time I reached for a cyclic-cross-file-type-declaration, there was a much simpler acyclic solution I found later.

<comment><USER15> Include doesn't work for cyclic types, they need to be in the same "type" block. I do not agree with Araq's stance here, there are often cases when closely-related types need to reference each other, and it's not always convenient to put them in the same file. That's why you see the "types.nim" file in larger Nim projects -- no one has a good solution and just shoves them all together. And, if you use types.nim, you no longer have proper visibility control, since fields cannot be private and there is no package-level visibility. Most languages understand this, C/C++/Rust all allow at least the ability to forward declare a type (and Rust allows cyclic, out-of-order types).

</comment></comment></comment><comment><USER17> What is the current state of REPLs for Nim? If I remember correctly, Nim had an official REPL a long time ago, but it was abandoned a few years back.

<comment><USER18> There is one bundled with a standard nim installation, and I use it regularly (when working in nim). It works, but it's not very good.

I expect the developers to know this, since its accessible only though the `$ nim secret` command.

</comment></comment><comment><USER19> The thing that put me off was the allowed inconsistent name formatting: snake_case, pascalCase, (and is it case-insensitive too). This makes it hard for text editors to find all references besides feeling like you're reading multiple codebases.

This feature is meant to make linking easier but it shouldn't have leaked into variability of a single module's sources.

</comment><comment><USER20> If you like Nim also check out Crystal.

</comment><comment><USER21> I really like Nim and have been eager to try for a project -- though for anything other than a simple script/wrapper I'd really want to see source- level debugging support in VSCode for one or two of the backends.

<comment><USER22> Neverwinter Nights nwsync tools are written in Nim and the source is available to tinker with. I've compiled and used the tools on my FreeBSD box to break apart the modules and prepare them for nwsync distribution (nwsync is used for client/server asset management mostly for persistent worlds, but is handy for just running a one-off server with your buddies).

Now you can learn a bit about Nim and have fun doing it :)

A couple of links:

[https://docs.google.com/document/d/1eYRTd6vzk7OrLpr2zlwnUk7m...](https://docs.google.com/document/d/1eYRTd6vzk7OrLpr2zlwnUk7mgUsyiZzLoR6k54njBVI/edit#)

[https://github.com/niv/neverwinter.nim](https://github.com/niv/neverwinter.nim)

</comment></comment><comment><USER23> Why use Nim over Go?

<comment><USER24> People complain about lack of generics and proper try/except/finally in Go. Nim has both.

<comment><USER25> And no native concurrency.

<comment><USER13> Nim has thread support natively. And an async implementation in it's standard library which is made entirely as a library, so you're free to write your own, in fact there exists alternative implementations of async/await in Nim. Just the fact that a feature like this _can_ be implemented as a library is a testament to how powerful of a language Nim is.

</comment></comment></comment></comment><comment><USER26> Nim currently in uber-cool phase. I love it.

After adding a million requested features it will end up bloated like all the others . . .

<comment><USER13> Nim has been trimming stuff out of its stdlib instead of adding them lately. And because of its huge focus on meta-programming almost anything can fit in an external package anyways (even async is a module in Nim, without any specific support in the compiler). The Nim language as such seems to be "complete" as it is now, and I'd say it's quite unlikely to gain bloat in any way that would affect people not using the bloated parts (i.e. the compiler will still stay fast).

<comment><USER26> Great to hear. Just hope they can resist the inevitable flood of "good ideas" and stick to their design.

[EDIT] recognized your nick from IRC a while back, my "good idea" is still to add support for 80-bit floats ;)

</comment></comment></comment><comment><USER27> _> Memory leaks are not a concern as Nim uses one of several available garbage collectors. The new ARC option works with reference counting instead of a GC._

Using "no memory leaks" and "reference counting" in the same sentence is _#fakenews_. Reference counting leaks cycles unless accompanied with a tracing GC (at which point reference counting makes little sense).

<comment><USER16> > Reference counting leaks cycles unless accompanied with a tracing GC (at > which point reference counting makes little sense).

Python proves otherwise. Reference counting gives you deterministic memory use and finalization _except_ when a cycle is involved. The tracing GC helps for those cases (and libraries) that do introduce cycles.

If each one of your objects is in a cycle, then -- yes, reference counting makes no sense. If only 1% of your objects are in a cycle, it makes 99% sense.

<comment><USER27> Python is a trivial special case as it has no concurrency. In a single- threaded language, that indeed makes sense. Multi-threaded RC is extremely tricky to implement efficiently, so unless you can prove there's no cycles (or you don't care it it leaks memory), it makes little sense.

<comment><USER16> Oh, so now it's about "efficiently". Goal posts have moved.

No, it's not hard at all to implement efficiently as long as objects don't cross a thread boundary (and e.g. Nim's older GC used to enforce that condition, an old version of K tracked it and switched to "lock; xadd" to count references when something did cross a thread boundary IIRC, which made it inefficient only for those objects that crossed the boundary which usually weren't many.

It's way simpler than multithreaded mark&sweep, for example. Regardless - <USER2> makes a lot of sense. It might not make a lot of sense to you, but it does in general in most contexts.

</comment></comment></comment></comment><comment><USER28> These pros and cons appear to have been curated from around the web; this is a secondary source. If the final selection has passed throught the filters of passion and bitter experience, the author doesn't say. The parent site aims to fill itself with "Useful Tech Content", and this article reads like an assignment completed by a strong student.

So anyone can dress like Moses, come down off the mountain with tablets, and we'll debate the scriptures without considering the provenance? Good to know. California ballot initiatives often work that way.

<comment><AUTHOR> It's a mix of research from the web (and I don't mean copy & paste), questions I and others have asked, and my own experience with Nim. This is not simply copy/paste. The rest of the comment I won't even bother to address as you sound like a troll.</comment></comment>


Tech IPOs could be windfall for California budget - sahin-boydas https://www.marketwatch.com/story/tech-ipos-could-be-windfall-for-california-budget-2019-03-31 <comment><AUTHOR> This seems like an interesting moment for the state to invest in infrastructure. Perhaps there is a way to redistribute some wealth for societal progress.

<comment><USER2> Let's build the planned Caltrain tunnel into downtown SF and BART tunnel into downtown SJ so the impact on the housing market is distributed more widely and people from more backgrounds can afford to commute to these centers of economic growth. And let's legalize the construction of high-rises within 1 mile of any BART or Caltrain station and invest in increasing the frequency and hours of the trains.

<comment><USER3> Please run for office because this sounds great. Maybe throw something in about repealing prop 13 too.

</comment></comment></comment><comment><USER4> If you know you are about to receive a huge windfall of life changing amounts of money why wouldn't you move to a income tax free state 6 months ahead of time?

<comment><USER5> Maybe life is about more than just minimizing tax obligations?

</comment></comment><comment><USER6> Maybe we should think about some high speed rail options!

</comment><comment><USER7> It will all be spent, nothing will improve, and a few people will get rich. Guaranteed.

<comment><USER8> Governor Newsom is more fiscally responsible than most. It will be more difficult for him than Governor Brown to say, "No". Newsom commands less respect, and has less experience, than Brown. But don't forget that Newsom was Governor of San Francisco during the Great Recession, and San Francisco was the _only_ large city in the state to maintain a balanced budget. Part of that was a pre-existing mandate that SF maintain a rainy day fund; but part of it was Newsom's City Hall extracting major concessions from unions and interest groups, shrinking expenditures. And SF wasn't as filthy rich as it is now. The big migration of tech from South Bay to the city didn't really get moving until about 2011.

<comment><USER9> "San Francisco is officially $10 billion in the hole"

[https://www.sfexaminer.com/news/san-francisco-is- officially-...](https://www.sfexaminer.com/news/san-francisco-is- officially-10-billion-in-the-hole/)

<comment><USER8> This is mostly the result of (a) voter-mandated, retroactive benefit increases and (b) courts forbidding the city (and voters) from rolling back those retroactive increases. See

[https://calpensions.com/2017/07/03/san-francisco-pension- deb...](https://calpensions.com/2017/07/03/san-francisco-pension-debt-not- curbed-by-voters/)

The following case relates to just one particular benefits measure:

[https://www.sfexaminer.com/news/sf-loses-lawsuit-against- may...](https://www.sfexaminer.com/news/sf-loses-lawsuit-against-mayor-lees- pension-reform-measure-pays-out-750k-in-legal-fees/)

City leadership itself has been relatively fiscally responsible. For example,

[https://www.sfchronicle.com/bayarea/article/SF-taking- steps-...](https://www.sfchronicle.com/bayarea/article/SF-taking-steps-to- avoid-projected-future-budget-13509714.php)

Which is actually quite impressive, IMO, because the _pressures_ to spend are enormous, and the city does indeed spend quite a lot. The politics at the Board of Supervisors is intense and there's a large populist faction that would like to spend much more. But at the end of the day what really matters is who is elected to City Hall, and at least when it comes to fiscal responsibility Newsom, Lee, and now Breed put a strong emphasis on long-term budget viability. But sometimes--like with voter-mandated expenditures--their hands are tied. Mayor Breed _opposed_ the recent Prop C which raised several hundred million in new revenue for spending on homelessness. (She supported a similar future ballot measure, but wanted to wait things out. Working under Mayor Lee she already had a sense of what was in the pipeline and wanted to see how those initiatives developed. And Lee and others were expecting another downturn very soon so were more concerned with shoring up the budget to avoid having to make deep cuts.)

EDIT: Also, the growth in healthcare costs is eating everybody alive. What should really worry people is whether California voters mandate single payer. Because California is limited in how it can control cost growth--most policy control resides in Washington, e.g. pharmaceutical regulation--it'll be a huge problem. But we won't be able to blame politicians for it.

<comment><USER9> Calling these "voter mandated" is a serious stretch. It was the government agencies who _put them on the ballots_ (as _opposed_ to any voter initiative/petitioning), and it was those same government agencies who _utterly lied_ about the fiscal effects in the ballot statements, as detailed in your own link. Quoting:

'The grand jury suggests voters may have been misled by official ballot pamphlet cost information on two of the three "significant" pension increases described in the report. A dozen retroactive retirement benefit increases between 1996 and 2008 are listed in a report appendix.

Voters were told that even with a retroactive pension increase for most employees (Proposition C in 2000) the city is not expected to make an annual payment to the retirement system "for at least the next 15 years."

The eight-year period with no annual city payment to the retirement system, known as a "contribution holiday," ended in 2004.

For a police and firefighter pension increase (Proposition H in 2002) voters were told that with a "large surplus" city contributions should not be needed for at least 10 years — but if needed, police and firefighters would pay "all or part" of the added cost.'</comment></comment></comment></comment></comment>


Lifestyle businesses - <AUTHOR> http://www.danielharan.com/2008/06/11/lifestyle-businesses/ <comment><USER2> This is a neat piece. I've found my Mac shareware business becoming a lot like this, as well as a lot of others. In some ways, it kind of annoys me, since I'm always reading startup sites like this, but in others, there really isn't a lot wrong with it.

<comment><USER3> what do you sell?

<comment><USER4> From his profile: <http://www.wonderwarp.com/>

<comment><USER5> That's a pretty cool app, I have a folder sitting on my desktop now called 'To Sort' with 77 items in it :s</comment></comment></comment></comment>


Why building a smartphone without US tech is impossible - <AUTHOR> https://www.hindustantimes.com/tech/here-s-why-building-a-smartphone-without-the-us-tech-is-impossible/story-BeuvBWelB3emXnSgkfGR5J.html <comment><USER2> Necessity is the mother of invention. I think a couple of these problems are overstated and if truly forced to create substitutes many non-US companies would step up to the challenge.</comment>


Hobbystrapped - "because running a small startup is my hobby." - <AUTHOR> http://venturesocially.tumblr.com/post/1730363970/hobbystrapped

<comment><USER2> [http://venturesocially.tumblr.com/post/1730363970/hobbystrap...](http://venturesocially.tumblr.com/post/1730363970/hobbystrapped)</comment>


The Dangers of Productive Procrastination - <AUTHOR> http://singlefounderproblems.com/productive-procrastination/ <comment><USER2> That is so true! one trick (dunno if that's the best word for it though) for dealing with the challenge of delving into some big new project is really starting small. I try and pick the smallest most trivial task and get going from there. I've found that it helps me get into things more easily (divide and conquer I think). I'm curious if anyone else has tried this or has some other techniques to share about procrastination?</comment>


The Chipotle Emphasis on "Throughput" Is A Recipe for Continued Disappointment - <AUTHOR> http://brianstorms.com/2014/02/the-chipotle-emphasis-on-throughput-is-a-recipe-for-continued-disappointment-talkin-to-you-chipotlet.html <comment><USER2> > _The executives describe their business in a thick jargon of corporate > culturespeak including "our unique food culture" (translated: take Mexican > cuisine and remove all the rich vibrancy of actual Mexican culture and > replace with a pleasant, clean, efficient retail ambience right out of the > movie Her)_

Oh, yes, why don't you start off the article by pointedly reminding us that you are _far_ too smug to ever consider eating (gag) _fast food_.

Oh, and then why don't you follow up by implying that "pleasant" and "clean" are anathema to authentic Mexican cuisine and culture. I'm sure that'll go over real well.

The rest of the article may be packed with brilliant insights, but after that intro I'm really not interested in finding out.

<comment><USER3> The article is generally mocking, but I think you're taking that quoted statement a little harder than it was meant to be taken. I think by "pleasant" and "clean" he means sanitized and slightly boring. It later becomes clear that the author does go to Chipotle, seemingly on a regular basis.

<comment><AUTHOR> This. I go prolly once a week. The Chipotle is in the first floor of my office building. But the experience is always the same.

I have nothing but respect for the employees. I feel like it's the corporate level that dehumanizes them and doesn't let them really be empowered, which would mean make sure the customer's happy and their order isn't screwed up. Maybe it's a San Diego thing, but at my Chipotle, the order is destined for screwup unless you watch the folks like a hawk.

</comment></comment></comment><comment><USER4> Never seen any absurd greeting, and for those who havent been to chipotle, or those who want to complain about how they order there, follow this simple guide and you wont have to repeat yourself: tell the person manning the section what you need from them and nothing else.

1\. You step to the first section, tell them whether you want a burrito or a bowl and potentially what type of rice/beans.

2\. Next person, next instruction, tell them your meat and possibly what salsa.

3\. Final person (besides the register) tell them what types of additional fixings, hopefully in the order they would stack next to your burrito.

This is a simple strategy and the only time I have had to repeat myself at a chipotle is when they are playing the music too loud.

<comment><USER5> The "absurd greeting" thing is a trend in the quick-serve restaurant business.

At first it was the "make the manager loop the dining room every 10 minutes" idea, then it transitioned into the "Hey, howzit goin'?" opening at the Taco Bell drive through[2], now it's the sushi-house irasshaimase! being screamed by everyone when the door opens.

[2] On a recent Ask Metafilter thread, someone was honestly asking if the new McDonald's drive-thru greeting ("Welcome Back!") was the result of face- tracking cameras and/or license plate storage being implemented at the store level. It took a lot of pages to try and convince the OP that this was just the corporation trying to be mushy/friendly/feely to the customer and nothing more. I still don't think he was convinced.

</comment></comment><comment><USER6> I'm not clear on what is broken. The reason Chipotle has become what it has is because it serves a particular market, and has been optimized for that market. All evidence points to that optimization being highly successful. A company can not grow as quickly and deliberately as Chipotle unless it is doing an awful lot of things right. And frankly, if you asked: What would McDonald's look like if they wanted to portray themselves as a healthy, eco-friendly, trend-setting fast food company? The answer would look a lot like Chipotle. So queuing theory aside, it works well enough to be a major success. So what if I have to repeat myself to the next server in line? The cost of repetition in this context is nearly zero.

<comment><USER7> McDonald's became a big investor in Chipotle when Chipotle went from 20 to 500 stores. I'd likely argue that no small part of how they became big was due to that hand. Then, McD divests and CMG hits NYSE and they ascend from there.

So, when you ask what would McD's look like if? Is that dancing around history or can I say, "What if I told you...?"

OP got high, got dragged to Chipotle, got all malcontent, and wrote a blog post on how much better he could run the $13B company. Soooo HN.

<comment><AUTHOR> Not really. I'm OP and I go to Chipotle all the time. It just has this suboptimal experience that drives me crazy.

Speaking of McDonald's, I'll never forget when this Chipotle opened, and a huge 18-wheeler McDonalds truck pulled in in the alley out back, and unloaded food supplies into the Chipotle. I had no idea . . .

</comment></comment></comment><comment><USER8> There's no reason to couple the order-taking and the order-fulfilment. At fast-food Mexican restaurants which take the order at the counter, give you a ticket, and hand off your finished product sometime later (I'm thinking of District Taco in DC or Pancho Villa in the bay area) throughput is noticeably higher, particularly because they can make more orders at the same time.

The one downside is limited backpressure on the order line, so you can end up with more people filing in than there are seats (or sometimes even space to wait for your order). Not as much of an issue for takeout-focused joints.

<comment><USER9> I think Chipotle, like Subway and other such restaurants, are trying to give the appearance of freshness and cleanliness.

</comment></comment><comment><USER10> Yeah, I've been to Chipotle probably 30 times in the past 2 years and have never endured the greeting thing. If it weren't for the photos, I'd have assumed the author was writing about Moe's[1] and accidentally got them confused (which is easy, since they're basically the same restaurant, except Moe's DOES the horrendous annoying greeting thing every time somebody walks in.)

1: [http://www.moes.com/](http://www.moes.com/)

</comment><comment><USER11> My real trouble with miscommunication at Chipotle is not that I have to repeat myself several times because I'm encountering new employees (Chipotle seems to have done a good job of training me as a customer to know exactly what I need to say at each section of the line), but that the glass partition is often so high that I have to repeat myself several times because my voice does not project over the glass. I'm 5'4", not abnormally short, and even on tip toe this happens. Having to shout my order is more annoying than repeating it, imo.

<comment><USER12> _Chipotle seems to have done a good job of training me as a customer to know exactly what I need to say at each section of the line_

Hear. "Hi, welcome to Chipotle, what can I get for you?" → "Wheat tortilla. _pause_ Brown rice." As an engineer I don't mind (I know exactly how their queue works and when to say what) but the interaction that takes place is _not_ normal.

</comment></comment><comment><USER13> I go to numerous restaurants with the same model as Chipotle, and none of them seem as disorganized as Chipotle. In fact, my friends and I generally like to make fun of Chipotle for being ludicrously inefficient, in some parts due to the crazy passing around of people and order components mentioned in this article, and partly due to the employees not having any real experience rolling burritos. In comparison, there's a 24-hour burrito place called Freebirds nearby (related lineage, but yet entirely unrelated to other instances of Freebirds if you happen to have one near you: the one in Isla Vista is unique) who have almost an identical mechanic, and yet the staff, many of whom have been working there the entire 15 years I've lived in this area, are able to rapidly organize and serve lines of drunk people going out the door and down the street at 1-2am, and without the burritos falling apart as you attempt to pick them up. I guess to say: I don't think it is Chipotle optimizing for "throughput" that causes the problems described here, as these problems directly and negatively impact their throughput. (Also, for those who doubt the greeting thing ever happens anywhere: the Chipotle near me definitely has the "people jump to greet everyone that walks in the door" property.)

</comment><comment><USER14> > The moment the fingers of one of your hands touch the door handle of the > Chipotle store and pull to swing open said door. It is at that very moment, > allowing just enough nanoseconds for the mere tip of one toe on one of your > feet to enter the restaurant, that the Chipotle Customer Experience begins. > That's all it takes. For you have entered more than a doorway. Much, much > more. You have passed through the Chipotle Greeting Membrane, and like the > blue humming mist above the egg-pods in Alien, Chipotle has noticed.

> "Huhhhhlllllo," some team member, some member of the Chipotle Crew sings, > from somewhere in the distance behind the counter far away, as if some > little buzzer deep underneath their uniform just emitted a gentle Skinnerian > electric shock against their body because a sensor tripped the moment you > came through the door, and this particular type of shock was one they've > been trained to recognize and which makes them mindlessly, instantly sing > the word "huhhhhhllllooo," or an equivalent sweet nothing, without even > looking up.

What a bunch of horseshit.

I visit Chipotle often, and yes, I visit much better Mexican restaurants often too. I do know the difference, but if I'm in the neighborhood of a Chipotle and I'm in the mood for a quick hearty Mexican-style salad, they've never disappointed me.

Part of it is I know what to do. Tell the first person "I'd like a salad to go with no dressing." (Their dressing is some awful sweet thing.) I wait a moment while they get the lettuce into the bowl. When they look up, I say "with brown rice, pinto beans, peppers, and chicken."

At this step and the next one, I pace the ingredient requests to match when they are adding them. It's easier and more reliable to watch and wait than it is to ask them to think ahead.

After the bowl is passed to the next person and they look up, I add, "I'd like pico de gallo, medium salsa, corn, and guacamole. I know the guacamole is extra." (That way they don't have to explain it.)

As the guac goes on, I mention one last thing: "And some lettuce on top so the the guacamole doesn't stick to the lid."

At this point they smile, knowing that I'm a real Chipotle Expert. (Much better when the guac doesn't stick to the lid!)

I'm in and out in less than five minutes (or less than ten if there's a long line) with a delicious salad - less than ten bucks and enough for two full meals.

Now _that 's_ throughput.

<comment><USER15> You've just repeated his thesis. This is exactly what he described. "The customer is really the boss here."

<comment><AUTHOR> Exactly.

</comment></comment></comment><comment><USER5> The author hasn't even begun to describe the mental juggling that you endure when trying to order for multiple people, especially when you're going off- menu or asking for omits/adds. Half your order crosses the boundary to server B and you're still trying to make sure server A has everything down.

With practice (and telling my kids they're locked into their favorite order for the next 10 years), I've managed to hit 80% accuracy. Short of writing it down (and no, their fax-in form has no room for customs or mods), I'm not sure how to get it any better without slowing the line to a complete halt.

<comment><USER16> Custom... mods...?

This is a fast food joint, not a from-parts computer you're building off Newegg. If you're expecting to rove off-menu, good luck.

Ordering from Chipotle for you? Obey the One Rule: tell each person only what they care about. Being as Chipotle is pretty much always moderately busy, you've got 5-10 people ahead of you, spend 3 seconds and notice who's doing what. That way you don't have to repeat yourself or waste anybody's time.

Ordering from Chipotle for you and your 10 friends? Order online, show up, #next.

<comment><USER5> Show me where on the online form I can order:

1) a side of white rice with a side of cheese on top (this is not a bowl with everything else omitted)

2) a chicken quesadilla (yes, this is a thing)

...and the comments/instruction box is just plain useless.

</comment></comment></comment><comment><USER17> Yes it's _...one big First World Problem type of whining..._

Online ordering is the way to go. There is a huge variation in the size of the burritos from order to order, but it's not worth writing more than a sentence about.

<comment><AUTHOR> Seems kind of silly that I would have to order online first, considering that the Chipotle I'm writing about is literally a quick walk down the stairs of my office building. It's literally right downstairs. I go there often. I always, always get the doge-speak "hai therez" and "welcomez" as I enter. It's kind of hilarious. But yeah, I prolly oughta try the online ordering... I'm just afraid they'll screw up and I won't find out until I'm back in my office. Oops, that's a First World Problem.

<comment><USER18> > I always, always get the doge-speak "hai therez" and "welcomez" as I enter. > It's kind of hilarious.

Hahahah totally agree, people with less education who work in fast food are basically idiot dogs.

... wtf, man.

</comment></comment></comment><comment><USER19> Chipolte's system is focused on food consumers or food consuming consumers. Its employees don't care because they can't. Care is not allowed. It slows down the machine. The question "what's good today?" has no meaning because the brown cardboard boxes from which today's ingredients emerged are indistinguishable from the brown cardboard boxes from which yesterday's emerged or tomorrow's will.

The general model of taking orders as people enter and preparing the food in parallel with their progress toward the cashier is sound. Fortunato's Pizza in downtown St. Pete uses it and it works well - despite allowing employees to act dignified instead forcing them to act Disneyfied.

The reason? Fortunato's isn't a franchise and the head of the production line at its nexus with the customer line was the owner himself. The face of the restaurant was its most seasoned veteran. He wrote the order down, and if it was pizza slices dropped them into the machine with the conveyor belt and heat elements himself. His greeting meant something and more importantly his customers' greetings meant something to him. They were his customers afterall.

[http://www.fortunatositalianmarket.com/](http://www.fortunatositalianmarket.com/)

</comment><comment><USER20> I short companies like chipotle. I invest in twitter and snapchat. that is where value is.

<comment><USER20> apparently my sarcasm is not appreciated.

chitptle has a great business model. and for fast food they are pretty efficient. I've been a pleased customer for 8 years. on every transaction, I assume that they made a profit.

<comment><USER6> I laughed and upvoted.

Next time, poke fun at TSLA or NFLX.

</comment></comment></comment><comment><USER21> I think this article exaggerates and I hate the smug tone of it all, but overall I do agree that the Subway/Chipotle model can be annoying at times as a customer. The problem is just that they intertwine ordering and preparing the order. I think this caught on because, as a customer, it's cool to see them make the food in front of you. But overall it causes a few problems:

(1) You can feel pressured sometimes to make really quick decisions because of a line behind you.

(2) It can be pretty confusing ordering multiple items.

(3) It's not actually that efficient. They'd be better off having one person take your order and different people, in a different area, preparing the orders. This would solve all three of these problems.

To make up for the "novelty" (which has died off big time at this point) of watching them prepare the food in front of you, some places just style the building interior in a more lively and fun way. For instance, one of my favorite local Mexican restaurants follows the above model, and the interior is designed to make it look like you're ordering from a taco cart on a Mexican street--even though you're actually in a strip center which is extremely generic looking on the outside.

</comment><comment><USER22> When discussing suggestions for improvements, the author notes:

>When Subway and Quiznos work well, they work well because you, customer X, and employee A, stick with each other the whole way down the line.

To be honest, this hasn't been my case for any Subway or Quiznos I've visited. The ones I've visited has always had a manned section, with one employee responsible for that section (bread, meats, condiments, checkout, etc.)

The difference, I find, is that at Chipotles, they seem to rush you along between sections. I guess, similar to eating a restaurant where they're trying to turn tables over...if you're in that mindset (get in, get out), it works.

At Subway, things are bit slower. The employees work together, relaying the information amongst each other (if possible), or getting that information from the customer. There's more conversation, I find.

</comment><comment><USER23> Or, you could realize how you're supposed to order at Chipotle based upon experiencing the fail, and do that next time. Don't tell the first person what meat you want, that's not their job. Know that you'll need to tell the cashier what your order is so they can ring you up. Don't order weird shit that's not made up of the basic stuff on the menu, keep it simple.

It's not complicated, the reason their business model works is because their food is pretty good and for the customer who adapts to understand their workflow they can get their food crazy fast. Its painless and I'd imagine this adaptation process where Chipotle regulars "know the drill" and get their food in like 30 seconds is part of the reason the company is doing so well.

</comment><comment><USER24> If a $17B market cap and continued growth is recipe for disappointment, then keep on disappointing more and more customers ([https://www.google.com/finance?q=NYSE:CMG](https://www.google.com/finance?q=NYSE:CMG)).

I'm a happy Chipotle customer. Fast, efficient, and clean. I like watching them make my burrito. I like telling them that they're putting too much of something or to load up more on the corn salsa. I also like that they cook the steak to a medium.

</comment><comment><USER25> Actually, my experience at chipotle has been pleasant most of the time and I order out of script stuff("chicken bowl to go with the fajita(veggies) and the tortilla on the side")

Big orders do throw them off but that's because they are optimized for the 99% case of 1-2 orders/customer.

</comment><comment><USER26> I went to Chipotle for lunch yesterday and felt really rushed, even though there weren't too many people behind me. I'd rather wait in line longer and have a more pleasant experience than to be another customer they just process through the line.

</comment><comment><USER27> They have at least one branch in London now. I've been there. They didn't do the creepy greeting thing, probably because we'd look at them like they were crazy and walk right out again. Also they might not find any workers.

<comment><USER28> Ive been at least 20+ chipotles in at least 5+ US states and never heard of this greeting thing.

<comment><USER29> I've never been greeted like that in MN and would probably walk out after saying "Yeah... no...". I do tend to go to Panchero's when I'm in the Twin Cities, MN.

</comment></comment></comment><comment> jack-r-abbit Sounds like this particular Chipotle we're talking about here is a just a shitty one. I've never had an issue with their assembly line process. It works quite well for me.

</comment><comment><USER30> Are there two chains called Chipotle and I've only ever been to one of them? Because this is clearly not talking about the one I've been to.

<comment><AUTHOR> Maybe it's a San Diego thing. This is what my Chipotle is like. Every time. I go frequently.

</comment></comment><comment><USER31> Queuing theory at it's finest! Bravo.

</comment><comment><USER32> Chipotles is such a hipster crap bucket. I can't believe people actually stand in long lines and pay good money to eat that wannabe faux texmex at a sterile no atmosphere cafeteria counter. If you are one of their many lost patrons, please do yourself a favor and go to a real texmex restaurant (or actual mexican for that matter) and discover what real food is like.

<comment><USER33> I like chipotle and I like real tex mex (I live in Texas). Chipotle is a better replacement for fast food; it doesn't compete in any way with tex mex restaurants in my mind.

</comment></comment><comment><USER34> This author needs to visit a pharmacy, not a Mexican fast-food franchise.

</comment><comment><USER35> I really don't care if I have to say "steak" twice. If it was 3 times I would probably not go there again, but twice is a not a big rock for my wagon.</comment>


US inaction is hurting the chance for peace in Libya - <AUTHOR> https://thehill.com/opinion/international/490917-us-inaction-is-hurting-the-chance-for-peace-in-libya <comment><USER2> I guess they could nominate that guy.

But as it notes Libya is just a game being played by a lot of players acting mostly on their own and I suspect little regard for the locals or peace.</comment>


Cpp-Taskflow: A New Task-Based Parallel Programming Library Using Modern C++ - <AUTHOR> https://github.com/cpp-taskflow/cpp-taskflow <comment><AUTHOR> We are happy to announce Cpp-Taskflow 2.0 - a new major release to help you quickly build large-scale parallel task graphs. With this version, you can enable both static and dynamic tasking in just a few minutes. Visit our GitHub ([https://github.com/cpp-taskflow/cpp-taskflow](https://github.com/cpp- taskflow/cpp-taskflow)) to learn more.

"Cpp-Taskflow has a very simple and elegant tasking interface. The performance also scales very well..." taskflow user quote

</comment><comment><USER2> This looks fantastic. Anyone tried it on aarch64?

<comment><AUTHOR> Thanks. It works on that platform as long as you have g++7.2.</comment></comment>


Stu Ungar - <AUTHOR> https://en.wikipedia.org/wiki/Stu_Ungar <comment><USER2> I read his biography over a decade ago in one night and it has stayed with me probably more than any other book I've read. It's such a gripping read. His talent and intellect were so clear that it makes his story all the more tragic.

Just one small anecdote from the book. By the time he was like 13 or 14 he was playing in the biggest underground card games on the East Coast. We're talking sketchy backrooms of bars hanging with some of the shadiest people betting tens of thousands of dollars. Not only was he super young, he had a small underdeveloped frame that made him look even younger.

So how was he able to get by in such an environment taking the money of shady characters much older and bigger than him? He was backed by the mob! Yup, his talent was so apparent at even such a young age, that the mafia took an interest in him and backed him both financially and physically from harm.

I really suggest any one interested to read the book: [https://www.amazon.com/dp/074347659X/ref=cm_sw_r_tw_dp_U_x_v...](https://www.amazon.com/dp/074347659X/ref=cm_sw_r_tw_dp_U_x_vU0KDb7WT1RBH)

</comment><comment><USER3> I was in Vegas this summer, and an older lady dealing in my games told us a few Stu stories. She dealt for him back in the days. She said that he was never the same after his son's death and never recovered from it. She also talked about his total recall memory as said in the article, he couldn't forget anything or anyone unless he was on high doses of drugs, which is probably why he was so addicted (must have been some sort of relief).

Today players are much stronger than he could possibly have been, though. There are a couple of players online of which we can easily say that they are the best players to ever live, and we know from recent advances in AI poker that they still have room to improve. Saying that he is the best player to ever live would be like saying Bobby Fisher or Paul Morphy are the best players to ever live ; it's true in the sense that they were more dominant in their days than anybody else in other eras, but in terms of pure game knowledge it keeps evolving as years pass.

<comment><USER4> > There are a couple of players online of which we can easily say that they > are the best players to ever live

Who are they?

<comment><USER5> I don't know who OP is referring to but I would argue against the notion that there are a couple of players who are clearly the best to ever live. The edges between the top players are way too small to determine this especially at the small sample sizes that they play against each other.

And the question becomes more complex when you realise that poker isn't just one game and you need to consider NLH vs PLO vs mixed, heads-up vs 6-max, cash vs tournaments. Some people specialise in a variant, others just play everything.

<comment><USER3> We could explore every variants indeed, but nlhe is the most popular and Stu's game choice. I was thinking about Linus and Baron as pete_mc replied, they've both crushed it in the past few years.

Of course there are other specialists above their competition in every variant ; my point remain, though, that the level is much better now, and would we analyse the plays made by Stu with solvers, we would find lots of mistakes made. (Actually I will probably do it for fun).

My point being, Stu was incredibly dominant in his time, and props to him for figuring out so much about the game especially back then, and that's a feat just for itself, but other players are incredibly dominant now too and with a much better understanding of what they are doing.

</comment></comment></comment></comment><comment><USER6> > During the 1992 World Series of Poker, Ungar faced off against 1990 World > Champion Mansour Matloubi in a series of $50,000 buy-in no limit hold'em > heads-up freezeout events. On the final hand of the game, Matloubi tried to > bluff Ungar all-in for $32,000 on the river with a board of 3-3-7-K-Q. > Ungar, who held 10-9, thought for a few seconds and said to Matloubi, "You > have 4-5 or 5-6 so I'm gonna call you with this" and flipped over his > 10-high to win the pot and bust Matloubi, who in fact held 4-5 offsuit.

<comment><USER7> Today exploits like this are impossible against even average players

<comment><USER8> Can you explain what would be impossible? Ungars call or Matloubis bluff? Novice poker player here, trying to understand.

<comment><USER3> We would need the transcript of the game to analyse it properly. Here it is :

\</comment></comment></comment></comment><comment></comment><comment>---- Stacks: Ungar: ~60,000; Matloubi: ~40,000 Blinds: 200/400 Hands: Matloubi holds 5-4 offsuit in the BB; Ungar has 10-9 offsuit in the small blind (the button).

Preflop: Ungar raises to 1,600 in the small blind, Matloubi calls.

Flop (pot 3,200): 3-3-7 rainbow Action: Matloubi checks, Ungar bets 6,000, Matloubi calls.

Turn (pot 15,200): K, board still rainbow Action: Matloubi checks, Ungar checks.

River (Pot 15,200): Q Action: Matloubi moves all in for about 32,000 and Ungar calls within a few seconds, declaring, "You've either got 4-5 or 5-6, I call." Ungar then flips up his 10-high to drag the $80,000 pot. \</comment><comment></comment><comment>----

Not sure what your parent has in mind, but just from the choice of sizings from both sides, I doubt that many people would play either side of the hand this way nowadays. Which kind of make any analysis a bit pointless. But I'll check tonight with a solver if it has anything to say about it.

<comment><USER9> Can't see how Ungar could have acted any differently here given the betting by Matloubi?

<comment><USER10> He had ten high. That loses to most bluffs. It's an underdog to a random hand.

Normally you'd fold and laugh quietly to yourself because your opponent thought they bluffed you when really they had the best hand.

</comment></comment></comment><comment><USER11> I used to play online poker a lot in the early 2000s.

What's really interesting between Stu's era and today (or even the last 20 years) is technology.

Live poker is a pretty slow game. You might get 30 hands in per hour and play with 5-15 other people (rotating in / out) during a few hour time span. The bottleneck is mainly the physical action of moving cards around, counting chips and slow players due to the environment.

But online is a totally different game. You could pretty easily play 4 tables in parallel by tiling them on your monitor. Then there was software you could run that overlays stats about every player you encounter (collected automatically). You gathered tremendous amounts of data that you could then analyze in real time to help make decisions and then also look at a hand by hand audit with those stats to help evaluate your game after the fact.

Some people ended up playing 10+ tables at once (even at pretty high stakes), and an online game can easily get 90 hands per hour just on a single table. So if you do the math, you could be cranking through 900 hands an hour vs 30 in a live scenario. That's 30x more hands played per hour. If you factor in playing for tens of thousands of hours, the amount of experience you can gain online in such a short amount of time is crazy. You could put in many millions of hands online vs low hundreds of thousands live, and then have a ton of data to help figure out the game better.

1 year of playing online like that gives you 30 years worth of experience. Of course it's not as high quality of experience since 10 tabling is tough, but even if you dropped it to 5 tables, that's still condensing 15 years worth of live play in 1 real life year online. So it's no surprise that players now have a huge upper hand in being able to improve their game.

<comment><USER12> Online and live are very different, though. Some of the skills are transferrable, others not so much. I think you can get very good online and then get trounced live where you are _limited_ to one table and don't have all your HUDs and record keeping software. When you're playing 10+ tables simultaneously online, are you even paying attention to the action at any particular table when you're not in the hand?

<comment><USER11> I don't play that many tables, but probably not much thought would be given to those hands since people playing 10-20+ tables are usually trying to grind out hands at a low +BB/100 win rate or even breaking even while taking advantage of rake back deals (not sure if that still applies today).

But at 3-5 tables you can definitely play close attention to everything going on. A lot of really high level players do well in both environments.

</comment></comment></comment><comment><USER13> Most top players today are like athletes. They eat, exercise, and study the game like pros. Being a sick drug addict and winning tournaments was just raw ability.

The level of the game was lower at the time. Ungar would be high level player even today's standards, but his game would not look as spectacular.

<comment><USER5> > Being a sick drug addict and winning tournaments was just raw ability.

And lots of luck. The variance in low sample sizes is ridiculously high, especially in tournaments.

<comment><USER14> I'd argue in those days the edges were much much bigger as well.

A good player like Stu would not have experienced that much variance against a weak field like back then

</comment></comment></comment><comment><USER15> A true legend. Probably would have been considered the best poker player of all time (and still is by some) if not for his drug problem and untimely demise.

</comment><comment><USER16> How could he bust out of single deck black jack with a $300,000 bank roll? Even someone like me who has a terrible memory can play a winning game against the house in a single deck game. Actually, you can easily play a winning game against single deck with basic high-low. That has to be drug abuse.</comment>


Uber, Maker of Summon-a-Car App, Wins in Washington - <AUTHOR> http://bits.blogs.nytimes.com/2012/07/10/uber-vs-washington-dc/ <comment><USER2> This is very disappointing. I hoped that the government would treat its duty to protect me from cheap car services more seriously.

<comment><USER3> I realize you are joking, but the concern really is that cab companies are something that consumers are trusting their lives with, and often in situations before they can evaluate trustworthiness or history, if not of entire companies then certainly of individual drivers. There are extensive regulations that have thereby been placed on such companies over the years related to vehicle maintenance, specialized insurance, and traffic organization. Uber believes that none of this should apply to them because they are being "disruptive" (as if that is somehow itself a benefit for which we should be optimizing as a society).

<comment><USER4> We don't miss regulation until it's gone. The apartheid government, in its dying days, decided to promote free-marketism and it deregulated the minibus taxi sector, thinking that each driver would run a one-man business. What really happened is that those with access to capital bought fleets of minibuses and South Africas cities became a nightmare by the mid-1990's with taxi-owners forming cartels which engaged in bloody wars for lucrative routes. The taxis are unsafe, and their drivers are reckless (passengers dare not complain). Government attempts at re-regulation are constantly stymied.

The taxi industry operates with impunity, and managed to get ownership of new Bus Rapid Transit systems in Johannesburg and Pretoria (they'd have shot bus drivers if they didn't get a stake).

I've been threatened personally with a weapon (a hammer, not a gun, fortunately) by a taxi driver who felt I didn't move out of his way fast enough. Not coincidentally, it was around that time that my libertarian leanings began to wane.

<comment><USER5> "engaged in bloody wars for lucrative routes" "threatened personally with a weapon"

Isn't the obvious solution to this problem the enforcement of existing laws against threats and violence?

Or conversely, if the government is so weak that it can't stop the taxi cartels from fighting bloody battles, surely it's also too weak to enforce cab licensing laws.

<comment><USER4> Yes, the fundamental problem is a weak state.

However, deregulating the industry made the problem far worse than it could have been. Our law enforcement is not entirely ineffectual, and a permit system would have provided more control than a free-for-all, by moderating supply. Buses remained more tighly controlled and I don't see bus warfare (there is an upward trend in accidents involving buses though I think that has more to do with poorly skilled drivers than profit-seeking).

</comment></comment></comment></comment></comment><comment><USER6> It's worth pointing out that many commentors in the last thread on this case justified the historic price regulation of cabs by municipalities based mostly off _safety issues_ , and often said that it was reasonable for the government to continue to so regulate even when technology disrupted the industry:

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

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

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

But the city council gets some angry emails from constituents about blocking Uber and what do they do? Remove the minimum prices requirements _without_ any compensating changes to the safety regulations. (Presumably, Uber cabs already satisfy the safety rules for dispatched sedans.)

So, whatever you think about cab regulation in the abstract, I think this is good evidence that the mechanism for how the government actually makes regulatory decisions bares no relation to abstract arguments. The government officials are just human beings responding to their various incentives.

</comment><comment><USER7> This is good news. What was proposed before (a price floor five times above taxis, assuredly to prevent disruption of the taxi industry) was not at all in the public's best interest.

<comment><USER8> Agreed. I don't understand preservational methodologies such as this. If the demand for taxis dies as a result of better alternatives, then let it. How else will we progress without being willing to give up our old habits?

<comment><USER9> It's not quite as simple as that -- taxis are widely used by homeless/indigent people as sometimes their only means of transportation to get to the doctor/employment/etc. These individuals may not have the correct technology or knowledge to use services like Uber.

If the taxi industry does die, cities should provide some kind of "summon-an- Uber" facility, perhaps through former payphone locations etc.

<comment><USER10> > It's not quite as simple as that -- taxis are widely used by > homeless/indigent people as sometimes their only means of transportation to > get to the doctor/employment/etc.

Wait, seriously? Taxis are pretty universally expensive, so it'd really surprise me if those without gainful employment were using them. Public transportation is far less costly, even if it is less convenient most of the time, so I'd figure that'd be used more in these cases.

<comment><USER11> That's assuming you live in a place with good public transportation.

A lot of people you wouldn't expect to be able to afford a taxi have to rely on them because they can't afford a car. It's one of the defining things about poverty, you end up spending more money on things than somebody better off because you can't afford the capital outlay to make it cheaper.

</comment></comment></comment></comment></comment><comment><USER12> I've been their customer for the past few months and I have to say, this service is quite amazing. It's not cheap, but it is extremely convenient and the cars and the drivers are really good.</comment>