[dart-misc] Notes from last week's DEP meeting

['Bob Nystrom' via Dart Misc]

I finally wrote up my notes from the meeting. They're here:

https://github.com/dart-lang/dart_enhancement_proposals/blob/master/Meetings/2015-05-27%20DEP%20Committee%20Meeting.md

This week is super duper exciting thanks to Patrice's fantastic proposal
<https://github.com/chalin/DEP-non-null> for non-nullable types.

We (the Dart team) still have a lot of work to do on our end to wrap our
heads around it and figure out what to do next, but Patrice has certainly
given us a lot to work with.

Cheers!

- bob

[Don Olmstead]

Here's hoping it gets picked up. Its a great proposal!

On Tue, Jun 2, 2015 at 2:50 PM, 'Bob Nystrom' via Dart Misc <

Post by 'Bob Nystrom' via Dart Misc
https://github.com/dart-lang/dart_enhancement_proposals/blob/master/Meetings/2015-05-27%20DEP%20Committee%20Meeting.md
This week is super duper exciting thanks to Patrice's fantastic proposal
<https://github.com/chalin/DEP-non-null> for non-nullable types.
We (the Dart team) still have a lot of work to do on our end to wrap our
heads around it and figure out what to do next, but Patrice has certainly
given us a lot to work with.
Cheers!
- bob
--
For other discussions, see https://groups.google.com/a/dartlang.org/
For HOWTO questions, visit http://stackoverflow.com/tags/dart
To file a bug report or feature request, go to http://www.dartbug.com/new
To unsubscribe from this group and stop receiving emails from it, send an

['Justin Fagnani' via Dart Misc]

+100!

Post by Don Olmstead
Here's hoping it gets picked up. Its a great proposal!
On Tue, Jun 2, 2015 at 2:50 PM, 'Bob Nystrom' via Dart Misc <

Post by 'Bob Nystrom' via Dart Misc
https://github.com/dart-lang/dart_enhancement_proposals/blob/master/Meetings/2015-05-27%20DEP%20Committee%20Meeting.md
This week is super duper exciting thanks to Patrice's fantastic proposal
<https://github.com/chalin/DEP-non-null> for non-nullable types.
We (the Dart team) still have a lot of work to do on our end to wrap our
heads around it and figure out what to do next, but Patrice has certainly
given us a lot to work with.
Cheers!
- bob
--
For other discussions, see https://groups.google.com/a/dartlang.org/
For HOWTO questions, visit http://stackoverflow.com/tags/dart
To file a bug report or feature request, go to http://www.dartbug.com/new
To unsubscribe from this group and stop receiving emails from it, send an

--
For other discussions, see https://groups.google.com/a/dartlang.org/
For HOWTO questions, visit http://stackoverflow.com/tags/dart
To file a bug report or feature request, go to http://www.dartbug.com/new
To unsubscribe from this group and stop receiving emails from it, send an

[Filipe Morgado]

+100!

Same!

[Warren]

Am I reading that correctly when it suggests that dart2js performance could
be significantly improved? That seems like a huge benefit.

Post by 'Bob Nystrom' via Dart Misc
https://github.com/dart-lang/dart_enhancement_proposals/blob/master/Meetings/2015-05-27%20DEP%20Committee%20Meeting.md
This week is super duper exciting thanks to Patrice's fantastic proposal
<https://github.com/chalin/DEP-non-null> for non-nullable types.
We (the Dart team) still have a lot of work to do on our end to wrap our
heads around it and figure out what to do next, but Patrice has certainly
given us a lot to work with.
Cheers!
- bob

['Bob Nystrom' via Dart Misc]

Post by Warren
Am I reading that correctly when it suggests that dart2js performance
could be significantly improved? That seems like a huge benefit.

Hopefully dart2js folks will correct me if I'm wrong, but here's how I
*think* it works...

If you call a method on null in JS, the semantics are different than
calling a method on null in Dart. That means that when dart2js compiles a
method call to JS, it has to add some extra boilerplate null checking
before it invokes the method to implement Dart's semantics. That adds to
code size and slows down performance.

Since that perf hit is unacceptable, dart2js actually has a bunch of code
internally to try to *infer* which variables are nullable and which aren't.
Even though *Dart* doesn't have non-nullable types, dart2js's type system
does.

However, without any annotations, that inference fails pretty often. If
Dart had explicit non-nullable types, and you ran dart2js with "trust type
annotations" enabled, then it should have an easier job of knowing which
variables aren't nullable and don't need the extra checks.

The actual impact of this is hard to guess. I think we'd have to run the
experiment and see. Personally, I think it's worth putting the resources
into an experimental implementation so that we can do that.

Cheers!

- bob

['Justin Fagnani' via Dart Misc]

On Tue, Jun 2, 2015 at 5:29 PM, 'Bob Nystrom' via Dart Misc <

Post by 'Bob Nystrom' via Dart Misc

Post by Warren
Am I reading that correctly when it suggests that dart2js performance
could be significantly improved? That seems like a huge benefit.

Hopefully dart2js folks will correct me if I'm wrong, but here's how I
*think* it works...
If you call a method on null in JS, the semantics are different than
calling a method on null in Dart. That means that when dart2js compiles a
method call to JS, it has to add some extra boilerplate null checking
before it invokes the method to implement Dart's semantics. That adds to
code size and slows down performance.
Since that perf hit is unacceptable, dart2js actually has a bunch of code
internally to try to *infer* which variables are nullable and which
aren't. Even though *Dart* doesn't have non-nullable types, dart2js's
type system does.
However, without any annotations, that inference fails pretty often. If
Dart had explicit non-nullable types, and you ran dart2js with "trust type
annotations" enabled, then it should have an easier job of knowing which
variables aren't nullable and don't need the extra checks.

Even without --trust-type-annotations, non-nullable types are likely to
generate static warnings that guide the program into being easier on type
inferencing.

Post by 'Bob Nystrom' via Dart Misc
The actual impact of this is hard to guess. I think we'd have to run the
experiment and see. Personally, I think it's worth putting the resources
into an experimental implementation so that we can do that.
Cheers!
- bob
--
For other discussions, see https://groups.google.com/a/dartlang.org/
For HOWTO questions, visit http://stackoverflow.com/tags/dart
To file a bug report or feature request, go to http://www.dartbug.com/new
To unsubscribe from this group and stop receiving emails from it, send an

[Alex Tatumizer]

There's certainly a problem with null, but not exactly the kind of problem
addressed by this proposal IMO.
To keep it short: "null" is meaningless. It can mean "Unknown",
"Unitialized", "CannotBeRepresentedByInt","UseDefault", etc etc, and with
single null, these meanings are not differentiated.

Ideally, there shouldn't be any "universal" null that means "superposition
of all possible meanings of undefined value".
E.g., in the context of optional parameters, if we want to say
"useDefault", we can explicitly pass a constant of type "UseDefault"(or
nothing, in which case parameter will be assigned a value of "useDefault" -
the only value of type UseDefault). Accordingly, declared type of parameter
should be a union - say, int | UseDefault.
Otherwise, I feel that no tenable concept can be ever formulated. E.g. you
call foo(x), where x is optional parameter, but your x is uninitialized -
however, foo treats it as "use default" - which is not what you meant -
it's a bug, not "useDefault". More situations like this will occur with
union types T | Null - "Null" here is too broad.

The fact that in javascript there's "undefined" and "null" should provide
some food for thought (obviously, 2 nulls with vague meaning are even worse
than one).

['Bob Nystrom' via Dart Misc]

Post by Alex Tatumizer
There's certainly a problem with null, but not exactly the kind of problem
addressed by this proposal IMO.
To keep it short: "null" is meaningless. It can mean "Unknown",
"Unitialized", "CannotBeRepresentedByInt","UseDefault", etc etc, and with
single null, these meanings are not differentiated.

This is true of numbers as well. 3 doesn't mean anything. 3 what? It's all
about context. null is the same. It's a meaningless value that you can
*assign* meaning to in some context for various useful reasons.

Post by Alex Tatumizer
Ideally, there shouldn't be any "universal" null that means "superposition
of all possible meanings of undefined value".
E.g., in the context of optional parameters, if we want to say
"useDefault", we can explicitly pass a constant of type "UseDefault"(or
nothing, in which case parameter will be assigned a value of "useDefault" -
the only value of type UseDefault). Accordingly, declared type of parameter
should be a union - say, int | UseDefault.
Otherwise, I feel that no tenable concept can be ever formulated. E.g. you
call foo(x), where x is optional parameter, but your x is uninitialized -
however, foo treats it as "use default" - which is not what you meant -
it's a bug, not "useDefault". More situations like this will occur with
union types T | Null - "Null" here is too broad.
The fact that in javascript there's "undefined" and "null" should provide
some food for thought (obviously, 2 nulls with vague meaning are even worse
than one).

As soon as you make UseDefault a first class value, someone will want to be
able to detect whether an argument was omitted or whether its value
was *explicitly
passed as UseDefault*. And now you're back to wanting yet another sentinel.

Personally, I think the sanest approach is:

1. Optional parameters are assigned null if the argument is omitted.

2. Obviously, they are also assigned null if the argument is explicitly
null.

3. APIs should not distinguish between an explicitly-passed null and an
omitted argument. (In particular, this means not using default values.)

If you do need to distinguish between "argument omitted" and "null, which
is a valid value for the argument", come up with new name for that method
and don't make the parameter optional.

Cheers!

- bob

[Alex Tatumizer]

Bob: Please allow me to disagree. In most contexts, there's at least a name
of variable that tells the meaning.
numberOfCucumbers=3
(Some languages - e.g. Ada - go much further in that direction). The
reverse is also true: if the name of variable is vague
(or the whole concept behind this variable is vague) - no amount or
compiler rules, types, etc will help.

In case of nulls - it's not clear in what sense the number of cucumbers is
null at all.

It's exactly that kind of superficial analogy with 3 that stands in the way
of recognizing the existence of (potentially infinite) variety of nulls.

I, for one, can live with nulls. Can't remember too many bugs because nulls
(much fewer than, say, "off-by-1" bugs).
But if somebody embarks on a mission of fixing nulls, I just tried to add
my 2 cents. Please ignore it if you don't like it.

