You mention the wiki page is badly written, and I have the same feeling whenever I read about anything mathematics related on it. But... it's written by volunteers, so I'll take what I can get. Since you obviously have the talent for explaining things, do you think the wiki page could be edited and improved for clarity?
I have thought about it, but I always worry about making large edits to Wikipedia pages that I'll put a lot of work into it and then someone will come along and just revert it. Maybe that fear is unfounded - I'll put it on my (very long) todo list!
I disagree with both points, in fact with every statement you made. Correctness can be achieved without use of exceptions (whether this is easier or harder to do is up for debate). Next, in some cases correctness may be sacrificed for performance reasons (e.g. solving a traveling salesman problem). I find it easier to properly handle unexpected error codes than unexpected exceptions. C++ has other strong sides beside performance. Java/C# often throw exceptions in very non-exceptional cases (e.g. .Net's File.Delete method).
Nope, there's no practical way to cover all possible cases. There is always a possibility of a totally exceptional situation arising (we're only human). And then your beautiful ole error-cods returnin' function either takes down your whole application (which might result in someone dying while on life support in a hospital) or plods on with a successfull error code (leaving your program in an incorrect state). All because you didn't have a catch-all-exceptions clause.
This is why I find C++'s "nothrow" a joke, by the way. It's not within human power to guarantee that any piece of code never throws exceptions. A gamma ray might flip a bit. You never know. The only practical way to reliability is the Erlang way: be prepared for errors arising anywhere anytime, not rely on fallible notions of what can and cannot cause errors.
There is a difference between preventing a program crash and handling errors. Please don't use catch-all-exceptions clause for either, especially not in hospital machines.
The difference between writing if (status != SUCCESS) and catch (Exception) is that the former will allow the program to actually crash when it should (see panic in Rust). You should not be able to recover from OutOfMemory or GammaRayFlippedABit errors (use ECC memory to prevent that). You should restart the process (or the entire machine) because you can't hope the developer was wise enough to destroy and recreate appropriate amount of state.
The additional problem with exceptions in Java and C# is that many times you don't care about failure of some operations, but the language practically forces you to write catch-all statement to prevent a program crash, so you end up accidentally catching unrecoverable errors.
> there's no practical way to cover all possible cases
This is something that can be enforced by the language, it's just that C doesn't do so. The Zig language does, though. The result is somewhat similar to conventional exceptions. [0]
It would be possible to do the same in C if a convention were used that could be verified by static analysis. I don't know if this has ever been implemented, though.
> And then your beautiful ole error-cods returnin' function either takes down your whole application (which might result in someone dying while on life support in a hospital) or plods on with a successfull error code (leaving your program in an incorrect state).
That's not an accurate account of how critical systems are written.
Plenty are written in C, which has no support for exceptions. Some are written in the SPARK language, a subset of Ada, which essentially forbids the use of exceptions. [1]
> This is why I find C++'s "nothrow" a joke, by the way. It's not within human power to guarantee that any piece of code never throws exceptions.
That's not right. Code written in C is guaranteed never to throw an exception, as the language doesn't support them. Error codes have to be used. Code can still go wrong, and can even produce undefined behaviour, but exceptions are never raised.
I'm not very knowledgeable on the particulars of nothrow and noexcept in C++ though, I have to admit. From a quick glance, it seems that it does provide a hard assurance that a noexcept function can never throw. If a noexcept function tries to throw, the effect is to call std::terminate. [2]
> A gamma ray might flip a bit.
That won't throw an exception, it will just flip a bit. Radiation-hardening is handled by hardware, and perhaps by replication, but not by software. [3]
> The only practical way to reliability is the Erlang way: be prepared for errors arising anywhere anytime, not rely on fallible notions of what can and cannot cause errors.
Again, that certainly isn't the only way. C and SPARK are both used for life-or-death code. No-one will ever write avionics software in Erlang.
> Even if reCAPTCHA was perfect, a hacker could manually validate their usernames of interest by trying to sign up, then automate an attack on the sign in page.
Why is imperfect reCAPTCHA worthless? Do sign up pages even allow brute forcing of usernames (once validated)?
Is he suggesting to fix sign up pages, or to allow brute forcing usernames on login?
His writing style is dramatic, but the arguments are very weak.
If this is one of his worst, I must read the rest. You are unsatisfied with an essay that is merely of correct reasoning, can you recommend some even better reading material than this?
Typically, yes. One of the most frustrating things about Reddit is the neverending cliched references. It's why HN comments are so much higher in quality.
> It's why HN comments are so much higher in quality.
Not always the case. Sometimes just boring. More relaxed attitude on reddit attracts more diverse expressions and sometimes that can be a bad thing, but sometimes it is a good thing.
You're absolutely right, it can be both good and bad. What's great is that since both Reddit and HN exists, there is space for both and no need to compromise on either side : relaxed on Reddit and high quality on HN
Wiki shows Algorithm R, this article talks about Algorithm D, both by the same author.
The former is well known, while the latter is more obscure. This is probably because the extra complexity of Algorithm D is rarely necessary. If k and n are on the same order of magnitude, there is not much difference, and if k << n then simple random sampling would work nearly as well.
My Philosophy of Computer Science professor argued that you could prove anything was Turing complete, by suitably "gerrymandering the inputs" of your definition.
What that actually means, I'm not sure. I know how gerrymandered congress is, and they couldn't possibly get enough work done to be Turing complete.
Can anyone explain the gradient merging example? If we sum an image in which luminosity is linearly rising from left to right with the image in which the luminosity is linearly rising from top to bottom, then the result should have constant luminosity across bottom left - top right diagonal. So we shouldn't see a circle effect in the top left corner, but rather a rotation of first gradient by +45 degrees. Or are the gradients not linear in luminosity? Or are you guys not seeing the circle effect? It does looks quite different on my other monitor, but I can still clearly see a circle instead of topleft-bottomright linear drop in luminosity on the left example.
I see a circle effect in the "correct" merge and don't see one in the "incorrect" merge. My guess is that the gradient is linear in sRGB values, so if you merge in sRGB space (incorrectly) then you get a rotated, sRGB space linear gradient.
Of course you need to log some data in textual format for emergencies, but if you had a tool that indexes events on timestamps, servers, monitorees, severity and event type, while severely reducing the storage required, you would be able to log much more data, and find problems faster. Arguing binary vs text logs is like arguing serial port vs USB on some industrial systems.
