On Saturday, 3 June 2017 at 11:18:16 UTC, Paolo Invernizzi wrote:
Sorry Ola, I can't support that way of working.
Don't take it wrong, Walter is doing a lot on @safe, but
compilers are built from a codebase, and the codebase has,
anyway, bugs.
I can't approve a "ok, do whatever you want in the
validate_input and I try to *safely* throw"
If the compiler is broken then anything could happen, at any
time. So that merely suggests that you consider the current
version to be of beta-quality.
Would you make the same argument for Python?
IMHO you can only do that if the validator is totally
segregated, and to me that means in a separate process, neither
in another thread.
Well, that would be very tedious.
The crux is:
The best way to write at good validator is to make the code in
the validator as simple as possible so that you can reduce the
probability of making mistakes in the implementation of the spec.
If you have to add code for things like division-by-zero logic
flaws or out of bounds checks then you make it harder to catch
mistakes in validator and increase the probability of a much
worse situation: letting illegal input pass.
So for a validator I want to focus my energy on writing simple
crystal clear code that only allows legal input to pass. That
makes the overall system robust, as long as the language is
capable of trapping all the logic flaws and classify them as a
validation-error.
So there is a trade off here. What is more important?
1. Increasing the probability of correctly implementing the
validation spec to keep the database consistent.
2. Reduce the chance of the unlikely event that the
compiler/unsafe code could cause the validator to pass when it
shouldn't.
If the programmer knows that the validator was written in this
way, it also isn't a big deal to catch all Errors from it.
Probabilistically speaking, the compiler being the cause here
would be a highly unlikely event (power failure would be much
more likely).
To me, pragmatic means that the B2B website has to be organised
in a way that the impact is minimum if one of the processes
that are handling the requests are restarted, for a bug or not.
See Laeeth [1]. Just handle "insignificant requests" to a
cheeper, less robust, less costly, web stack.
Then we land on the conclusion that development and running cost
would increase by choosing D over some of the competing
alternatives for this particular use case.
That's ok.