(BTW, I can't recall a single bug where I by mistake pass the number of
apples where function expected cucumbers. There was a couple of cases where
I confused the order of int parameters, but that's a different case).

[Cristian Garcia]

Please, no more than one NULL value. JavaScript's "undefined" vs "null" is
a pain for library makers that end up checking for all kind of variations.
Non-nullable values might be efficient, but I dont particulary like how its
harder to check for exceptions.
For example, in a generic class how do you check if a parameter is
initialize? Null checking, but if the type parameter is non-nullable it
will always pass the test. So you check to see if its the default, but what
if the user did pass a default value (eg. 0 for ints). You might end up
creating a boolean for this plus extra logic to be consistent.

Post by Alex Tatumizer
Bob: Please allow me to disagree. In most contexts, there's at least a
name of variable that tells the meaning.
numberOfCucumbers=3
(Some languages - e.g. Ada - go much further in that direction). The
reverse is also true: if the name of variable is vague
(or the whole concept behind this variable is vague) - no amount or
compiler rules, types, etc will help.
In case of nulls - it's not clear in what sense the number of cucumbers is
null at all.
It's exactly that kind of superficial analogy with 3 that stands in the
way of recognizing the existence of (potentially infinite) variety of nulls.
I, for one, can live with nulls. Can't remember too many bugs because
nulls (much fewer than, say, "off-by-1" bugs).
But if somebody embarks on a mission of fixing nulls, I just tried to add
my 2 cents. Please ignore it if you don't like it.
(BTW, I can't recall a single bug where I by mistake pass the number of
apples where function expected cucumbers. There was a couple of cases where
I confused the order of int parameters, but that's a different case).
--
For other discussions, see https://groups.google.com/a/dartlang.org/
For HOWTO questions, visit http://stackoverflow.com/tags/dart
To file a bug report or feature request, go to http://www.dartbug.com/new
To unsubscribe from this group and stop receiving emails from it, send an

[Alex Tatumizer]

Post by Cristian Garcia
Please, no more than one NULL value. JavaScript's "undefined" vs "null"

is a pain for library makers that end up checking for all kind of
variations.
You misunderstood my point.
What I wanted to say is that IF someone declares nulls a problem worthy of
50-page write-up, this attempt is doomed, unless null gets removed from the
language completely.
Instead, you can define your OWN singletons (e.g. as enums with a SINGLE
VALUE) - e.g. Uninitialized, Unknown, UseDefault, Inifinity, Foobar (each
is a separate class) and use unions e.g. int | Unknown.
They are not nulls - they are special values used to extend a normal class
(analogy with adding "infinity" to int) Current "null" doesn't cut it,
though for brevity it can be treated as synonym to Uninitialized (but not
anything else).

And I agree with your sentiment that the game is not worth the candles.
Leaving everything as it is is a lesser evil IMO.
Sometimes people set themselves artificial goals and go into greatest
lengths possible to achieve them, even if it makes program
incomprehensible. Rust language is a very good example.

[Joao Pedrosa]

Hi,

While playing with some lower level languages in the past few days I can
only wonder about this proposal. :-)

In Fletch I was doing some memory accesses with FFI which meant that I had
to deal with "null" (0) values a lot. Then in the Postgres client code I
was writing I had to deal with null values some of the time. I knew they
were null because the protocol specified null as valueLen == -1.

It seems that the higher level languages have been beholden by that kind of
inheritance.

Also it was kind of fun to see overloading of functions in C++. :-) If
that's where we are headed to if they keep on straightening up the static
features of the language. :-)

In the Skia C++ code I was browsing, I was at times surprised by the
absence of extra bounds checks and the like. Their C++ code was actually
quite pleasant for the conciseness. :-)

In higher level languages it seems that it's every developer's goal to
ensure that code will not blow up in their part of the fence. There may
always be this hope that the compiler can "hoist" stuff out of the hot
loops or that the extra checks won't matter for the type of application
being developed.

Meanwhile, a lot of code is being written in languages like JavaScript. And
I realize that coming up with an alternative to them is nigh impossible.
There will be this gap between the languages that can script and the ones
that will need scripting and like chocolate and peanut butter combination
goes, they may work well together, but people may be happy with just 1 of
those at a time as well. :-)

Cheers,
Joao

Post by Alex Tatumizer

Post by Cristian Garcia
Please, no more than one NULL value. JavaScript's "undefined" vs "null"

is a pain for library makers that end up checking for all kind of
variations.
You misunderstood my point.
What I wanted to say is that IF someone declares nulls a problem worthy of
50-page write-up, this attempt is doomed, unless null gets removed from the
language completely.
Instead, you can define your OWN singletons (e.g. as enums with a SINGLE
VALUE) - e.g. Uninitialized, Unknown, UseDefault, Inifinity, Foobar (each
is a separate class) and use unions e.g. int | Unknown.
They are not nulls - they are special values used to extend a normal class
(analogy with adding "infinity" to int) Current "null" doesn't cut it,
though for brevity it can be treated as synonym to Uninitialized (but not
anything else).
And I agree with your sentiment that the game is not worth the candles.
Leaving everything as it is is a lesser evil IMO.
Sometimes people set themselves artificial goals and go into greatest
lengths possible to achieve them, even if it makes program
incomprehensible. Rust language is a very good example.
--
For other discussions, see https://groups.google.com/a/dartlang.org/
For HOWTO questions, visit http://stackoverflow.com/tags/dart
To file a bug report or feature request, go to http://www.dartbug.com/new
To unsubscribe from this group and stop receiving emails from it, send an

[Alex Tatumizer]

Here's a much simpler proposal on how to deal with nulls.
Just call the variable (parameter) that accepts nulls with underscore at
the end. e.g. int numberOfCucumbers_ may be null, but int numberOfCucumbers
can't.
It doesn't require any changes in the language or even APIs (for the most
part) - just renaming some function parameters that can really accept
nulls.
It's the same idea as to call a variable "elapsedTimeInSeconds" vs
"elapsedTimeInMilliseconds". Compiler will not help in that, but for human
programmer it's good enough to eliminate most of confusion and bugs.
Similarly, underscore is for human reader only - compiler doesn't know
anything about the convention.
How about that?

[Filipe Morgado]

Nah! Personally, I'm all in for NNBD as it is in the proposal (expect I
would use postfix ! and ?, but that's just a detail).

I would look into what Ceylon is doing, they have some pretty neat
features, IMO, despite being apparently unsuccessful.
(Not easy to compete in the JVM world, almost as tough as competing against
JS).

Post by Alex Tatumizer
Here's a much simpler proposal on how to deal with nulls.
Just call the variable (parameter) that accepts nulls with underscore at
the end. e.g. int numberOfCucumbers_ may be null, but int numberOfCucumbers
can't.
It doesn't require any changes in the language or even APIs (for the most
part) - just renaming some function parameters that can really accept
nulls.
It's the same idea as to call a variable "elapsedTimeInSeconds" vs
"elapsedTimeInMilliseconds". Compiler will not help in that, but for human
programmer it's good enough to eliminate most of confusion and bugs.
Similarly, underscore is for human reader only - compiler doesn't know
anything about the convention.
How about that?

['Andreas Kirsch' via Dart Misc]

A problem that gets aggravated with NNBD is forwarding of function calls:

Right now, if you want to allow simple function forwarding you can use the
following:

```
void actual_f([optionalParam]) {
if (optionalParam == null) {
optionalParam = defaultValue;
}
....
}

void forwarding_f([optionalParam]) => actual_f(optionalParam);
```
Otherwise you have to do
```
void forward_f([optionalParam]) {
if (optionalParam != null) {
actual_f(optionalParam);
} else {
actual_f()l
}
}
```

With NNBD, this won't be possible anymore and you will always have a
combinatorial explosion because passing on null won't work anymore.

Post by Filipe Morgado
Nah! Personally, I'm all in for NNBD as it is in the proposal (expect I
would use postfix ! and ?, but that's just a detail).
I would look into what Ceylon is doing, they have some pretty neat
features, IMO, despite being apparently unsuccessful.
(Not easy to compete in the JVM world, almost as tough as competing
against JS).

Post by Alex Tatumizer
Here's a much simpler proposal on how to deal with nulls.
Just call the variable (parameter) that accepts nulls with underscore at
the end. e.g. int numberOfCucumbers_ may be null, but int numberOfCucumbers
can't.
It doesn't require any changes in the language or even APIs (for the most
part) - just renaming some function parameters that can really accept
nulls.
It's the same idea as to call a variable "elapsedTimeInSeconds" vs
"elapsedTimeInMilliseconds". Compiler will not help in that, but for human
programmer it's good enough to eliminate most of confusion and bugs.
Similarly, underscore is for human reader only - compiler doesn't know
anything about the convention.
How about that?

--
For other discussions, see https://groups.google.com/a/dartlang.org/
For HOWTO questions, visit http://stackoverflow.com/tags/dart
To file a bug report or feature request, go to http://www.dartbug.com/new
To unsubscribe from this group and stop receiving emails from it, send an

['Andreas Kirsch' via Dart Misc]

Actually... after further pondering:

Perfect forwarding using getters:
```
typedef void Actual_F([optionalParam]);

Actual_F get forward_f => actual_f;
```
fixes all combinatorial issues I mentioned above. It is not what you would
expect usually, but it seems to work and if you take on the work to create
typedefs, it even does parameter type checking etc.

Post by 'Andreas Kirsch' via Dart Misc
Right now, if you want to allow simple function forwarding you can use the
```
void actual_f([optionalParam]) {
if (optionalParam == null) {
optionalParam = defaultValue;
}
....
}
void forwarding_f([optionalParam]) => actual_f(optionalParam);
```
Otherwise you have to do
```
void forward_f([optionalParam]) {
if (optionalParam != null) {
actual_f(optionalParam);
} else {
actual_f()l
}
}
```
With NNBD, this won't be possible anymore and you will always have a
combinatorial explosion because passing on null won't work anymore.

Post by Filipe Morgado
Nah! Personally, I'm all in for NNBD as it is in the proposal (expect I
would use postfix ! and ?, but that's just a detail).
I would look into what Ceylon is doing, they have some pretty neat
features, IMO, despite being apparently unsuccessful.
(Not easy to compete in the JVM world, almost as tough as competing
against JS).

Post by Alex Tatumizer
Here's a much simpler proposal on how to deal with nulls.
Just call the variable (parameter) that accepts nulls with underscore at
the end. e.g. int numberOfCucumbers_ may be null, but int numberOfCucumbers
can't.
It doesn't require any changes in the language or even APIs (for the
most part) - just renaming some function parameters that can really accept
nulls.
It's the same idea as to call a variable "elapsedTimeInSeconds" vs
"elapsedTimeInMilliseconds". Compiler will not help in that, but for human
programmer it's good enough to eliminate most of confusion and bugs.
Similarly, underscore is for human reader only - compiler doesn't know
anything about the convention.
How about that?

--
For other discussions, see https://groups.google.com/a/dartlang.org/
For HOWTO questions, visit http://stackoverflow.com/tags/dart
To file a bug report or feature request, go to http://www.dartbug.com/new
To unsubscribe from this group and stop receiving emails from it, send an

['John Messerly' via Dart Misc]

On Wed, Jun 10, 2015 at 5:58 AM, 'Andreas Kirsch' via Dart Misc <

Post by 'Andreas Kirsch' via Dart Misc
Right now, if you want to allow simple function forwarding you can use the
```
void actual_f([optionalParam]) {
if (optionalParam == null) {
optionalParam = defaultValue;
}
....
}
void forwarding_f([optionalParam]) => actual_f(optionalParam);
```
Otherwise you have to do
```
void forward_f([optionalParam]) {
if (optionalParam != null) {
actual_f(optionalParam);
} else {
actual_f()l
}
}
```
With NNBD, this won't be possible anymore and you will always have a
combinatorial explosion because passing on null won't work anymore.

