On Monday, 18 November 2013 at 22:17:16 UTC, Jonathan M Davis wrote:
> You validate by parsing the
> string, and you extract the necessary data from it by parsing it.

I feel like you and Walter are both saying the same thing.

fromISOString sounds to me like a data validation function. It is one that once validated provides a "validated" type, much like SortedRange.

I don't think Walter disagrees with that, but isn't calling it out specifically. Did I get that right?

On Thursday, November 21, 2013 08:20:39 Jesse Phillips wrote:
> On Monday, 18 November 2013 at 22:17:16 UTC, Jonathan M Davis
> 
> wrote:
> > You validate by parsing the
> > string, and you extract the necessary data from it by parsing
> > it.
> 
> I feel like you and Walter are both saying the same thing.
> 
> fromISOString sounds to me like a data validation function. It is one that once validated provides a "validated" type, much like SortedRange.
> 
> I don't think Walter disagrees with that, but isn't calling it out specifically. Did I get that right?

As I understand it, when Walter is talking about a validator function, _all_ it does is validate the input. It doesn't operate on the data beyond doing validation - the idea being that you validate that the input has some particular property or properties and then all the code that follows can just assume that rather than checking it again. For instance, you could have a function which validated that a string was valid UTF-8 and then have all code that follows just assume that it was valid UTF-8 without ever checking. The validator function is a separate function from any of the functions that actually do any of the work.

So, to do that with fromISOExtString, you'd have something like

enforce(isValidISOExtString(str)); //validator function
auto data = Date.fromISOExtString(str); //func which actually does the work

and fromISOExtString wouldn't do any validation at all. It would assume that the caller had already done the validation - either by calling the validator function - isValidISOExtString - or by knowing that it was valid based on where it came from (e.g. from toISOExtString).

In many cases, this makes sense from the standpoint of efficiency, because it allows you to check once and then avoid checking in the rest of the code rather than checking at various points throughout the code and potentially duplicating the checks that way. However, in the case of fromISOExtString (as well as many other parsing functions), you are essentially required to parse the string in order to validate it, meaning that if you had isValidISOExtString, and you called it before fromISOExtString, you'd be doubling the amount of work. fromISOExtString might be able to avoid a few of its checks if it knew that it could assume that the string was already valid, but a large portion of the work would have to be done regardless simply because that's what it takes to parse the date from the string. As such, having a separate validator function doesn't make a lot of sense. Rather, it makes more sense to have the function validate its own input rather than assume that the caller already validated it. But Walter seems to be arguing in favor of having a separate validator function all the time (or very close to all the time) - including in this particular case. So, I don't think that we're saying the same thing at all.

- Jonathan M Davis

On Thursday, 21 November 2013 at 03:10:17 UTC, Walter Bright wrote:
> ...
> The solution was to replace the horn's siren with a voice saying what was wrong, such as "fire engine no. 2" and "pull up". This worked BETTER.
>
> I see no difference with coding styles. Some are better, some are worse. As Andrei stated, consistency is not sufficient.
>
> For example, no indenting at all. Consistent? Yes. Bad? Yes. Case closed!

I strongly agree with Walter on this one.

On Thursday, 21 November 2013 at 03:15:16 UTC, Walter Bright wrote:
> On 11/20/2013 5:45 PM, Andrei Alexandrescu wrote:
>> In this context "objectively worse" means "all reasonable people would say it's
>> worse".
>
> It could also be objectively measured as:
>
> 1. results in more bugs
>
> 2. takes people longer to get up to speed with code written that way

You need to prove first that it results in more bugs because of inherent code style traits, not preferences of target audience. Otherwise you can have a potential code style which is objectively good for one measured group of programmers and objectively bad for other. Which contradicts the definition of "objectivity".

There is nothing terrible about being only subjectively worse / better. Code style exists only to help people and it is completely natural that its applicability is evaluated in people context. But that is a different thing with different name.

Same with your plane example - as described, one case wasn't objectively worse than another (or probably was but it wasn't checked). But as it is all about pilots (who are very alive subjects), subjective comparison is important enough to make the change and resulted in real practical improvement.

On 11/21/2013 6:10 AM, Dicebot wrote:
> You need to prove first that it results in more bugs because of inherent code
> style traits, not preferences of target audience.

You're saying that human factors engineering is purely a matter of personal preference. IT IS NOT. The way the mind works is not random.


