On Friday, 29 May 2020 at 12:52:06 UTC, Andrei Alexandrescu wrote:
> On 5/28/20 7:35 PM, Adam D. Ruppe wrote:
>> On Thursday, 28 May 2020 at 22:56:15 UTC, Andrei Alexandrescu wrote:
>>> Large projects separate compilation inter-procedural analysis does not scale yadda yadda yadda.
>> 
>> We need to stop making assertions without measurements. This may be true, but it needs to be based on empirical fact - the one thing we should notice is compile speed is sensitive to surprising things and not to other surprising things....
>
> Needs to be based in sound analysis, not measurements, as a quadratic is not scalable regardless of the constant. When I was in the field there was no escaping this fact, and all interprocedural analyses that did anything interesting were limited to programs a few KB in size.
>
> Perhaps things have improved since, and it would be great if they did. Timon should know about this.

Where I work we typically use decision matrix. In it's current state, DIP process would benefit if a decision matrix can be introduced for controversial proposals. It will help to summarize the options and counter options proposed and the weightage for each option (based on sound reasoning).

https://en.wikipedia.org/wiki/Decision_matrix

On Friday, 29 May 2020 at 12:52:06 UTC, Andrei Alexandrescu wrote:
> On 5/28/20 7:35 PM, Adam D. Ruppe wrote:
>> On Thursday, 28 May 2020 at 22:56:15 UTC, Andrei Alexandrescu wrote:
>>> Large projects separate compilation inter-procedural analysis does not scale yadda yadda yadda.
>> 
>> We need to stop making assertions without measurements. This may be true, but it needs to be based on empirical fact - the one thing we should notice is compile speed is sensitive to surprising things and not to other surprising things....
>
> Needs to be based in sound analysis, not measurements, as a quadratic is not scalable regardless of the constant. When I was in the field there was no escaping this fact, and all interprocedural analyses that did anything interesting were limited to programs a few KB in size.
>
> Perhaps things have improved since, and it would be great if they did. Timon should know about this.

Of course, we need both theory and the empirical.  O(N lg N) may be the upper limit of what is countenanced for performance work, a useful filter, but the constants, as Andrei knows better than most, can really get you.  Big-Oh is helpful but it is too loose to be the final word.

Additionally, the empirical can help you catch big-Oh analysis errors.

On 29.05.20 14:40, Meta wrote:
> On Friday, 29 May 2020 at 08:52:14 UTC, Timon Gehr wrote:
>>> I find that response surprising, given that you used to use Haskell (do you still?), which gets along fine without exceptions.
>>
>> http://hackage.haskell.org/package/base-4.14.0.0/docs/Control-Exception.html 
>>
>>
>> Furthermore, imperative-style code in Haskell is based on monads, which are a generalization of exceptions.
> 
> I'm going to step up the pedantry and say that this proves my assertion; Haskell (the language) gets along fine without exceptions, but they're there for you to use as a library, only if you want to.

Prelude> case (1,1) of (2,2) -> 0
*** Exception: <interactive>:4:1-24: Non-exhaustive patterns in case

On Friday, 29 May 2020 at 20:02:37 UTC, Timon Gehr wrote:
> On 29.05.20 14:40, Meta wrote:
>> On Friday, 29 May 2020 at 08:52:14 UTC, Timon Gehr wrote:
>>>> I find that response surprising, given that you used to use Haskell (do you still?), which gets along fine without exceptions.
>>>
>>> http://hackage.haskell.org/package/base-4.14.0.0/docs/Control-Exception.html
>>>
>>>
>>> Furthermore, imperative-style code in Haskell is based on monads, which are a generalization of exceptions.
>> 
>> I'm going to step up the pedantry and say that this proves my assertion; Haskell (the language) gets along fine without exceptions, but they're there for you to use as a library, only if you want to.
>
> Prelude> case (1,1) of (2,2) -> 0
> *** Exception: <interactive>:4:1-24: Non-exhaustive patterns in case

Okay, I'll concede that one. I forgot that non-exhaustive patterns throw exceptions; I thought I remembered them raising errors.

Let's talk about Rust instead, then, which 100% absolutely does not have exceptions. They seem to make do with Option/Result/try (though I guess since they're monads you'd consider those equivalent to exceptions, but they don't behave like exceptions as they're just sugar over pattern matching).