Context:
https://github.com/chalin/DEP-non-null/blob/master/doc/dep-non-null-AUTOGENERATED-DO-NOT-EDIT.md#e11-optional-parameters-are-nullable-by-default-in-function-bodies-only

In your example `optionalParam` is dynamic. There's a comment in that
section about when `p` is implicitly `dynamic`, but I'm not sure I can
follow what it's trying to say. Is `optionalParam` type `!dynamic` from the
perspective of forward_f?

On Wed, Jun 10, 2015 at 6:53 AM, 'Andreas Kirsch' via Dart Misc <

Post by 'Andreas Kirsch' via Dart Misc
```
typedef void Actual_F([optionalParam]);
Actual_F get forward_f => actual_f;
```
fixes all combinatorial issues I mentioned above. It is not what you would
expect usually, but it seems to work and if you take on the work to create
typedefs, it even does parameter type checking etc.

yeah, but often forwarding needs to do something before or after, take an
extra argument, etc. That was the problem we had with the prefix ? missing
argument operator.

The combinatorial explosion is a bit scary. I think we'd mitigate it by
design guidelines that say to always use ?T if default value is null, or
else use a default value other than null. It may be worth filing this as an
issue on the DEP.

['Bob Nystrom' via Dart Misc]

On Wed, Jun 10, 2015 at 8:05 AM, 'John Messerly' via Dart Misc <

I think we'd mitigate it by design guidelines that say to always use ?T if
default value is null

I think this is what I'd do. If a parameter is "optional" that pretty much
does imply its, well, optional, and may be absent. To me, "null" is sanest
value to use to indicate an absent parameter. That means the type of my
optional parameters will be nullable.

Cheers!

- bob

['Andreas Kirsch' via Dart Misc]

Thanks for linking to the DEP and adding context to my rambling! :)

"E.g., one can invoke f, defined above, as either f() or f(1), but f(null)
would result in a static warning and dynamic type error." is the bit that
causes my slight headache.

However, this is not a real issue of NNBD. It's more that the optional
parameter feature in Dart does not feel complete. Hopefully, someone will
provide a DEP for that eventually.

Thanks!

On Wed, Jun 10, 2015 at 5:56 PM 'Bob Nystrom' via Dart Misc <

Post by 'Bob Nystrom' via Dart Misc
On Wed, Jun 10, 2015 at 8:05 AM, 'John Messerly' via Dart Misc <

I think we'd mitigate it by design guidelines that say to always use ?T
if default value is null

I think this is what I'd do. If a parameter is "optional" that pretty much
does imply its, well, optional, and may be absent. To me, "null" is sanest
value to use to indicate an absent parameter. That means the type of my
optional parameters will be nullable.
Cheers!
- bob
--
For other discussions, see https://groups.google.com/a/dartlang.org/
For HOWTO questions, visit http://stackoverflow.com/tags/dart
To file a bug report or feature request, go to http://www.dartbug.com/new
To unsubscribe from this group and stop receiving emails from it, send an

[Vadim Tsushko]

If (as in document) your f declared as:

int f([int i = 0]) => i;

Why you do not want f(null) give you static warning?
You already gave both type and default value parameter

Post by 'Andreas Kirsch' via Dart Misc
Thanks for linking to the DEP and adding context to my rambling! :)
"E.g., one can invoke f, defined above, as either f() or f(1), but f(null)
would result in a static warning and dynamic type error." is the bit that
causes my slight headache.
However, this is not a real issue of NNBD. It's more that the optional
parameter feature in Dart does not feel complete. Hopefully, someone will
provide a DEP for that eventually.
Thanks!
On Wed, Jun 10, 2015 at 5:56 PM 'Bob Nystrom' via Dart Misc <

Post by 'Bob Nystrom' via Dart Misc
On Wed, Jun 10, 2015 at 8:05 AM, 'John Messerly' via Dart Misc <

I think we'd mitigate it by design guidelines that say to always use ?T
if default value is null

I think this is what I'd do. If a parameter is "optional" that pretty
much does imply its, well, optional, and may be absent. To me, "null" is
sanest value to use to indicate an absent parameter. That means the type of
my optional parameters will be nullable.
Cheers!
- bob
--
For other discussions, see https://groups.google.com/a/dartlang.org/
For HOWTO questions, visit http://stackoverflow.com/tags/dart
To file a bug report or feature request, go to http://www.dartbug.com/new
To unsubscribe from this group and stop receiving emails from it, send an

[Anders Holmgren]

I agree that default values on optional parameters as they exist to day
(independent of this DEP) tend to be fairly useless once you start
forwarding them as you end up needing to specify the same default values on
all the methods.
I raised an issue for this DEP to consider them but it was felt they didn't
belong in this one, which is fair enough. But it would be nice to fit this
into another DEP (possibly its own

Post by Vadim Tsushko
int f([int i = 0]) => i;
Why you do not want f(null) give you static warning?
You already gave both type and default value parameter

Post by 'Andreas Kirsch' via Dart Misc
Thanks for linking to the DEP and adding context to my rambling! :)
"E.g., one can invoke f, defined above, as either f() or f(1), but
f(null) would result in a static warning and dynamic type error." is the
bit that causes my slight headache.
However, this is not a real issue of NNBD. It's more that the optional
parameter feature in Dart does not feel complete. Hopefully, someone will
provide a DEP for that eventually.
Thanks!
On Wed, Jun 10, 2015 at 5:56 PM 'Bob Nystrom' via Dart Misc <

Post by 'Bob Nystrom' via Dart Misc
On Wed, Jun 10, 2015 at 8:05 AM, 'John Messerly' via Dart Misc <

I think we'd mitigate it by design guidelines that say to always use ?T
if default value is null

I think this is what I'd do. If a parameter is "optional" that pretty
much does imply its, well, optional, and may be absent. To me, "null" is
sanest value to use to indicate an absent parameter. That means the type of
my optional parameters will be nullable.
Cheers!
- bob
--
For other discussions, see https://groups.google.com/a/dartlang.org/
For HOWTO questions, visit http://stackoverflow.com/tags/dart
To file a bug report or feature request, go to
http://www.dartbug.com/new
To unsubscribe from this group and stop receiving emails from it, send

--

For other discussions, see https://groups.google.com/a/dartlang.org/
For HOWTO questions, visit http://stackoverflow.com/tags/dart
To file a bug report or feature request, go to http://www.dartbug.com/new

[Danny Tuppeny]

Post by Alex Tatumizer
There's certainly a problem with null, but not exactly the kind of problem
addressed by this proposal IMO.
To keep it short: "null" is meaningless. It can mean "Unknown",
"Unitialized", "CannotBeRepresentedByInt","UseDefault", etc etc, and with
single null, these meanings are not differentiated.

I'm a big fan of the idea of NNBD.

The big issue with null is that is is often an undesirable and invalid case
that we have to code for. Let's say I have a boolean state in my app for
which the only valid (logical) values are true or false. When I write code
that checks this, I can:

1. Ignore nulls, and assume it will never happen
2. Treat null as true
3. Treat null as false
4. Crash if null

None of these are good. (1) is hard to verify (I had to read all code and
ensure nothing sets it to a value that could be null), and could change in
future. (2) and (3) may do bad unexpected things. (4) is more work (why am
I writing code to check for a condition that should never occur).

It should absolutely be possible to have the compiler enforce this for me.
I really don't know why languages are still being designed today that have
this concept of nulls. If we want a "null value" we can build it without
one in the language. If we do not want one, we cannot remove it if the
language supports it. The only valid reason I see for it is interop with
other languages and even that I don't believe is a good reason.

Language designers: Stop f***ing doing this! Let us decide what's valid in
our program and what's not.

And once we've all agreed on this, can we eliminate an even bigger lie in
our type systems... Exceptions? :)

[Günter Zöchbauer]

I mostly agree with your view on nulls. I think it's helpful sometimes if
null is available to indicate "uninitialized" but usually null is just a
burden.
I developed in a language for about 6 years which didn't have null at all
and rarely missed null.
One case was an interface to an C++ application which controlled a plant,
but I would count that as legacy.
Not having null needed some workarounds when working with databases,
especially Oracle made it quite cumbersome to work without null back then -
don't know if they ever implemented storing empty strings as empty strings
instead of auto-converting to null, but these workarounds were part of the
language and framework so there actually was no issue related to missing
null.
I only found out about the required workarounds later when I tried to do
something similar in C# when I learned that Oracle causes quite some
troubles when you want to avoid null.

What's your issue with exceptions?

Post by Danny Tuppeny

Post by Alex Tatumizer
There's certainly a problem with null, but not exactly the kind of
problem addressed by this proposal IMO.
To keep it short: "null" is meaningless. It can mean "Unknown",
"Unitialized", "CannotBeRepresentedByInt","UseDefault", etc etc, and with
single null, these meanings are not differentiated.

I'm a big fan of the idea of NNBD.
The big issue with null is that is is often an undesirable and invalid
case that we have to code for. Let's say I have a boolean state in my app
for which the only valid (logical) values are true or false. When I write
1. Ignore nulls, and assume it will never happen
2. Treat null as true
3. Treat null as false
4. Crash if null
None of these are good. (1) is hard to verify (I had to read all code and
ensure nothing sets it to a value that could be null), and could change in
future. (2) and (3) may do bad unexpected things. (4) is more work (why am
I writing code to check for a condition that should never occur).
It should absolutely be possible to have the compiler enforce this for me.
I really don't know why languages are still being designed today that have
this concept of nulls. If we want a "null value" we can build it without
one in the language. If we do not want one, we cannot remove it if the
language supports it. The only valid reason I see for it is interop with
other languages and even that I don't believe is a good reason.
Language designers: Stop f***ing doing this! Let us decide what's valid in
our program and what's not.
And once we've all agreed on this, can we eliminate an even bigger lie in
our type systems... Exceptions? :)

[Anders Holmgren]

I think I will make everything non null and use Option for the nullable
case. That's what I do already but now the analyser will help me

Post by Günter Zöchbauer
I mostly agree with your view on nulls. I think it's helpful sometimes if
null is available to indicate "uninitialized" but usually null is just a
burden.
I developed in a language for about 6 years which didn't have null at all
and rarely missed null.
One case was an interface to an C++ application which controlled a plant,
but I would count that as legacy.
Not having null needed some workarounds when working with databases,
especially Oracle made it quite cumbersome to work without null back then -
don't know if they ever implemented storing empty strings as empty strings
instead of auto-converting to null, but these workarounds were part of the
language and framework so there actually was no issue related to missing
null.
I only found out about the required workarounds later when I tried to do
something similar in C# when I learned that Oracle causes quite some
troubles when you want to avoid null.
What's your issue with exceptions?

