On Thursday, 11 June 2015 at 12:49:20 UTC, Abdulhaq wrote:
>> D is really unique in the sense that it's open enough for people not to feel that they have to role their own. D also has enough features to satisfy many different users, although - and this is often forgotten - you don't _have_ to use them all. People like Go and Rust, because it tells them exactly what to do. D doesn't, they have to think for themselves, and a lot of people hate that, which is sad, because having loads of things to choose from makes you think more about your code and software design in general and it makes you a better programmer/coder/architect.
>
> Thinking like that is fine when you work on your own, but when you're in a large team and working on a large code base the prospect of trying to grok a dozen different coding approaches using different feature sets of some uber language is entirely unappealing and best avoided.

Good point. But teams have to decide what's best for their project(s) and lay down rules and guidelines, regardless of the language they use.

On Thursday, 11 June 2015 at 12:42:36 UTC, Ola Fosheim Grøstad wrote:
> People are not abandoning Dart because shows any signs of being a dead or a bad language, they do it because they don't trust Google.

My experience is many believe in corporate backing. Is it just PR?

> It seems to be a controversial subject: https://github.com/D-Programming-Language/phobos/pull/1090#issuecomment-12737986

As the topic has been argued for the past 50 years. No one ever agrees
on the best way to handle errors. But I think most of this is because programmers tend to be the most stubborn and unchanging type of folks in the world. They often care that they look right. Not that they are right ;)

> Exceptions are not meant to force handling errors at he source.

This attitude is why so many exceptions go unhandled at the upper
layers. When you have a top level that calls a function that calls 50 other functions, each that throw a handful or more different exceptions, it's unreasonable to expect the upper layer coder to account for all of them. In fact, in practice they usually don't until bugs arise. This is provably bad practice.

> If you want to force handling errors at the source they should be part of the return type.

Again what errors are worth throwing as exceptions in your
paradigm? Which ones are worth returning? This separation is very
arbitrary for my taste.

> Exceptions are not "hard fails".

They can be if they go unaccounted for (depending on the
language/environment). Java has the infamous,
NullPointerException that plagues Java applications. C# has the
NullReferenceException.

> You don't have to crash the entire program just fail the action the user was trying to do and display a nice error message with whatever information you can and want to provide to the user. Even if you don't handle them, they > provide information useful for debugging.

Not gonna disagree there.

>>> It doesn't really guarantee the functions not annotated as throwing won't > crash
>>
>> Combined with other guarantees (such as immutability, thread
>> local storage, safe memory management, side-effect free code, no
>> recursion, etc), you can make a reasonable guarantee about the
>> safety of your code.
>
> And a superhero cape, combined with an airplane, airplane fuel and flight school, allow you to fly in the air.

Not really sure how to parse this...Doesn't seem like you have any good argument against what I said. Again I said you can make a *reasonable* guarantee. And I am not alone here. If you look at Rust, it really does illustrate a trend that functional programming has been pushing for a long time. Provable guarantees. Problems are very rarely unique. There are a core set of things that happen frequently that cause problems. And these things are easily recognizable by compilers. You can't prevent everything, but you can prevent a good deal of the obvious stuff. This is just an extension of that mindset. So it is not really that outlandish.

> It is the other restrictions(without getting into a discussion about each and every restriction in the list) that make the code safer - nothrow doesn't really contribute IMO.

Without the nothrow, you cannot guarantee it won't cause problems
with unhandled errors ;) Seems like a nice guarantee to me. I
would at least like this option, because library writers often
try to write in an idiomatic way (and I tend to use the most reputable libraries I can find), which gives you some guarantees. The guarantee would be better served by default IMHO though.

Having a 'throw' keyword is also useful for IDE's. Anybody that
has used Visual Studio and C# will tell you a nice feature is
that Visual Studio can tell you what exceptions get thrown when calling a
method (very useful). C# does it in a different way, but a 'throw' keyword would actually help scanners figure this out very trivially as well as programmers just reading the header of a function.

> Scala and Rust seem to maintain both paradigms just fine. It's actually beneficial to have both - you have to acknowledge return-type-based exceptions, and you can always bypass them by turning them to exceptions, which are good for logging and debugging.

I do not believe Rust has exceptions.