> Same with your plane example - as described, one case wasn't objectively worse
> than another (or probably was but it wasn't checked).

Yes it was checked. People crashed. It was objectively worse. It's not a matter of preference.


> But as it is all about
> pilots (who are very alive subjects), subjective comparison is important enough
> to make the change and resulted in real practical improvement.

A real practical improvement is quite objective and measurable - fewer crashes. It's not happenstance that airline travel is far, far safer now. An awful lot of crashes were caused by pilot confusion - and every one is analyzed and designs are changed and tested to eliminate that confusion.

The objective results are obvious.

On 11/20/2013 10:35 PM, Jonathan M Davis wrote:
> Definitely, but almost all arguments over coding style seem to be very
> subjective even when some people try and claim that some of the issues are
> objective.

I've run across actual research on aspects of this now and then, and real measurable statistics show one way is better than another (better meaning produces fewer perceptual mistakes).

It's not dissimilar to A/B testing often done on web shopping pages.


> Most style choices which are objectively bad don't even ever get
> made precisely because they're objectively bad. There are of course
> exceptions, but I've rarely seen style arguments that are actually objective,
> and it's not uncommon to have people with drastically different opinions as to
> what looks good and who think that it should be obvious to everyone that what
> they think looks good looks good and that the other style looks horrible.

Just because A/B testing isn't done doesn't mean it's subjective.


> And I've run into plenty of cases where one developer thinks that a particular
> coding style is much easier to read, which is in complete contrast with what
> another developer thought was legible (how many parens to use and where being
> a prime example of that). So, it at least almost always seems like what's
> considered be a good, legible style is very subjective.

I bet if testing was done on it, a clear difference would emerge.

Just because two developers argue about it doesn't make it subjective. For example, we can both argue about where a program is expending its time, and we can both be wrong if we actually profile it and see.

The way humans perceive information is not random. Human factors engineering is not junk science. There's a reason lower case letters exist, it is not merely personal preference. It's objectively easier to read.

On Thursday, 21 November 2013 at 07:44:44 UTC, Jonathan M Davis wrote:
> As I understand it, when Walter is talking about a validator function, _all_
> it does is validate the input. It doesn't operate on the data beyond doing validation

I doubt Walter first checks that a file is a valid D program before tokenizing. More importantly he probably would not go for such a change.

The thing is, ISO String isn't a date, we first need to create a date and in doing so we validate it is valid and never have to check again.

On Thursday, November 21, 2013 16:38:48 Jesse Phillips wrote:
> On Thursday, 21 November 2013 at 07:44:44 UTC, Jonathan M Davis
> 
> wrote:
> > As I understand it, when Walter is talking about a validator
> > function, _all_
> > it does is validate the input. It doesn't operate on the data
> > beyond doing validation
> 
> I doubt Walter first checks that a file is a valid D program before tokenizing. More importantly he probably would not go for such a change.

Of course not, which makes his argument all the odder. Maybe he misunderstood what fromISOExtString does when responding to my argument that it made no sense to use a separate validator function for it.

> The thing is, ISO String isn't a date, we first need to create a date and in doing so we validate it is valid and never have to check again.

Agreed. But Walter is specifically arguing for doing validation in separate functions from those that do the work, which would mean having something like isValidateISOExtString which could be called fromISOExtString and then requiring that the string passed to fromISOExtString be valid or you get undefined behavior (in release at least, where there would be no assertions) as opposed to doing the checking in fromISOExtString. It's not necessarily a bad idea in the general case, but in this particular case, it makes no sense IMHO. However, when I argued that, for some reason Walter seemed to think that it was a perfect example of a case where there should be a separate validator function. So, maybe there's a miscommunicaton with regards to what fromISOExtString does.

- Jonathan M Davis

On 2013-11-18 06:32:46 +0000, Andrei Alexandrescu said:
> 
> 1. Fix scope(failure) and then use it.
> 
> Andrei

Huh?  Scope failure has no purpose here.  It does not CATCH the exception and prevent it from bubbling up the call chain.    Try/catch does do this.

-Shammah

On Friday, 22 November 2013 at 01:49:11 UTC, Shammah Chancellor wrote:
> On 2013-11-18 06:32:46 +0000, Andrei Alexandrescu said:
>> 
>> 1. Fix scope(failure) and then use it.
>> 
>> Andrei
>
> Huh?  Scope failure has no purpose here.  It does not CATCH the exception and prevent it from bubbling up the call chain.    Try/catch does do this.
>
> -Shammah

It does if you return from the scope(failure) block. The problem is you cannot mark the function as "nothrow"

For example:
---
void throwingFunction() {
    throw new Exception("damn!");
}

void someFunc() // nothrow
{
    scope(failure) {
        writeln("Failed in someFunc()");
        return;
    }
    throwingFunction();
}

void main() {
    try {
        someFunc();
        writeln("Yay, someFunc() is nothrow");
    } catch(Exception e) {
        writeln("An exception in main!");
    }
}

Output:

Failed in someFunc()
Yay, someFunc() is nothrow.
---

But you cannot mark someFunc() as nothrow.