Post by Danny Tuppeny

Post by Alex Tatumizer
There's certainly a problem with null, but not exactly the kind of
problem addressed by this proposal IMO.
To keep it short: "null" is meaningless. It can mean "Unknown",
"Unitialized", "CannotBeRepresentedByInt","UseDefault", etc etc, and with
single null, these meanings are not differentiated.

I'm a big fan of the idea of NNBD.
The big issue with null is that is is often an undesirable and invalid
case that we have to code for. Let's say I have a boolean state in my app
for which the only valid (logical) values are true or false. When I write
1. Ignore nulls, and assume it will never happen
2. Treat null as true
3. Treat null as false
4. Crash if null
None of these are good. (1) is hard to verify (I had to read all code and
ensure nothing sets it to a value that could be null), and could change in
future. (2) and (3) may do bad unexpected things. (4) is more work (why am
I writing code to check for a condition that should never occur).
It should absolutely be possible to have the compiler enforce this for
me. I really don't know why languages are still being designed today that
have this concept of nulls. If we want a "null value" we can build it
without one in the language. If we do not want one, we cannot remove it if
the language supports it. The only valid reason I see for it is interop
with other languages and even that I don't believe is a good reason.
Language designers: Stop f***ing doing this! Let us decide what's valid
in our program and what's not.
And once we've all agreed on this, can we eliminate an even bigger lie in
our type systems... Exceptions? :)

--
For other discussions, see https://groups.google.com/a/dartlang.org/
For HOWTO questions, visit http://stackoverflow.com/tags/dart
To file a bug report or feature request, go to http://www.dartbug.com/new

[Danny Tuppeny]

Post by Günter Zöchbauer
I mostly agree with your view on nulls. I think it's helpful sometimes if
null is available to indicate "uninitialized" but usually null is just a
burden.

When there is no null, there's always something to replace it (eg. Option).
In this case, you can choose when to use it, rather than have it forced
upon you.

Post by Günter Zöchbauer
don't know if they ever implemented storing empty strings as empty strings
instead of auto-converting to null

This sounds like a silly bug/implementation issue rather than an issue with
null/not null. As developers we should have complete control over our
types. If we want null, we should have some option, and if we don't, we
shouldn't. SQL Server has has had the ability to have nullable and
non-nullable fields (probably) forever. If you want a bitfield that can
have a NULL that's fine, but if you don't, you can do that too. If you want
a string that can be stored as empty or null to mean different things,
that's possible, and if not, you can ensure there's no null.

I really don't understand why programming languages keep doing the null
thing. There's simply no good argument for it, and so many against.
NPEs/NREs are probably the most common exception by a huge factor. Every
time an Android app crashes on me, I tap through to see the stack trace
(being curious), and 99% of the time, it's an NPE. It just needs to end! ;(

What's your issue with exceptions?
Similar to nulls (but worse), they are a lie in the type system. I write
you a method that says it returns true or false, but it can actually return
true, false, or throw. Error/failure information should (mostly) be encoded
in the return type, so that it's discoverable and harder to accidentally
ignore. Currently it's just a big get-out if you can't return the type you
originally declared. Although people say you shouldn't use exceptions for
anything that's not an exception, that's just not how it's worked out.

I haven't used it, but I believe Go made real attempts to address this,
with error information being part of the return types. However they do
still have Panic/Recover which might undermine the idea of no exceptions
(though I don't know enough about it to have a real opinion, nor do I know
if Go developers find it to be better or worse in practice).

So nulls and exceptions cause similar issues - restricting the ability to
properly express what your code will/won't return, or rely on what someone
elses code claims to return. The more runtime errors we can make
compile-time errors, the better.

['Bob Nystrom' via Dart Misc]

Putting on my language nerd hat for a minute...

Post by Danny Tuppeny
Similar to nulls (but worse), they are a lie in the type system. I write
you a method that says it returns true or false, but it can actually return
true, false, or throw.

From the perspective of the type system, exceptions are perfectly sound.
Consider this:

int throws() => throw "oops!";

var result = throws();


Here the throws() function declares that it will always return an int. What
that means is that an expression that is an invocation of throws() will
evaluate to an integer *if it completes. *And, in this case, it does. You
will never ever ever get a value for result that is not an int. Granted,
that's because you'll never get to the point where result is even assigned
a value, but that's not the type system's fault. A return type describes
what kinds of values you get *given the assumption execution proceeds
normally*. Exceptions are a case where that assumption is not true, but it
doesn't mean the return type is any more wrong than it is here:

int neverReturns() {
while (true) {}
}

Even catch clauses are type safe because you simply won't enter it if the
type doesn't match. You can make a language that is fully, perfectly
statically sound without much difficulty even while having exceptions. It
just means some programs may abort abnormally. But that's pretty much
always the case. Most type systems don't try to track stack overflows, out
of memory errors, or infinite loops either. Exceptions are a more limited
case of that kind of behavior where execution may stop or jump to a
different part of a program.

Personally, I think they are a really really nice feature.

Post by Danny Tuppeny
Error/failure information should (mostly) be encoded in the return type,
so that it's discoverable and harder to accidentally ignore.

They tried that with checked exceptions in Java. In practice, it's really
painful to work with. In most cases, exceptions are, well, exceptional, and
it's too cumbersome to *always* force programmers to deal with it. Maybe
Java could have made this work better by having some syntactic sugar to
ignore checked exceptions in the kind of scripty code where it makes sense
to not deal with them, but the overall consensus is that they were a bad
idea.

Post by Danny Tuppeny
I haven't used it, but I believe Go made real attempts to address this,
with error information being part of the return types. However they do
still have Panic/Recover which might undermine the idea of no exceptions
(though I don't know enough about it to have a real opinion, nor do I know
if Go developers find it to be better or worse in practice).

Right, Go did two things weird:

1. They added panic, so you still have to deal with unwinding in your
code and make sure you defer. You still have to assume your function may
exit spontaneously, so you lose the local reasoning of say, C.

2. They made errors a *product* type instead of a *sum* type. That means
a function that can fail returns *both* a result value and an error.
Better make sure you check to see if one or the other is zero-initialized!
What I think they should have done—which is what almost every other
language that returns errors does—is return a success value *or* an
error.

Cheers!

- bob

[Danny Tuppeny]

Post by 'Bob Nystrom' via Dart Misc
Putting on my language nerd hat for a minute...
// ... ///
Even catch clauses are type safe because you simply won't enter it if the
type doesn't match. You can make a language that is fully, perfectly
statically sound without much difficulty even while having exceptions. It
just means some programs may abort abnormally. But that's pretty much
always the case. Most type systems don't try to track stack overflows, out
of memory errors, or infinite loops either. Exceptions are a more limited
case of that kind of behavior where execution may stop or jump to a
different part of a program.

Sure, but it's a a subtle behaviour that is easily missed and not well
communicated. The type system is sound at compile time (assuming no casts
etc., but let's not go into that ;)), exceptions are a big source of
runtime failures.

Post by 'Bob Nystrom' via Dart Misc
Personally, I think they are a really really nice feature.

I think they could be, if used appropriately. I think they're way over used
because they're easy and cheap (it's easier to throw an exception if the
file is not found, than to propagate that error information back in a
return type).

Post by 'Bob Nystrom' via Dart Misc
They tried that with checked exceptions in Java. In practice, it's really
painful to work with. In most cases, exceptions are, well, exceptional, and
it's too cumbersome to *always* force programmers to deal with it. Maybe
Java could have made this work better by having some syntactic sugar to
ignore checked exceptions in the kind of scripty code where it makes sense
to not deal with them, but the overall consensus is that they were a bad
idea.

I knew someone would mention checked exceptions! I've done very little
Java, and it's because of this. My first 30 mins with Java were so utterly
frustrating I ragequit and vowed never to go back. It was for exactly the
reasons you mentioned - I was writing my first Android app, and wanted to
just call some APIs and examine the return values... I couldn't compile
without handling every error (I really didn't care about exceptions at the
time, I was exploring). The IDE had this "helpful" command to just fill in
a load of empty catch blocks for me. Of course, once my application is
littered top-to-bottom with these, it's not going to be a fun job to go and
put in the "correct" code for them.

I think the *idea* of checked exceptions is good, but it just doesn't work
out. Having the info in the return values is far less intrusive and less
frustrating!

Post by 'Bob Nystrom' via Dart Misc
I haven't used it, but I believe Go made real attempts to address this,

Post by Danny Tuppeny
with error information being part of the return types. However they do
still have Panic/Recover which might undermine the idea of no exceptions
(though I don't know enough about it to have a real opinion, nor do I know
if Go developers find it to be better or worse in practice).

1. They added panic, so you still have to deal with unwinding in your
code and make sure you defer. You still have to assume your function may
exit spontaneously, so you lose the local reasoning of say, C.
2. They made errors a *product* type instead of a *sum* type. That
means a function that can fail returns *both* a result value and an
error. Better make sure you check to see if one or the other is
zero-initialized! What I think they should have done—which is what almost
every other language that returns errors does—is return a success value
*or* an error.

