Live data from Hacker News

“The Mess We're In” by Joe Armstrong at Strange Loop [video]

youtube.com

51–60 of 80 posts

Re: “The Mess We're In” by Joe Armstrong at Strange Loop [video]

#51

Earlier quoted context omitted.

Disclaiming liability and such is an important F/OSS norm. Of course, proprietary software will improve on this (only) if forced to by competition. The omnipresence of EULAs is a much bigger problem, though. I think the F/OSS norms are better all around.

> Disclaiming liability and such is an important F/OSS norm. Indeed. So there can be a market for companies that take on liability when serving commercial customers using F/OSS code that they have audited and that they feel exposes no more risks than they can bear. The original authors should definitely not be liable if they label their code as alpha or beta quality and do not wish to be exposed at all. They are doin…

One way or the other, the problems with software are mostly a matter of economics and incentives.

Computers and software are the way they are because of the set of tradeoffs that the market rewards.

It's certainly possible to write software with fewer bugs, that consumes fewer CPU cycles, memory, starts faster etc...: but it does less. So far, most people and businesses prefer software that does more at the cost of slower boot times, more CPU usage, and a few more bugs.

Re: “The Mess We're In” by Joe Armstrong at Strange Loop [video]

#52

Earlier quoted context omitted.

Disclaiming liability and such is an important F/OSS norm. Of course, proprietary software will improve on this (only) if forced to by competition. The omnipresence of EULAs is a much bigger problem, though. I think the F/OSS norms are better all around.

> Disclaiming liability and such is an important F/OSS norm. Indeed. So there can be a market for companies that take on liability when serving commercial customers using F/OSS code that they have audited and that they feel exposes no more risks than they can bear. The original authors should definitely not be liable if they label their code as alpha or beta quality and do not wish to be exposed at all. They are doin…

Granted, then the price of such software will skyrocket. The price people pay for most software accounts for the fact that such liability is not covered. Couple that with common software development practices, as well as time invested.

It's not merely accepting liability, there are a whole slew of changes that need to come before this, and frankly, I doubt most people would pay for that. Indeed, if people want to be covered now, they can be. They just have to pay for it.

Re: “The Mess We're In” by Joe Armstrong at Strange Loop [video]

#53
post #51

Earlier quoted context omitted.

> Disclaiming liability and such is an important F/OSS norm. Indeed. So there can be a market for companies that take on liability when serving commercial customers using F/OSS code that they have audited and that they feel exposes no more risks than they can bear. The original authors should definitely not be liable if they label their code as alpha or beta quality and do not wish to be exposed at all. They are doin…

One way or the other, the problems with software are mostly a matter of economics and incentives. Computers and software are the way they are because of the set of tradeoffs that the market rewards. It's certainly possible to write software with fewer bugs, that consumes fewer CPU cycles, memory, starts faster etc...: but it does less. So far, most people and businesses prefer software that does more at the cost of s…

I think it is mostly a lack of choice. If everybody does it then 'the market' becomes a de-facto monopoly and someone trying to do it right would not stand out in a meaningful way until it is too late. After all, all software is presented as 'bug free' until proven otherwise. Your bug free (really) software looks just as good as my bug free (really not) software on the outside.

Six months down the line, when my not so bug free code eats your data I will point to that line in my EULA that says I'm not liable. Nobody will care, after all it is your data that got lost, not theirs. The fact that your EULA does not have that line and that you offer a warranty does not count for anything until someone would be willing to pay a premium. The only people that would like to pay that premium are the ones that lost their data...

So it's an industry phenomenon. Imagine extrapolating this to buildings. Engineers claim their buildings will stand. Those engineers that talk nonsense will be sued out of business. But if they could disclaim responsibility they would continue to happily practice their borked trade and as a rule people would suffer from this. And so engineer became a word that actually meant something.

But in software 'engineer' is roughly equivalent to 'can hold keyboard without dropping it'.

Re: “The Mess We're In” by Joe Armstrong at Strange Loop [video]

#54
post #16
post #14

During the last minute of the talk, he says: "Computers are becoming a big environmental threat. They're using more energy than air traffic." Is this actually true? Sure, the average person spends a lot more time on a computer than in a plane, but still it seems crazy that they'd be comparable. Or at least the comparison isn't very relevant, because the Internet can significantly reduce people's need to travel.

Well modern aircraft are pretty efficient and probably not the top offender. However he also mentions we probably can't do a lot more with computer to reduce their power consumption.

> Well modern aircraft are pretty efficient and probably not the top offender.

It depends entirely on how much they get used! An SUV that gets driven once a year contributes less carbon than a Prius that is driven all day every day.

Comparing the aggregate numbers is obviously the only way to compare computers and airplanes anyway.

Re: “The Mess We're In” by Joe Armstrong at Strange Loop [video]

#55
post #51

Earlier quoted context omitted.

One way or the other, the problems with software are mostly a matter of economics and incentives. Computers and software are the way they are because of the set of tradeoffs that the market rewards. It's certainly possible to write software with fewer bugs, that consumes fewer CPU cycles, memory, starts faster etc...: but it does less. So far, most people and businesses prefer software that does more at the cost of s…

I think it is mostly a lack of choice. If everybody does it then 'the market' becomes a de-facto monopoly and someone trying to do it right would not stand out in a meaningful way until it is too late. After all, all software is presented as 'bug free' until proven otherwise. Your bug free (really) software looks just as good as my bug free (really not) software on the outside. Six months down the line, when my not s…

> Your bug free (really) software looks just as good as my bug free (really not) software on the outside.

