I get the reference, but what I came to say is... Of all the companies that I can think of, I would say Lego is most vulnerable to a 3D printing boom. It may start with printing replacement pieces. It'd be a long slow decline though, a la CD, as I can't see 3D printers becoming ubiquitous that soon, nor can I see them being capable of producing all the pieces (transparent plastics, etc).

If I were Microsoft, I would just charge the customer an extra 30% on top of whatever base price I wanted to charge. If the customer asks, "Hey, why is this so much more expensive than on the Windows app store?" explain to them how Apple's pricing works.

What's preventing me is that the person at the other end doesn't use Skype... hence the network effect. You have to use what other people on the network use. Skype is a good example of the network effect, which is the point I was trying to make. It's not a good example of Apple abusing the network effect; I was not trying to make that point.

What scares me about proliferation is: while for rational people mutually assured destruction means nukes are unlikely to ever be used, when it comes to religious people, reason takes a back seat. (Or, if you want to be charitable, the premises from which they reason are extremely pliable.) FWIW this is also increasingly an argument against the USA having nukes.

If I could figure out how to install Facetime for Android, we could continue the discussion face to face.

The network effect is where you need to use (random example) Skype because everyone else you need to talk to uses Skype, and Skype is not built on open standards in a way which would allow you to use an alternative.

Incidentally, if it keeps prompting you for a password that you keep cancelling, the answer is apparently to delete all stored web content... in Safari. (It worked for me.) Whether or not it is good that other applications apparently have unrestricted access to your Safari cookies is left as an exercise for the reader.

I invite you to submit it to the prestigious Journal of Universal Rejection for peer review.

Add a stylus and some handwriting recognition, then invent some kind of adhesive micropayment system and a physical distribution/collection network, and it could be used as a high latency message transmission system?

"The problem with these (untested, speculative) solutions"

I'm not sure they're untested or speculative; they're all in use somewhere, but because we're not required to use them, we don't. Whether in combination they'd yield a greater quantity of robust, higher quality code is speculative, but given that the status quo ain't working, I'm open to alternative suggestions.

"Notice how your own solutions, for example, do nothing to address the installation/deployment issues spoken about in the fine article."

True - I'd broadened to software engineering in general. OTOH, if there were an accepted, stable, boring but well defined API for installation, tested and hardened over the course of 50 years, I'd expect fewer issues. E.g. .deb means I can write an installer (for one system only, which is the tragic part) without having to devise my own, and without understanding how it works internally, only the options it gives me (i.e. its API).

"languages/tools can't do everything: to get better code, you ultimately need to get better people"

On this specific point, the point of code reuse is that
(a) people would write less code, so they wouldn't need to have as much engineering wisdom as otherwise; in my experience the average coder works better in the constraints a framework than when given free reign. If nothing else, it gives them time to learn without fubaring things fundamentally and leaving spaghetti in their wake.
(b) the code gets better over time, meaning less need to fork off and write new code
(c) if they were writing new code, they'd be encouraged to reuse an existing API written by their betters, which is the hard bit

I would expect the tests to be part of the public API, possibly augmented by third party tests. So while I could provide stubs, they would be there for users of my API to see. They would no doubt judge the quality of the software I've provided accordingly.

I frequently remark to my colleagues how bizarre it seems to me that after 50 years or so of software engineering, we're still building awful crap. If we were architects, we'd be unveiling skyscrapers built using favela techniques of plugging any old crap together, in the mud, next to a river.

There are lots of reasons, but the two big ones I'd say are time pressures (which we as programmers will never be able to resolve) and a lack of code reuse (which we can resolve). For example, the constant churn of technologies to me is simply a failure to reuse code.

I would start by trying to engineer whole classes of faults out at the language level, as has been done with buffer overflows and garbage collection.

Make static analysis much more anal, forcing the programmer to express their intent up front - static types, constraints, etc. Make the compiler a totally pedantic Nazi. Sure, it's nice to be able to hack shit up in an afternoon in Python or whatever, but then it ships, and the bugs come in, and you end up adding a pile of asserts and whatnot that should have been caught way before the product shipped.

Make unit/integration testing a mandatory part of the build, i.e. the compiler/linker refuses to link with code that hasn't been marked as tested.

If we learned to put the hard thinking and effort into designing APIs, and then reusing those same APIs across whole new classes of problem (because the language makes defining APIs is such a hassle that we'd rather not dream up new ones left and right), I think things would improve massively. Forcing the APIs to be public, but allowing the internals to be as obscure and proprietary as you like, would allow for reuse, interoperability, and hopefully improvement (by replacing particular implementations of APIs with better ones). Add a sane API mechanism for backwards compatibility, so that when you realise the API is fundamentally bad, you can or are required to implement the old API in terms of the new, and you don't just abandon people to DLL version hell. A language could provide support all of these things.

None of this would stop you from writing shitty code. But at least, to do so, you'd have to knowingly subvert the compiler in a bogus way, ignoring screeds of the compiler telling you that you and your code suck goats' balls.

Is there a patent on administering electric shocks every time there's a build error?

"Do we know that reducing the CO2 level in the atmosphere - by whatever means necessary - will reverse or start to reverse climate change?"

If we're driving towards a cliff, do we know whether braking will prevent a crash? If we don't know, does that mean we shouldn't brake?

We know that accelerating our greenhouse gas emissions will kill us all.

Hans Reiser?

Here's an article from the Guardian (UK) about the "end of work" and work trends:

http://www.skidelskyr.com/site/article/why-we-need-weekends/