1. Yeah, when I read about Panic/Recover, my enthusiasm was dampened :( I'm
sure there were good reasons for it, but now it just seems like there are
two ways of doing errors you have to pick between (if I was told to write
data to disk, and the path is invalid, is that a panic or a graceful
return?)

2. Hmm, that does sound a bit strange... I wonder what the reason for that
is... I wish I had time to learn all of these different languages; there's
so much good information in learning why languages have the features they
do (or don't)!

[Anders Holmgren]

You could always us Either if you don't like exceptions. I tried it for a
bit but found it went to generics hell pretty quickly and gave up

Post by 'Bob Nystrom' via Dart Misc

Post by 'Bob Nystrom' via Dart Misc
Putting on my language nerd hat for a minute...

// ... ///
Even catch clauses are type safe because you simply won't enter it if the

Post by 'Bob Nystrom' via Dart Misc
type doesn't match. You can make a language that is fully, perfectly
statically sound without much difficulty even while having exceptions. It
just means some programs may abort abnormally. But that's pretty much
always the case. Most type systems don't try to track stack overflows, out
of memory errors, or infinite loops either. Exceptions are a more limited
case of that kind of behavior where execution may stop or jump to a
different part of a program.

Sure, but it's a a subtle behaviour that is easily missed and not well
communicated. The type system is sound at compile time (assuming no casts
etc., but let's not go into that ;)), exceptions are a big source of
runtime failures.

Post by 'Bob Nystrom' via Dart Misc
Personally, I think they are a really really nice feature.

I think they could be, if used appropriately. I think they're way over
used because they're easy and cheap (it's easier to throw an exception if
the file is not found, than to propagate that error information back in a
return type).

Post by 'Bob Nystrom' via Dart Misc
They tried that with checked exceptions in Java. In practice, it's really
painful to work with. In most cases, exceptions are, well, exceptional, and
it's too cumbersome to *always* force programmers to deal with it. Maybe
Java could have made this work better by having some syntactic sugar to
ignore checked exceptions in the kind of scripty code where it makes sense
to not deal with them, but the overall consensus is that they were a bad
idea.

I knew someone would mention checked exceptions! I've done very little
Java, and it's because of this. My first 30 mins with Java were so utterly
frustrating I ragequit and vowed never to go back. It was for exactly the
reasons you mentioned - I was writing my first Android app, and wanted to
just call some APIs and examine the return values... I couldn't compile
without handling every error (I really didn't care about exceptions at the
time, I was exploring). The IDE had this "helpful" command to just fill in
a load of empty catch blocks for me. Of course, once my application is
littered top-to-bottom with these, it's not going to be a fun job to go and
put in the "correct" code for them.
I think the *idea* of checked exceptions is good, but it just doesn't
work out. Having the info in the return values is far less intrusive and
less frustrating!

Post by 'Bob Nystrom' via Dart Misc
I haven't used it, but I believe Go made real attempts to address this,

Post by Danny Tuppeny
with error information being part of the return types. However they do
still have Panic/Recover which might undermine the idea of no exceptions
(though I don't know enough about it to have a real opinion, nor do I know
if Go developers find it to be better or worse in practice).

1. They added panic, so you still have to deal with unwinding in your
code and make sure you defer. You still have to assume your function may
exit spontaneously, so you lose the local reasoning of say, C.
2. They made errors a *product* type instead of a *sum* type. That
means a function that can fail returns *both* a result value and an
error. Better make sure you check to see if one or the other is
zero-initialized! What I think they should have done—which is what almost
every other language that returns errors does—is return a success value
*or* an error.

1. Yeah, when I read about Panic/Recover, my enthusiasm was dampened :(
I'm sure there were good reasons for it, but now it just seems like there
are two ways of doing errors you have to pick between (if I was told to
write data to disk, and the path is invalid, is that a panic or a graceful
return?)
2. Hmm, that does sound a bit strange... I wonder what the reason for that
is... I wish I had time to learn all of these different languages; there's
so much good information in learning why languages have the features they
do (or don't)!
--
For other discussions, see https://groups.google.com/a/dartlang.org/
For HOWTO questions, visit http://stackoverflow.com/tags/dart
To file a bug report or feature request, go to http://www.dartbug.com/new

[Danny Tuppeny]

Post by Anders Holmgren
You could always us Either if you don't like exceptions. I tried it for a
bit but found it went to generics hell pretty quickly and gave up

It's more of other peoples code I dislike them for. I pull in a third party
library and the API is documented (if I'm lucky), but none of the
exceptions :(

[Daniel Joyce]

Thats because exceptions can emerge all the way down, library uses a
library which uses the VM. At the top level, it becomes nearly impossible
to list all potential exceptions that may be thrown. It has always been a
problem.

Post by Danny Tuppeny

Post by Anders Holmgren
You could always us Either if you don't like exceptions. I tried it for a
bit but found it went to generics hell pretty quickly and gave up

It's more of other peoples code I dislike them for. I pull in a third
party library and the API is documented (if I'm lucky), but none of the
exceptions :(
--
For other discussions, see https://groups.google.com/a/dartlang.org/
For HOWTO questions, visit http://stackoverflow.com/tags/dart
To file a bug report or feature request, go to http://www.dartbug.com/new
To unsubscribe from this group and stop receiving emails from it, send an

--
Daniel Joyce

The meek shall inherit the Earth, for the brave will be among the stars.

[Danny Tuppeny]

Post by Daniel Joyce
Thats because exceptions can emerge all the way down, library uses a
library which uses the VM. At the top level, it becomes nearly impossible
to list all potential exceptions that may be thrown. It has always been a
problem.

Sure; I'm not saying there's not a good reason they're not documented; but
it doesn't help us write stable software. I think we need something better
than exceptions; and it probably needs to be something with language
support. I just don't think exceptions are the way.

[Don Olmstead]

The solution is to just not use exceptions [?]

Post by Danny Tuppeny

Post by Daniel Joyce
Thats because exceptions can emerge all the way down, library uses a
library which uses the VM. At the top level, it becomes nearly impossible
to list all potential exceptions that may be thrown. It has always been a
problem.

Sure; I'm not saying there's not a good reason they're not documented; but
it doesn't help us write stable software. I think we need something better
than exceptions; and it probably needs to be something with language
support. I just don't think exceptions are the way.
--
For other discussions, see https://groups.google.com/a/dartlang.org/
For HOWTO questions, visit http://stackoverflow.com/tags/dart
To file a bug report or feature request, go to http://www.dartbug.com/new
To unsubscribe from this group and stop receiving emails from it, send an

[Danny Tuppeny]

Post by Don Olmstead
The solution is to just not use exceptions [?]

I sometimes have to consume other peoples code. 15 years of doing this is
pushing me towards preferring to write my own code than depend on third
parties because the quality is so unknown. The main product I work on
currently runs on a custom fork of NHibernate because of serious bugs that
have patches posted to their issue tracker that have never been merged with
no reason. Even a "well known" third party library can be of questionable
quality :(

I feel I have somewhat derailed this thread! :-/

[Alex Tatumizer]

The main product I work on currently runs on a custom fork of NHibernate

Don't use bloated 1-mln LOC "frameworks" that serve unknown purpose.
Don't write 1-mln LOC programs that serve unknown purpose ("unknown" by
definition - no one can be expected to know that much).
You will see major improvement in your life :-)

I'm doing this for 35 years, and all my "fights" so far were solely against
complexity. Fighting with others and also with myself. With mixed success
though.

Post by Don Olmstead
The solution is to just not use exceptions [?]

I sometimes have to consume other peoples code. 15 years of doing this is
pushing me towards preferring to write my own code than depend on third
parties because the quality is so unknown. The main product I work on
currently runs on a custom fork of NHibernate because of serious bugs that
have patches posted to their issue tracker that have never been merged with
no reason. Even a "well known" third party library can be of questionable
quality :(
I feel I have somewhat derailed this thread! :-/
--
For other discussions, see https://groups.google.com/a/dartlang.org/
For HOWTO questions, visit http://stackoverflow.com/tags/dart
To file a bug report or feature request, go to http://www.dartbug.com/new

[Danny Tuppeny]

Post by Alex Tatumizer

The main product I work on currently runs on a custom fork of NHibernate

Don't use bloated 1-mln LOC "frameworks" that serve unknown purpose.

Unfortuantely this PoS was in the codebase long before I joined (along with
PostSharp, and other junk of questionable quality
<https://plus.google.com/113181962167438638669/posts/QF5pDB4XY6F>).
Sometimes, third party code seems like a good idea, and then turns out not
to be. The best fix is to improve the quality of libraries (which fixing
issues like forced nulls and poor use of exceptions helps) rather than to
just avoid them (though for now, avoiding is probably the best option!).

Post by Alex Tatumizer
Don't write 1-mln LOC programs that serve unknown purpose ("unknown" by
definition - no one can be expected to know that much).
You will see major improvement in your life :-)

Again; most of it was before my time; but nobody wrote a 1m LoC program, it
just started off as a small application and grew over time. We're working
on fixing this, but unsurprisingly, it's a massive job.

Post by Alex Tatumizer
I'm doing this for 35 years, and all my "fights" so far were solely
against complexity. Fighting with others and also with myself. With mixed
success though.

It's one of the reasons I'm a big fan of non-null, pure functions,
immutability... Lack of these all add complexity we don't want; but current
languages force upon us. Any language that tries to gets these right seems
to be considered niche and doesn't get adopted as well as those that copy
the flaws of those before them. We could get so much more from our
languages and tools, but the majority of devs don't see the benefits of
them.

C# seems to be doing well at stealing some of these ideas though (there's
talk of non-null in C# 7, there's first-party immutable collections, and I
keep my fingers crossed Code Contracts will one day become more than a MSR
project). Roslyn analyzers are looking good too. And if Duocode turns out
to work well, we could have all of these things in our client-side code
too! :)

[kc]

Post by Danny Tuppeny
It's one of the reasons I'm a big fan of non-null, pure functions,
immutability... Lack of these all add complexity we don't want; but current
languages force upon us. Any language that tries to gets these right seems
to be considered niche and doesn't get adopted as well as those that copy
the flaws of those before them. We could get so much more from our
languages and tools, but the majority of devs don't see the benefits of
them.

Definitely. A better immutability/pure story from Dart would help. The
whole React philosophy is about diff-ing trees of value objects and
immutability for performance and complexity management.

Post by Danny Tuppeny
C# seems to be doing well at stealing some of these ideas though (there's
talk of non-null in C# 7, there's first-party immutable collections, and I
keep my fingers crossed Code Contracts will one day become more than a MSR
project). Roslyn analyzers are looking good too. And if Duocode turns out
to work well, we could have all of these things in our client-side code
too! :)

C# 7 is going in a very interesting direction.

K.

[Alex Tatumizer]

And if Duocode turns out to work well, we could have all of these things

in our client-side code too! :)
Duocode looks really impressive. But what's the point? As soon as it gets
released, the "community" will be all over it porting their favorite
10-megaton kludge into the new field, spamming every blog and news
aggregator, spreading fake evidences and anecdotes on how it improves their
"productivity" etc. - the same we saw over and over with every
language/platform. In the end, it won't matter one single bit that there's
C# underneath, as opposed to, say, javascript or dart or you name it.
This effect doesn't come from somebody's evil mind- it's a product of
current mindset among current generation of programmers, a kind of mass
delusion, there's no cure for this.

[Danny Tuppeny]

Post by Alex Tatumizer

And if Duocode turns out to work well, we could have all of these things

in our client-side code too! :)
Duocode looks really impressive. But what's the point?

There are many advantages to this, such as...

- A level of type safety neither TypeScript nor Dart provide
- Excellent Visual Studio support (even TypeScript's VS support is poor
compared to C#)
- Ability to write Roslyn-based code analyzers/fixes against client code
as well as server
- Sharing DTO classes between client/server to ensure client app and
server API can't be out of sync

We've spent a long time evaluating all sorts of tech for our future work,
and DuoCode looks to give us the best of all of the things we've looked at
(we've created bindings for React/Flux
<http://www.productiverage.com/react-and-flux-with-duocode> and Jasmine and
have a C# implementation of the Dart test runner to automate browsers and
collate the results). It's looking incredibly promising so far!

[Alex Tatumizer]

I can see advantages of DuoCode, but I'm afraid somebody with a
brainwashing power will hijack it to build something like Angular, and then
every corporate employer will require C#+Angular (this sum, for me, is less
than zero).
But suppose the impossible happens (miracle), and we have clean and pure
DuoCode UI component library.
Hesitating to ask: why do you (we?) need dart then? What is the advantage
of dart over DuoCode? The latter is much more mature, familiar to many
users, has quite decent IDE, no risk of sudden death, (+ all other things
you mentioned). ???

[Danny Tuppeny]

Post by Alex Tatumizer
I can see advantages of DuoCode, but I'm afraid somebody with a
brainwashing power will hijack it to build something like Angular, and then
every corporate employer will require C#+Angular (this sum, for me, is less
than zero).

