Ford CEO says the company 'overestimated' self-driving cars - <AUTHOR> https://www.engadget.com/2019/04/10/ford-ceo-says-the-company-overestimated-self-driving-cars/ <comment><USER2> Ford's problem may be Argo. Ford spent $1 billion for Argo, and paid for a big building with the Argo name on top. But Argo didn't get their California license to test autonomous vehicles until early this year.[1]

Self-driving has had too many "fake it til you make it" startups. Cruise started that way, and suckered GM into buying them for $1 billion. Uber bought Otto, and we now know how fake that technology was. Tesla hyped their basic lane-keeper and car detector into an "autopilot" then repeatedly plowed into clearly visible obstacles and killed people.

(Despite all the blithering about edge cases, they haven't been big problems in practice. The serious Uber and Tesla accidents were not edge cases. They were blatantly obvious obstacles: a semitrailer, a fire truck, a fixed barrier, and an isolated pedestrian on an open road.)

Waymo, meanwhile, keeps plugging away, driving around, getting their level of disconnects down each year, improving their sensors, and doing large scale tests. Once in a while they get rear-ended. If they don't get killed by Google/Alphabet's attention deficit disorder problem, as happened to Google's robotics efforts, they're going to get this into production.

It's not easy, and it's not impossible. It's just hard, like television or xerography. Those took decades from first demo until they worked well. This doesn't fit well with the startup make-money-fast model. It does fit with the big-company R&D lab model.

[1] [https://techcrunch.com/2019/01/29/argo-ai-acquires-permit- to...](https://techcrunch.com/2019/01/29/argo-ai-acquires-permit-to-test- autonomous-vehicles-in-california/)

<comment><USER3> I agree Waymo is doing the best here, but Waymo is nowhere near a real self- driving car. They can't make unguarded left turns. Or drive in the dark, or the rain. Much less the snow, or in construction, or on poorly marked roads, or roads that aren't marked at all. Or city roads that aren't laser-mapped to the centimeter. Or roads with many pedestrians. Or cyclists.

And even when they do make it work, how is money going to be made by someone like Waymo? I don't see a route to the supposed massive profitability that would justify the huge investments being made.

<comment><USER4> > I agree Waymo is doing the best here, but Waymo is nowhere near a real self- > driving car. They can't make unguarded left turns. Or drive in the dark, or > the rain. Much less the snow, or in construction, or on poorly marked roads, > or roads that aren't marked at all. Or city roads that aren't laser-mapped > to the centimeter. Or roads with many pedestrians. Or cyclists.

I work for Google, opinions are my own.

I don't know the specifics myself but I trust what you're saying is true and agree those are real problems.

Nevertheless, one of the best things to do when you have a really hard problem is to simplify the problem. It's not as though we have to have fully self driving cars before they're released.

I think what would make a lot more sense is some middle ground where we have certain sections of the road where self driving cars will be able to work well and only allow them there.

<comment><USER2> That was the idea with Google's little bubble car. It was supposed to have a top speed around 25mph and cruise around retirement communities. That seemed like a feasible goal. But it cost too much to make as a product. The LIDAR units alone would have put it over $100K.[1]

Voyage.auto [2] claims to be deploying such cars now. Or rather, their web site contains announcements from late 2018 that they were doing so. Later information seems to be lacking. It's a basically good idea, but they claim an on-site staff of 5 for three cars, so they are nowhere near this making financial sense.

A real problem with self-driving cars is the false-alarm rate for emergency braking. If you're conservative about crash prevention, every once in a while the vehicle is going to detect something it doesn't identify as safe and will brake hard. That's why Uber turned off automatic braking in their cars - "to reduce potential for erratic behavior."[3] False-alarm braking, or even strong braking conservative by human standards, limits customer acceptance.

[1] [https://arstechnica.com/cars/2015/05/googles-quirky-self- dri...](https://arstechnica.com/cars/2015/05/googles-quirky-self-driving- bubble-car-hits-public-roads-this-summer/)

[2] [https://voyage.auto/](https://voyage.auto/)

[2] [https://www.latimes.com/business/autos/la-fi-uber-arizona- nt...](https://www.latimes.com/business/autos/la-fi-uber-arizona- ntsb-20180524-story.html)

</comment></comment></comment></comment><comment><USER5> The problem with self-driving cars is you can get most of the way to a working solution but that's not good enough.

If the solution is flawed even a little bit, people will die. That will give self-driving cars a bad reputation and people will be unwilling to ride in them.

If you are going to geofence self-driving cars it is questionable whether they are better than trains and buses.

I think the best we can hope for in the next 10 years is better driver assistance systems, like GM Super Cruise or Tesla's Autopilot (if they can make it stop crashing into things).

<comment><USER6> It seems to me that self-driving cars can't be just as safe as the status quo, but have to be far far better. It's an unreasonable need, but human nature.

I'll bet that to really make it work well, you also need to redesign roads to suit the new cars.

In any case, I'll believe it when I see widespread/universal adoption of self- driving in constrained environments (mining vehicles, warehouses, storage yards). Step two will be things like garbage trucks (slow, expensive, otherwise automated, phone home when it gets in trouble).

<comment><USER7> >It seems to me that self-driving cars can't be just as safe as the status quo, but have to be far far better. It's an unreasonable need, but human nature.

What would be the point of self-driving cars which were no safer than the status quo? That's just removing freedom from drivers and adding more complexity to infrastructure for no added benefit.

It's also exactly the narrative that proponents of self-driving cars have been driving (pun intended), self-driving cars would eliminate all, if not nearly all, accidents and fatalities.

<comment><USER8> What they're talking about I think is the usual statement that self driving cars only need to be slightly better than the status quo (in deaths per mile driven) to make sense because then anyone moving from driving to using a self driving car decreases the number of deaths. From a raw statistics POV this makes sense, if a self driving car is even just a little bit better than the average driver on average anyone switching to an autocar will decrease the number of injuries.

What they're saying (and I agree) is that human nature means people won't be willing to get into a car that's 'just a little better than average.' There's a couple reasons I think that will be true: 1) people generally think they're better than they are at driving 2) moving from people to autopilot moves the responsibility from generic 'bad drivers' causing accidents to a single system. Going from a diffuse responsibility to a more concentrated liability on the part of the manufacturer will probably mean they'll be blamed much more for the failures of their cars.

<comment><USER9> I think insurance companies can affect this behavior. If self driving cars are safer, then the insurance companies could lower rates for those cars, creating some economic incentive to override the irrational human brain.

</comment></comment></comment></comment></comment><comment><USER10> I think a more fundamental problem here is that self-driving cars are as much an infrastructure problem as they are a technological one.

As an analogy, consider hybrid vs electric vehicles. In places like North America with large, open spaces, electric vehicles really only serve a specific type of urban driver. The culture, infrastructure and geography dictate 600km distances which really aren't practical at the moment with current battery tech. Whereas hybrid vehicles can (or could) quite easily reach that range with options to recharge once you get to your destination or have a longer stopover and still use existing infrastructure. The focus on purely electric is a lost opportunity for anyone who needs power or long distance.

Similarly, cars could be designed to be self-driving in the easy cases; highways, certain urban thoroughfares, particular times of day and the like where existing vehicle and pedestrian flow patterns eliminate the edge cases. coordinating systems along the aforementioned types of roads could be installed as was done for cellular service and GPS and other protocols could be developed to ensure safety and reliability as well as fallback in case of emergencies.

Instead, we've decided on all-or-nothing bets which don't move things forward --or at all--and my worry now is that we'll lose an opportunity to pick the low-hanging fruit and solve the harder problems incrementally over time.

<comment><USER11> But chasing the higher hanging fruits might allow for breakthroughs that you would not see if you only went for the low hanging fruits.

The range anxiety is less and less problematic with EV. The Tesla Roadster 2 already is said to have a range of more than 1.000 km. Add current research in the fields of solid state batteries and super capacitators and you have the possibility to reach those numbers even with less expensive versions of EV. German automakers already calculate that by 2026 electric engines will be cheaper and more capable than their ICE counterpart.

If you go for that easy middle ground like hybrid cars that you suggest, you limit yourself to the local maximum of that solution. Hybrid cars have the same maintenance cost as non hybrid cars and additionally the complexity of balancing both engines. The only saving in maintenance cost is by going full electric. In the same way you might only achieve certain breakthroughs by actually going for full autonomy even if it wont work perfectly for the next decades for all edge cases.

<comment><USER12> Bloomberg believes Teslas numbers are a little optimistic and claim it's not possible with "current" battery technology: [https://www.bnnbloomberg.ca/tesla-s-newest-promises-break- th...](https://www.bnnbloomberg.ca/tesla-s-newest-promises-break-the-laws-of- batteries-1.924595)

It doesn't mean Tesla won't do it. But it will be a big deal if they do.

</comment></comment></comment><comment><USER13> Well it's been a day or two since I've had a comment buried so I might as well not mince words.

It's an incredibly difficult problem and Ford is way behind. So it makes sense for him to try to reduce expectations.

On the other hand, there are a lot of other companies than Ford doing self driving cars, and some are very advanced.

It is really amazing to me that people are still in denial about the existence of self driving cars.

They have existed and worked with various limitations for decades. The latest from Tesla and Waymo are still limited in some ways but also extremely capable.

Teslas can now do all of the driving from one freeway to another up until you enter a normal street.

Waymo is way beyond that. From what the riders are saying at r/selfdrivingcars, the only time the employees actually need to take over are occasions where there are very risky maneuvers in heavy traffic. Now, I believe they could relax the safety parameters and the cars would execute the same as the Waymo employees in those situations. It's just that there is no margin for error sometimes with traffic and if there is an accident at this stage they want to be able to blame the employee.

So what's holding Waymo back from removing the employees from the car is mainly just an abundance of caution.

<comment><USER14> Has Waymo expanded the list of routes significantly? Last I read about it, the number of disengagements was very low, but the cars were traveling a pretty low of number of fixed routes in areas with good weather and visibility.

<comment><USER13> They are not fixed routes at all as far as I know. It takes people where they ask to go on the app according to what I've heard. It is a geofenced area. Phoenix pretty much always has good weather and visibility that's why they are starting there.

</comment></comment></comment><comment><USER15> I've been saying this for a while. Truly autonomous cars are decades away.

My line has always been that I hope that by the time I can't, or am not allowed, to drive any more, autonomous cars will be ready... But that I am not even sure about that.

Many of my friends have ridiculed me. They think their elementary-school-kids will not need to learn how to drive. Perhaps I'll have the last laugh. (But actually I hope I'm wrong about this.)

<comment><USER16> Here in Seattle, we have single-lane roads that go both directions.

When two cars are facing each other, there is a lot of human interaction and understanding about who should go first, who should pull off into a parking spot, or perhaps who should reverse into the intersection to let the other pass.

This is one of thousands of edge-cases that are going to be extremely challenging to automate. I'm not sure it's even possible without some understanding of the counterparty, their intentions and body language.

One problem with developing these technologies in California is that California has very wide, very regular roads. High visibility and dry conditions are the norm. There are few uncontrolled intersections (in Seattle they are the rule, not an exception). I think California's history as a motorist culture has conversely made it one of the easiest places to automate.

<comment><USER17> > Here in Seattle, we have single-lane roads that go both directions.

We have those in California, too.

> One problem with developing these technologies in California is that > California has very wide, very regular roads.

Except where it doesn't.

> High visibility and dry conditions are the norm.

San Francisco, for instance, has fog about 1 in 3 days of the year.

<comment><USER18> >Except where it doesn't.

It has few enough that you can route around them and still get where you're going.

<comment><USER19> > It has few enough that you can route around them and still get where you're > going.

I think this is a misconception. California has many residents who live in areas that don't have the super wide roads you're thinking it has. It has a wide gamut of roads and many residents (such as myself) are surrounded by more narrow roads. I'm not even in San Francisco. I'm in a suburb in the bay area. (San Carlos)

<comment><USER20> Exactly where in San Carlos do you think a self-driving / autonomous vehicle would not be able to traverse without affecting the safety or enjoyability of a pedestrian / bicyclist / another vehicle?

The following seems to show a road next to a playground in San Carlos.[1] You think thats too narrow a road for an autonomous vehicle to navigate without endangering kids? Have you familiarized yourself with the latest in autonomous / self-driving tech?[2]

I think your fears are overblown or purposely exaggerated.

[1] Laureola Park San Carlos, CA Playground

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

[2] The $800M Robo Taxi That Could Beat Uber

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

<comment><USER19> 2 blocks from that playground.

[https://goo.gl/maps/vokEswX4S8z](https://goo.gl/maps/vokEswX4S8z)

I live on that street. The streets adjacent to it are also plagued by a plethora of cars on both sides. Much worse than what streetview is showing because streetview is done midday on weekdays when everyone is gone. (Notice how most of the driveways are empty and recycling cans are out - it's the middle of a Thursday that this was taken) It used to be that people would park with their cars on the curb to give more access but I don't see people doing that anymore.

Certain weekends and at night these streets are very full with cars. Much more than google street view shows. It's deceptively smaller than it appears. It looks as if two cars might be able to slip by but frequently not the case. I can't actually remember the last time I saw two cars go by each other side by side without one pulling over to wait for another to pass on my street in particular. The more main street to the south has the same problem but is even wider.

The streets in particular are pretty wide for this issue but because of street parking being available on both sides, it's an issue.

</comment></comment></comment></comment></comment></comment></comment><comment><USER21> I'd rather have frequent, reliable and safe public transport than self-driving cars. Can we pour billions of dollars into that instead, please?

<comment><USER22> Self-driving cars are the future of frequent, reliable and safe public transport.

Why own a car when you can have a self-driving car pick you up from anywhere, bring you anywhere, and drive away to the next customer when it's done.

Sure some people would still want to own a car, or drive one themselves, but eventually I can imagine self-driving shared cars will become cheaper and are still a reliable way of transportation. For many people, owning a car will no longer be desirable since shared self-driving cars suit their needs.

<comment><USER23> Because where I live it takes at least an hour for a taxi to decide to come get me (and that's being generous: last time it was about 4 hours). Uber simply says "no cars available" and Lyft frustratingly shows cars 10 miles away that simply disappear. Just because the car has no driver doesn't mean that the economics change enough to service a low population density area.

The reality is that there are huge swaths of the US where you need personal transportation.

<comment><USER24> > The reality is that there are huge swaths of the US where you need personal > transportation.

Yes, but 80% of the population lives in urban areas, so would be better served by improved public transit. That doesn't mean anyone is taking your personal car away if that's the best way to get around in a low population density area.

</comment></comment></comment></comment><comment><USER25> I've often wondered why consumer-level self-driving cars are being pushed as a thing when the logical step would be automating service vehicles first - low- risk vehicles that cover the most miles, which can go much slower if working 24/7\. Instead of trying to replicate complex pedestrian routes at standard speed, why not handle established delivery routes instead, and optimise over time for new routes?

It's interesting to see how the numerous players in the field, including startups across the globe, are trying to handle this problem, but no one seems to be close. It's a slow race, where everyone is noisy in order to not seem they've been overtaken.

<comment><USER26> almost.. like trains?

<comment><USER27> Curious have you ever been on one? Not sure how fast or slow they are for cargo but I have taken a train from Orlando to Hollywood (near the Miami area) approx a 3 hour drive by car. On a good day its a 6 hour train ride, I think I have been on there for 10 hours before. Some people for waaay longer from further up north.

I rather be on the road but a train was cheaper than spending money on tolls plus gas. Saving money then was a necessity for me.

<comment><USER28> I can't believe that "have you ever been on a train" is a real question.

Depending on the route, I could see those numbers being reversed in the UK and Europe; intercity trains are fast but pricey, even allowing for the much higher fossil fuel taxes.

Commuter trains are a similar story; while it's expensive and unpleasant to commute into central London by train, doing it by car will be even slower, incur the congestion charge, and there's nowhere to park.

<comment><USER29> The price various a lot.

\- In Belgium you can ride from anywhere in the country to anywhere else for 7.5€ (if you buy a prepaid ticket for 10 rides), which is hard to beat even with a car with great mileage.

\- In Portugal, you can go from Lisbon to Porto for 15€ (buying a couple weeks in advance). By car, that won't even cover the tolls.

</comment></comment></comment></comment></comment><comment><USER30> If it allows for development of more systems to to augment a driver's ability or limitations. Rather than relying on some unfeasible HAL dream. Things such as: [https://en.wikipedia.org/wiki/Collision_avoidance_system](https://en.wikipedia.org/wiki/Collision_avoidance_system)

BMW has been working on something similar, in the goal of developing new safety/comfort for riders. I tried showing it to some older riders who gave the whole 'they want to automate everything etc etc carburetors drum brakes kick starts points etc' [https://www.youtube.com/watch?v=MfGmfV9em1A](https://www.youtube.com/watch?v=MfGmfV9em1A)

<comment><USER31> That's what most of people don't understand - self driving cars are evolutionary, not revolutionary. You are not getting a car that can do everything - just a car that does progressively slightly more and more every day, like automated parking on 2019 toyotas or adaptive cruise control, etc.

<comment><USER32> If my car could drop me off at the front door and go park on its own, that would be a significant improvement over the status quo. A personal automated valet is perhaps a little easier than an automated driver that does everything. Low speeds also means stopping or starting on a dime, which would allow it to be more conservative about identifying obstacles than when driving at highway speeds.

I don't really understand why nobody aimed for that sort of incremental improvement. Maybe the sensor package is too expensive to use in such a limited fashion?

</comment></comment></comment><comment><USER33> Game changing technology tends to be overestimated in the short term and underestimated in the long term.

<comment><USER34> Any examples?

<comment> barry-cotter Personal computers, mobile phones, genome sequencing, MOOCs, email, the telegraph, phones, the railway.

There are examples where it was just straight up overestimated as well of course, like AirPower in warfare but air travel was definitely under estimated too. A plane is a flying bus and people travel across a continent for a weekend trip.

</comment></comment></comment><comment><USER35> If you think that self-driving cars are going to take over anytime soon, I have some bitcoin to sell you.

<comment><USER36> i mean, bitcoin is doing quite well..

</comment></comment><comment><USER37> I don't understand why all these car companies are trying to create it themselves ( doubted it since it was starting to be a hype)

Self driving cars is currently a not solved solution ( too complex). Instead of putting in billions of dollars to be the best.

Put in billion of dollars to work with the best when a decent solution comes out ( eg. currently that's Waymo) and delegate responsability. Currently, i wouldn't partner up with any of them.

<comment><USER38> There is a real danger that someone else comes up with a solution that is enough better than humans that governments outright ban anything else. This risk has a huge downside.

Car companies need to hedge this risk. There is evidence that self driving cars can work (they already do in some areas), so the amount of effort worth putting in his pretty high.

<comment><USER39> Car companies are extremely capable lobbyists. They'll probably be fine.

</comment></comment></comment><comment><USER40> So we're entering the through of disillusionment, which is only part 3 of the hype cycle tough.

</comment><comment><USER41> It has been obvious to intelligent observers since the self-driving car hype started that this hype is hugely overblown. My own opinion is that fully self- driving cars capable of competing with human drivers will remain a dream for at least two more decades. What really interests me is why and how the hype became so powerful, even among people who one would think would know better. How much of the hype is explained by stupidity and how much of the hype was created as a deliberate scam? I also wonder if maybe the military is more involved that people might think. After all, even if self-driving cars are decades away, the autonomous technology created as a product of self-driving car research can be already used, now, for military appications. A tank doesn't have to avoid killing people the way that a car on public roads does.

</comment><comment><USER42> Of course the car companies are all in on an improvement to their devices that would sell more of them; what I really want, though, is far more buses on the road (big ones on the arterials, van-sized ones on the side streets) and a much larger and more intricate trolley system.

I don't want to see a world that enhances and entrenches private vehicle movement; that's not necessary. The goal is to get from place to place. I want to step outside, walk a block, wait 3 minutes, and get on a bus or a marshrutka and be on my way without ever thinking about gas, traffic, insurance, or any of that.

All this "when self-driving cars..." is missing the point: we can move people conveniently and easily and more earth-friendly with what we've got, we just don't use it well because car companies want to sell everyone a private vehicle.

<comment><USER23> I don't disagree with you, but...

Follow the money. If there was sufficient profit in what you describe, it would be happening. Since it's clearly not then it has to be done by Government. That means actual people lobbying their local and state government for change.

And on top of that, it has to be marketed properly. Where I live there's essentially no taxi/Uber/Lyft service (see my comment above about waiting 4 hours for a taxi), but the County has an on-demand bus service that you can call and they'll pick you up at your home. However, since I've never had to take it, the few times I needed a taxi (e.g., to go pick up my car from the shop), I never even remembered that it exists!

</comment></comment><comment><USER43> I think Ford is correct here. Getting the problem 99% right means a lot of people get killed and injured.

By tackling small chunks such as geofencing, and things like autonomous busses on planned routes, the industry will move the ball forward in slow, steady steps.

But to me, the idea that a real self-driving car would be around the corner (i.e. 2020 or 2021) is just laughable. People underestimate the difficulty of that last 1%. My best guess is that the last 1% is greater than the first 99%.

Or, as Yogi Berra might say - the first 99% is the easy part; the second 99% is the hard part.

</comment><comment><USER44> I'll believe in self-driving cars once the robots start sorting my trash and recyclables for me... And once my Tesla stops driving like it's drunk!

</comment><comment><USER45> Driving on the road is about cooperating with the other people so that everyone benefits. Almost everyone underestimated the social aspect of it.

<comment><USER46> I doubt they underestimated the social aspect of it given I was at a talk about self driving cars about 10 years ago and one of the developers went into detail about how the hardest part they had to work on was the social aspect of driving.

I remember at the time being surprised to hear that as it's always something I'd taken for granted but it's something that I've consciously noticed ever since.

<comment><USER45> Thank you for pointing it out. I am sure there were always a few who did focus on the social aspect. I just feel that the direction in which the car industry and self-driving tech has grown obviously suggests that they underestimated it. Everyone would agree that if every car in the road is autonomous, it will be possible to nearly eliminate accidents and casualties and increase commuting efficiency. Unless there is a bug in the system or a rogue actor takes over that is- but that's a different type of risk. However, people are still buying cars with no self-driving capabilities and financing them for next 5-6 years or even longer. Let alone the infrastructure which is crumbling away instead of being readied for autonomous tech. That's why people like the Ford CEO are having to come out and recognize issues like this.

<comment><USER46> I wonder if we're using the same term to describe different things since I'm not talking about the social stigma of owning an autonomous car.

I'm talking about social in terms of reading the intentions of other drivers (eg joining a busy motorway or deciding who goes first on a spot island when all lanes have stopped and waited for the other) and other hazards (eg pedestrians crossing the road without looking properly because they're distracted with young kids, chatting to friends, or tapping on their phone)

As a driver you developer an intuition for how other drivers would react in different situations. Sometimes that's based on the speed of a vehicle, the angle of the car or driving style (eg are they bumper to bumper with the car in front?). Sometimes it's based on profiling/prejudice about people who drive certain brands of cars (eg BMW owners do tend to be pushier drivers than perhaps someone in a Fiat 500 - obviously this isn't always the case but you might still be more cautious if you see someone approach a busy junction in a powerful car).

Another thing experienced drivers might react to is if they see a series of brief break lights ahead at roughly the same point but cars aren't swerving around an obstruction then that might suggest there's a speed trap.

There's even been times when I've been on a motorway and a car has suddenly swerved in front of me however I was already hovering over the break just in case as I was expecting it through a series of subtle clues I picked up from their driving style. I knew that they were about to change lanes without checking their mirror even before they committed to the manoeuvre themselves.

There are so many hints and cues that drivers pick up on from other drivers. So much non-verbal communication. And that was the hardest part to train an AI. Sure you can teach them to react to hazards _as they happen_ but having them pre-empt hazards _before_ they happen without having that algorithm react to every false positive is a whole over level of engineering. It's something that takes humans literally years of driving every day to get good at and we already come pre-programmed with more sophisticated hazard detection before we even sit our bum behind that steering wheel than AIs have currently.

So this is the social aspect I was referring to. And I'm sure autonomous cars will learn this in time too - or at least get a close enough approximation where they're "good enough" for general purpose driving.

edit: I should have added that one good thing about AI is at least it's reaction times are lower. That reduces the significance of pre-emptively spotting likely hazards somewhat.

</comment></comment></comment></comment><comment><USER47> For self driving cars to actually work, you really need the road infrastructure to support them, and for a majority of cars to be self-driving so they can coordinate with other vehicles. A car run entirely by sensors without receiving outside information will always be doomed to fail.

</comment><comment><USER48> We know how an autonomous car will drive in a system made up of mostly human drivers. But what we do not know is what that system will look like when autonomous cars take over. That's a huge leap and I don't think we have yet to even address that question.

<comment><USER49> Most countries don't even fix pot holes in their capitals, I don't see them rebuilding their entire road infrastructure for autonomous cars.

<comment><USER50> The idea of self-driving cars being practical somewhere like Bangalore is laughable.

<comment><USER51> Traffic saturated cities like Bangalore and Beijing have the strongest reasons to make self driving vehicles work, however. It is laughable that Americans would be the ones to do this, given their relatively traffic light cities (even LA is nothing compared to BJ) and high rates of personal car ownership.

<comment><USER52> Don't the traffic saturated cities have a better incentive to make public transportation as good as possible? Less people on the roads seems like it would benefit everyone in that case, whereas most american cities are too sparse to support that kind of infrastructure

<comment><USER51> They do that as well. The problem persists inspite of Beijing's huge and growing subway system. Take myself as an example, I decided taking a taxi to work was worth it over a subway ride because of the crowded conditions...even though it lived and worked near stations on the same line.

American cities has plenty of space to build new roads, that isn't possible in many Chinese cities. Anyways, roads and private transportation will always be there, why not optimize it along with a decent public transit system to boot?

</comment></comment></comment></comment></comment></comment><comment><USER53> Yeah. Machine vision is hard. Really hard.

<comment><USER39> It's that, but it's also that "driving" is a problem with a really large surface area. There are so many edge cases that it's insane. And every single major metro area basically has subtly different rules and baseline assumptions about how people will drive.

</comment></comment><comment><USER54> Companies that do not figure out a long-term partnership model will definitely not find this sustainable. Spending billions of $$ without a clear revenue mechanism in short-term is definitely not sustainable, even though AV will be trillion $$ industry long term. And if you doubt my last statement about AV becoming a Trillion $$ opportunity, read this book on AVs by Spencer Burns (legit automobile guy) and you will see his reasoning.

</comment><comment><USER55> Highway driving is the first step. Limited challenges, different problem space. Once that's completely nailed down, we'll start to see workable urban solutions.

The reality is that human drivers will be better at interacting with other human drivers in close quarters for the time being.

</comment><comment><USER56> I think we all underestimate it. Driving a car in a road without assistance is solving the robot navigation problem forever. Its the answer to life, the universe and everything. There is still great progress and it will probably work in some limited sense.

</comment><comment><USER57> When you add up the amount of money that Americans spend on car payments, auto insurance, and gasoline every year, if that same amount of money were spent on public transit you'd have a really nice system which would also be self- driving from the rider's point of view.

</comment><comment><USER58> As a total layperson, I think the focus should be on long term car-to-car networking. Skip this visual feedback rut we are in and make every new car broadcast its position, velocity, acceleration, heading, etc.

Problem is how to get manufacturers on board en masse.

<comment><USER59> >Problem is how to get manufacturers on board en masse.

I think security is a much, much larger problem. Designing a safe, secure and reliable system for vehicles to communicate information with each other on an ad-hoc basis and designing a system to make use of that information in a way that doesn't allow bad actors to cause mayhem may be an equally hard problem to solve as the generalized computer vision that we need to make the current self-driving thrust work.

</comment></comment><comment><USER60> Having been working in "AI" field and delivered couple of projects. I think, Automation/AI always needs humans.

What we see from all these hyped tech, is just the MVP version. You discover the problems when it's in production.

</comment><comment><USER61> Is there a way to short the self-driving cars business? I have found the whole idea of self-driving cars ludicrous since the beginning and it boggles my mind why people with experience in computers do not feel the same.

</comment><comment><USER62> I don't see the point of every car manufacturer making their own self driving cars. They don't make their own air bags, ABS, transmissions, etc. Leave that to suppliers like Bosch instead.

</comment><comment><USER63> Overestimated? How come anybody that has any history with computers knows how difficult it is going to be but such a vast amount of people, including people with money are so bullish about them.

After doing some projects in kuala lumpour and singapore I knew that self driving cars were going to be incredibly difficult. one minute, driving along with no problems, next minute a huge amount of rain got dumped out of the sky, next minute the rain had stopped but some roads were impassable, some merely flooded but still open, others were undrivable on the sides but ok if you drove down the center.

How do you code for that?

<comment><USER29> The market for self-driving cars that run everywhere except in places with monsoons is still quite big.

<comment><USER63> Yeah true. Though probably each location will have it's own problems. Fallen branches, missing man hole covers, gangs of window washers.

</comment></comment></comment><comment><USER64> I really really like driving cars and I don't think self-driving cars is the future it could be a small part of the future though.

</comment><comment><USER65> Didn't they fire the last CEO for being too slow to adopt new technologies?

</comment><comment><USER66> It would be a lot simpler if they just skipped to self flying cars

</comment><comment><USER67> Just the dip in the gartner hype cycle...

</comment><comment><USER68> I don't actually believe this will prove to be correct, it just might take a decade longer and or be on more limited routes but it will happen.

<comment><USER69> Autonomous vehicles operating on limited routes (geofenced) at first is exactly what is described in the article, so it's not clear to me what you disagree with.

<comment><USER68> I suppose you could say that, but I'm saying it'll be late rather than not be possible. I suspect roads will start being built with automation in mind for example, and push bikes might be required to have a small transceiver to alert the cars AI to their whereabouts. I think Ford are saying here that it just won't be good ever, I'm saying it will be better, later and slower to be everywhere but will still exist.

<comment><USER69> Nowhere in the title or body of the article does it suggest it won't be possible. In fact it's simply saying it's harder than many people thought.

</comment></comment></comment></comment><comment><USER70> In one browser tab, everyone's clamouring for autonomous self-driving cars.

In another browser tab, a gamer is streaming himself driving in Euro Truck Simulator 2 for over four hours.

If only we had a way to connect people who would willingly do a job, with companies which would pay to have a job done, minus the cutthroat capitalist exploiters/employers.

</comment><comment><USER71> I'm totally getting one of those:

[https://www.amazon.com/Karl-Marx-Told-You-T- Shirt/dp/B075CTQ...](https://www.amazon.com/Karl-Marx-Told-You-T- Shirt/dp/B075CTQ3ML)

</comment><comment><USER72> How come all of us people that drive cars and are not in the car production business ,all knew the predictions Hackett and the rest made was loony?

</comment><comment><USER73> SDCs are a slipperly ope to AGI.

<comment><USER74> They're really not. Nothing on the horizon right now points to AGI.

<comment><USER75> Merely scaling up a GAN and optimizing it's network structure and training procedure allowed GANs to create nearly realistic high resolution faces. If you can generate realistic faces, then you can likely also generate realistic action and thought sequences simply with an even larger model.

An action/thought sequence is just a 4D tensor with some outputs controlling actuators. Thinking is just production of actions while actuator output neurons are inhibited, which can simply be implemented by a product with some sigmoid activated neurons.

Coherent combinations of such sequences can be produced by feeding both the current sensory inputs and the preceding internal state as conditioning vector to both the generator and discriminator.

You simply need to find a way to train the discriminator not only to tell real from fake, but to determine the value of the generator's outputs and make it backpropagate those values in time during training over several generated episodes by TD.

As the GAN is conditioned on its own previous state, it can learn by trial and error how to combine the short action and thought sequences it produces, can thus learn to produce coherent ("real") language and logic.

Based on such intuitions, I'd say it is impossible to tell when AGI will come exactly, but currently technology _looks damn promising_.

<comment><USER76> > If you can generate realistic faces, then you can likely also generate > realistic action and thought sequences simply with an even larger model.

I'd really be willing to take bets that, for the next thirty years (paid out at the end of that period), nothing remotely like AGI will happen. Should fund my retirement pretty nicely.

<comment><USER77> What's your standard for AGI? Passing the Turing test?

I would also be willing to bet a lot that will happen within 30 years.

<comment><USER76> AGI being at least on par with humans when it comes to creativity and invention? I.e. writing great novels, coming up with compelling philosophy, coming up with new, good mathematics etc.

</comment></comment></comment></comment></comment></comment><comment><USER78> Driving is fun. Being a passenger is not so much fun. Technical issues aside, for this simple reason I don't see self-driving cars becoming popular.

<comment><USER79> Driving is not fun. Being a passenger is much more fun. For this simple reason, I see self-driving cars becoming popular.

There are different opinions out there. I for one would rather learn and relax than drive.

</comment></comment><comment><USER80> Infrastructure, machine learning, sensors, and other components are there. We already got self driving cars.

Now human adoption and acceptance is the problem.

<comment><USER81> We have self driving cars, they just can't go where we want and need them to go, and won't change for decades.</comment></comment>


Soil gets its smell from bacteria trying to attract invertebrates - <AUTHOR> https://www.newscientist.com/article/2239854-soil-gets-its-smell-from-bacteria-trying-to-attract-invertebrates/ <comment><USER2> Wonder why the smell is considered pleasant to humans (especially freshly/lightly wet soil).

Similarly, what're the secrets to the amazing fresh spring/summer rain smell...

<comment><USER3> This is called Petrichor and the human nose is indeed hyper sensitive to it (5 parts per trillion).

[https://en.m.wikipedia.org/wiki/Petrichor](https://en.m.wikipedia.org/wiki/Petrichor)

<comment><USER4> Similarly and linked in the same article, the human nose is sensitive to ozone in as little as 0.1 ppm, and it seems an unlikely coincidence that it starts to become hazardous to respiratory tissue above this concentration.

<comment><USER5> That seems like a stretch to me. Sources of hazardous concentrations of ozone are generally technogenic in nature -- the concentrations produced by lightning in the troposphere are far too low to pose any real danger. As such, there's no reason that humans (or any organisms) would have evolved to specifically detect that.

<comment><USER4> Probably not directly, but the mechanisms we evolve are generalized to some degree, i.e they often end up being useful for things our ancestors never encountered.

Perhaps the method by which we smell give us a similar sense for some similarly hazardous molecules. According to the wiki O3 smells much like Chlorine, they are both highly oxidizing which is why they can be hazardous.

</comment></comment></comment></comment></comment><comment><USER6> So soil bacteria smell good to invertebrates for the same reason that fertile/virile humans smell good to their sexual complements: it helps to distribute their genes.

</comment><comment><USER7> I am a little confused, am I reading this correctly?

\- the smells are coming from streptomyces

\- springtails are attracted to the smells

\- springtails feed on the streptomyces

therefore the conclusion is not that bacteria are attracting invertebrates with the smell, but rather the invertebrates evolved to smell something they feed on?

Did I read this wrong?

<comment><USER8> It's hard to tell which is which and it's probably a bit of both. I don't really understand why whenever the living nature is being explained, it's done in a way that attributes to some design what really belongs to an accident of evolution. Species develop traits continuously and in a chaos, every individual is a mutant, then environmental pressure determines combinations that are most suited to reoccur (through reproduction).

In this case two species found each other. Maybe a few springtails had the genes to detect the smell. Of those, a few found it pleasant, it could be that others didn't. Maybe a few streptomyces had the genes to produce the smell. A happy accident that allowed both these genetic traits to endure environmental pressure.</comment></comment>


HTML5 Poses Threat to Flash and the App Store - <AUTHOR> http://blogs.wsj.com/tech-europe/2011/07/28/html5-poses-threat-to-flash-and-the-app-store/?mod=google_news_blog

<comment><USER2> Flash? Sure, HTML5 can replace many uses of Flash. But HTML5 is no competition for an app store. Apple's App Store has value in two ways: (1) for developers it's an easy way to pull money from consumers with a mere password entry (i.e. no email, address, CC number, etc. entry). (2) For consumers, it allows easy discoverability of nominally safe applications.

The technical side of having APIs to draw things on the screen are very minor hurdles compared to the social hurdles that the App store has overcome.

<comment><USER3> The translation for App Store appears to be 'native apps'.

</comment></comment><comment><USER4> Typical tech "journalism":

> The problem is HTML5 is not scheduled for official approval by the World > Wide Web Consortium (W3C) until 2014.

Does anybody care about this, anywhere? It's relevant inasmuch as not all features of the spec(s) have been implemented, but it's been well established that XHTML2 killed the waterfall model for web-dev. The whole reason HTML5 is thriving is due to ongoing incremental improvements, not a hardcoded release date.

> If you're not looking to monetize your app then, absolutely, you should go > for HTML5. If you're looking to monetize it. then native coding for the App > Store is still the way to go.

This completely ignores the fact that you can build native apps using HTML5, not to mention all the successful freemium/subscription based web apps (the model works far better for Basecamp than Angry Birds, but it's still working well for many).

<comment><USER5> > This completely ignores the fact that you can build native apps using HTML5

You can and you can't. You can wrap a web view inside an app, sure, but HTML5 apps _never_ look as good or work as well as native solutions- the UI doesn't match, any attempt at using a map view is a mess... the web browsers haven't received enough attention to make them look as good.

About the only OS in which this works well is WebOS, where, IIRC, you can write a native app using JS and HTML.

<comment><USER4> I think it depends heavily on the app type and the feature-set required. Certain apps can never be duplicated well or even at all; others (such as apps that wrap web content already, or form-centric business tools) would be near- indistinguishable to the casual users who are the target market for most apps. (Also keep in mind, the article was referring not to the quality of products, but of potential business models).

Moreover, cross-platform distribution is nothing to sneeze at. I'm reminded a little of Java programs back when Macs had under 5% market share, and far less native software. I might have been annoyed that these programs were slow and didn't honor Mac conventions, but when there weren't good alternatives, it still beat having nothing at all.

</comment></comment></comment><comment><USER6> I made the first real-time, online, turn-based games for the iPhone/iPod Touch before the App Store existed. They used Javascript and AJAX and worked well, but couldn't compete with Apps in the App Store when it was later released. HTML5 does not change that.

The App Store killed the Web App by offering native device functions to developers. These functions could theoretically be built-in to Safari with some custom Javascript hooks, but I don't see much motivation for Apple to do that. I imagine it's more likely for Android to do.

While were on the subject, native hooks through Javascript would be freaking awesome, and make mobile apps much easier for existing websites to create.

<comment><USER7> May not be exactly what you say you want, but it's gotta be pretty close:

<http://www.phonegap.com/>

</comment></comment><comment><USER8> Wasn't Angry Birds done in WebGL? That's not HTML5. Microsoft won't implement it in IE. And a desktop computer has quite a bit more power than an iPad.

</comment><comment><USER9> Please don't link to Murdoch's stuff. Thanks.

<comment><USER10> I don't think that the article really portrays an accurate view of the HTML5 vs. Flash vs. native apps clearly, but saying that a site's article should not be posted because a company owned by the same conglomerate as the site performed phone hacking is ridiculous.

<comment><USER9> Have you ever watched Faux Noos?</comment></comment></comment>


Plans for Nodecamp.eu 2012 - <AUTHOR> http://michaelbumann.com/post/14721766342/nodecamp-eu-2012

<comment><USER2> I would vote for Berlin, but that's Germany again, so what about London: <http://nodejs.meetup.com/> (most ppl in Europe with interest on meetup.com).</comment>


Fowler: EditingPublishingSeparation (2012) - <AUTHOR> https://www.martinfowler.com/bliki/EditingPublishingSeparation.html <comment><AUTHOR> The presentation linked from the article has some additional details on how to implement this pattern:

[https://www.martinfowler.com/articles/two-stack- cms/](https://www.martinfowler.com/articles/two-stack-cms/)</comment>


Go generics may use square brackets [] not parenthesis () - <AUTHOR> https://groups.google.com/forum/#!topic/golang-nuts/7t-Q2vt60J8 <comment><USER2> Why don't they just use characters from the Canadian Aboriginal Syllabics block?

[https://www.reddit.com/r/rust/comments/5penft/parallelizing_...](https://www.reddit.com/r/rust/comments/5penft/parallelizing_enjarify_in_go_and_rust/dcsgk7n/)

<comment><USER3> > type ImmutableTreeListᐸElementTᐳ

> _If you look closely, those aren 't angle brackets, they're characters from > the Canadian Aboriginal Syllabics block, which are allowed in Go > identifiers. From Go's perspective, that's just one long identifier._

And the next comment is the same thing everyone else is thinking: " _oh my god_ "

<comment><USER4> To be fair I suspect this part of that sentence explains the reason for choice of these special character:

 _From Go 's perspective, that's just one long identifier._

The designer was using those characters to trick the Go compiler which I then suspect means things like go format would also continue to work.

Then the designer could easily create a pre-processor that translates those placeholders characters as a way of providing some sort of generics in Go.

So in reality this was quite a good solution as I can imagine coming up with a solution that broke go format would have been a real pain to use.

<comment><USER5> > So in reality this was quite a good solution

Yes, I do not understand why people find this so hilarious. It's a clever choice.

<comment><USER6> Because they look like normal angle brackets. Unless you are in on the secret, you won't understand why your code doesn't work.

<comment><USER7> Easily fixed by using ᑅ ᑀ, ᕙ ᕗ, or ᗕ ᗒ.

<comment><USER2> For some values of "easily" and "fixed".

</comment></comment></comment></comment></comment></comment></comment><comment><USER8> >A typical computer keyboard provides four easily accessible pairs of single- character symmetrical "brackets"

"falsehoods programmers believe about keyboards"

On the keyboard layouts of many countries these keys aren't accessible at all, either missing entirely or only being accessible via unergonomic key combinations.

For this reason myself (and many other programmers) own additional ANSI-US layout keyboards.

<comment><USER9> QWERTZ here. I need to use the following key combinations:

shift + 8 -> (

shift + 9 -> )

alt + ctrl + 8 -> [

alt + ctrl + 9 -> ]

alt + ctrl + 7 -> {

alt + ctrl + 0 -> }

Alternatively alt + ctrl can be replaced by altgr.

And for further fun:

alt + ctrl + ß -> \

shift + 0 -> =

shift + 7 -> /

Actually, it is probably easier to link the whole layout: [https://de.wikipedia.org/wiki/DIN_2137#/media/Datei:Deutsche...](https://de.wikipedia.org/wiki/DIN_2137#/media/Datei:Deutsche_Tastaturbelegung_T1_nach_DIN_2137-01 --2018-12.png)

It is pretty bad for programming in languages that make heavy usage of braces/brackets/parenthesis.

<comment><USER10> at that point, you might as well buy a QWERTY keyboard

<comment><USER11> Everyone in our field should do themselves a favor and learn to touch-type regardless of the physical keyboard.

<comment><USER9> I tried to learn the qwerty layout before, but my muscle memory is so ingrained that it was impossible for me at the time.

And without correct keycaps it is even harder.

<comment><USER11> Not being able to look at the keyboard is actually a good way to learn.

Of course you'll have to fight your muscle memory and type at 20 wpm for a couple weeks. There's no shortcut.

<comment><USER9> My problem is that I need to be able to check where the keys are to be able to learn it in the first place. I can touch type quite well, just not type at all in a layout I never used before, without being able to look at the keys.

<comment><USER11> Print out the layout and put it under your monitor while you learn.

<comment><USER9> That is such a good idea that I missed it for being so simple.

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER12> I really like the syntax used to declare generic type parameters to functions in ML-type languages like F#.

Writing the below in other languages (pseudocode) feels repetitive in the same way that `Thing thing = new Thing()` did back before `var` or `auto` types became popular:

        list<Y> Map<X, Y>(list<X> inputs, X->Y mapping)

Why do I need to put <X, Y> in brackets after Map? To tell the compiler that these are generics, not attempts to reference actual specific types that just happen to have crappy, nondescript names like X and Y.

In F# and friends, there is no need to put a bracketed block declaring which types are generic parameters. I would simply write:

        let map (inputs: list<'x>) (mapping: 'x -> 'y) : list<'y> = ...

The little apostrophe or tick mark before the type name tells the compiler it's a generic type parameter. It's not legal to name a concrete type with a leading tick mark, so there can be no mix-up. At first it looks ugly, but once you are used to it, it is natural and less cluttered than having to have these separate bracketed declarations for "uh-oh, here comes a generic".

But I suspect Go will always want more explicit syntax for generics. In part out of backwards compatibility, but largely because Go's designers see generics as an advanced, occasionally useful feature. Correspondingly they'll want the presence of a generic function to have ugly syntactical warning signs: here be dragons.

Functional languages usually take the opposite approach and see a fully generic function as _less_ complex than one for a specific type, because just by looking at its signature, you know it doesn't require anything special about the input objects it's going to work on. It is not going to be calling methods on them or messing with their guts. It's just treating them as black- box, could-be-anything cards to be shuffled around from point A to point B.

<comment><USER13> > Why do I need to put <X, Y> in brackets after Map? [...] In F# and friends, > there is no need

Try:

      let foo (arg: list<'x>) : list<'x> =
        ...
        <inside foo somewhere>
        let bar (arg: list<'x>) : list<'x> = ...
        ...

Is bar generic over a fresh type that happens to be named 'x, or is it a monomorphicly-typed local function that uses the type 'x that foo is generic over?

<comment><USER14> not sure about F#, but in haskell it's the former, and you can switch to the latter with the -XScopedTypeVariables language extension. though IME you rarely (if ever) need it thanks to type inference.

<comment><USER13> Actually, on further consideration, you could restrict the ' to only occur where the type parameter is _introduced_ , like so:

      List<X> foo(List<'X> inp) =
        ...
        List<X> bar(List<'X> xs) = ... # new X scoped to this declaration
        List<X> baz(List<X> xs) = ... # use foo's X
        ...

</comment></comment></comment></comment><comment><USER15> To me, Go feels condescending to write without generics. I may just not groke the idioms - but putting users in a walled garden that the standard library has the privileged to escape from (i.e. (Map<k, v>)) just seems to go too far in not trusting the programmer. The fact that generics have taken so many years - to still be talking about what [<( to use is beyond me.

There is a difference between becoming C++ and allowing programmers to make fundamental abstractions without interface{} hacks.

<comment><USER16> The problem is not so much the absence of generics but the availability of crazy reflection at runtime compared to the rigid type system at compile time. There absolutely is a lack of balance here.

All these things were already pointed out 10 years ago and were met by "you don't need that with Go", "Go back writing Java" sort of contempt, which gave the Go community a bad reputation.

Go could have been fixed 10 years ago if Rob Pike and co listened. They didn't want to because they thought they knew better than everybody else. ADA already fixed the genericity problem while keeping things readable with a limited form of generics as incomplete types.

<comment><USER17> As I already mentioned a coupled of times, even CLU like generics would have been a good enough solution.

Something that they acknowledged not bothered to look at initially.

[https://go.googlesource.com/proposal/+/master/design/go2draf...](https://go.googlesource.com/proposal/+/master/design/go2draft- generics-overview.md)

> We would have been well-served to spend more time with CLU and C++ concepts > earlier.

</comment></comment></comment><comment><USER18> > A typical computer keyboard

A typical NORTH AMERICAN computer keyboard.

Does the myopia of the Go compiler team know any bounds?

<comment><USER19> You mean a typical English keyboard?

Ironic that you are criticising them for only thinking of the US, but you've done exactly the same thing.

<comment><USER20> The ISO UK keyboard layout exists. The North American keyboard layout is North American, not "English".

<comment><USER21> This is true, but an ISO UK keyboard _also_ "provides four easily accessible pairs of single-character symmetrical 'brackets'"; for this particular purpose there is no distinguishing factor between the two layouts.

</comment></comment></comment></comment><comment><USER22> I wish they would just freeze the language and not add anything. I like it the way it is. I feel like the general attitude of software developers is: if it isn't changing and being updated it's dying. I think we should start putting weight on stable unchanging software.

<comment><USER23> Meanwhile I will never use Go until it has generics.

I wonder if there is more of people like me or people like you...

<comment><USER24> Based on the popularity of the language alone, I can say rather definitely the latter.

<comment><USER25> I'm sure that being backed by the largest software/advertising company in the world has nothing to do with its adoption rate, and that popularity is a direct mapping of quality of a programming language.

<comment><USER26> The Google backing and hype kept me away from Go for years. After being stuck with a succession of scripting languages that weren't doing it for me and being frustrated at the time it takes to be as productive in something like c, Go is really the sweet spot of readability, reliability and productivity for me. I think the Google backing may not be as advantageous as some people think. Dart did not become a popular language and would probably have died out if Flutter hadn't come along.

<comment><USER27> Yeah, Go being from Google is not necessarily a good thing. It means the language is under the control of a single company and, what's more, a company that is well-known for giving up on many of its projects.

<comment><USER28> And the open-source aspect of Go's development is managed entirely in Google services (the dev mailing list is a Google Group, you can't contribute without a Gmail address...the list is long). Sure it's hosted on GitHub, but the majority of the real conversations are elsewhere.

</comment></comment></comment></comment></comment></comment></comment><comment><USER26> I really like the Go standard libraries. I can do most of what I need with them. I worry some of the people calling for generics will move the language in the direction of massive abstract libraries. I don't want to include a Go version of Boost in everything I build. Complicated type signatures seem like an unnecessary additional burden for average programmers.

I really hope generics, like reflection, are only used when there isn't a simpler option. I honestly would have preferred and had more use for sum types.

I like the square brackets though. They look right for Go and it is more readable.

<comment><USER29> I haven't used Go but I'm curious, how do core data structures like hash maps work without generics? Does everyone just roll their own for their particular use-case?

<comment><USER30> The built-in types map, chan, array, and slice take type parameters, and they are usually sufficient for doing whatever you need to do.

It's incredibly great that, generally speaking, if I'm looking at Go code, the only kind of hashtable there can possibly be is the Go map data structure. The only kind of blocking queue there can possibly be is the Go chan data structure.

You will never see a LinkedTreeDeque or whatever other bizarre concoction someone might come up with. And people don't feel obligated to make every API an iterator of some kind.

Go makes being generics architecture astronautics impossible, and I really love that about it. Perhaps that makes me basic, but I am basic and happy.

<comment><USER16> > The built-in types map, chan, array, and slice take type parameters, and > they are usually sufficient for doing whatever you need to do.

They are so sufficient you need to learn all these tricks by heart in order to do basic operations on slices:

[https://github.com/golang/go/wiki/SliceTricks](https://github.com/golang/go/wiki/SliceTricks)

</comment></comment></comment></comment><comment><USER31> Honest question; why use a comparatively exotic syntax for generics? Most other similar languages — Java, C# — and perhaps most notably C++ since its the closest analogue in terms of paradigm and domain, all use angle brackets (without getting into the semantic differences between "classic" generics and the STL).

AFAIK, Golang assigns no special syntactic meaning to angle brackets beyond comparison operators (correct me if I'm wrong though, I don't write much Go), and using a familiar syntax would make it easier to work with coming from other languages.

<comment><USER32> From the post:

> Angle brackets require unbounded parser look-ahead or type information in > certain situations

So they want to avoid angle brackets so they can efficiently parse source code.

<comment><USER31> Thanks! I'll have to look into this some more but if anyone can volunteer the information, these questions come to mind:

\- What situations could cause the look-ahead to be unbounded?

\- How does the Go parser's implementation differ from those of the languages I'd previously listed which all also have angle brackets for comparison ( _and_ bit shifts, as another commenter pointed out) while apparently avoiding unbounded look-ahead?

\- What challenges does the Go parser present when trying to adapt it to follow patterns more like those from the other languages' parsers?

\- I'm assuming "unbounded" here doesn't mean "it could take unlimited time" but rather "it could incur non-negligible compile-time penalties;" do the benefits of a slightly-quicker compilation (which has nominally no impact on runtime performance) outweigh improved readability?

<comment><USER33> Unlimited lookahead parsers are not necessarily inefficient in terms of time. PEGs for instance run in linear time, but use up linear memory, which is the problem: [https://en.wikipedia.org/wiki/Parsing_expression_grammar](https://en.wikipedia.org/wiki/Parsing_expression_grammar)

> \- How does the Go parser's implementation differ from those of the > languages I'd previously listed which all also have angle brackets for > comparison (and bit shifts, as another commenter pointed out) while > apparently avoiding unbounded look-ahead?

I think parsing Java or C++ requires unlimited lookahead.

<comment><USER30> [https://blog.reverberate.org/2013/08/parsing-c-is- literally-...](https://blog.reverberate.org/2013/08/parsing-c-is-literally- undecidable.html)

</comment></comment></comment></comment></comment><comment><USER34> > Angle brackets require unbounded parser look-ahead or type information in > certain situations

So.... they'd rather pull the "it's hard to do" or the NIH card, than make it easier for developers switching between languages? Interesting choice. Someone mentioned "condescending" \-- that description fits perfectly.

And there I was thinking that COMPILER WRITING should be hard - as hard as possible - in order to make the code which is to be compiled as easy to write as possible.

<comment><USER35> I think they actually make a fair point because in this case "hard to do" probably equates to "makes the compiler a lot slower".

Go is very easy to switch to from most other languages so I don't think making it harder to switch is a design goal from the team.

When Go came on the scene, I actually really appreciated the fact that they truly explored what a new language could do differently, especially because it was coupled with a strong philosophy.

Now, since 1.0 there have been plenty of decisions made which I dislike. Still, I think the glasses through which you choose look at the Go teams motive aren't fair. Why _wouldn 't_ designers of a programming language like Go think it through very carefully, weigh every angle and decide to settle on a lesser used but possible equally valid solution compared to 80% of the languages out there?

<comment><USER36> > I think they actually make a fair point because in this case "hard to do" > probably equates to "makes the compiler a lot slower".

They are wrong in this case.

When considering whether to allow `foo<T>();` in Rust, we measured the performance impact that infinite look-ahead / backtracking would have in that case. The result was negligible.

Why? Because the amount you have to look-ahead, before you can say "definitely wrong; let's turn back", in realistic code is bounded to maybe max 30 for some very complex generics. It's however much more likely that no back-tracking occurs at all because the parse will be correct.

When engineering your compiler, you can always make choices about which path is statistically more likely, as back-tracking in a well designed language is usually pathological. The theoretical O(..) complexity is largely irrelevant.

(Source: I was the main maintainer of rustc's parser and refactored large parts of it.)

</comment></comment></comment><comment><USER37> If the type keyword needs to be added anyways, why not angle brackets then? Is it still ambiguous?

<comment><USER38> The way I read it, the type keyword would only be used in when declaring generic functions/types, but the angle brackets syntax has clashes when calling generic functions.

</comment></comment><comment><USER39> Just use guillamets already.

<comment><USER40> Link for those who are curious: [https://en.wikipedia.org/wiki/Guillemet](https://en.wikipedia.org/wiki/Guillemet)

<comment><USER41> ‹‹››

</comment></comment></comment><comment><USER42> I know it's unpopular but judicious use of significant white space would solve the ambiguity too.

</comment><comment><USER43> Perl allows optional delims if ambigious. so if the best set <> is ambigious double or triple them. But much easier would be to demand uppercase T type variables.

       a, b = w < x, y > (z)

w is lowercase, unambigious. Parsed as list of comparisons.

      a, b = T < x, y > (z)

Ambigious, so use

      a, b = T <<< x, y >>> (z)

instead. These cases are very rare. Or demand parens for such ambigious lists of comparisons. Might be too late already.

Of just demand the type keyword there also:

      a, b = w < type x, y > (z)

</comment><comment><USER17> If they finally end up adding any kind of generics support, it feels much more natural, from my experience with languages that use [] and () for type parameters, [] are much better visually.

</comment><comment><USER44> This is a good move, which will make Go more consistent. Making custom generic and builtin generic consistent absolutely makes Go more easy to learn and read.

</comment><comment><USER45> I liked the alternative proposed later in the thread:

        gen T   type pair struct { a, b T } // contrast with type pair(type T) ...
        gen T,U type W struct { a T; b U } // contrast with type W(type T, U) ...
        gen T   func Print(s []T) {...}  // print a slice of T

or using `forall`

        forall T, type pair struct { a, b T }

V readable IMO

</comment><comment><USER23> > Angle brackets require unbounded parser look-ahead or type information in > certain situations

I wonder how this is solved in Java, and C++, and C#, and...

<comment><USER46> It is solved by doing unbounded parser look-ahead (if you need that) or by requiring that all tools have full type information to understand programs (if you need that).

It is definitely better for tooling not to need either, both for human readers and mechanical tools

The example in the mail shows that using angle brackets with Go would require full type information, making simple tools like gofmt impossible.

<comment><USER23> > making simple tools like gofmt impossible.

So now we're making language design decisions based on the limitations of the bonus linter?

My opinion of Golang drops more and more with every new detail I learn about it...

<comment><USER47> One of the benefits of Go is super fast compilation time. Unlimited look ahead is likely to make the compiler slower. Ergo, it's not a great idea.

<comment><USER48> Parser speed is negligible contributor to slowness in any compiler. rustc has a couple of places were it performs bounded lookahead to supply suggestions for incorrect code, but the grammar of the language is regular. 3rd party tools don't have to worry about it, and users get accurate suggestions. The cost is 1) you have to implement a more complex parser while 2) making people go "you already know what I meant, just take it without me using the 'ugly' turbofish". It think this is the correct approach for language design.

</comment></comment></comment></comment></comment><comment><USER49> I did not see digraphs mentioned. Could look like <: and :>.

The formatting tool could even normalize that to some prettier unicode.

</comment><comment><USER50> Are they adding Java style generics (type erasure), or C++ style (compile time specialization)?

<comment><USER51> The go2 proposal (as currently implemented) is a source-to-source translator back to go1, so neither in that case.

As for the existing implementation of generic map[K]V, generic []T, chan(T), etc., it's a best-of-both-worlds mix - a kind of erasure (there is only one map implementation in a Go binary) but with a static vtable for accessors without Java's need for boxing - all possible owing to the clever coupling between the runtime and the compiler.

See [https://dave.cheney.net/2018/05/29/how-the-go-runtime- implem...](https://dave.cheney.net/2018/05/29/how-the-go-runtime-implements- maps-efficiently-without-generics)

</comment></comment><comment><USER52> Honestly, I prefer the parenthesis notation to the square or angled brackets. It is perhaps a bit verbose, but easy to read in my eyes. Not to mention the keyboard problems with non-English keyboard layouts.

</comment><comment><USER53> Doesn't [ ] have similar problems? Suppose I write:

a[x](z)

Is that a read of array a with index x followed by a function invocation with the parameter z.

Where it could also be a type conversion of z into generic type a of x.

<comment><USER54> The issue isn't the interpretation; it's the parsing. It doesn't matter to the parser in this case if x is a type or an int. You'll have the same AST either way. But if you have f<a,b>(x), it matters if this is a generic or a pair of comparisons because the AST would be totally different.

</comment></comment><comment><USER55> Funny how we add 100 new emoji per year, and yet we can't seem to be able to add a new matching pair of characters in our keyboards for 5+ decades...

<comment><USER56> How many of those emoji are on your keyboard?

<comment><USER55> On my iOS virtual keyboard that would be all of them. Heck, the Mac laptop's touch strip also features a selection.

But that wasn't my point. It was that we get a ton of BS cosmetic/fun items on the Unicode standards, and we can't get a few simple glyph additions on our hardware keyboards that would seriously help programmers for decades to come...

</comment></comment></comment><comment><USER57> seems like you could just not use ',' as the separator character in type declarations. +-*^% I think have the same problems, but @#$ are available. weird syntax, but go already makes the tradeoff, do what's fast to parse.

</comment><comment><USER58> You have emoji on your keyboard?

</comment><comment><USER19> This is much more readable IMO.

</comment><comment><USER59> Whatever!! Go finally brought generics. The same thing which it used to criticize java for Lol

</comment><comment><USER60> can someone just stick this thread forever on top of HN listing

</comment><comment><USER61> If go gets generics I will never use it again.

<comment><USER62> Why?

<comment><USER63> I wondered this too. It's not like there's a part of a language you MUST use. Perhaps they are fearful that it'll grow and grow and add features in that will make it difficult to learn and unwieldy. Stroustrup always said that new languages seem fast and easy to learn precisely because they are new languages and don't have the features of maturity. Perhaps this is the case here.

<comment><USER17> He is quite right, yes C++ is a monster dragon, but most languages of similar age only look simple on the surface, even a beginners friendly language like Python.

Beneath that simple surface for beginners lies a multi-paradigm language, with overloading, metaclasses, dynamic code generation, multiple inheritance, breaking changes across minor versions in 30 years of history, a standard library that can be used as doorstep when printed, several implementations not 100% semantic compatible with CPython,.....

<comment><USER63> Yes, it's good isn't it!</comment></comment></comment></comment></comment>


2018 and CD burning still painful - <AUTHOR> https://www.preining.info/blog/2018/01/2018-and-cd-burning-still-painful/ <comment><USER2> 2018 and still burning audio CDs? Not that one shouldn't, but ...</comment>


Announcing React/NodeGUI – Build Native Desktop Apps with JavaScript and CSS - <AUTHOR> https://blog.atulr.com/nodegui-intro/ <comment><USER2> TIL:

> NodeGUI is powered by Qt5 green_heart which makes it CPU and memory > efficient as compared to other chromium based solutions like electron.

I can't tell you how happy this makes me

<comment><AUTHOR> Haha happy to hear :)

</comment></comment><comment><USER3> > Note: Since we do not in any way modify the code of Qt and only link to it > dynamically, I beleive we are in compliance with the LGPL license > requirements of QT. And hence this library can be licensed under its own > License (for which we have chosen MIT License). The links to QT source code > and appropriate license notices are attached. We try our best to abide by > the software licenses and any non compliance is not by will. If there is > some discrepancy please let us know in the issues and we will try and fix it > up. If you follow the recommended build steps and do not statically link QT > libraries on your own you are safe to use this library for commerical > puropses (provided you abide by MIT License).

Anyone familiar with licensing, is the author's note here correct, and can we use NodeGUI just like any other MIT libraries, eg. bundling the GUI part for distribution?

<comment><USER4> Yes with some exceptions:

1\. To use it in a closed-sourced application you have to keep the Qt libraries dynamically linked and bundled with the application. The license is fine as long as it is dynamically linked.

Example: [https://github.com/gitahead/gitahead](https://github.com/gitahead/gitahead) Used to be closed-source and uses Qt5. Now it is open-source and is under the MIT license.

2\. Static linking however requires you to either purchase a commercial license or you release your source under GPL-3.0 and then you can statically link your app.

No. 1 is probably what you are after.

</comment></comment><comment><USER5> [https://doc.qt.io/qt-5/topics-web- content.html](https://doc.qt.io/qt-5/topics-web-content.html) why not directly use Qt5 and its js/css functionalities, is this basically wrapping Qt5 c++ API via nodejs N-API so we can develop in typescript instead of c++?

I wish there is a light-weight html-css-engine written in C/c++ that we can all use cross-platform for desktop GUIs, chromium is really for browsers, which is too heavy for many GUIs on desktop

</comment><comment><USER4> Finally, this alternative addresses the eternal problems that has plagued electron with criticism for years.

Cross-Platform, Native, Consistent and efficient in both CPU time and memory consumption whilst applying the React styling into Desktop apps. Not spawning a instance of a full web browser.

To compete with Electron, some sort of migration path is needed here.

<comment><AUTHOR> Yeah, I see it as similar to how we transitioned from

Cordova ---> React Native for mobile app dev

Electron ---> NodeGUI for Desktop apps</comment></comment>


Balancing Multiplayer Competitive Games (2009) [pdf] - <AUTHOR> https://static1.squarespace.com/static/50f14d35e4b0d70ab5fc4f24/t/53ef1dbae4b0a6d424125a6f/1408179642248/GDC+2009+sirlin+handout6.pdf

<comment><USER2> Good article.

 _Definition: What is Depth? A multiplayer game is deep if it is still strategically interesting to play after expert players have studied and practiced it for years, decades, or centuries._

We often talk about _skillcaps_. The more _skillcaps_ a game has the better it is. Ideally, you want a game to have an infinite number of skillcaps. A skillcap is a level of expertise which allows the players in it to dramatically beat the players which belong to the lower level of expertise. The idea behind skillcaps is that, if you, as a player, are in a lower skillcap, it means you're not entirely exploiting all the possibilities of the game. Many skillcaps means that increasing things like reflex is not enough. The player needs to increase its _understanding of the game_. Incidentally, that game is very deep.

Also, there is a measure for player expertise called the Elo rating system: [http://en.wikipedia.org/wiki/Elo_rating_system](http://en.wikipedia.org/wiki/Elo_rating_system)

 _Definition: What Is Balance? A multiplayer game is balanced if a reasonably large number of options available to the player are viable--especially, but not limited to, during highlevel play by expert players_

Well, not really in my opinion. A game is balanced if you cannot find a single way-of-playing to beat an equally-expert opponent more than 50% of the time when the opponent is not allowed to use that same way-of-playing. (Note we are talking here about robots which automatically play each game with the exact same level of expertise.)

EDIT: oh the author calls that _fairness_. Fair enough then.

<comment><USER3> >A skillcap is a level of expertise which allows the players in it to dramatically beat the players which belong to the lower level of expertise.

Where are you getting that definition? I've always seen "skill cap" defined as the highest possible level of skill, beyond which no increased skill can increase performance. "Skill cap" is also not a measure of players, but of game mechanics and games themselves. We might say that checkers has a lower skill cap than chess, or that the bishop has a lower skill cap than the queen, but we wouldn't say that Magnus Carlsen is at a higher skill cap than I am. He's just more skilled.

We want unreachable skill caps, so that there's always room for improvement. I'm not sure any game has an infinitely high skill cap.

<comment><USER4> I think it's by analogy to the chess piece version you mentioned. A _strategy_ has a skill cap. Therefore, a player who only knows some subset of strategies, where the max skill cap within that set is X, will always eventually be beaten by some other player who knows a strategy outside that set, with a higher skill cap. That player can be said to "have" the skill cap of the highest- skill-cap strategy they're currently aware of.

To put it another way: a "perfect" player with mastery of every strategy they are aware of, but with imperfect knowledge of the space of possible strategies, will have a skill level at the game equal to the highest-skill-cap strategy they're aware of.

Or, if you only practice the strategies you already have, you'll only ever get as good at the game as your best strategy is powerful. It can be _much_ higher-ROI to explore the game's strategy-space to find higher-skill-cap strategies.

Imagine a game where a player who has 80% mastery of a large number of strategies, beats a player with 90% mastery of fewer strategies. The 80% player probably won because one of the strategies they were competent at had a high-enough skill-cap to dominate the other player who didn't know that strategy.

</comment></comment></comment><comment><USER5> Another great talk on the same issue:

Design in Detail: Changing the Time Between Shots for the Sniper Rifle from 0.5 to 0.7 Seconds for Halo 3

PDF: [http://twvideo01.ubm- us.net/o1/vault/gdc10/slides/Griesemer_...](http://twvideo01.ubm- us.net/o1/vault/gdc10/slides/Griesemer_Jaime_DesignInDetail_Sniper_Halo3.pdf)

Talk & SlideDeck: [http://www.gdcvault.com/play/1012211/Design-in-Detail- Changi...](http://www.gdcvault.com/play/1012211/Design-in-Detail-Changing-the)

</comment><comment><USER6> I've casually worked on MUDs for a while and whenever I help a friend, the first thing I do is put their game in a spreadsheet. It usually reveals several things they didn't realize about their game.

They tend to tweak their games over and over based upon feedback until they eventually don't know what their own game is doing.

<comment><USER7> I've toyed with MUDs a bit as well. I'm actually thinking about doing it again because I want to play around with a component-entity-system idea I had. Anyway, I've always figured that keeping everything as a zero-sum-rule is the only way to really balance things. A spreadsheet makes this much more visible (because you can list all your assumptions (weights etc) in a sheet and calculate if everything balances or not. Then if you learn the assumptions are wrong, modify them and rebalance). So yeah, definitely good advice!

</comment></comment><comment><USER8> Thank you for this.

I need help balancing my RTS for this weeks indiecade submission if anyone is interested in helping ?

</comment><comment><USER9> One method that has proven to work good is to keep statistics and then nerf overused tactics and bump the ones that are rarely used. It will make some interesting game play!

Also try to have as much diversity as possible. This is one of my favorite quotes: "This game is so imbalanced so that it get balanced".

<comment><USER10> Chess 1.1 changelog

      * nerfed movement for white pieces to balance out first-move advantage
      * added "undo" and "knight blast radius damage" DLC

<comment><USER11> The author of the article actually has come up with "Chess 2". [http://www.sirlingames.com/products/chess-2-print-and- play](http://www.sirlingames.com/products/chess-2-print-and-play)

</comment></comment></comment><comment><USER12> _Definition: What Is Balance? A multiplayer game is balanced if a reasonably large number of options available to the player are viable--especially, but not limited to, during high-level play by expert players._

Interesting. I think of 'balance' in multiplayer games as a different thing altogether. I am usually thinking of the match itself, rather than the design of the game. In that sense, a game is "balanced" if the overall skill level on each side is reasonably close to the overall skill level on the opposing side. Games where one team is just too much better than the other are boring. "Balanced" games -- where you really don't know who will win until the game is over -- are usually the most fun.

<comment><USER13> I think you're confusing "game" and "match", where "game" means the rules defining how players interact, and "match" means one instance of a game being played by a specific group of players.

"game" and "match" can sometimes be used interchangeably (e.g. "that was a good game" can mean a single match), but a discussion on "game balance" typically refers to the rules themselves being fair.

What you described, grouping players into opposing teams of roughly equal skill, is called matchmaking, and it's a different problem from game balance. In fact, in a competitive match where game balance is arguably the most important, matchmaking is not a big problem since it's solved by a bracket of some sort.

<comment><USER12> I think you didn't read my post very carefully.

I'm not confusing those terms at all. I said:

"I am usually thinking of the match itself, rather than the design of the game".

By which I mean pretty much exactly what you said. "Game" can mean either a single match, or the actual thing that you are playing.

My point was that the term "balance" isn't limited to the dynamics of the game (those that exist regardless of the players skills in using them), but that it is often used to refer to the equality of the teams -- and that when I hear the term "balance" in regard to gaming I am more likely to think of the team equality than the other possibility.

<comment><USER4> Where do you go, that you hear so many complaints about unbalanced matchmaking?

Tournaments and ladder systems almost automatically cause match "balance" in the way you're speaking of. Some games go further and introduce handicaps, so weaker players can play stronger players with the result not being predictable. In either case, nobody is really thinking about balance; it's just built into the social systems _around_ the game.

The only time one might hear complaints about match "balance" is in non- competitive "casual" play. (This is actually a large part of what Nintendo's game design is about. The Smash Bros, Mario Kart, Mario Party, etc. series are all about letting people with unbalanced skill—family members, say—play casually against one-another while still having fun.)

</comment></comment></comment></comment><comment><USER14> My opinions:

I think attempting to balance games where the number of character/choices are large enough is a futile process (especially if the design process aims at the "cream of the rop" players). The truth is that at the end of the day, competitions are still going to be populated with players would use the top ~20% something (depending on the game) of the character cast, with a very small minority actually bothering with the other characters due to the playing-to-win mentality. I see this pattern being very common with a lot of games, and attempts at balancing them only _shuffle_ the casts around i.e. a new set of characters now dominate, replacing the old ones. Part of the reason is because the characters/game mechanics are so intricately tied to one another, a small change could flip the entire "metagame" around.

This symptom is more apparent with MOBA games such as Dota 2. After each balance patch, the game becomes chaotic enough to raise interests among players, although the metagame will eventually converge to a singular point. Players will then complain and the process continues. Each patch hardly makes the game more balanced, they just make the game different. I think at stages like this, you simply have to adopt a new definition of "balance".

Also I disagree with "Design Self-balancing Forces". While the mechanics proposed are good at creating depth for the game, I think it's misguided to add them with balance in mind. An example is the game Street Fighter 3 (specifically the third edition, Third Strike): the designer added a "parry" mechanic in which allows a player (with a good guess, timing and some memorization) to counter any attack. This could be perceived as an attempt to give any character a chance, but in practice players argue that this makes the strongest characters even stronger (of course it's hard to verify this because an identically copied game with no "parry" doesn't exist) because they can counter attack for much higher damage.

Also, Sirlin (the author) spends a lot of his time with versus fighting games, and the article reflects that. I think if you're looking to balance a game of another genre, it's unlikely that his philosophies will be very useful. Just for reference, versus fighting games usually have these metrics: character pool is between 10-30 (usually don't go up much), there's a heavy emphasis on specialising on one character (could go up to 3), heavy emphasis on reaction and guessing, long intervals between balance patches (if there are going to be patches at all), at competitions there rarely are rules (i.e. usually no banning, save for a few games where balance is pretty bad). If you compare this to other genres (FPS, RTS, MOBA, ...) these metrics will be very, very different.</comment>


Tab: Startup To Shutdown - <AUTHOR> https://medium.com/on-startups/b0722086c0f7

<comment><USER2> As a customer of the Campus location I love the simplicity of paying with Tab. From my perspective this plus the 10% bonus when topping up over £10 is nearly there... if only these guys could've survived long enough to make this viable. I'm sure someone else will.

</comment><comment><USER3> This is really a shame, as I loved the Tab product. To take my money, the staff in the Campus cafe _had_ to know my name, which got us engaged in conversation. I guess this is one of the qualitative benefits to which the post refers.

I would love to see something like Tab work across multiple shops. In my home town, it would be great to have something like a Tab account which works in the butchers, the bakers, the grocers, etc.

Anyway, thanks to the Tab team and good luck with whatever you do in the future. Thanks for the post.</comment>