India will ban driverless cars in order to protect jobs - <AUTHOR> https://www.engadget.com/2017/07/24/india-ban-driverless-cars-protect-jobs/ <comment><USER2> Reminds me of this story

> The story goes that Milton Friedman was once taken to see a massive > government project somewhere in Asia. Thousands of workers using shovels > were building a canal. Friedman was puzzled. Why weren't there any > excavators or any mechanized earth-moving equipment? A government official > explained that using shovels created more jobs. Friedman's response: "Then > why not use spoons instead of shovels?"

[http://online.wsj.com/article/SB1000142405270230407010457639...](http://online.wsj.com/article/SB10001424052702304070104576399704275939640.html?mod=WSJ_Opinion_LEADTop)

The attribution for the quote is a bit disputed though : [http://quoteinvestigator.com/2011/10/10/spoons- shovels/](http://quoteinvestigator.com/2011/10/10/spoons-shovels/)

<comment><USER3> The brilliance of the Friedman anecdote is that it reveals something Higher- Life-Form types like Nitin Gadkari, who propose to save you with the wonderful power of regulation, miss. What they miss is that in their world there's _no_ logically sound riposte to Friedman's question. It _should_ be spoons. Teaspoons, even. Creates more jobs.

But actually what works is, perhaps, shovels. And then, if you can afford it, earth-moving equipment.

Who says shovels are best?

Prices say shovels are best. And then, later, prices say earth-moving equipment is best. You don't have to be a Randian absolutist to conclude that governments inevitably distort outcomes and impoverish people, even at the margin, when they control prices.

I think what is implicit in a move like Gadkari's is a belief that the idea of a "market-clearing price" is an economic textbook proposal that one is free to adopt or not adopt. In fact these concepts are not theories but reality- reflecting lenses. Prices are actual facts. The ban on driverless cars will create grey markets, criminals, cartelize commercial driving, artificially enhance transport costs, and, perhaps most insidiously, marginally nudge a young man or woman on the edge of deciding between (say) driving and doing a Masters degree, to drive.

<comment><USER4> Prices don't simply say shovels are best. Economic theory says that under some ideal conditions, prices reflect what is most efficient, and that whats most efficient is best.

That is, your argument is more an assumption that ideal economic models apply than a justification. Ideal economics don't always apply, prices aren't always transparent, competition isn't always perfect, cows aren't spherical.

</comment></comment></comment><comment><USER5> "We won't allow any technology that takes away jobs. In a country where you have unemployment, you can't have a technology that ends up taking people's jobs"

I guess we should spin up the weaving looms when the next recession hits?

<comment><USER6> Serious question -- why not? What makes this a bad idea?

<comment><USER7> Because automated weaving makes clothes a lot cheaper.

Put another way, when workers become more efficient -- one factory worker able to control many weaving machines, or a relatively small group of programmers able to control many cars -- people's standard of living increases.

Maybe you're willing to pay more for clothes, or transportation, or any one thing. But paying more for _all_ of the things that have gotten cheaper due to increases in efficiency since time X is tantamount to going back to the standard of living of time X.

<comment><USER8> What's the point of making things cheaper when it centers the wealth on just a few owners? When there are lots of workers working low income jobs versus just a few workers working high income jobs, it creates a healthier more distributed economy.

<comment><USER9> An estimated 2.3 Billion people now own smartphones. That number is growing at about 10% per year. All those people have access to the sum of all human knowledge and the ability to educate themselves almost as well as (some would argue even better than) the students of the most expensive universities.

They can communicate with anyone else at almost zero marginal cost, and can sell products and services to basically anyone else on the planet. All because things keep getting cheaper.

That's the point of making things cheaper.

Sure, a consequence of that is that the founders and executives and financiers of Google, Samsung, Apple etc are wildly rich. And that means they can (and do) invest in new products and services to keep improving peoples' standard of living, as well as funding benevolent projects.

It's pretty amazing if you ask me.

<comment> dorian-graph > All those people have access to the sum of all human knowledge and the > ability to educate themselves almost as well (some would argue even better) > than students of the most expensive universities. They can communicate with > anyone at almost no marginal cost, and can sell products and services to > basically anyone else on the planet.

Is this even happening though?

<comment><USER9> _Out of Coursera 's 18 million registered learners, 1.3 million are from India with top registered learners hailing from Bengaluru, Delhi, Mumbai, Chennai and Hyderabad, the website said today.

Driven by the vast interest coming from Bengaluru, technology hub, nearly half of enrollments in the country are in technology courses such as computer science (25 per cent) and data science (18 per cent)._

\- [http://economictimes.indiatimes.com/industry/services/educat...](http://economictimes.indiatimes.com/industry/services/education/bengaluru- tops-online-learning-in-india-coursera/articleshow/52078732.cms)

Top Freelancing countries on Elance:

India $312,865,112/649,566 freelancers

United States $310,023,579/1,123,935 freelancers

Ukraine $72,429,514/29,341 freelancers

Pakistan $71,061,107/176,011 freelancers

United Kingdom $35,320,646/126,670 freelancers

Canada $31,379,228/85,639 freelancers

Romania $28,062,831/44,305 freelancers

Russia $27,416,743/21,045 freelancers

Philippines $18,261,489/178,725 freelancers

Argentina $17,796,295

China $17,518,704/28,752 freelancers

Serbia $13,600,638/18,577 freelancers

Bangladesh $11,092,326/66,970 freelancers

[https://www.elance.com/trends/talent- available/geo#GeoRankin...](https://www.elance.com/trends/talent- available/geo#GeoRanking)

<comment><USER8> And when you try net income per person, you get:

       Ukraine  $2,468.54
       Russia  $1,302.77
       Serbia  $732.12
       Romania  $633.40
       China  $609.30

<comment><USER9> Thanks, I'm capable of using a calculator :D

There will naturally be a distribution of incomes among those people, with some people earning little or nothing, and some people earning a lot.

The point is that whatever the income a given person is earning, that is income that was unavailable to them before modern computing and communications devices became affordable to them.

That's money that people are using to build better lives for themselves, their families and their communities.

As I said, that is the point of making things cheaper.

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER10> While a braindead statement, it's a bit of a moot point. Humans will likely settle on Mars before self-driving tech can smoothly navigate India's traffic and roads.

<comment><USER11> I consider myself a fully autonomous human being, and there is no way I would ever try to navigate roads in India. If solving autonomous cars in, say, Denmark is checkers, solving it in India is Go.

<comment><USER12> If driving in Denmark is checkers, driving in India is a tavern brawl.

(Disclaimer: I haven't been to India for a couple of decades... maybe it's improved?)

</comment></comment></comment><comment><USER13> You could see this as political posturing by the transport minister. As the article mentions, with the state of India's roads, it was unlikely that it was going to be getting self-driving cars in the short-term. Banning them now, and removing the ban once the technology becomes feasible for India's environment is very possible.

</comment><comment><USER14> India has one of the highest number of road fatalities in the world (In top 5). 400 people die everyday on the road! 1000s of more accidents happen which don't get tracked. People who did nothing wrong get killed because someone was not paying attention.

Driverless cars or rather augmented driving will save lives but the minister doesn't care for those. Driverless cars will create more jobs in engineering, training and monitoring because driverless cars will not come one fine day but over a period of 10 years.

As someone who is working on self driving tech, this saddens me.

India needs more eyes on this problem because of our roads and our bad traffic sense. The fact that we don't drive on the same side of the road as the western world means their tech won't be adaptable directly. So much potential and opportunity but I guess the minister wants us to keep doing the cheap menial jobs.

</comment><comment><USER15> I live in India. Irrespective of whether the Government bans driverless cars or not, Indian roads and traffic conditions are not suitable for driverless cars. Period.

<comment><USER16> I bet if we start testing self driving cars in India, we'll get there in perhaps another 10-20 years. What's needed is an extremely good path planning algorithm. Rest of the self driving tech SLAM et al is already solved.

However, the bigger problem on Indian roads is congestion. I think you need smaller autonomous vehicles that can navigate through the crevices and cracks ( gallis ). Something smaller than the Tata Nano.

<comment><USER15> definitely a driverless toy car :)

</comment></comment></comment><comment><USER17> I hope this doesn't set any sort of precedent. This is extremely short- sighted. Jobs will be lost, but we should look for real solutions that don't slow down the improvement of quality of life or the advancement of the human race in general. Maybe basic income?

</comment><comment><USER18> It is easy to shit on the politician's statement, but at least try to understand where they are coming from. India is facing massive crises on multiple fronts. Huge number of youth enter the job market every year and there simply aren't enough jobs to go around. Driving employs a lot of people who vote, so he can't just ignore their concerns.

In many states, unemployed youth are likely to create a law and order crisis or exacerbate one that already exists. Neither does India have a huge amount of money lying around to fund something like UBI.

However, this situation didn't just happen on its own. Indian bureaucracy stifles private businesses by all kinds of vague regulations. A lot of effort is needed to rectify this and some people in power understand this, though it would take some time for them to bring the rest of them on board.

Secondly, the automobile industry in India is extremely significant. I believe they also bring in a substantial amount of foreign exchange now. If the global market is moving towards driverless technology, then India's corporates can't afford to be left behind. And they will put a lot of pressure on the law makers.

Finally, these politicians aren't very principled people. They will definitely change their tune under the right circumstances.

<comment><USER11> I think it's already the case that there are _tons_ of "make work" jobs in India. When I visited, in the hotel I stayed at there were like 4 doorman at the entrance. In the shared office building where I was working, there were _2_ people manning the copier - if you wanted to copy something, you had to hand it to the copier attendant, who would make your copies and then bring them back to you.

I think your comment is pretty accurate. It's one thing for us to laugh at the minister, but we don't really have any other solution for the huge numbers of people who will be put out of work if driverless cars take off in India.

</comment></comment><comment><USER19> A long-ish read.

In Indian malls, there are so many helpers standing around that if you lift up a merchandise, you'll be jump scared by someone asking you how she can help you. People are also used to asking the prices of the items, even though just flipping around would reveal the tags that clearly earmarks the final price (all tax and details). Indian are more used to DIFM (Do it for Me) than the western DIY culture.

Personally, I usually go on weekdays and I can have about 3+ people buzzing around me trying to help me decide what I want to buy. They all are my personal Siri for that location and context.

The labor market is also so cheap that Indians can afford to get much cheaper manual solutions than the one time bigger investment in automation and technology. Most people also know that it is more economical in the long run but don't really want to wait for the far-future gain.

If I hire a wash-helper to just wash my clothes twice a week, it will cost me just about ₹1000 ($15) (or even less) a month in Bangalore. A good washing machine (no dryer) will set you back by about ₹30,000($466). At that rate, I can have the wash-helper wash my clothes without failing or consuming electricity for 2+ years.

Very similar with a Dishwasher. A dishwash-helper can equivalently go on for 3+ years without any mechanical failure, no electricity consumption and you can talk to her. No annual maintenance needed either.

In early 2005, I was speaking at my first international conference and had my first US culture experience. There was a big mall opposite the Hyatt, Dearborn (forgot the name). I went in at a store and there was nobody to help me. The unmarked labels didn't help either. I did realize that I had to scan the barcode with a scanner (attached at quite convenient locations) and shows me the price details including the state tax. Manual labor is costly stateside and automation and modernization can bring in huge ROI. In India, anything that is a DIY needs someone to show them the DIY to the people.

So, when the transport minister says what he says, it is so easy for him to look for all the easier and more comfortable routes - just get someone to do it, "drive the car". We are a country where if Ikea comes in, my advice will be to have an army that can go and assemble their furniture at the customer location.

You, me and the people who think about automation, thinking 10 years ahead etc are far and few in between, especially in India, so he will very likely win.

Hell, many other politicians and fanatics are fighting over the exclusion of the word "cow" in public exhibitions such as movies.

<comment><USER20> Clarifying a few things so that people get a perspective on your post is about.

>>In Indian malls, there are so many helpers standing around that if you lift up a merchandise, you'll be jump scared by someone asking you how she can help you.

This is because most people can't use these things properly. Its easier(and cheaper) to put a lift operator than to have people damage lift and having it repaired/replaced.

>>People are also used to asking the prices of the items, even though just flipping around would reveal the tags that clearly earmarks the final price (all tax and details).

Very few do this. Those people who ask generally do it because we are price conscious, absolutely nothing wrong with that.

Look at the wester society, bulk of the personal finance problems there arise because people spend money they don't have.

>>Personally, I usually go on weekdays and I can have about 3+ people buzzing around me trying to help me decide what I want to buy.

Again easier to help you shop quickly this way, than having tens of people pile up in the store.

>>If I hire a wash-helper to just wash my clothes twice a week, it will cost me just about ₹1000 ($15) (or even less) a month in Bangalore.

Most people would and do buy a Washing machine for something like this. You must be rich.

\-----

Let's be frank this no-driverless cars is just political talk. When those cars arrive, these people will be the first ones trying to convince public about it.

<comment><USER19> LOL. Very true about the lifts. People, even many educated ones still ask which way the lift is going. I sometimes questioned, "Which button did you press?" They believe they should be "calling the lift" and not "pointing/pressing" which way need to go.

Being rich, is kinda subjective. No, I'm not rich.

</comment></comment></comment><comment><USER21> Given India's infrastructure and assuming it will be not a 100% driverless cars , this is not an issue indian legislators need to worry about. At least until India can achieve a 100% literacy rate and assure driving licenses given out are genuine.

</comment><comment><USER22> What a shame. The mortality rate for car accidents in India is staggering.

<comment><USER23> I'm honestly surprised it's not a bigger deal, particularly since it's easy to draw vehicular safety along class lines - rich people have big safe cars and drivers and poor people don't. I'd think India's class-conscious politicians would make some noise.

</comment></comment><comment><USER16> Ah, another ban. Welcome to the new age governance in India. Some government official in Karnataka wanted to ban ride sharing as well. I hear the government's sentiment about creating jobs, but hey have these guys ever sat in that shitty truck and driven all night ? Fucking armchair politicians.

Anyways, I used to think why hasn't any company invested in self driving tech in India - and now the answer becomes pretty clear. One can possibly take the government head on and challenge the ban in the Supreme court.

</comment><comment><USER24> Forget the part about protecting jobs, how confident will the driverless cars companies be even otherwise, sending their cars out into the chaotic traffic in India, where you routinely share the road with bicycles, motorcycles, scooters, rickshaws, handcarts, buses, lorries (trucks), cows and the occasional sheep and donkeys?

Related video => [2006] India Driving [https://www.youtube.com/watch?v=RjrEQaG5jPM](https://www.youtube.com/watch?v=RjrEQaG5jPM)

<comment><USER25> I remember reading about an Indian startup making autonomous vehicles. I believe they were bought out by TATA or funded by some big company. This was couple years back.

Edit: [https://www.google.com/amp/s/thenextweb.com/cars/2017/06/12/...](https://www.google.com/amp/s/thenextweb.com/cars/2017/06/12/dr- roshy-john-on-turning-a-3500-car-autonomous-and-the-future-of-self-driving- vehicles-in-india/%3famp=1)

</comment></comment><comment><USER26> India's exports have to compete against those of other countries. If India places itself at a competitive disadvantage as this Transportation official proposes they will lose sales and thus jobs.

Sure they can manipulate the currency but that places a tax on what everyone buys from overseas and lowers standards of living.

</comment><comment><USER27> I find this discussion pointless as driverless cars that can drive on Indian roads are a long way from becoming a reality.

</comment><comment><USER28> A complete joke, India can't even supply 24/7 electricity and water to the majority of their population, they may as well be discussing the outlawing of thermodynamics. It is as if a child showed up to a dissertation discuss astrophysics, what a bunch of clowns.

</comment><comment><USER29> human costs are so cheap there.. the ROI threshold is much more challenging to achieve

<comment><USER30> In a darker aspect, it seems the gov't values the lives of their citizens so little that they can't be afforded modern technological gains. The rich of India will sure experience it, as they travel abroad.

</comment></comment><comment><USER31> These ideas seem to come up a lot. I see people advocating these ideas everywhere, even on HN.

How can anyone think that job creation is better than job elimination?

</comment><comment><USER32> What a complete idiot in soooo many ways...now you can understand the situation of India's development when such utter morons are "leaders" of India! India actually needs driverless cars more desperately than any country in the world given it's world-leading 200,000 fatalities every year.

<comment><USER33> China had 260k: [https://en.wikipedia.org/wiki/List_of_countries_by_traffic-r...](https://en.wikipedia.org/wiki/List_of_countries_by_traffic- related_death_rate)

If you sort that by per 100k people or vehicles, India isn't doing too badly. They just have a lot of people.

<comment><USER34> And it's not even the main reason they need it, which is to optimize the usage of much more limited road infrastructure. Even china has been building roads like crazy, there is only so much space to put them when population density is so high....

</comment></comment></comment><comment><USER35> Given the infrastructure in India, this is probably a wise decision.</comment>


Ask HN: What are your experiences with taking a non-strategic investment? - <AUTHOR>

The Skinny: a Hardware venture.
Background: We took a $50k loan to secure patents on our hardware.
Moving Forward: The gentleman who gave us the loan has offered us the $2.5M we need to finish product development and get to commercialization. But he has no background in hardware, engineering, or tech. He is not a strategic partner, but he's got the money and it's something that no one else has offered us.
I know he'll be a great asset at developing the business, generating sales, and even resourcing manufacturing. But during the product development phase I don't see him as a fit.
What are your experiences with taking a non-strategic investment vs turning down the only investment offer on the table? <comment><USER2> If you aren't sure, give him a valuation that would make it worth it. Fundraising right now isn't as easy as a lot of articles make it out to be, and having money in the bank will free you from the roadshow of raising.</comment>


Place to find remote job - <AUTHOR>

Hey!
Can you help me with one issue.
What is the best place to place my cv\cover letter in order to find a customer?<p>By the way, here is my cover letter:
https://docs.google.com/document/d/1gMhaKWyzm1p44SJhBz69Rp8MFgnDf8TShZ8t5eH-US8/edit?usp=sharing <comment> V-2 "Because I do not want build bad application"

That doesn't sound good or reliable. Opening with "hello, my name is" also doesn't strike me as a good choice for a cover letter supposedly written by a professional. But I'm not a native speaker either...

To attend your question, there's "Ask HN: Who's hiring" entries here, they include remote offers.

Not a long ago someone advertised their service here - [http://jobs.remotive.io](http://jobs.remotive.io) \- although the job pool isn't very huge yet.

There's StackOverflow Careers, especially if you have a profile on SO already... and besides, JobServe.com and all the usual</comment>


Rob Pike's Rules of Programming - <AUTHOR> http://users.ece.utexas.edu/~adnan/pike.html <comment><USER2> I don't think the author's interpretation of #5 to mean use smart objects (which I'll guess means objects in the object-oriented sense) is correct. I interpret Pike's meaning to be to use dumber objects that make the data visible and obvious. That's also consistent with Go's emphasis on simple datatypes.

It's very close (in my opinion) to a restatement of Brook's quote "Show me your flowcharts and conceal your tables, and I shall continue to be mystified. Show me your tables, and I won't usually need your flowcharts; they'll be obvious."

<comment><USER3> No, it doesn't mean objects in the object-oriented sense. It means something more like "don't build an array and then iterate through it to get the minimum item, if you could just build a minheap." I.e., if you can, use data structures that do the heavy lifting of your algorithms "for free."

<comment><USER4> Total tangent, but it occurs to me that if all you want is the minimum item, you maybe don't even need a minheap. You can just keep a single item--the smallest--and replace the operation of adding to the array with the operation of compare-and-possibly-replace.

<comment><USER5> As long as you don't need to remove items or update their costs often.

</comment></comment></comment></comment><comment><USER6> I feel torn about the "premature optimization" stuff. On the one hand it's clearly true that we're terrible at predicting bottlenecks and it makes no real sense to second guess them at any fine level of detail. On the other hand, I think about products that I love to use and they are all fast. I think about the first iPhone and how utterly crucial that first user experience was. Did they achieve that by just writing giant gobs of code and then circling back afterwards to fix a few hotspots? I think about how Chrome was such a delight after FireFox got slower and slower and more bogged down. Clearly, Chrome was written from the ground up to avoid that. I am not so sure you can really optimise for performance after the fact, at least not universally. There are times when you have to build it into the very fabric of a project right from the start. Once a project has a giant mass of moderately slow code, there's nothing you can do except rewrite it to get better performance.

<comment><USER7> To me premature optimization goes far beyond just speed: it's a judgment call, and it affects everything we do as programmers.

Should I spend more time here making this variable readable? Should I structure this script to be maintainable, or is it going to be of no use in 2+ weeks?

Sometimes the answer is yes; sometimes the answer is no. The key is not to _pre_ -maturely optimize. You have to use your own good judgment and an iterative problem solving process to figure out what the metaphorical bottle neck is and fix it (I say metaphorical because, again, it's not just about speed).

<comment><USER6> Yes - I think this is what I was trying to express. I guess I think the message about premature optimization is much more subtle than usually accounted for. It's about decisions to introduce complexity, to sacrifice design integrity, etc. in favour of performance.

But it is not about devaluing having a careful discipline and intuitive sense of the performance of code and a rigour about how you think about performance in your work. All those things are still incredibly important.

</comment></comment></comment><comment><USER8> This list is from Rob's "Notes on Programming on C", written 25 years ago: [http://doc.cat-v.org/bell_labs/pikestyle](http://doc.cat-v.org/bell_labs/pikestyle)

Worth reading for some context.

</comment><comment><USER9> "Premature optimization is the root of all evil" I always thought this was a Knuth quote.

[http://c2.com/cgi/wiki?PrematureOptimization](http://c2.com/cgi/wiki?PrematureOptimization)

seems to concur.

<comment><USER10> From [1], page 8:

      There is no doubt that the grail of efficiency leads to abuse.
      Programmers waste enormous amounts of time thinking about, or worrying
      about, the speed of noncritical parts of their programs, and these
      attempts  at efficiency actually have a strong negative impact when
      debugging and maintenance are considered. We should forget about small
      efficiencies, say about 97% of the time: premature optimization is the
      root of all evil.

      Yet we should not pass up our opportunities in that critical 3 %. A
      good programmer will not be lulled into complacency by such reasoning,
      he will be wise to look carefully at the critical code; but only after
      that code  has been identified. It is often a mistake to make a priori
      judgments about what parts of a program are really critical, since the
      universal experience of programmers who have been using measurement
      tools has been  that their intuitive guesses fail. After working with
      such tools for seven years, I've become convinced that all compilers
      written from now on should be designed to provide all programmers with
      feedback indicating  what parts of their programs are costing the
      most; indeed, this feedback should be supplied automatically unless it
      has been specifically turned off.

[1] [http://cs.sjsu.edu/~mak/CS185C/KnuthStructuredProgrammingGoT...](http://cs.sjsu.edu/~mak/CS185C/KnuthStructuredProgrammingGoTo.pdf)

<comment><USER11> The "indicating what parts of their programs are costing the most" made me think of the color scheme when working in cython: white (C-fast), yellow (slow). [http://docs.cython.org/src/quickstart/cythonize.html#determi...](http://docs.cython.org/src/quickstart/cythonize.html#determining- where-to-add-types)

of course it doesn't tell you anything about the speed of the C code, but I find the line coloring to be a nice UI for showing computational cost.

</comment></comment></comment><comment><USER12> I think what happens with all intermediate or senior programmers is that we start to think about the best solution instead of just getting the job done.

Most code we write will either not be used or eventually rewritten anyways.

<comment><USER6> > Most code we write will either not be used or eventually rewritten anyways.

But it's like the advertsing paradox: we know most of our code will be discarded or rewritten, but we don't know which parts won't. And even worse, it is often the bad parts that survive because people become afraid to touch them.

<comment><USER13> We're screwing ourselves badly with that attitude in the long term. Because of similar attitudes in setting up industrial contro systems, you can now shut down an entire factory with a misplaced ICMP ping. Layers of hacks built on layers and layers of other hacks will bite us hard at some point, and I mean in the "lives lost" sense of biting.

</comment></comment></comment><comment><USER14> Anyone have good before and after examples of Rule 5? That is, a "dumb" data structure with "smart" code refactored to a smart data structure with dumb code?

<comment><USER15> I don't have actual code. But when tutoring CS1 and CS2 students during undergrad, it was common for students to try to implement algorithms in terms of linked lists when they should have been using a tree.

The really persistent students would get things to almost work -- often with hundreds or thousands of lines for something that, with a tree, doesn't take more than 10-50 lines.

This is also an interesting case study in human behavior; the students were typically too impatient to spend 20 minutes thinking about the problem before coding, but could spend 20-30 hours on a single assignment. Odd combination of work ethic and lack of patience...

<comment><USER3> > the students were typically too impatient to spend 20 minutes thinking about > the problem before coding, but could spend 20-30 hours on a single > assignment. Odd combination of work ethic and lack of patience...

I wouldn't call it a lack of _patience_ , per se. In most modern models of the brain, exercising executive control to think abstractly ("using System 2") expends energy for as long as you're doing it, and the explanation for many of the brain's inherent shortcuts and biases is to to prevent you from switching into System 2 for longer than absolutely necessary.

I have a feeling that a large part of what is characterized as "intelligence" is simply the brain being willing, for whatever reason, to switch into System 2 "mode" more often, and stay in it for longer.

<comment><USER11> In case anyone else is wondering, System 1 = autopilot thinking and System 2 = deliberate thinking.

From Thinking, Fast and Slow by Daniel Kahneman

<comment><USER16> Kahneman chose the names "1" and "2" because he asserts that those names are easier to remember than "autopilot" and "deliberate", and so don't require System 2 thinking when you use them. I find that the confusion arouns these names undermines Kahneman's theory, as seen in this thread.

</comment></comment></comment></comment></comment><comment><USER17> > Rule 3. Fancy algorithms are slow when n is small, and n is usually small. > Fancy algorithms have big constants. Until you know that n is frequently > going to be big, don't get fancy. (Even if n does get big, use Rule 2 > first.)

Thing is, I _don 't_ know; n is definitely small in our unit tests, but if it isn't guaranteed¹ to be small, I'd rather start the code off as something with O(decent) as opposed to O(whatever an array gets me). It's not clear to me if this is what Rob Pike means though: does simply using a hashtable when appropriate to avoid iterating through a list count as "fancy"?

When the ultimate bounds of n aren't certain, I'd rather start with a good O(...) algorithm, and _then_ apply the "measure, and optimize."

¹and even then, if my "guarantee" is coming from something other than physics, I'm wary.

<comment><USER18> If you can get a naive n^2 solution, or build a complicated nlgn solution, and you know the size of the data will be ~100 items, certainly never >1000 solutions, I'd choose the naive solution.

Edit: and it's not in the middle of a tight loop

</comment></comment><comment><USER19> This is great advice. What I take away from it is, keep it simple, keep it readable, and save the detailed optimization for later, when you have time to really test and measure it.

</comment><comment><USER20> Data live much longer than programs.

<comment><USER21> Exactly!

Make the format simple and obvious enough to be applicable for a wide range of purposes. Because humility.

[http://keithp.com/blogs/Repository_Formats_Matter/](http://keithp.com/blogs/Repository_Formats_Matter/)

On-the-wire formats matter, on-disk formats matter.

</comment></comment><comment><USER22> This shouldn't replace understanding the problem domain and carefully planning before tackling a moderate to large scale project. Yes, one shouldn't tune each individual piece with unjustified optimization but the high level design should be thoughtfully laid out prior to hammering out large swaths of code.

Too many developers plow forward in a brute force manner creating unmanageable inconsistent messes and use rules like these to justify their lousy (lack of) design choices.

My rules:

1\. Understand the problem domain.

2\. Design flexible solution using common patterns.

3\. Stub out skeleton of system encompassing majority of specs.

4\. Revisit design and consider all conceivable exceptions and outlier and tweak design as necessary.

5\. Review above work with others and tweak design further as necessary.

6\. Coding.

<comment><USER7> > Design flexible solution using common patterns.

Maybe this is part of the problem. I'm relatively young, so I've only seen a few design patterns, but it'd be interesting to have a high-level look at some of the most common patterns and what they're good at and what they aren't. For instance, I've never really used a messaging queue, but it seems like a genius design for a particular type of problem. I wonder how many other designs are out there that I'm not using, instead opting to shoe-horn in my existing ways of thinking.

<comment><USER23> Just in case, here's the 'Gang of Four' book on design patterns: [http://www.amazon.com/Design-Patterns-Elements-Reusable- Obje...](http://www.amazon.com/Design-Patterns-Elements-Reusable-Object- Oriented/dp/0201633612)

</comment></comment></comment><comment><USER24> I like Rule 6. Nearly but not 100% sure that it is from another version of this same list by Rob Pike, that I read somewhere else:

Rule 6. There is no Rule 6.

</comment><comment><USER25> I have one rule , "pray .... non stop"

</comment><comment><USER26> Can be distilled into a one liner. "NO DRUM SOLOS"

</comment><comment><USER27> Pre-optimization is one of the biggest problems with today's programmers. First priority should always be releasing the software. Let it break. Make optimizations when and where necessary.

No one can look into the future.

<comment><USER28> First priority is about modularity and elegance. An elegant program is often fast, correct and with a short time-to-market.

It is the numerous scores of small hacks that bogs down programmers nowadays.

<comment><USER27> When I say first priority is releasing the software - it means releasing software that works functionally. We cant optimize stuff which we are not sure will even break due to performance issues.

Analyze traffic/usage of parts of the application - mark areas which are used most - analyze performance - optimize if not up to mark.

If stress is always on elegant code - it'll always end up taking more time. In real-life scenario, no module is ever "bug-free". The cases change from day to day. When you're absolutely sure that the functionality is exactly what is required - then you should spend time optimizing it.

</comment></comment></comment><comment><USER29> That's why I trust golang.

</comment><comment><USER30> "Rule 5. Data dominates. If you've chosen the right data structures and organized things well, the algorithms will almost always be self-evident. Data structures, not algorithms, are central to programming."

Quite ironic coming from the creator of Go. Algebraic data types, anyone?

<comment><USER31> Oh, interesting. It's the middlebrow dismissal. I thought it had become an endangered species, but here it is, stepping right out into a crowded thread and trying to take out Rob Pike of all people. Good show!

[https://news.ycombinator.com/item?id=4692598#up_4693920](https://news.ycombinator.com/item?id=4692598#up_4693920)

<comment><USER32> Of course pg hates the "middle brow" dismissal. Part of his schtick is Malcolm Gladwell style 'intellectual porn' essays that ignore facts and complexity to paint an aesthetically pleasing (but false) narrative to people who are not subject experts. At this stage I'm not sure if PG does it deliberately like Gladwell admitted doing. I'm willing to give him the benefit of the doubt and say he does it inadvertently by writing about topics where he has no knowledge of previous study, coupled with a large ego born of being rich and constantly surrounded by sycophants trying to get funding.

The middle brow dismissal is apt/damaging in these situations because it saves everybody a lot of time by quickly demonstrating that the author ignored those pesky real world facts and complexities that spoilt the ideological narrative.</comment></comment></comment>


HN: good interdisciplinary MS/PhD programs for tech/culture? - <AUTHOR>

Curious to know if any HN readers have programs (academic or otherwise) on their radars that integrate cultural issues with engineering, experimentation, hands-on kinds of stuff.
I'm thinking of something similar to MIT's media lab:  http://www.media.mit.edu/research/groups-projects
I have a weird background (ex-Army intel, classics & international affairs degrees) but have been getting into learning about coding more, fully knowing I'll never be much of a coder or engineer, and wanting to experiment more.  But I do want to play with stuff and build more products than do analysis the rest of my life, which is what I'm in danger of being lured into while I'm in DC.
What are you folks keeping your eyes on? <comment><USER2> NYU's ITP program is similar in some respects to MIT's Media Lab. I attended their spring project show a few years ago and it was very interesting. Lot's of creative types there. MIT's Media Lab is also a very interesting place with very, very smart people there. I've heard that it is difficult to get into.

<comment><AUTHOR> Just wanted to follow up... I checked out the ITP course list and it really looks outstanding for what I want to learn next. Think I might be applying... Once again, appreciate the tip.

<comment><USER2> No problem. Attend one of the project shows they have from time to time, if possible. It was very cool to see the cool projects, but the students were all really cool and willing to chat about the projects and ITP. They could tell you a lot more about the program.

</comment></comment></comment><comment><USER3> You definitely want the MIT Media Lab. They have hardcore things going non from both ends of the spectrum (quantum computing all the way to next gen human interfaces)

<comment><AUTHOR> Thanks. :) I definitely spent some time checking out their project outlines on the site, and some of the demos...</comment></comment>


Tell HN: an iPhone app for the blind - <AUTHOR>

I was inspired by an idea mortenjack posted on HN, and instead of thinking "yeah, that's cool." I decided to have a shot at it. I'm busy as all hell with college and other apps, but I'm sure I'll be able to fit in the time somewhere (pshht, sleep, who needs it).
This is the original thread that started it all: http://news.ycombinator.com/item?id=1705463
Thanks for reading. If it wasn't for HN this idea would never have gotten off the ground like it did. Donate if you can (and don't judge the done-in-one-take video)!
Any questions, ask away. <comment><AUTHOR> In retrospect, I should have shaved before I took the video, but I was too excited. Don't judge me (and the project, especially)!</comment>


Show HN: Extend Markdown on Static Sites with Inline JavaScript (Hexo/Vue.js) - <AUTHOR> https://www.flex.io/blog/markdown-syntax-javascript-hexo-vue/ <comment><AUTHOR> Hi all -- we're using Hexo for our website. For our API docs we wanted to provide 'live' runnable code snippets in Markdown, so I came up with a way to make it easy for anyone on our team to add tiny Javascript apps in Markdown with a simple tag. Thought HN might find it useful too and happy to answer any questions.

The link above lets you play with live examples; GitHub repo here: [https://github.com/flexiodata/markdown- components](https://github.com/flexiodata/markdown-components).</comment>


Ask HN: Tracking a Business Process? - <AUTHOR> How do you track business processes, measure their performance, report on KPIs or maybe even do some predictive analytics in order to get ahead of a problem? Think tracking an order fulfillment process like Amazon or doordash would with all their sub-processes such as payment, packaging, shipping etc.
I have used AMPs like AppDynamics or DynaTrace but they are too low level to map to relevant business events and none of them handle asynchronicity well.
I have also tried Elastic and Splunk but they are difficult to define a multi step sequence to track.
I have also thought of solutions such as Heap analytics but most of these tools are focused on conversion optimization.
I'm trying to find an off the shelf tool to hand to our operations team where they can define their own metrics and track each customers order events. <comment><USER2> At my company we're using [https://camunda.com/products/cloud](https://camunda.com/products/cloud) (non- cloud version: [https://camunda.com/products/](https://camunda.com/products/)).

Some of the stack is open source.

<comment><USER3> In addition to Camunda's core product, they've more recently come out with [https://zeebe.io](https://zeebe.io). Zeebe also may be used in a monitoring- only use-case.

<comment><USER2> Neat, thanks!

</comment></comment></comment><comment><USER4> I'm building / speccing out an app in this space and would love to learn more about what you're looking for. Shoot me an email if you're interested in informing the spec.</comment>


GitHub Status Generator - <AUTHOR> https://github-status-generator.com/ <comment><USER2> It doesn't sit right with me to register real domain names for throwaway novelty stuff.

I miss the time when someone's single "homepage" domain would house the collection of all their hacks, both serious and novelty.

<comment><USER3> I don't know how GitHub legal would react to having their trademark in a domain name, but I have a feeling this might not last long.

(Disclosure: I received _many_ c&d in my former life for this kind of thing and I won't be doing it again.)

</comment></comment><comment><USER4> > GitHub's down and I can't really do work

One of the rationale for distributed versioning systems was precisely to prevent things like this from happening. I find it a bit sad that we have reverted to the old, centralised workflow, mainly due to GitHub's omnipresence.

</comment><comment><USER5> The source code is here: [https://github.com/aapeliv/github-status- generator.com](https://github.com/aapeliv/github-status-generator.com) but it might be 404ing for you today, lol.

</comment><comment><USER6> Excellent stuff. Impressively quick. One feature request: can each generated status stack up for maximum effect?

Like this: [https://i.imgur.com/74zUHKy.png](https://i.imgur.com/74zUHKy.png)

<comment><AUTHOR> All done, I added multiple events. Let me know what you think.</comment></comment>


Visualizing Data with Elasticsearch, Logstash and Kibana - <AUTHOR> http://blog.webkid.io/visualize-datasets-with-elk/

<comment><USER2> This was very clear and easy to understand. I'm a big fan of elastic search, but don't have any exposure to logstash or kibana. The screengifs were also a welcome touch; though some seem to have trouble loading.

Overall, this is looks exciting and i will have to play with this over the weekend!

Thanks a ton for writing this up</comment>


Read-only deploy keys - <AUTHOR> https://github.com/blog/2024-read-only-deploy-keys <comment><USER2> Read only deploy keys are also a feature of Bitbucket: [https://confluence.atlassian.com/display/BITBUCKET/Use+deplo...](https://confluence.atlassian.com/display/BITBUCKET/Use+deployment+keys)

<comment><USER3> And in their enterprise equivalent _Stash_

<comment><USER4> Sadly stash really isn't that great compared to GitHub or GitLab IMHO

<comment><USER5> GitLab CEO here, thanks! And deploy keys in GitLab have always been read-only [http://doc.gitlab.com/ce/ssh/README.html](http://doc.gitlab.com/ce/ssh/README.html)

</comment></comment></comment></comment><comment><USER6> Now we wait another five years for the ability to share deploy keys across repositories. If you have more than one project in your CI deployable app (for example a couple of internal python libraries), you can't use the same deploy keys. Their suggestion, "don't use modules, package everything in one application or use a full key". Now deploy keys can be R/O (fantastic), this limitation is double annoying.

<comment><USER7> Rather than using Deploy Keys at all it seems completely better in almost every way to create a fake GitHub user and use its account's regular SSH key. You can, using Teams, give that user read-only access to whichever repo(s) it needs access to for deployment.

<comment><USER8> Github calls these "machine users". But it's more annoying to manage than the deploy keys UI.

</comment></comment></comment><comment><USER9> Deploy keys weren't read-only already? Seriously?

<comment><USER10> I don't know about your use-case, but in my experience by far the greatest use of these keys is (as they say in the linked article) for use by continuous integration servers. Some folks tag each build (if it creates an artifact), and almost _everyone_ tags release builds created by CI. Thus, these keys need to be R/W to push tags back up.

<comment><USER11> [https://developer.github.com/v3/git/tags/](https://developer.github.com/v3/git/tags/)

Use API + oauth access?

<comment><USER12> API access is a lot more permissive. A deploy key only have access to 1 repo, but there's no way to limit API tokens to a single repo (and by default they have access to all repos in all organizations the issuer of a token have access to).

<comment><USER11> Yes, I didn't realize how bad github's security model of this stuff was.

<comment><USER13> Yeah, it's terrible.

You can't give read only Oauth access to private repos....it has to be read/write. Which means if you want to use online CI tools with those private repos....you've got to hope they don't either turn malicious, or they get hacked and have their keys copied.

</comment></comment></comment></comment></comment></comment><comment><USER14> Now we just need branch restricted keys & keys that aren't allowed to force push (both of these would make me feel a lot better about using certain 3rd party automation in combination with my github repos).

Not that I really expect that to happen anytime soon, I believe others have been asking for the above for quite some time.

</comment><comment><USER15> I asked this question 5 years ago on SO: [http://stackoverflow.com/questions/2868432/github- readonly-a...](http://stackoverflow.com/questions/2868432/github-readonly- access-to-a-private-repo). Glad it got addressed.

</comment><comment><USER16> I always thought that deploy keys are read-only. I can't understand why one would need a special interface to add a read-write key that is the same as any other key you add manually.

Iirc only the owner can create deploy keys, so it wasn't a feature aimed to teams either.

<comment><USER17> They are not tied to a specific, potentially personal, GitHub account.

</comment></comment><comment><USER18> Deploy keys could only exist in one repo at a time. And I think a lot of people thought they were read only.

</comment><comment><USER19> I would love to see auth token that provide read-only access to select repositories. I find SSH keys much harder to use in a Docker-based deployment.

<comment><USER20> Couldn't you create a new user, give it access to those chosen repositories, and then use the API to access them with read-only permissions?

<comment><USER21> If I'm not mistaken you can't grant an application read-only access to a repository? GitHub really isn't very granular in their permissions...

<comment><USER22> Not sure the best route, but the ugly route I know of is place the user in a group wich just have read-only. I am really shocked GH doesn't actually make role-based more granular. I have to add a group to a repository, and can't have the option now to add user to a repository....</comment></comment></comment></comment>


SOPA won't stop the internet, it will merely force it underground.  - <AUTHOR> http://blog.webdistortion.com/2011/11/24/sopa-wont-stop-the-internet-it-will-merely-force-it-further-underground/

<comment><USER2> This article seems to be just the kind of positive vibe that geeks love to read: "The Net interprets censorship as damage and routes around it." Yeah, right. I don't see any evidence that we will have a usable underground internet soon, and in the meantime an ultra-censored, walled-garden internet appears inevitable.

Technical efforts might eventually create a platform which cannot be controlled by the government but it will be a very long time before this is usable for all but the most technical people. By the time something is ready for the the average public we will have had a censored internet and no viable uncensored platform for many years. How will you convince average joe that they should be interested in such a project? This will be a niche service used by child pornographers, drug traffickers, file sharers and freedom geeks. Good luck convincing anybody to identify with that group.

<comment><USER3> I genuinely agree with you on all points.

However, I do have one small note; the early 90s internet was also unusable for all but the most technical people. It was also fantastic, and I'd largely be happy to have access to an internet community of that size and quality today -- especially since I wouldn't have to also give up today's consumer internet.

<comment><USER4> IRC and USENET never went away...

<comment><USER3> USENET: The eternal September. IRC: mIRC

</comment></comment></comment></comment><comment><USER5> Recent (French) history tells us that this argument will probably not be taken into account by the law makers, because they are in majority incompetent, and more importantly this argument isn't backed with promises of positive income nor better behaviour. They will blindly look at the exposed pros and cons, and their limited expertise will merely say "so what" to these cons. The SOPA project, much like all Internet regulation projects, are considered as short- term "win-win" deals and long-term "win-don't care" deals with the Entertainment Majors. Since they expect the masses to not understand the cons either and keep voting the way they always did, they don't foresee any negative mid-term consequences either.

Arguments against Internet Regulation laws have to include profits for the government, otherwise I'm afraid the law makers will keep on not listening.

</comment><comment><USER6> I find the article a little overzealous; while I'm no staunch capitalist, including sentences like "The web in its current, open state is a threat to capitalist ideals" doesn't help convince me about your goals.

And yes, while this is partially true, a lot of legitimate businesses and people who aren't motivated enough to "go dark" also drive the internet, and they're not going to be so easily forced underground - any such internet would be a shadow of its former self, and an easy thing for governments to demonise with the usual examples (drug trafficking, child pornography, etc.)

<comment><USER7> It's not even true: plenty of free market capitalists view copyright as a monopolistic distortion caused by the state, not as a real mechanism of the market.

 _Against Intellectual Property_ [1] is a good example.

[1]: <http://mises.org/journals/jls/15_2/15_2_1.pdf>

</comment></comment><comment><USER8> The net _can_ route around censorship. People will just have to get used to encrypting their stuff, using proxies, hiding their DNS requests, and support ISPs that resist. Maybe it will spark the demand for more off-shore data centers.

A "dark net" is highly unlikely given the geographic dispersion of our populations and the high-cost of infrastructure for moving signals over those kinds of distances.

</comment><comment><USER9> Some (unintended?) irony:

From a random Server Beach Unix host of mine:

       shephard@sbwc:~$ dig +short blog.webdistortion.com
       ghs.google.com.
       ghs.l.google.com.
       18.104.22.168

From my laptop at work using whatever DNS resolvers happen to be operational here:

       ghshephardmb:~ shephard$ dig +short blog.webdistortion.com
       ghshephardmb:~ shephard$

</comment><comment><USER10> Wasn't the US once known as "the land of the free"? When did they lose it?</comment>


Bring the Bay's Top Student Entrepreneurs Together With 150 Global Innovators - <AUTHOR> http://kairosfundraiser.com/

<comment><AUTHOR> Developer here. This was a ~24 hour hack put together to try to raise the funds that we need to subsidize 15 financially at-need students (myself included) to this fantastic event. Many of us have already started companies or are pioneering some incredible research but don't have liquid capital to afford the trip and event costs (includes lodging and food).

We are working on a full-length blog post that will be posted tomorrow to go into the details of the opportunity that we have in front of us.

As with any fundraiser, any help is absolutely appreciated.</comment>


SpaceX's Starship Mk1 just blew off its bulkhead in a pressurization accident - <AUTHOR> https://twitter.com/NASASpaceflight/status/1197265917589303296 <comment><USER2> I read this was a manufacturing pathfinder.

Manufacturing and assembly of high strength hardened steel is near black art.

Pathfinders do exactly what they say, they lead you through unknown territory to the outcome of the manufacturing journey you embarked on. Often things go boom, you find out why, add it to your corpus of black art knowledge, and keep pathfinding until you run out of budget / succeed / change mission.

So as manufacturing pathfinder, this is what success often looks like.

<comment><USER3> I must admit that Elon has done some fairly impressive things, and I respect his hustle and innovation.

With that said, the cult that surrounds his projects where people say things like "this is what success looks like" when a big metal thing blows up unexpectedly or robot car goes flying off an exit ramp is a never ending source of amusement.

<comment><USER4> The cult is funny indeed, but do mind that the giant SpaceX booster rockets exploded in giant balls of fire a LOT before they eventually (and reliably) landed like in a sci-fi movie, on land and on a moving boat. SpaceX has earned some benefit of the doubt.

<comment><USER5> I don't think the issue is that a prototype didn't function as desired, it's the re-framing of that event as a "success" that reeks of cult-like worship mentality.

When something doesn't behave as desired, it is a failure. You can learn from failure, that's how you get to success, but the failure itself is not a success.

<comment><USER6> I agree calling it a success is too rosy, but I think people are really thinking od this as progress, not a regression like the event itself would naively suggest, because the company relies on hardware failure to inform design improvements.

</comment></comment></comment></comment></comment><comment><USER7> "You will learn more from your failures than your successes - so embrace those mistakes, as difficult as that sounds, and grow from them. When a project is successful, you're never really sure why, because so many elements come into play. However, when you fail, you always know why. That is how you learn and grow."

Lynda Resnick

</comment><comment><USER8> Oh dear! It looks like someone accidentally divided by 2 for the cylindrical hoop stresses, forgetting that they're not the same equation as for spherical stresses. :)

Less facetiously, a thin-walled cylinder's stress is a function of pressure, radius and thickness with the equation:

sigma = P*r/t

whereas for a sphere (including the spherical end caps on a cylindrical pressure vessel), it follows the equation:

sigma = Pr/(2t)

To me, it looked like it failed around the join between the spherical end cap and the cylindrical body, where this transition between stress regimes occurs, which is a common weak spot in the above analysis. This is a canonical early engineering statics problem.

It's worth noting, though, that all of the above is almost certainly a gross simplification and likely has very little bearing on the actual problem. It's fun to simplify and hypothesise, though! Also, unplanned failures make for great viewing :)

<comment><USER9> That's why you take your maximum design stress and double it, right? /s

<comment><USER10> I don't know what happened here, but if I remember correctly, in rockets, safety factor is typically smaller than 2 or the design would be too heavy. But I guess the safety factor for pressure testing is 4.

Source: article 220.127.116.11 of this document; [https://www.faa.gov/about/office_org/headquarters_offices/as...](https://www.faa.gov/about/office_org/headquarters_offices/ast/reports_studies/library/media/Operational_Guidelines_for_Spaceflight_Pressure_Vessels.pdf)

Edit: I didn't see the "/s" before writing this comment.

<comment><USER11> > in rockets, safety factor is typically smaller than 2 or the design would be > too heavy

Safety factors feel like p-values. Why .05? Because. What if it's not good enough? We'll move the goal post.

<comment><USER8> They are, somewhat. You can theoretically make a safety factor 1.0 if you're really absolutely certain of the input criteria.

Safety factor is really just a (somewhat blunt) method of managing risk. It's just admitting that we don't know the true load spectra that a design is exposed to, so we take what we believe is the max load and then slap a multiplier on it to manage how much uncertainty we expect, be it from estimates of that load, or dynamic factors, etc. etc.

We then also consider the consequence (since risk = likelihood x consequence). If the consequence of a failure is that our balsa-wood model bridge falls over, we shrug and keep it low. If it's that our pressure vessel undergoese a BLEVE [1] in the middle of a population centre then you jack it right the hell up.

There's nothing that specifically requires a safety factor. We could spend millions of dollars and thousands of hours understanding _exactly_ the load spectra a design experiences, but that may be prohibitively expensive in the case of designing a bridge, so we instead accommodate more risk by overdesigning the item. In a space application where every kg of launch mass represents big $$$, then spending that extra time and money to understand the load specifics in more detail makes sense.

[1]: [https://en.wikipedia.org/wiki/BLEVE](https://en.wikipedia.org/wiki/BLEVE)

<comment><USER12> Safety factors also mitigate stupidity (your bridge is rated for load X, but someone drives 1.1 X through it because they're in a hurry) and cascade failures (a component upstream of yours fails and sends more load down your way).

<comment><USER13> Those both sound like kinds of ways the real maximum load could be higher than what you've called your maximum load

<comment><USER12> Only as long as your "real maximum load" != "announced maximum load". For the type of stupidity mitigation I mentioned, you want the real maximum load to be greater than the max load you announce to the customer/users. For mitigating cascade failures, you want the real maximum load to be greater than the maximum load value meant to be used internally by people designing other components in the system (though here, a smarter way would be to do a system- wide analysis of load flows to prevent cascade failures under user stupidity; however, here we're rapidly approaching the point at which I just talk out of my ass, having no real expertise on the topic).

<comment><USER8> There's also some benefit in throwing a moderate safety factor on something if it doesn't actually compromise the intended form or function of the component, just as future insurance. For example, if you design a bit of equipment to take a certain load, but there's no size or mass constraints on it, and you can throw a 1.5x safety factor on, then it's not necessarily a bad thing. Even if your 'true' load as measured over several years of service only ends up being 1.2x, then the extra 0.3 or so can come in useful if a future engineer has to make modifications to the function of the device, or if they are asked to evaluate a life extension, etc.

In less words, I'm eternally thankful that I work in an era where much of the older equipment I used was designed in an era of slide rule. This means there's a bit of extra 'meat' in the designs which often means that when I do a more precise computational analysis, I can deal with 10% material loss through corrosion, or extend out the life by some period of time because it's not been designed precisely to the material limits.

<comment><USER12> > _I 'm eternally thankful that I work in an era where much of the older > equipment I used was designed in an era of slide rule._

Yes, I feel this way too. The knowledge and tooling of modern engineers is amazing, and can do miracles when applied to tasks that seemed impossible just a century ago. But more often than not, it's used to pinch pennies from old designs. This makes me wish for infrastructure projects to be forced to be designed with slide rules again - the less precise your determination of maximum load is, the less the beancounters can "optimize" it.

This is doubly sad in our era, where matter is cheap and labor is expensive - adding extra safety margin can be almost free, but it's an easy target for cost reduction.

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER14> And that's why they are testing it.

<comment><USER15> Depends on what kind of test that was supposed to be.

If they pumped it until it explodes it would be a kind of test (also called experiment) where it makes sense.

If you design something with a margin of safety, then pump it to working pressure and it blows, then it means you made a mistake. If you made a mistake it shows you don't know what is necessary to design a rocket (yet).

Seriously, they don't build skyscrapers or bridges and leave for 5 days to see if they topple to prove the design was correct.

<comment><USER16> Rockets are designed to have a vastly lower margin of safety. If they never fail in testing that's a sign you're over engineering it and sacrificing cargo capacity, which is a bad thing. That said, these failures should be uncommon.

<comment><USER17> That's basically been the conventional thinking about rocketry historically - scientists and engineers looked at the tyranny of the rocket equation and choose to maximize payload per launch because they were largely funded by government or quasi government "cost plus" types of contracts. The design philosophy of working close to margins comes from this thinking.

SpaceX's greatest contribution has been to look at rocketry from the point of view of economics of running a rocket launching business as opposed to a "per launch cost plus" model realizing that fuel cost for launching a rocket is close to trivial compared to the facrication cost of making a rocket.

So their entire design philosophy is around reusability and reusability seems to push costs down low enough that you can get more payload up by simply doing more launches. While SpaceX is famous for not filing patents and instead protecting their IP using the trade secret approach and fabricating everything in-house, you can bet they'll be operating with more engineering headroom to get reliability and reusability.

Evidence for their bet having been right is the fact that they have grabbed virtually 100% of commercial and quasi-governmental launches and some part of US government launches. Other players in this space now almost entirely depend on defence contracts or national prestige contracts to survive.

<comment><USER18> Doesn't matter. If you take the conservative assumptions that go into manufacturing, say, a car and apply those to a rocket, you'll get something that won't even lift off the ground, much less make orbit.

Any rocket HAS to be very close to the limits of what materials used allow, and not the +50% margin of error you routinely seen in other fields. What you say about SpaceX is true, but only relative to the rocket industry as a whole. E.g. SpaceX uses cheap, available materials and simple designs over exotic composites and complex mechanisms. But they still operate close to the margins, as they have to in order to have any payload capacity at all. In fact, the move to steel probably reduced their mass margins even further.

EDIT: Actually maybe I shouldn't have used a car as an example: [https://www.youtube.com/watch?v=pJdrlWR- yFM](https://www.youtube.com/watch?v=pJdrlWR-yFM)

<comment><USER17> The video is hilarious! Thanks for sharing!

<comment><USER18> My favorite part is the look on the engineer's faces when they're asked to turn a Robin Reliant into a Space Shuttle.

"Have you got a spare billion dollars?"

"No. That's why we came to you."

</comment></comment></comment></comment></comment></comment></comment><comment><USER19> Is the Starship Mk1 more structurally sound than it looks? From a first glance and having no knowledge of its design, it looks like an empty soda can that would deform at the slightest disturbance. And the way it crumpled in the video doesn't seem far off from what I would expect.

<comment><USER20> Rockets are actually pretty easy to poke holes in. They're meant to keep stuff in, not out. A dropped torque wrench blew up a Titan.

[https://en.m.wikipedia.org/wiki/1980_Damascus_Titan_missile_...](https://en.m.wikipedia.org/wiki/1980_Damascus_Titan_missile_explosion)

<comment><USER21> It's somewhat impressive that the actual nuclear warhead didn't so much as leak. Which is what's supposed to happen but still you don't usually design something to withstand a botched missile launch capable of 'catapulting' a 740 ton door.

<comment><USER22> There wouldn't be much to 'leak'. The nuclear material in weapons is relatively safe to handle as long as you don't ingest it. It's the post- explosion fission products that are nasty.

Also with nuclear weapons, as much engineering has gone into safety as into weapon design itself. It's astronomically improbable for a modern nuclear weapon to detonate prior to arming even if the explosive lens is set off.

The reentry vehicle is designed to come down at circa mach 14 so a little bit of heat and jostling isn't going to bother it.

Cool video about some of the engineering involved: [https://www.youtube.com/watch?v=97t7Xj_iBv0](https://www.youtube.com/watch?v=97t7Xj_iBv0)

<comment><USER23> The word "safety" in connection with nukes has been redefined to mean "it blows when you push the button". So the DOE's responsibility to maintain the "safety" of the arsenal sounds much better than it is.

Not blowing up when you don't push the button doesn't have a name.

When they actually dropped a pair by accident from a B-52, both got very far into their ignition sequence before something failed. Questions were Asked, after. So it is probably better now. Here. Russia? Israel? India? No telling.

<comment><USER22> You're talking about an incident involving a mark-39 bomb which was built in the 1950s, the same time period when USA ran reactors with a man wielding an axe to cut rope to drop control rods as an emergency shutdown measure.

We have come a long, _long_ way since then in nuclear safety both in weapons and reactors.

<comment><USER23> Who is "we"?

Does it include Rick Perry? You are aware that the supposed secret "nuke launch code" was seventeen zeroes?

<comment><USER22> The code you're talking about is the final step in a long sequence of events that requires positive authorisation from 6+ individuals from the president down.

By the time you've punched in the code, whether it's an OTP or seventeen zeroes, you've already committed a missile to a target and you're already 100% going to go through with the launch because two missile combat crew members turned their keys.

Russia doesn't even bother with these kinds of codes. Their second strike capability is fully autonomous and will launch even if all of c&c infra is destroyed.

This also has absolutely nothing to do with the mechanical intrinsic safety of the actual nuclear weapon during a fire or the RV that carries it. Which is the original topic at hand. The code is just an extra step to arm the weapon. The physical safeties are there to 99.999% guarantee that the weapon will not detonate unless armed. Even if you try really really hard to detonate it.

More thinking has gone into each tiny element of this process including the kind of paint used on bombs, than you have given to the topic as a whole.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><AUTHOR> It looks as if not only the bulkhead got separated but also the top-most ring where it was attached. I don't remember right now how that section looked, but maybe it was not the bulkhead at a fault but the seam between the first and second ring from the top.

<comment><USER24> I agree that's what it looks like. Interestingly, during fabrication, the bulkhead was attached to the ring, and then the whole ring was lifted up and welded on. Maybe there was interaction of the heat affected area from the two welds? The bulkhead was welded only ~100mm up from the bottom of the ring.

</comment></comment><comment><USER25> During prototype tests you don't have to target 6-sigma, obviously, but I hope we get a post-mortem without spin.

<comment><USER26> When their entire business depends on very carefully managing their PR, you're not going to get a public post-mortem without spin.

If a government regulator runs the investigation, you might. I don't know if a regulator's going to get involved in this, though.

<comment><USER27> > When their entire business depends on very carefully managing their PR

You really think this? My perception is that their PR is fairly blunt and upfront. while they may not tell you _everything_ they dont seem to be trying to "spin" anything

<comment><USER28> >they dont seem to be trying to "spin" anything

Compare their statements about the cause of the CRS-7 explosion to NASA's.

<comment><USER29> I dug around and didn't find an official SpaceX statement. The cause was a poorly constructed struct they bought from a 3rd party company.

> Compare their statements about the cause of the CRS-7 explosion to NASA's.

Did NASA's and SpaceX's statements differ in content?

<comment><USER28> SpaceX statement: [https://www.spacex.com/news/2015/07/20/crs-7-investigation-u...](https://www.spacex.com/news/2015/07/20/crs-7-investigation- update)

NASA accident investigation report: [https://www.nasa.gov/sites/default/files/atoms/files/public_...](https://www.nasa.gov/sites/default/files/atoms/files/public_summary_nasa_irt_spacex_crs-7_final.pdf)

TBF the NASA report came much later than the SpaceX explanation. However it might be of interest to compare:

SpaceX explanation of why looking at the right telemetry is hard vs "Technical Finding 4" from NASA.

SpaceX explanation of the strut's "certifications" and max load vs "Technical Finding 1" (and the longer explanation earlier in the document, you can do a control-f for "Where the IRT differs with SpaceX is in regards to the initiating cause")

<comment><USER30> "SpaceX chose to use an industrial grade (as opposed to aerospace grade) ... cast part"

Hmm.. Isn't this a common cost-cutting strategy for Musk's companies? The touchscreen in the Model 3s was (is?) also industrial grade, if I recall correctly.

<comment><USER31> > The touchscreen in the Model 3s was (is?) also industrial grade, if I recall > correctly.

Isn't that exactly what it should be? Or would you expect aerospace grade material there? Or is there yet another grade in between called 'automotive'?

<comment><USER32> Yup! I think the common electronic tolerances go: commerical, industrial, automative, military, aerospace, and then space, though I may be missing one or two.

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER33> If you go back a couple hours in the linked live feed you can find the event pretty easily. Look for the big plume in the preview when you hover over the progress bar. About 1:50 ago at this working writing. I guess it would have been around 1540 EST.

<comment><USER34> Looks like the welds holding the bulkhead on failed.

For those who aren't keeping up with this the failure was on the Mk1 prototype. Mk2 has been build nearly in parallel with Mk1 and will take over early flight testing (20km hop). Elon has tweeted that this team will jump to Mk3 instead of trying to repair Mk1.

<comment><USER35> Airliners rarely use welds because they're very hard to make with consistent high quality and are also very hard to inspect. Instead, they're riveted together.

<comment><USER36> There are airplanes constructed with chemical bonding as well, such as the Boeing 787 Dreamliner and my personal favorite, the AA-1, released in 1967! Welded airplanes are practically nonexistent, but there are techniques other than riveting. And with the rise in popularity of composite materials, we're likely to see fewer and fewer rivets on airplanes.

</comment></comment></comment></comment><comment><USER37> Comment from Elon Musk: [https://twitter.com/elonmusk/status/1197271943180771329](https://twitter.com/elonmusk/status/1197271943180771329)

Official SpaceX statement: [https://twitter.com/thesheetztweetz/status/11973066177605591...](https://twitter.com/thesheetztweetz/status/1197306617760559104)

</comment><comment><USER38> I don't know the specifics of this particular setup, but aren't pressure vessels usually tested hydrostatically.

Water, for example, can be pressurised without actually compressing, and therefore doesn't undergo rapid expansion when a failure occurs.

There may be reason that precluded pressure testing with a fluid tough.

<comment><USER39> Compared to the fuels that the vessel is designed to carry, water might as well be liquid lead. It would easily crush the structure before you got enough in there to do hydro testing.

Edit: correction, looks like they're using methane/LOX. Methane is 422g/L and LOX is 1141g/L (compared to water at 1000g/L). If it was the LOX tank then they could have probably hydro tested it. Not so much with the CH4 which is probably the upper tank? It also bears mentioning that they would want to test at the appropriate temperatures. Water isn't great for hydro testing at LOX/liquid CH4 temps.

<comment><USER40> How do you "hydro" test it at cryogenic temperatures, where physical properties of the vessel material are markedly different?

</comment></comment></comment><comment><USER41> Just another test.

However...

To me there is an issue with large diameter pressured tubes - the point where the tube connects to the top is affected by the surface area divided by the diameter. Obviously one of those scales linearly, and the other squared.

That suggests to me (I'm definitely not a rocket scientist!) that the upper bound might be smaller than this diameter, or the weight will have to increase in order to beef up the strength of this point.

Pretty interesting problem to deal with now that they are this far into the design. I'm sure there are many possible solutions, and it will be fun to see what they come up with.

</comment><comment><USER42> Nothing blows up means you aren't innovative enough.

</comment><comment><USER43> I think it's good. Better to find the flaws now and do a resdesign, instead of having astronaughts being blown out into space ;)

</comment><comment><USER44> They should opt for a single block of stainless steel carved into a rocket as a unibody design for added strength.

<comment><USER45> Not the whole rocket obviously but milling the tank from a whole block has been done.

</comment></comment><comment><USER46> I haven't seen an mention if anyone was injured. Was there someone on the cherry picker?

<comment><USER47> You would never have people around when doing high pressure ops. This might even have been a proof test, where the tank is pressurized to test for leaks so something like this failure is a plausible scenario.

</comment></comment><comment><USER48> Whoever gets in that thing is spam in a can /s (quote from the right stuff)

</comment><comment><USER49> Does fail early apply to Space tech development?

<comment><USER50> It's worked fairly well for SpaceX so far...

</comment></comment><comment><USER51> "Was that the primary buffer panel?"

</comment><comment><USER52> for some reason i feel like im watching a 2nd grader's baking soda volcano project. i guess it's the perspective of the camera, or im not accustomed to the looks of prototype rockets, but to me it looks like a paper mache diorama

<comment><USER53> Starship looks particularly shoddy because it's made from relatively small steel plates welded together. The welding process causes each plate to warp slightly, so the end result looks like a quilt rather than a nice uniformly smooth cylinder. Most rockets don't look like this. Most prototype rockets don't look like this either.

The argument has been that this is good enough to start testing structural features, and probably also good enough to do a little bit of low-stress flying as well. The first argument seems sound. I'm not so sure about the second... there are a _lot_ of welds. At least a few of them are likely to be structurally unsound, and assessing weld quality is difficult.

In any case, for the "real" Starship, they plan to use a technique similar to the one they use on Falcon, where they roll a huge metal plate and then stir- friction weld along the seam. This kind of tooling is difficult and expensive to set up, and the configuration of the machinery and the material depends a lot on the actual design, which hasn't been finalized yet.

Apparently they're using thicker steel then they plan to use on the monolithically constructed version to compensate for weld quality, but I don't know... weld seams are great stress concentrators, and stress concentrations are where fractures are likely to form, and fractures on the skin of a rocket are usually catastrophic failures. All it takes is one defect.

</comment></comment><comment><USER54> The front fell off!

</comment><comment><USER55> Aren't pressure tests done with water?

That way, since water is non-compressible, if it fails, you just get a small hole or buldge somewhere rather than the catastrophic damage seen here.

Perhaps they already tested with water and now needed to test with the real fuel/oxygen to get the temperature correct?

<comment><USER9> Is it strong enough to take a full tank of water? Liquid methane weighs less than half what water weighs.

<comment><USER50> Liquid oxygen weighs more than water though...

<comment><USER9> True, although only slightly. Of course, it also wouldn't be trying to take off with a full tank of water and you'd expect it to pull at least 2G during takeoff (do we have an actual figure?) so I'm guessing the answer would be 'yes, it could take it'?

</comment></comment></comment></comment><comment><USER56> This integration test is _way_ too late to be finding faults like these. This is top down design, which is expensive an error prone. The ship should be designed and tested in a bottom up fashion, such that the failure modes of every individual component is already known, as per Feynman. SpaceX is repeating the mistakes of the Space Shuttle program.

</comment><comment><USER11> There was a post on HN a few days ago about how SpaceX got a full examination, while Boeing more or less got a pass from Nasa. This is a different vehicle, but it gives an idea of the maturity of SpaceX. And yes, the earlier story was really more about trying to establish a pattern around the 737 Max failure, but that issue was at least complicated. This is just sloppy.

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

</comment><comment><USER57> I had an unpopular opinion amongst friends that this thing looked like a total piece of shit, like a movie prop. They were using rented lifts and cranes to assemble it in the field. Clock right twice a day or maybe there's a reason everything about Apollo spacecraft was meticulously assembled.

<comment><USER58> I wish more smart people like you worked there.

<comment><USER59> Yes because without this dude they would've never invented self landing reusable rockets</comment></comment></comment>


What Repubs and Dems Can Learn from "The Myth of Millionaire Tax Flight" - <AUTHOR> http://www.taxpolicycenter.org/taxvox/what-republicans-and-democrats-can-learn-myth-millionaire-tax-flight <comment><AUTHOR> tl;dr:

> While everyone seems aware of a handful of high-profile millionaires > decamping to low-tax states for tax reasons, in truth few move in response > to state tax rates. Young examined tax data from every millionaire in the > United States over thirteen years. He found that, even over that long time > horizon, only 0.3% of all millionaires, on net, moved to a lower tax state. > A larger share—about 2.5 percent-- move from one state to another each year, > but most do not migrate for tax reasons. [...]

> While blue states are changing tax policy [SALT deduction workarounds] in > response to what is largely a myth, red states seem blind to the very real > consequences of their tax and spending policies. There, years of tax cuts > (often tilted toward higher-income households), along with balanced budget > requirements, have created funding crises in their education systems. Red > state budgets tend to be very regressive – giving benefits to the already > well off at the expense of others, especially the poor. But as Young points > out, "cutting funding for education to finance tax cuts for the wealthy is a > classic intergenerational transfer from the young to the old." As such, the > policies ignore who really is mobile across state lines: young people, who > are leaving red states in droves: "The most mobile people in the country are > young college graduates – who have annual cross-state migration rates four > times as high as millionaires (12 percent versus 2.5 percent)."</comment>


4 Reasons I use large type to optimize user experience - <AUTHOR> http://mikeyanderson.com/optimal_characters_per_line

<comment><AUTHOR> I've had this design for about a year and a half. It seems like many of the blogs here are taking the same route so I figure I'd share why I did it. Let me know if you think it's helpful.</comment>


TypeScript Complex Runtime Validation - <AUTHOR> https://github.com/gao-sun/power-guard <comment><USER2> Any idea on how it compares to `zod`?</comment>


Ask HN: A good slide-deck for HTML? - <AUTHOR>

Hi, I am a senior student in a tech institute and I will be organizing a small talk to introduce freshmen to HTML and CSS. Can someone please suggest me a good slide-deck that I can use/refer to? <comment><USER2> <http://dontfeartheinternet.com> \- these are videos on the basics of HTML and CSS.

Good luck!

</comment><comment><USER3> <http://www.slidedeck.com/> ?</comment>


Third Nokia lawsuit accuses Apple of multiple patent violations - <AUTHOR> http://www.appleinsider.com/articles/10/01/04/third_nokia_lawsuit_accuses_apple_of_multiple_patent_violations.html

<comment><USER2> Remember when Steve Jobs proudly introduced the iPhone and said "works like magic…and boy have we patented it"?

Apple plays very nasty on the IP front, so I can't muster any kind of sympathy for them.

</comment><comment><USER3> I'm sure nokia doesn't give a damn about my one-man boycott but they can take their lawsuits and shove them...

If their answer to the Iphone is a lawsuit instead of a better phone then they've just admitted they stopped being a contender.

I'm pretty brand loyal, I've had nokia phones for more than a decade now with one very brief excursion in to samsung land.

It's a pity, Nokia used to command some respect because of the quality of their product, the quality has steadily gone down over the years (the old stuff _NEVER_ crashed or froze) and now they're turning in to a milk-the- patents shop.

<comment> Tuna-Fish Nokia did most of the legwork for developing cell networks early on. Everyone else is paying them for using their patents. Why not Apple?

<comment><USER3> Everybody else is paying the mobster, why don't you ?

That's a bad argument.

If Nokia had a leg to stand on they would have sued apple the day they first released the iphone. Now that Nokia is losing in the marketplace they want a piece of the pie.

I can't wait until we reach the 'lawyer event horizon' when progress outside of open sourced hardware and software grinds to a messy halt because all the time and money is taken up with lawsuits.

The phone was an invention worth patenting, the cell phone is variation on a theme, and the research that went in to it was largely funded by the public.

 _LONG_ before Nokia got in on the act cell phones were a reality, it's true that the current crop is a serious improvement over what was available at the time but we're talking incremental improvements here.

In the name of interoperability that stuff got standardized, after that point you compete in the marketplace, patents should get tossed out.

Otherwise patents become a measure to control the competition instead of a device to foster innovation.

<comment> Tuna-Fish > Everybody else is paying the mobster, why don't you ?

The patent system is set up so that innovators (like Nokia) share their research in exchange for a limited time monopoly on the fruits of that research. You can argue that the system is fucked up, but if Nokia hadn't been promised that monopoly, they probably wouldn't have shared all that research. They did, and now companies like apple can make phones with no need to do basic research, instead letting them concentrate on building UI's and such. This is how it works, and this is how every other phone manufacturer in the world is comfortable with it working.

> If Nokia had a leg to stand on they would have sued apple the day they first > released the iphone.

Not only do they have a leg to stand on, they have successfully defended many of the patents in question in court in previous cases. And why didn't they sue earlier? I'd be ready to bet you a lot of money they have been in talks with apple all this time trying to make a deal without having to resort to a legal battle.

> I can't wait until we reach the 'lawyer event horizon' when progress outside > of open sourced hardware and software grinds to a messy halt because all the > time and money is taken up with lawsuits.

Or then, people who clearly use other people's research to build stuff could pay for it without wasting time taking stuff to court like _every other phone manufacturer does._

> The phone was an invention worth patenting, the cell phone is variation on a > theme, and the research that went in to it was largely funded by the public.

The cell phone was not worth patenting? Please. There is ridiculously lot of manhours spent in thousands of little details that had to be worked out so that lots of people can be served over limited radio channels in a noisy environments. And, while it's true there was a lot public funding early on, there were also many private companies spending a lot of money getting basic research done, including, but not limited to, Ericsson and Nokia.

> LONG before Nokia got in on the act cell phones were a reality, it's true > that the current crop is a serious improvement over what was available at > the time but we're talking incremental improvements here.

Actually, Nokia has been in mobile telephony since NMT, and when things got digital they were on the leading edge -- for example, the first ever commercial GSM call was made on a Nokia phone in 1991.

> In the name of interoperability that stuff got standardized, after that > point you compete in the marketplace, patents should get tossed out.

Or, people could agree on fair terms to licence each others patents like the cell phone manufacturers decided. Nokia pays other people for using their patents.

> Otherwise patents become a measure to control the competition instead of a > device to foster innovation.

When you refuse to license them for reasonable terms, that's exactly what happens. Good thing that's not what Nokia is doing.

</comment></comment></comment></comment><comment><USER4> Looks like a lot of hardware patents in there. Personally, I think Apple is going to be having a tough time, but IANAL so let's see what happens.

</comment><comment><USER5> If only all this money paid to the lawyers goes to R&D and marketing to make the Nokia products better.</comment>


"Like Cardboard": The weird new Domino's ads that bash the company's pizza. - <AUTHOR> http://www.slate.com/id/2241113/

<comment><USER2> Domino's Pizza is pulling down some major good press by basically trashing their own product and then engineering their own comeback. As an indication of how much traction they've gotten, I was reading a political article the other day -- some rant about something-or-another -- and the author's thesis was how the subject compared to the Domino's Pizza ads.

Kudos to Domino's for such a unintuitive yet highly effective campaign.</comment>