No, actually, it looks a lot worse: given the same time and developers, the bug free software will do way less than the buggier software. That, or at feature parity, the bug-free software takes more time and/or requires more people, so arrives later or costs more.

I don't have any direct experience, but I suspect there are niches here and there where the market and/or regulations put a premium on no bugs. Avionics? Some categories of medical software?

Re: “The Mess We're In” by Joe Armstrong at Strange Loop [video]

#56
post #55

Earlier quoted context omitted.

I think it is mostly a lack of choice. If everybody does it then 'the market' becomes a de-facto monopoly and someone trying to do it right would not stand out in a meaningful way until it is too late. After all, all software is presented as 'bug free' until proven otherwise. Your bug free (really) software looks just as good as my bug free (really not) software on the outside. Six months down the line, when my not s…

> Your bug free (really) software looks just as good as my bug free (really not) software on the outside. No, actually, it looks a lot worse: given the same time and developers, the bug free software will do way less than the buggier software. That, or at feature parity, the bug-free software takes more time and/or requires more people, so arrives later or costs more. I don't have any direct experience, but I suspect…

Being able to sell software has precious little to do with the actual product but everything with marketing. So my crap software might (on the outside) look even better!

You can only tell good quality software from bad quality software by auditing the code, not by observing the software from a users perspective (unless it refuses even to perform the basics).

Re: “The Mess We're In” by Joe Armstrong at Strange Loop [video]

#57

I totally agree with the "abolish names and places". Why can't I just write: $ cp hash:// . and have my computer do whatever it takes to retrieve a file with this hash and copy it on my disk?

Because this blocks the very human needs for error-checking and maintaining awareness of context.

It's not like you're going to type that in. You're going to copy and paste it from somewhere. So it's just as good to use

http://releases.ubuntu.com/14.04.1/ubuntu-14.04.1-server-amd...

as

hash://b4ed952f6693c42133f73936abcf86b8

In either case, your computer can do whatever it takes to get the file. With a useful URL, you'll have a reasonable notion about what's coming down and whether it matches your intentions.

Without that, the very natural question is, "Did I get the thing I wanted?" For example, it would be easy to paste the wrong hash code.

There are other benefits, like real-time binding. A hash is going to point to a particular sequence of bits. But you may not want a particular file, but rather the best current mapping from an idea to a file. E.g., if Ubuntu discovers a an issue with their released ISO, they can make a new one and replace what gets served up by the URL.

Re: “The Mess We're In” by Joe Armstrong at Strange Loop [video]

#58
post #55

Earlier quoted context omitted.

> Your bug free (really) software looks just as good as my bug free (really not) software on the outside. No, actually, it looks a lot worse: given the same time and developers, the bug free software will do way less than the buggier software. That, or at feature parity, the bug-free software takes more time and/or requires more people, so arrives later or costs more. I don't have any direct experience, but I suspect…

Being able to sell software has precious little to do with the actual product but everything with marketing. So my crap software might (on the outside) look even better! You can only tell good quality software from bad quality software by auditing the code, not by observing the software from a users perspective (unless it refuses even to perform the basics).

Observing the software from a user's perspective is all that counts, though. Marketing is important, yes, but if you're in a niche where quality counts more because bugs cost your users money, then people will sit up and take notice, eventually.

Re: “The Mess We're In” by Joe Armstrong at Strange Loop [video]

#59

Earlier quoted context omitted.

I'm not sure if this is sarcasm or not. The usability of such an approach is terrible: humans like names, and like hierarchy. This is the same reason we use DNS instead of IP addresses. There was URN https://en.m.wikipedia.org/wiki/Uniform_Resource_Name many moons ago that is still used. A URN resolver is a software library that could convert that identifier to a URL. URLs aren't much different from URNs but they act…

> humans like names, and like hierarchy. They do, but that does not mean there should not be other ways to access data. Hashes are universal and unambiguous. There should be a way to retrieve a file given its hash. > You could create a URL scheme called "hash" but it would be hard to see how you could design a standard resolver unless it was one big centralized hash table in the sky - you still would need to, at the…

Why should there be that? You're talking about an enormous, complicated system. What's the use case that justifies the effort?

Re: “The Mess We're In” by Joe Armstrong at Strange Loop [video]

#60
post #51

Earlier quoted context omitted.

One way or the other, the problems with software are mostly a matter of economics and incentives. Computers and software are the way they are because of the set of tradeoffs that the market rewards. It's certainly possible to write software with fewer bugs, that consumes fewer CPU cycles, memory, starts faster etc...: but it does less. So far, most people and businesses prefer software that does more at the cost of s…

I think it is mostly a lack of choice. If everybody does it then 'the market' becomes a de-facto monopoly and someone trying to do it right would not stand out in a meaningful way until it is too late. After all, all software is presented as 'bug free' until proven otherwise. Your bug free (really) software looks just as good as my bug free (really not) software on the outside. Six months down the line, when my not s…

Some industries have decided that software really does matter, and go to greater lengths to make sure it works.

It'd be annoying if Things for iOS crashed and lost all of my data. It'd be horrifying if flight control software crashed and all aboard a plane were killed. It stands to reason that some software is and should be held to higher standards than other software. It probably doesn't make sense that all software should be held to the same high standard, as it is extremely time- and resource-consuming to ship avionics software. Do folks really want to dish out a few $thousand for a copy of Things for iOS?

And some companies do already take responsibility for open source software. In aerospace development, we routinely use GNU software that has been thoroughly inspected and certified as good by companies that accept many thousands of dollars to stand behind it. (Of course, if we were to upgrade from their GNU Foo 2.1.0 to the FSF's copy of GNU Foo 2.2.0, then all bets are off.)

Post reply on HN