Earlier quoted context omitted.
Agree. Plus plenty of labor has gone into customer facing bugs that autos, hw, consumer electronics etc prob wouldn't stand for. And we build on hw which is formally verified.
> And we build on hw which is formally verified. Ehm, what?
How Did Software Get So Reliable Without Proof? (1996) [pdf]
121–126 of 126 posts
Re: How Did Software Get So Reliable Without Proof? (1996) [pdf]
#122Formal proofs are useless because most systems in the real world are far too complex to be formally verified. The formal proofs for most systems would be so long and complex that they would be almost guaranteed to suffer from human error; the proofs are much more likely to have errors than the underlying code itself. It is a tool invented by bureaucrats for the sole purpose of job creation. If society keeps becoming…
Re: How Did Software Get So Reliable Without Proof? (1996) [pdf]
#123It didn't - but most errors are simply tolerated because imperfect automation still has absurd economy of scale, very few applications are on a regulated field or have a well-defined quality standard to meet, and unreliable software tends to at least fail consistently, so it's still a win to diagnose and fix processes compared to humans making creative mistakes.
> because imperfect automation still has absurd economy of scale That's what FULL AFK botting in games taught me, kinda random % values, so in my experience it was Automating 80% of stuff is easy, can be done in 1h 90% is starting getting tricky 95% requires you to spend days of testing and writting various scripts 100% is additionally limited by BOT API and would require you to write your own stuff and talk to bot v…
Re: How Did Software Get So Reliable Without Proof? (1996) [pdf]
#124Because reliable and proof are not the same concepts and one is not needed for the other. Proof is logical certainty for all time ( in the past, present and future ). Reliability is not. Reliability doesn't require mathematical proof - this goes for airplanes to your kitchen faucet to software. Software became more and more reliable through testing, errors, fixes/patches, etc. Also, many times good enough is good eno…
Re: How Did Software Get So Reliable Without Proof? (1996) [pdf]
#125Earlier quoted context omitted.
For algorithms without provided proof, we can only estimate their correctness based on how battle-tested they are. If an algorithm has been run many times and it has been correct every one of those times, then we feel somewhat confident that we got it right. Over time, we'll find weird edge cases where it doesn't work, and fix them. Few algorithms are as battle-tested as the sorting algorithm from the Java standard l…
> even software that's this battle-tested is still not fully reliable But does it matter? I also don't understand formal methods well, but wouldn't they also be subject to bugs? It seems like all we can do is make software less unreliable.
That depends on the application. It probably doesn't most of the time. My point is not that it is always economical to use formal methods, just that I suspect their cost is overestimated compared to the benefit (because most programmers are simply unfamiliar with FM).
> I also don't understand formal methods well, but wouldn't they also be subject to bugs?
Yes, they are. There are multiple classes of errors FM are vulnerable to.
1. In FM you prove your code correct with respect to a specification. But you can make errors in the specification too. The arguments for FM are: a) the spec is much smaller than the program, so the opportunity for error is lower, and spec errors are more obvious; b) often if your spec is wrong, you'll find out when you try to prove your algorithm; and c) combining testing with FM is very likely to uncover whatever errors are left.
2. If your proof of correctness is not mechanically verified, then you may still have trivial implementation errors like mixing up variables and the like.
3. If it is mechanically verified, then theoretically there's still opportunity for errors. The verifier might contain a bug, the compiler might contain a bug, the hardware you run the algorithm on might contain a bug, cosmic radiation may flip a bit during the verification/compilation process, invalidating the correctness, etc. I can soapbox about the implications of this but I will only do that when prompted to :)
So indeed, there is no method that gives you zero probability of failure. But you can get the probability orders of magnitude lower, which may be worth it depending on what you're working on.
Re: How Did Software Get So Reliable Without Proof? (1996) [pdf]
#126Earlier quoted context omitted.
> because imperfect automation still has absurd economy of scale That's what FULL AFK botting in games taught me, kinda random % values, so in my experience it was Automating 80% of stuff is easy, can be done in 1h 90% is starting getting tricky 95% requires you to spend days of testing and writting various scripts 100% is additionally limited by BOT API and would require you to write your own stuff and talk to bot v…
Which games, out of curiosity? Sounds like a whole new way to enjoy games.
Some random thoughts because I'm kinda busy
Game is great and insanely addictive(seriously, I can talk about this more if youre interested), but community on private servers is insanely toxic and uneducated (I don't really like saying this like that, but seriously that's something you tend to do not experience in other games) due to... well, that's interesting topic.
This game has relatively high entry level because it's like 23 years old game which has A LOT of content, even more if you do not use spoilers for quests/missions.
If you don't play on private servers, then you have to buy "premium account" to be able to play the game to its full potential which costs like 10 euro for a month
Dying in this game is very punishing, but it used to be worse like decade ago because nowadays you can buy ingame_currency relatively cheap. Dying decade ago without "protections" could waste your like 2-3 hours of exp and some items, add to that fact that you can be killed on PvP servers by anyone "just because" :P
This game is also interested from programming perspective -
Private servers are an initiative by programmers to recreate this game engine and host their own server. Nowadays it's mature.
One of the most popular private server engines: https://github.com/otland/forgottenserver
It's really impressive project.
When it comes to botting FULL afk scripts
You have to write code which goes to the exp place, don't get stuck somewhere, exp there for a hours (using spells, drink health/mana potions, take loot from corpses, run on the more or less complex spawns (map), go back to the city if you don't have potions, sells loot, take cash to the bank, and repeat
Many things can go wrong during that cicle - like other played blocked your "road" to the exp for 1min, or you character just died due to PK(players), lag and maaaaaaaany other.
Your script has to consider a lot of those different conditions and trade offs (sometimes you don't want to kill monsters that are between your city and your spawn because it would take 10min, so you just want to run through them, but you can get "trapped" (sorrounded) by them, so you have to consider this)
It's not easy to do this good enough that you can start bot on VPS and it will running for a day, week or something similar.