I don't mind a language having multiple ways to handle errors.
Seeing how its a topic no one ever is on the same page about,
it's actually a wise design decision. But you don't often see
library writers mixing them for consistency purposes. It's just
easier for people to learn your library when you have one error
handling scheme. It's usually encountered only where two
libraries written by different vendors have to interact in
application code.

> If exception handling is enforced, they can only be bypassed by converting them to errors or crashes, which are much less nice than exceptions when it comes to debugging, logging and cleanup.

Exceptions have many benefits. They have many disadvantages too.
They are often very slow on the exceptional path, which occur
more frequently than most admit.

> Writing code that acknowledges that this code can fail due to an exception somewhere else does not count as ignoring it.

You could not handle it all the way up the chain (at the cost of
adding something to a definition, not much trade-off there). That
would essentially be ignoring it. From a design perspective you
could also have some mechanism (be it a keyword or whatever) that
you use to explicitly 'suppress' them for code that needs to be
faster, or code that you literally don't care. In application
code, you care. It's a good default to force people to handle
errors as they occur (which is what I am talking about,
defaults). If they wish to not handle them there, it's not at all
hard to imagine ways to allow people to 'suppress' them or 'pass
them up' when the situation calls for it. Force people to deal
with them by default, let them explicitly handle it in another
way. Or they can just use return types.

On Thursday, 11 June 2015 at 13:05:14 UTC, Kagamin wrote:
> On Thursday, 11 June 2015 at 12:42:36 UTC, Ola Fosheim Grøstad wrote:
>> People are not abandoning Dart because shows any signs of being a dead or a bad language, they do it because they don't trust Google.
>
> My experience is many believe in corporate backing. Is it just PR?

I don't know, but I think so. Lack of stability in Google forward looking statements causing trust issues? It would probably be different if Google offered support contracts.

I also suspect that Google projects are perceived as being too big to be taken over by an open source community, thus a move to github can be viewed as an long term attempt to ditch the project while saving face.

I don't think the idea that "open source means nobody can take it away from us" is something people believe in now that there are so many open source projects.

I should also mention that D has essentially enabled this
philosophy that I am speaking about concerning errors by using
the 'scope' keyword. I believe handling errors with scope
literally translates to try\catch blocks behind the scenes. I
also believe this is an encouraged way of dealing with errors in
D.

On 6/10/15 6:43 PM, Tofu Ninja wrote:
> On Thursday, 11 June 2015 at 01:30:08 UTC, weaselcat wrote:
>> 'he' has been a gender neutral pronoun for centuries, and as far as
>> I'm aware this has its roots in latin using 'man'(vir?) as a gender
>> neutral pronoun.
>
> I am just saying that personally it sounds odd to me to use it that way
> and I don't hear people use it that way either. In gender neutral
> contexts where you don't know the gender I almost always say/hear
> they/their. Maybe he losing its gender neutrality is a recent thing, I
> don't know. Maybe its just a thing with mid-westerners?

It does appear to be a recent thing, if you trust Wikipedia:

http://en.wikipedia.org/wiki/Gender-specific_and_gender-neutral_pronouns#Generic_he

Also the earlier section on "Historical and dialectal gender-neutral pronouns" is interesting: maybe we can start using "a" or "yo" as pronouns.