This is no different to every corporate employer requiring AngularJS. But I
don't think it makes sense to say "we shouldn't have something good,
because they every employer will want it". If it's good, it's not a bad
thing that they'll want it. If it's not good, it's unlikely they'll want
it. The sort of companies that let non-technical managers demand particular
skills that you don't think are good are not the companies you want to work
for anyway.


But suppose the impossible happens (miracle), and we have clean and pure

Post by Alex Tatumizer
DuoCode UI component library.
Hesitating to ask: why do you (we?) need dart then? What is the advantage
of dart over DuoCode? The latter is much more mature, familiar to many
users, has quite decent IDE, no risk of sudden death, (+ all other things
you mentioned). ???

Even if C# is mature and here to stay, Duocode is still new and unknown; so
there are still similar risks of sudden death etc (though I hope neither
DuoCode or Dart disappear anytime soon!).

That aside, I just can't see any world in which case 100% (or even close)
would agree C# is better than Dart. The real question for Dart is how many
users does it need in order for Google to continue putting resources into
it (and that question is still valid, even without Duocode).

Nobody is complaining about too much choice in languages on the server. We
get to pick our language based on all sorts of factors (ease of
development, maintainability, suitability of job, familiarity, easy of
recruiting experienced devs, to name just a few). If we had some
language-agnostic VM in all browsers that meant we could write lots of
different languages, I would view this as a good (great!) thing. We should
have the freedome to pick our front-end languages just like we can pick the
server-side ones.

A colleague today reminded me of a blog post
<http://blog.dantup.com/2014/05/web-development-sucks-and-its-not-getting-any-better/>
where I said all compile-to-JavaScript languages are a hack. Even though
I'm a big fan of both Dart and DuoCode, I do still stand by that somewhat.
Nobody is compiling to JavaScript because it's a good idea. It's because
it's the only thing we can do. We're desperate to avoid writing JavaScript,
yet it's the only thing we can run in the browsers.

It's kinda tragic that the web got to where it is today with JavaScript. It
was a terrible accident. I really believe we need a language-agnostic
runtime/vm in all major browsers. I really didn't ever expect it to happen
(the chances of browser vendors working together are slim) but I now have a
little hope after the announcement of WebAssembly
<http://techcrunch.com/2015/06/17/google-microsoft-mozilla-and-others-team-up-to-launch-webassembly-a-new-binary-format-for-the-web/>.
Both Google and MS clearly want us to have something better with JavaScript
and if they're now open to working together to put the same thing into
their browsers to aid this; maybe one day we'll be able to cut our
JavaScript ties completely!

[Daniel Joyce]

So WebAssembly can't get here fast enough then, at least when it starts
allowing DOM access

Post by Danny Tuppeny

Post by Alex Tatumizer
I can see advantages of DuoCode, but I'm afraid somebody with a
brainwashing power will hijack it to build something like Angular, and then
every corporate employer will require C#+Angular (this sum, for me, is less
than zero).

This is no different to every corporate employer requiring AngularJS. But
I don't think it makes sense to say "we shouldn't have something good,
because they every employer will want it". If it's good, it's not a bad
thing that they'll want it. If it's not good, it's unlikely they'll want
it. The sort of companies that let non-technical managers demand particular
skills that you don't think are good are not the companies you want to work
for anyway.
But suppose the impossible happens (miracle), and we have clean and pure

Post by Alex Tatumizer
DuoCode UI component library.
Hesitating to ask: why do you (we?) need dart then? What is the advantage
of dart over DuoCode? The latter is much more mature, familiar to many
users, has quite decent IDE, no risk of sudden death, (+ all other things
you mentioned). ???

Even if C# is mature and here to stay, Duocode is still new and unknown;
so there are still similar risks of sudden death etc (though I hope neither
DuoCode or Dart disappear anytime soon!).
That aside, I just can't see any world in which case 100% (or even close)
would agree C# is better than Dart. The real question for Dart is how many
users does it need in order for Google to continue putting resources into
it (and that question is still valid, even without Duocode).
Nobody is complaining about too much choice in languages on the server. We
get to pick our language based on all sorts of factors (ease of
development, maintainability, suitability of job, familiarity, easy of
recruiting experienced devs, to name just a few). If we had some
language-agnostic VM in all browsers that meant we could write lots of
different languages, I would view this as a good (great!) thing. We should
have the freedome to pick our front-end languages just like we can pick the
server-side ones.
A colleague today reminded me of a blog post
<http://blog.dantup.com/2014/05/web-development-sucks-and-its-not-getting-any-better/>
where I said all compile-to-JavaScript languages are a hack. Even though
I'm a big fan of both Dart and DuoCode, I do still stand by that somewhat.
Nobody is compiling to JavaScript because it's a good idea. It's because
it's the only thing we can do. We're desperate to avoid writing JavaScript,
yet it's the only thing we can run in the browsers.
It's kinda tragic that the web got to where it is today with JavaScript.
It was a terrible accident. I really believe we need a language-agnostic
runtime/vm in all major browsers. I really didn't ever expect it to happen
(the chances of browser vendors working together are slim) but I now have a
little hope after the announcement of WebAssembly
<http://techcrunch.com/2015/06/17/google-microsoft-mozilla-and-others-team-up-to-launch-webassembly-a-new-binary-format-for-the-web/>.
Both Google and MS clearly want us to have something better with JavaScript
and if they're now open to working together to put the same thing into
their browsers to aid this; maybe one day we'll be able to cut our
JavaScript ties completely!
--
For other discussions, see https://groups.google.com/a/dartlang.org/
For HOWTO questions, visit http://stackoverflow.com/tags/dart
To file a bug report or feature request, go to http://www.dartbug.com/new
To unsubscribe from this group and stop receiving emails from it, send an

--
Daniel Joyce

The meek shall inherit the Earth, for the brave will be among the stars.

[Danny Tuppeny]

Post by Daniel Joyce
So WebAssembly can't get here fast enough then, at least when it starts
allowing DOM access

I presumed DOM access would be there from the start (though I haven't seen
anything explicitly say one way or the other). The tooling page
<https://github.com/WebAssembly/design/blob/master/Tooling.md> makes for
interesting reading too:

*Compilers and language virtual machines:*

