crdoconnor

>The one advance that might finally challenge the 'no silver bullet' rule is machine learning.

Definitely not. Machine learning is up there with 2012's nosql movement as one of the most overhyped silver bullets.

The improvements to programming over the last 30 years have been incremental more than anything in spite of the hype cycles of various silver bullets (OOP, functional programming, side effect free code, TDD, nosql, static types, etc.)

30% is not nearly enough. It's still a free lunch for property/landowners.

Ah I see, yes that makes perfect sense. I've used integer keys too. Sorry, I thought by non-string you meant non-scalar - i.e. the idea of using lists as keys (allowed in YAML).

JSON alternative with lighter syntax and comments is basically what I tried to make StrictYAML.

I made it largely because I saw a disconnect with what YAML was, and what people - including me - thought it was (which is what it should be).

Don't agree with non-string map keys though... they're a complication I never saw a use for.

Have you tried writing JSON by hand or diffing it in a pull request?

The main issue I had with TOML is how much more syntactically noisy it is. Equivalent files with 2-3 levels of nesting usually become at least 50% longer than equivalent YAML.

More here : https://hitchdev.com/strictyaml/why-not/toml/

That's why StrictYAML always interprets as string unless there's a schema. Cuts out the surprise type conversions.

The fundamentals appear to be intrinsic scarcity + facilitating illegal transactions easily (circumventing currency controls, drug deals, malware ransoms, etc.).

I haven't seen much intrinsic value beyond those two things. Everything else is fluff (e.g. coffee shops taking bitcoin) or speculation.

That said, illegal transactions are an absolutely massive part of the global economy.

What's perplexing to me is that governments haven't yet reacted to this by bringing the hammer down. Realistically, if you're not involved in fluff or speculation you're probably using bitcoin to break the laws of some country.

Theranos was a fraud to consumers and regulators.

Wework isn't so much a fraud as the next pets.com waiting to happen.

Doesn't seem like it would be easy without a firehose of metadata and I doubt Google would be amenable to providing that for a competing service.

At this point to enable that kind of competition would have to have legislative protection (e.g. a law similar to the UK one mandating banks/gas/electric companies have to provide APIs).

There's a bigger ideological drive to show that taking US oil assets in the country and diverting the funds toward social programs was a dire mistake.

I always thought the fact that it described rising wages and living standards as a disease pretty clearly indicated that there was something wrong with them.

It's not just that though. It's also seen as a way of criminalising undesirables.

Metaphorically. On the first day airbus got about 100 orders and Boeing got none.

Or maybe they just don't want to buy aircrafts that crash.

The Paris air show wasn't good for Boeing either.

>To get an ICLA all legit while you are employed, run it by the legal department of the company you are employed by, and they can give you an idea if any changes to the agreement is needed (and of course, if you are allowed to spend company or private time on the project), and get it signed legally and on file for all parties involved. Done.

IME company legal departments are unlikely to indulge this kind of thing unless they owe you a favor.

Where they do, their blanket response is usually "no, now go away".

Ideally any solution to this problem should take account of corporate legal departments' aversion to extra work and risk.

There are many arguments I can think of for using docker but "standard" is a pretty poor one. Directories, bash scripts and package managers are also arguably "standard" and sufficient to install most software. We should care primarily about alleviating deployment pain - not about argumentum ad popularum.

"Shipping container standardisation" is not a metaphor for what docker is, it's marketing. Docker, of course wants to be a "standard" product. Every product wants to be that.

In my experience, it's been more like a buggy kludge to deal with applications that have isolation issues with their dependencies and unnecessary overhead for applications that don't. All with a sprinkling of marketing hype.

>And I don't think you need to be an expert to realize that full autonomy is a Really Bad Idea. All you have to do it look at how the 737MAX MCAS debacle is unfolding.

Thank you for this. Boeing's hard on for de-skilling pilots isn't getting nearly enough credit as the reason why all those people died.

This is my experience too. Realism in testing is criminally underrated while code coverage is criminally overrated.

IME unit tests can only effectively substitute for integration tests where you're testing logical/algorithmic code with simple function inputs/outputs.

I think his point might actually have been the point he made rather than the different point you made.

If there's some level of confidence you're missing when using python because of the explicit types, you'd be better off making up for it using asserts rather than additional tests.

The same reason why automating farming led to the creation of jobs: we never run out of things to do if we never run out of things to want.

shrug I meet a lot of young people without degrees doing jobs that didn't exist 10-15 years ago too (e.g. social media managers). And there are way more people with degrees these days.

I think there are other less impersonal, more policy driven reasons than robots why the middle class is being hollowed out, but it sure feels like they'd rather we believed it was robots.

>But this report presents a more nuanced view, stressing that the productivity benefits from automation should boost growth, meaning as many jobs are created as lost.

Way to bury the lede, Rory.

He is a fool who pretends to be playing one. The upper echelons of the conservative party are not at all meritocratic - you do not have to be whip smart to get there, but being personable counts. He's made enough self inflicted strategic blunders.

Nonetheless he holds a certain appeal for the upper classes in the UK. I don't think his appeal translates down to people who work for a living though.

It's also about power. There's a good book called carbon democracy about how coal naturally led to the upsurge of democracy because it was labour intensive - he who can interrupt the flow of energy controls society and coal required a LOT of people to function.

Apparently the original shift to oil (started by churchill before ww1) was done in large part because it was far less labor intensive and so it took political power out of the hands of coal miners.

I can imagine how it felt to have income, camaraderie, identity and political power stripped from you all at the same time. Not great.

This "unit tests substitute for static types" is a common straw man. Asserts catch similar kinds of bugs to static type checkers with a similar level of effectiveness and cost.

Moreover, they're typically able to do more sophisticated checks than most languages (e.g. similar to the kind of sophistication of Haskell's type system).

(yes, I know what is going to be replied... IME, they actually fail in prod vanishingly rarely)

>Of course, as your system grows, you start to want static checks

I've been working on large scale python systems for about 10 years. For me, the most cost effective checks as a system grew have been asserts.

They allow extremely sophisticated pre/post condition checking (partly helped by pythons flexibility), they're cheap to write, they don't take up much space, they catch a shit ton of bugs, they clearly highlight the source of the bug, they work together really well with higher level tests and I've almost never had them trigger in prod (so the fact that they technically could, as static type fans keep reminding me, doesn't really bother me).

For me, asserts and integration tests are what make large scale python systems a pleasure to write.

It's probably a lot more than 300 and China can turn off the tap on day one.

>Unique today. But what about tomorrow? It's not like another country can't do the same thing.

It requires the willingness to throw public money at it and depreciate the currency, decades of patience and favourable trade conditions. Technically other countries could do it but most have neither the patience, capital, time or goodwill. This may well include the US.

>There's nothing inherently Chinese about opening a factory quickly.

It's the ecosystem of factories in close quarters that creates their non-replicable competitive advantage. That includes soft capital (lots of people with experience) with hard (container shipping).

For the time being (and at least for the next decade), that is uniquely Chinese, and only the US or EU are even capable of duplicating that (and it's unclear whether they have the will).