On 06/11/2015 06:52 AM, Chris wrote:
>
> In your case, the song reminds me of:
>
> Wouldn't It Be Good - Nik Kershaw
>
> https://www.youtube.com/watch?v=AYMAtbq0bjY
>
> (God, I'm so old!) :-)

Oh man, that takes me back. 80's had the best pop music, IMHO. Miss that stuff. Although, I still have trouble accepting anything from that decade as "old", but maybe that just dates me too ;)

On 06/11/2015 07:31 AM, "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= <ola.fosheim.grostad+dlang@gmail.com>" wrote:
> On Thursday, 11 June 2015 at 11:20:12 UTC, Kagamin wrote:
>> Then brainfuck wins.
>
> Always.
>

It *is* very fun to implement. I'm more partial to this one though: https://esolangs.org/wiki/Fuckfuck

And then there's http://compsoc.dur.ac.uk/whitespace/

On 06/11/2015 07:37 AM, Bruno Medeiros wrote:
> On 10/06/2015 12:38, "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?=
> <ola.fosheim.grostad+dlang@gmail.com>" wrote:
>> I think Rust has an advantage over Go in the name Mozilla alone, they
>> are more idealistic than Google.
>
> Agreed. In concrete terms, Mozilla is a non-profit, whereas Google is
> not. Google can easily drop (or reduce) support for Go if it doesn't
> serve whatever business goal they want. Or alternatively they might not
> be interested in evolving Go (or Go's toolchain) in directions that are
> useful for other people, but have little value for their business or
> technical goals.
>

Well, Mozilla's really a for-profit owned by a non-profit, which is a little weird.

In any case, Mozilla's demonstrated enough times in their history that they're not particularly worried about alienating and ignoring big groups of users. (Heck, they don't even try to promote their products as customizable anymore.) Of course, whether this will actually translate into similar issues with Rust remains to be seen. Hopefully they'll be more reasonable with Rust.

On Thursday, 11 June 2015 at 13:21:27 UTC, Dave wrote:
>> Exceptions are not meant to force handling errors at he source.
>
> This attitude is why so many exceptions go unhandled at the upper
> layers. When you have a top level that calls a function that calls 50 other functions, each that throw a handful or more different exceptions, it's unreasonable to expect the upper layer coder to account for all of them. In fact, in practice they usually don't until bugs arise. This is provably bad practice.

I'd rather have an exception unhandled at the top level than discarded at a middle level. Much easier to debug when you get a proper stack trace. Also, the top level handling can be very generic if it's purpose is not to solve the problem but to log it and to allow to use to continue using the other parts of the program as much as possible.

>> If you want to force handling errors at the source they should be part of the return type.
>
> Again what errors are worth throwing as exceptions in your
> paradigm? Which ones are worth returning? This separation is very
> arbitrary for my taste.

Exceptions are for when something went wrong. Returned errors are for when the function can't do what you asked it to do, but that doesn't mean that something went wrong.

For example, if you try to write to a file and fail that's an exception, because something went wrong(e.g. - not enough disk space, or a permissions problem).

But if you have a function that parses a string to a number and you call it with a non-numeric string - that doesn't necessarily mean that something went wrong. Maybe I don't expect all strings to be convertible to numbers, and instead of parsing each string twice(once for validation and once for the actual conversion) I prefer to just convert and rely on the conversion function to tell me if it's not a number?

Note that doesn't mean that every time a function returns an error it's not a problem - they can indicate problems, the point is that it's not up to the callee to decide, it's up to the caller. The conversion function doesn't know if I'm parsing a YAML file and if field value is not a number that just means it's a string, or if I'm parsing my own custom file format and if something specific is not a number that means the file is corrupted.

In the latter case, I can convert the returned error to exception(the returned error's type should have a method that returns the underlying result if it's OK and if there was an error raises an exception), but it's the caller's decision, not the callee.

>> Exceptions are not "hard fails".
>
> They can be if they go unaccounted for (depending on the
> language/environment). Java has the infamous,
> NullPointerException that plagues Java applications. C# has the
> NullReferenceException.

Even if they go unaccounted for, you still get a nice stack trace that helps you debug them. Maybe we have different definitions for "hard fail"...

>>>> It doesn't really guarantee the functions not annotated as throwing won't > crash
>>>
>>> Combined with other guarantees (such as immutability, thread
>>> local storage, safe memory management, side-effect free code, no
>>> recursion, etc), you can make a reasonable guarantee about the
>>> safety of your code.
>>
>> And a superhero cape, combined with an airplane, airplane fuel and flight school, allow you to fly in the air.
>
> Not really sure how to parse this...Doesn't seem like you have any good argument against what I said. Again I said you can make a *reasonable* guarantee. And I am not alone here. If you look at Rust, it really does illustrate a trend that functional programming has been pushing for a long time. Provable guarantees. Problems are very rarely unique. There are a core set of things that happen frequently that cause problems. And these things are easily recognizable by compilers. You can't prevent everything, but you can prevent a good deal of the obvious stuff. This is just an extension of that mindset. So it is not really that outlandish.
>
>> It is the other restrictions(without getting into a discussion about each and every restriction in the list) that make the code safer - nothrow doesn't really contribute IMO.
>
> Without the nothrow, you cannot guarantee it won't cause problems
> with unhandled errors ;) Seems like a nice guarantee to me. I
> would at least like this option, because library writers often
> try to write in an idiomatic way (and I tend to use the most reputable libraries I can find), which gives you some guarantees. The guarantee would be better served by default IMHO though.

Even with no throw you can't guarantee a function won't cause problems with unhandled errors - unless you use a very strict definition of handling errors, that include discarding them or crashing the program. nothrow can only guarantee the function won't expose any problems you can use the exceptions mechanism to debug or deal with - not very useful, considering how easy it is to convert an error that plays nice with the exceptions mechanism to an error that horribly crashes the program...

> Having a 'throw' keyword is also useful for IDE's. Anybody that
> has used Visual Studio and C# will tell you a nice feature is
> that Visual Studio can tell you what exceptions get thrown when calling a
> method (very useful). C# does it in a different way, but a 'throw' keyword would actually help scanners figure this out very trivially as well as programmers just reading the header of a function.

If you insist on forcing developers to handle exceptions close to the source, or to explicitly pass them on, I guess it can be useful let them know what it is that they are require to handle/pass on. Still, I don't think it's a good idea to needlessly burden people just so you could provide them with the tool to better handle that burden.

>> Scala and Rust seem to maintain both paradigms just fine. It's actually beneficial to have both - you have to acknowledge return-type-based exceptions, and you can always bypass them by turning them to exceptions, which are good for logging and debugging.
>
> I do not believe Rust has exceptions.

It has panics, which are different from exceptions in that you can't catch them(unless it's from another thread), but close in their usage to what I have in mind when referring to exceptions - they don't allow you to go on with what you where trying to do, but allow you to debug the problem and/or back down from it gracefully.

> I don't mind a language having multiple ways to handle errors.
> Seeing how its a topic no one ever is on the same page about,
> it's actually a wise design decision. But you don't often see
> library writers mixing them for consistency purposes. It's just
> easier for people to learn your library when you have one error
> handling scheme. It's usually encountered only where two
> libraries written by different vendors have to interact in
> application code.

It's not a matter of preferences, just like choosing between int and float is not a matter of preferences. Each type of error has it's own purpose, and a library can use them both.

>> If exception handling is enforced, they can only be bypassed by converting them to errors or crashes, which are much less nice than exceptions when it comes to debugging, logging and cleanup.
>
> Exceptions have many benefits. They have many disadvantages too.
> They are often very slow on the exceptional path, which occur
> more frequently than most admit.

Returned errors provide a faster error path, and when you have to decide if an error should be returned or thrown, the ones that should be thrown are usually the ones where you don't care as much about speed.

>> Writing code that acknowledges that this code can fail due to an exception somewhere else does not count as ignoring it.
>
> You could not handle it all the way up the chain (at the cost of
> adding something to a definition, not much trade-off there).

Assuming you have control over the definition, which is not always the case. In Java, for example, when you implement an interface you have no control over the signature of it's methods. The library that have provided that interface doesn't know what the implementers are going to do, so it has to either mark the methods as all-throwing(kind of defeats the purpose of the `throws` annotation), or pretend it's implementers can't throw(which we know is not true).

> That
> would essentially be ignoring it. From a design perspective you
> could also have some mechanism (be it a keyword or whatever) that
> you use to explicitly 'suppress' them for code that needs to be
> faster, or code that you literally don't care. In application
> code, you care. It's a good default to force people to handle
> errors as they occur (which is what I am talking about,
> defaults). If they wish to not handle them there, it's not at all
> hard to imagine ways to allow people to 'suppress' them or 'pass
> them up' when the situation calls for it. Force people to deal
> with them by default, let them explicitly handle it in another
> way. Or they can just use return types.

Returned errors are a faster mechanism that forces to deal with the error at the source, or explicitly transfer it to the upper level at the cost of changing the function's signature. Exceptions are a slower mechanism that allows to deal with the errors far from the source without requiring special function signatures in the middle levels(when they do require it's a syntactic salt, not a requirement of the mechanism).

nothrow by default is combining the slowness of exceptions with the limitness of returned errors. Why would anyone want to do that?