- Compilers for languages which can target WebAssembly (C/C++, Rust, Go,
C#) should be able to run in WebAssembly themselves, emit a WebAssembly
module that can then be executed.
- Virtual machines for languages such as bash, Python, Ruby should work.
- Virtual machines which use a just-in-time compiler (JavaScript VMs,
luajit, pypy) should be able to support a new just-in-time backend for
WebAssembly.

Not only do they have languages like C#/Go/Rust in mind; but they want it
to be possible to have the compilers run in WebAssembly too! =D

[Günter Zöchbauer]

Post by Danny Tuppeny

Post by Daniel Joyce
So WebAssembly can't get here fast enough then, at least when it starts
allowing DOM access

I presumed DOM access would be there from the start (though I haven't seen
anything explicitly say one way or the other). The tooling page
<https://github.com/WebAssembly/design/blob/master/Tooling.md> makes for
*Compilers and language virtual machines:*
- Compilers for languages which can target WebAssembly (C/C++, Rust,
Go, C#) should be able to run in WebAssembly themselves, emit a WebAssembly
module that can then be executed.
- Virtual machines for languages such as bash, Python, Ruby should work.
- Virtual machines which use a just-in-time compiler (JavaScript VMs,
luajit, pypy) should be able to support a new just-in-time backend for
WebAssembly.
Not only do they have languages like C#/Go/Rust in mind; but they want it
to be possible to have the compilers run in WebAssembly too! =D

A lot of promotion but from what I have seen most things are dead slow
except some C code directly translated to asm.js.
Loading a Python or Ruby runtime (transpiled to asm.js) into the browser
and then loading Python or Ruby code to run on this runtime - just forget
it.

[Danny Tuppeny]

Post by Günter Zöchbauer
A lot of promotion but from what I have seen most things are dead slow
except some C code directly translated to asm.js.
Loading a Python or Ruby runtime (transpiled to asm.js) into the browser
and then loading Python or Ruby code to run on this runtime - just forget
it.

I don't see any logical or technical reason why we can't have the same
performance in the browser that we have outside of it. Maybe not
immediately if it'll still be executed as JS, but it sounds like the
long-term goal is much more than this.

[Günter Zöchbauer]

Post by Danny Tuppeny

Post by Günter Zöchbauer
A lot of promotion but from what I have seen most things are dead slow
except some C code directly translated to asm.js.
Loading a Python or Ruby runtime (transpiled to asm.js) into the browser
and then loading Python or Ruby code to run on this runtime - just forget
it.

I don't see any logical or technical reason why we can't have the same
performance in the browser that we have outside of it. Maybe not
immediately if it'll still be executed as JS, but it sounds like the
long-term goal is much more than this.

Sure, but I think it's a bit early to get excited.

[Danny Tuppeny]

Post by Günter Zöchbauer
Sure, but I think it's a bit early to get excited.

Maybe; but it's not often that all major browser manufacturers agree on a
common direction rather than going off and doing their own thing (NaCl
,PNaCl, Dart, asmjs, TypeScript...). It's a big milestone, even if it is
very early days :)

[Günter Zöchbauer]

Post by Danny Tuppeny
It's kinda tragic that the web got to where it is today with JavaScript.
It was a terrible accident. I really believe we need a language-agnostic
runtime/vm in all major browsers. I really didn't ever expect it to happen
(the chances of browser vendors working together are slim) but I now have a
little hope after the announcement of WebAssembly
<http://techcrunch.com/2015/06/17/google-microsoft-mozilla-and-others-team-up-to-launch-webassembly-a-new-binary-format-for-the-web/>.
Both Google and MS clearly want us to have something better with JavaScript
and if they're now open to working together to put the same thing into
their browsers to aid this; maybe one day we'll be able to cut our
JavaScript ties completely!

While I despise JS as a programming language for developing applications I
think that its ability to apply monkey-patching was and is critical for the
web to evolve. Remove this and the browser as a platform as we know it will
cease to exist and browsers will evolve to proprietary products where only
customized applications run.

[Benjamin Strauß]

Post by Günter Zöchbauer
While I despise JS as a programming language for developing applications I
think that its ability to apply monkey-patching was and is critical for the
web to evolve. Remove this and the browser as a platform as we know it will
cease to exist and browsers will evolve to proprietary products where only
customized applications run.

There are programming/language concepts that solve the same problem and are
much clearer, uniform and more compelling compared to javascript's monkey
patching.

[Günter Zöchbauer]

Post by Benjamin Strauß

Post by Günter Zöchbauer
While I despise JS as a programming language for developing applications
I think that its ability to apply monkey-patching was and is critical for
the web to evolve. Remove this and the browser as a platform as we know it
will cease to exist and browsers will evolve to proprietary products where
only customized applications run.

There are programming/language concepts that solve the same problem and
are much clearer, uniform and more compelling compared to javascript's
monkey patching.

I believe this without hesitation, but are these other options as flexible?
I don't care what concept is used, I'm just sure that this is a critical
point.

[Benjamin Strauß]

Post by Günter Zöchbauer

Post by Benjamin Strauß

Post by Günter Zöchbauer
While I despise JS as a programming language for developing applications
I think that its ability to apply monkey-patching was and is critical for
the web to evolve. Remove this and the browser as a platform as we know it
will cease to exist and browsers will evolve to proprietary products where
only customized applications run.

There are programming/language concepts that solve the same problem and
are much clearer, uniform and more compelling compared to javascript's
monkey patching.

I believe this without hesitation, but are these other options as flexible?
I don't care what concept is used, I'm just sure that this is a critical
point.

I don't want to go off topic too far but yes they are. See

for a direct example regarding the DOM.
I highly recommend to watch the whole session from Gilad. I hope he is
successful in putting this into Dart someday.

[Daniel Joyce]

Monkey patching is very dangerous. I've junk break in Rails because someone
Monkey patched something I didn't know about. Same for Javascript.

Scala implicit conversions give you 99% of the power for example, and are
typesafe. And it won't break anyone elses coded unless they explicitly
import your implicits.

Post by Benjamin Strauß

Post by Günter Zöchbauer

Post by Benjamin Strauß

Post by Günter Zöchbauer
While I despise JS as a programming language for developing
applications I think that its ability to apply monkey-patching was and is
critical for the web to evolve. Remove this and the browser as a platform
as we know it will cease to exist and browsers will evolve to proprietary
products where only customized applications run.

There are programming/language concepts that solve the same problem and
are much clearer, uniform and more compelling compared to javascript's
monkey patching.

I believe this without hesitation, but are these other options as flexible?
I don't care what concept is used, I'm just sure that this is a critical
point.

I don't want to go off topic too far but yes they are. See
http://youtu.be/ES0UKKVnFn4 for a direct example regarding the
DOM. I highly recommend to watch the whole session from Gilad. I hope he is
successful in putting this into Dart someday.
--
For other discussions, see https://groups.google.com/a/dartlang.org/
For HOWTO questions, visit http://stackoverflow.com/tags/dart
To file a bug report or feature request, go to http://www.dartbug.com/new
To unsubscribe from this group and stop receiving emails from it, send an

--
Daniel Joyce

The meek shall inherit the Earth, for the brave will be among the stars.

[Alex Tatumizer]

If it's good, it's not a bad thing that they'll want it. If it's not

good, it's unlikely they'll want it.
Haha. How do they know the thing is good if they never tried it before?
People are susceptible to propaganda, be it programming framework, healthy
diet, dress fashion or even philosophic view on origin of life.

Remember a mass delusion known at the time as "XML revolution"? These days,
we have a new "revolution" every week.

[Jan Mostert]

Java's got a @NotNull annotation which doesn't do much in Java (except for
muting warnings that a variable might not have been initialized, it doesn't
actually enforce anything),
but if null is a problem for some in Dart, why not implement something like
@NotNull and make it do something useful like forcing the value to
something default if it becomes null.

@NotNull(default=0)
int someRandomIntegerThatYouDontWantToBeNull;

print(someRandomIntegerThatYouDontWantToBeNull); //prints 0

someRandomIntegerThatYouDontWantToBeNull = 3;
print(someRandomIntegerThatYouDontWantToBeNull); //prints 3

someRandomIntegerThatYouDontWantToBeNull = null;
print(someRandomIntegerThatYouDontWantToBeNull); //prints 0






--
Jan Vladimir Mostert
janvladimirmostert.com

Post by Alex Tatumizer

If it's good, it's not a bad thing that they'll want it. If it's not

good, it's unlikely they'll want it.
Haha. How do they know the thing is good if they never tried it before?
People are susceptible to propaganda, be it programming framework, healthy
diet, dress fashion or even philosophic view on origin of life.
Remember a mass delusion known at the time as "XML revolution"? These
days, we have a new "revolution" every week.
--
For other discussions, see https://groups.google.com/a/dartlang.org/
For HOWTO questions, visit http://stackoverflow.com/tags/dart
To file a bug report or feature request, go to http://www.dartbug.com/new
To unsubscribe from this group and stop receiving emails from it, send an

[Günter Zöchbauer]

An annotation by itself doesn't do anything and Patrice created a great
proposal how to add this to the language properly.

Post by Jan Mostert
muting warnings that a variable might not have been initialized, it doesn't
actually enforce anything),
but if null is a problem for some in Dart, why not implement something
something default if it becomes null.
@NotNull(default=0)
int someRandomIntegerThatYouDontWantToBeNull;
print(someRandomIntegerThatYouDontWantToBeNull); //prints 0
someRandomIntegerThatYouDontWantToBeNull = 3;
print(someRandomIntegerThatYouDontWantToBeNull); //prints 3
someRandomIntegerThatYouDontWantToBeNull = null;
print(someRandomIntegerThatYouDontWantToBeNull); //prints 0
--
Jan Vladimir Mostert
janvladimirmostert.com

Post by Alex Tatumizer

If it's good, it's not a bad thing that they'll want it. If it's not

good, it's unlikely they'll want it.
Haha. How do they know the thing is good if they never tried it before?
People are susceptible to propaganda, be it programming framework, healthy
diet, dress fashion or even philosophic view on origin of life.
Remember a mass delusion known at the time as "XML revolution"? These
days, we have a new "revolution" every week.
--
For other discussions, see https://groups.google.com/a/dartlang.org/
For HOWTO questions, visit http://stackoverflow.com/tags/dart
To file a bug report or feature request, go to http://www.dartbug.com/new
To unsubscribe from this group and stop receiving emails from it, send an

['Lasse R.H. Nielsen' via Dart Misc]

Post by Günter Zöchbauer
An annotation by itself doesn't do anything and Patrice created a great
proposal how to add this to the language properly.

Absolutely true.
And you can already get the behavior today, it just takes more writing:

var _internal = 0;
int get someRandomIntegerThatYouDontWantToBeNull => _internal;
void set someRandomIntegerThatYouDontWantToBeNull(int value) {
if (value == null) value = 0;
_internal = value;
}

The place where non-null really matters is in typing of parameters and
return types, where you can't add setters.
/L
--
Lasse R.H. Nielsen - ***@google.com
'Faith without judgement merely degrades the spirit divine'
Google Denmark ApS - Frederiksborggade 20B, 1 sal - 1360 KÞbenhavn K
- Denmark - CVR nr. 28 86 69 84

[Jan Mostert]

Missed the original post, awesome writeup!
So the default mode will be nothing is null until you add that ? syntax
Looks ugly though, almost perl-like, maybe I'm just old-school, but the
@Nullable looks much more readable and seeing as it won't be used often,
occasionally add @Nullable doesn't seem like a big deal.



--
Jan Vladimir Mostert
janvladimirmostert.com

Post by Günter Zöchbauer
An annotation by itself doesn't do anything and Patrice created a great
proposal how to add this to the language properly.

for muting warnings that a variable might not have been initialized, it
doesn't actually enforce anything),
but if null is a problem for some in Dart, why not implement something
something default if it becomes null.
@NotNull(default=0)
int someRandomIntegerThatYouDontWantToBeNull;
print(someRandomIntegerThatYouDontWantToBeNull); //prints 0
someRandomIntegerThatYouDontWantToBeNull = 3;
print(someRandomIntegerThatYouDontWantToBeNull); //prints 3
someRandomIntegerThatYouDontWantToBeNull = null;
print(someRandomIntegerThatYouDontWantToBeNull); //prints 0
--
Jan Vladimir Mostert
janvladimirmostert.com

Post by Alex Tatumizer

If it's good, it's not a bad thing that they'll want it. If it's not

good, it's unlikely they'll want it.
Haha. How do they know the thing is good if they never tried it before?
People are susceptible to propaganda, be it programming framework, healthy
diet, dress fashion or even philosophic view on origin of life.
Remember a mass delusion known at the time as "XML revolution"? These
days, we have a new "revolution" every week.
--
For other discussions, see https://groups.google.com/a/dartlang.org/
For HOWTO questions, visit http://stackoverflow.com/tags/dart
To file a bug report or feature request, go to
http://www.dartbug.com/new
To unsubscribe from this group and stop receiving emails from it, send

[Jan Mostert]

PS, in what version can we expect the non-null goodness?
Is it something that is scheduled for V2 or is it around the corner?

--
Jan Vladimir Mostert
janvladimirmostert.com

Post by Jan Mostert
Missed the original post, awesome writeup!
So the default mode will be nothing is null until you add that ? syntax
Looks ugly though, almost perl-like, maybe I'm just old-school, but the
@Nullable looks much more readable and seeing as it won't be used often,
--
Jan Vladimir Mostert
janvladimirmostert.com

Post by Günter Zöchbauer
An annotation by itself doesn't do anything and Patrice created a great
proposal how to add this to the language properly.

for muting warnings that a variable might not have been initialized, it
doesn't actually enforce anything),
but if null is a problem for some in Dart, why not implement something
something default if it becomes null.
@NotNull(default=0)
int someRandomIntegerThatYouDontWantToBeNull;
print(someRandomIntegerThatYouDontWantToBeNull); //prints 0
someRandomIntegerThatYouDontWantToBeNull = 3;
print(someRandomIntegerThatYouDontWantToBeNull); //prints 3
someRandomIntegerThatYouDontWantToBeNull = null;
print(someRandomIntegerThatYouDontWantToBeNull); //prints 0
--
Jan Vladimir Mostert
janvladimirmostert.com

Post by Alex Tatumizer

If it's good, it's not a bad thing that they'll want it. If it's not

good, it's unlikely they'll want it.
Haha. How do they know the thing is good if they never tried it before?
People are susceptible to propaganda, be it programming framework, healthy
diet, dress fashion or even philosophic view on origin of life.
Remember a mass delusion known at the time as "XML revolution"? These
days, we have a new "revolution" every week.
--
For other discussions, see https://groups.google.com/a/dartlang.org/
For HOWTO questions, visit http://stackoverflow.com/tags/dart
To file a bug report or feature request, go to
http://www.dartbug.com/new
To unsubscribe from this group and stop receiving emails from it, send

['Lasse R.H. Nielsen' via Dart Misc]

Post by Jan Mostert
PS, in what version can we expect the non-null goodness?
Is it something that is scheduled for V2 or is it around the corner?

It's not even accepted yet, and it's a major change that requires all
implementations to be updated, so it's definitely not around the corner.

V2 is a good guess if it is accepted, but I'm not in a position to make
anything but guesses :)