On Thursday, May 28, 2020 2:41:43 PM MDT Meta via Digitalmars-d wrote:
> On Thursday, 28 May 2020 at 00:31:09 UTC, Jonathan M Davis wrote:
> > On Wednesday, May 27, 2020 5:57:00 PM MDT Meta via
> >
> > Digitalmars-d wrote:
> >> On Wednesday, 27 May 2020 at 18:50:50 UTC, Jonathan M Davis
> >>
> >> wrote:
> >> > Based on some of Walter's comments, it also sounds like he intends to make nothrow the default in another DIP, which is also a terrible idea. I'm increasingly worried about the future of D with some of where these DIPs are going.
> >> >
> >> > - Jonathan M Davis
> >>
> >> What's wrong with nothrow by default? Probably 97% of code doesn't need to throw exceptions.
> >
> > If anything, I would say the opposite.
> >
> > <snip>
>
> I find that response surprising, given that you used to use Haskell (do you still?), which gets along fine without exceptions.

Functional languages are a very different beast from imperative or multi-paradigm languages. So, to a great extent, we're talking apples and oranges when comparing them. Regardless, Haskell avoids some of the pitfalls of not using exceptions while being pretty firmly stuck with others. Because it's purely functional, you can't easily ignore the results of functions, which makes error-codes (or monads with error reporting) less error-prone than they are in languages like C++, Java, or D, but the result still clutters the code considerably. It's very typical in Haskell that you're stuck passing monads in one form or another well up the call stack, so the error-handling effectively infects the whole program instead of being segregated to the portions where it's most appropriate to deal with it. And of course, it gets that much more fun when you need to be passing multiple things up the call stack via monads.

Ultimately though, Haskell is so different from D that it's hard to really talk about best practices from one applying to the other. Personally, I think that it's great to spend time using a functional language as your main language for a while, because it forces you to get better at functional programming practices such as recursion - but it forces it by not letting you have the full toolbox like a multi-paradigm language does. I'm _much_ more comfortable with stuff like templates and range-based code than I would have been had I not spent a fair bit of time programming in Haskell previously, but honestly, I hate functional languages. They're far too restrictive, and I don't understand how anyone can seriously program in them professionally. Debugging Haskell is a disgusting, unpleasant process in comparison to an imperative or OO language. I highly recommend that programmers spend some time in functional land to improve their skills, but I would never want to program with such tools for a living.

Regardless, as far as code in languages like D, C++, C#, Java, etc. goes, exceptions are by far the cleanest and least error-prone way to deal with error conditions in general. They definitely aren't always appropriate, but for your average program, they're how I'd expect most error-handling to be done.

- Jonathan M Davis

On Friday, 29 May 2020 at 22:19:37 UTC, Jonathan M Davis wrote:

> Personally, I think that it's great to spend time using a functional language as your main language for a while, because it forces you to get better at functional programming practices such as recursion - but it forces it by not letting you have the full toolbox like a multi-paradigm language does. I'm _much_ more comfortable with stuff like templates and range-based code than I would have been had I not spent a fair bit of time programming in Haskell previously, but honestly, I hate functional languages. They're far too restrictive, and I don't understand how anyone can seriously program in them professionally. Debugging Haskell is a disgusting, unpleasant process in comparison to an imperative or OO language. I highly recommend that programmers spend some time in functional land to improve their skills, but I would never want to program with such tools for a living.

If someone wants to practise or have fun with a functional language, and at the some time have some concrete and good tool for a real job, I suggest giving a try to Elm.

It's rock solid, and much more easy then Haskell (its compiler is written in Haskell), and you can learn and be profitable in a really short time.

Bonus point, fantastic error messages provided and ... well you can avoid Javascript!

On Thursday, 28 May 2020 at 22:43:29 UTC, Andrei Alexandrescu wrote:
> And that should be a breaking change. So all is good.
>
> Changing the regime of a function from nothrow to throw is major.

Of course changing the regime of a function from nothrow to throw is major.  That will be the case whatever the default regime is.  But the point I was making was about how default regime choice mixes with the requirement for breaking change.

The scenario imagined here is "What happens if a function is using the default regime by accident because the developer forgot to add an attribute to change it?"

If the default regime is 'throw', then one can switch a function from the default regime to its opposite, without breaking change.

If the default regime is 'nothrow', then changing from the default regime to its opposite is inherently a breaking change.

We can reasonably expect that it will be a common scenario for developers to just use the default and then realize later that wasn't intended.  So when picking a default regime, it might be a good idea to pick the default that allows switching away without breakage.

(The same argument has been advanced for final-by-default class methods, you may recall.)