/L
--
Lasse R.H. Nielsen - ***@google.com
'Faith without judgement merely degrades the spirit divine'
Google Denmark ApS - Frederiksborggade 20B, 1 sal - 1360 KÞbenhavn K
- Denmark - CVR nr. 28 86 69 84

[Daniel Joyce]

Yes, that is very horrible, and at least Either chaining with synactic
sugar is 'beautiful' compared to that. Trivial to convert exceptions to
Either as well.

Post by Daniel Joyce
Thats because exceptions can emerge all the way down, library uses a
library which uses the VM. At the top level, it becomes nearly impossible
to list all potential exceptions that may be thrown. It has always been a
problem.

Post by Danny Tuppeny

Post by Anders Holmgren
You could always us Either if you don't like exceptions. I tried it for
a bit but found it went to generics hell pretty quickly and gave up

It's more of other peoples code I dislike them for. I pull in a third
party library and the API is documented (if I'm lucky), but none of the
exceptions :(
--
For other discussions, see https://groups.google.com/a/dartlang.org/
For HOWTO questions, visit http://stackoverflow.com/tags/dart
To file a bug report or feature request, go to http://www.dartbug.com/new
To unsubscribe from this group and stop receiving emails from it, send an

--
Daniel Joyce
The meek shall inherit the Earth, for the brave will be among the stars.

--
Daniel Joyce

The meek shall inherit the Earth, for the brave will be among the stars.

[Daniel Joyce]

(for{
a <- doSomething1().right
b <- a.derp().right
x <- doSomething2().right
}yield(x)) match {
case Left[_] => "We had an error"
case Right[_] => "We're okay"
}

The need to use .right is a scala wart of Either. There are other impls in
scala without this stupidity

Where each step is a function returning a Either, where Left[_] is error
and Right[_] is a result.

If any step returns a Left[_], then the value of the for block is a Left,
else it is a Right.

The only caveat is function/method called must return a Either ( though
defining conversions it is trivial to lift other types in a Either ).

But if you want to return a value instead of throwing exceptions, pattern
matching is key to making this nice. Otherwise its a mess of if/else or
switch case checks.

The relatively weak typing in Dart may make something like this untenable.

Post by 'Bob Nystrom' via Dart Misc

Post by 'Bob Nystrom' via Dart Misc
Putting on my language nerd hat for a minute...

// ... ///
Even catch clauses are type safe because you simply won't enter it if the

Post by 'Bob Nystrom' via Dart Misc
type doesn't match. You can make a language that is fully, perfectly
statically sound without much difficulty even while having exceptions. It
just means some programs may abort abnormally. But that's pretty much
always the case. Most type systems don't try to track stack overflows, out
of memory errors, or infinite loops either. Exceptions are a more limited
case of that kind of behavior where execution may stop or jump to a
different part of a program.

Sure, but it's a a subtle behaviour that is easily missed and not well
communicated. The type system is sound at compile time (assuming no casts
etc., but let's not go into that ;)), exceptions are a big source of
runtime failures.

Post by 'Bob Nystrom' via Dart Misc
Personally, I think they are a really really nice feature.

I think they could be, if used appropriately. I think they're way over
used because they're easy and cheap (it's easier to throw an exception if
the file is not found, than to propagate that error information back in a
return type).

Post by 'Bob Nystrom' via Dart Misc
They tried that with checked exceptions in Java. In practice, it's really
painful to work with. In most cases, exceptions are, well, exceptional, and
it's too cumbersome to *always* force programmers to deal with it. Maybe
Java could have made this work better by having some syntactic sugar to
ignore checked exceptions in the kind of scripty code where it makes sense
to not deal with them, but the overall consensus is that they were a bad
idea.

I knew someone would mention checked exceptions! I've done very little
Java, and it's because of this. My first 30 mins with Java were so utterly
frustrating I ragequit and vowed never to go back. It was for exactly the
reasons you mentioned - I was writing my first Android app, and wanted to
just call some APIs and examine the return values... I couldn't compile
without handling every error (I really didn't care about exceptions at the
time, I was exploring). The IDE had this "helpful" command to just fill in
a load of empty catch blocks for me. Of course, once my application is
littered top-to-bottom with these, it's not going to be a fun job to go and
put in the "correct" code for them.
I think the *idea* of checked exceptions is good, but it just doesn't
work out. Having the info in the return values is far less intrusive and
less frustrating!

Post by 'Bob Nystrom' via Dart Misc
I haven't used it, but I believe Go made real attempts to address this,

Post by Danny Tuppeny
with error information being part of the return types. However they do
still have Panic/Recover which might undermine the idea of no exceptions
(though I don't know enough about it to have a real opinion, nor do I know
if Go developers find it to be better or worse in practice).

1. They added panic, so you still have to deal with unwinding in your
code and make sure you defer. You still have to assume your function may
exit spontaneously, so you lose the local reasoning of say, C.
2. They made errors a *product* type instead of a *sum* type. That
means a function that can fail returns *both* a result value and an
error. Better make sure you check to see if one or the other is
zero-initialized! What I think they should have done—which is what almost
every other language that returns errors does—is return a success value
*or* an error.

1. Yeah, when I read about Panic/Recover, my enthusiasm was dampened :(
I'm sure there were good reasons for it, but now it just seems like there
are two ways of doing errors you have to pick between (if I was told to
write data to disk, and the path is invalid, is that a panic or a graceful
return?)
2. Hmm, that does sound a bit strange... I wonder what the reason for that
is... I wish I had time to learn all of these different languages; there's
so much good information in learning why languages have the features they
do (or don't)!
--
For other discussions, see https://groups.google.com/a/dartlang.org/
For HOWTO questions, visit http://stackoverflow.com/tags/dart
To file a bug report or feature request, go to http://www.dartbug.com/new
To unsubscribe from this group and stop receiving emails from it, send an

--
Daniel Joyce

The meek shall inherit the Earth, for the brave will be among the stars.

[Alex Tatumizer]

In my latest java project (at work) I throw exceptions in 30 places, and
handle them in one (ONE!) place. On top of that, almost every library
method throw exceptions. If it were golang (instead of java) I would have
hundreds of places like this:
x,err=foo();
if (err) {
return -1,err
}
y,err=bar();
if (err) {
return -1,err
}

Basically, program would drown in error processing. Do you find this style
beautiful? Readable? Want dart to become more like this?

[Danny Tuppeny]

Post by Alex Tatumizer
In my latest java project (at work) I throw exceptions in 30 places, and
handle them in one (ONE!) place. On top of that, almost every library
method throw exceptions. If it were golang (instead of java) I would have
x,err=foo();
if (err) {
return -1,err
}
y,err=bar();
if (err) {
return -1,err
}
Basically, program would drown in error processing. Do you find this style
beautiful? Readable? Want dart to become more like this?

No, I do not want Dart to become more like this. But given the choice
between libraries where I can see *exactly* what can happen when I call
them versus having absolutely no clue what type of errors they may throw, I
would definitely take the former.

I think exceptions are bad, there's just no way of knowing what you're
going to get when you call someone elses code. I think the more we can do
to mitigate this, the better. Task<T>/Future<T> has given us a good way to
handle code that might take a long time to finish, I think we need a better
way to indicate failures in our code.

I work on a fairly big project (> 1m LoC) and I spend my day drowning in
exception logs. So many of these runtime failures (which are basically
error screens to our user telling us we've screwed up) could be avoided if
the language/tools gave us better support (eg. no nulls, ability to know
up-front what the failure conditions of given code are).

I'm also an Android user and I spend my day clicking "Report" on crash
dialogs, even on apps from companies like Google.

Part of the blame for bad software falls on the the tools and languages. We
can do better. We *must* do better if we want software driving our cars. Do
you want null reference exceptions to occur in your car when you're driving
down the motorway? An uncaught exception because the programmer didn't know
that the speedometer would throw if there was a blowout?

[Günter Zöchbauer]

Post by Danny Tuppeny

Post by Günter Zöchbauer
I mostly agree with your view on nulls. I think it's helpful sometimes if
null is available to indicate "uninitialized" but usually null is just a
burden.

When there is no null, there's always something to replace it (eg.
Option). In this case, you can choose when to use it, rather than have it
forced upon you.
Sure

Post by Günter Zöchbauer
don't know if they ever implemented storing empty strings as empty
strings instead of auto-converting to null

This sounds like a silly bug/implementation issue rather than an issue
with null/not null. As developers we should have complete control over our
types. If we want null, we should have some option, and if we don't, we
shouldn't. SQL Server has has had the ability to have nullable and
non-nullable fields (probably) forever. If you want a bitfield that can
have a NULL that's fine, but if you don't, you can do that too. If you want
a string that can be stored as empty or null to mean different things,
that's possible, and if not, you can ensure there's no null.

Sure, but it's hard to force Oracle or other companies to change this.
There were a lot of requests on this several year old bug report/feature
request and they were still considering ...
There world often just isn't the way it should be is all I'm trying to say.

Post by Danny Tuppeny
I really don't understand why programming languages keep doing the null
thing. There's simply no good argument for it, and so many against.
NPEs/NREs are probably the most common exception by a huge factor. Every
time an Android app crashes on me, I tap through to see the stack trace
(being curious), and 99% of the time, it's an NPE. It just needs to end! ;(
What's your issue with exceptions?
Similar to nulls (but worse), they are a lie in the type system. I write
you a method that says it returns true or false, but it can actually return
true, false, or throw. Error/failure information should (mostly) be encoded
in the return type, so that it's discoverable and harder to accidentally
ignore. Currently it's just a big get-out if you can't return the type you
originally declared. Although people say you shouldn't use exceptions for
anything that's not an exception, that's just not how it's worked out.
I see.
I haven't used it, but I believe Go made real attempts to address this,
with error information being part of the return types. However they do
still have Panic/Recover which might undermine the idea of no exceptions
(though I don't know enough about it to have a real opinion, nor do I know
if Go developers find it to be better or worse in practice).
So nulls and exceptions cause similar issues - restricting the ability to
properly express what your code will/won't return, or rely on what someone
elses code claims to return. The more runtime errors we can make
compile-time errors, the better.

I worked a while with Go and I like it a lot, also the intrisinc way of
returning a value AND an error code.
If you don't handle the error code properly you're still likely to trigger
a panic but I think it's a quite powerful approach and makes the intention
more obvious and improves readability.

[Günter Zöchbauer]

+100

[Anders Holmgren]

+101

+100

['Andreas Kirsch' via Dart Misc]

This would be awesome!

Post by 'Bob Nystrom' via Dart Misc
+101

+100

--
For other discussions, see https://groups.google.com/a/dartlang.org/
For HOWTO questions, visit http://stackoverflow.com/tags/dart
To file a bug report or feature request, go to http://www.dartbug.com/new
To unsubscribe from this group and stop receiving emails from it, send an

[Günter Zöchbauer]

I'm tempted to argue that you can't want this more than me,
but https://pub.dartlang.org/packages/constrain shows quite some dedication
where I don't have anything to show ;-)

+101

+100