Google's Dart Programming Language Soon Won't Take 'Null' For … – Slashdot

Posted under Programming, Technology On By James Steward

Catch up on stories from the past week (and beyond) at the Slashdot story archive




The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
you didn’t handle the problem when your resource allocation did not work ? Let’s blame null.
you want to put in a sentinel when you’ve reached the end of the data ? Let’s re-invent null
just don’t call it null
it makes total sense that they are obsessed with fool-proofness for a programming tool that only a fool would use.
 
imho this is only true for beta consumer apps. Not technologies they are also using internally. They have been maintaining GWT for way longer than any sane person round have considered using it..
Fwiw, dart is already 11 years old and instead of killing it and developing something from scratch they painstakingly developed a migration path and lots of tools to migrate from the new nnbd type system. I’ve migrated quite a bit of code, certainly not easy.. but considering the paradigm shift from the first dart v

just don’t call it null

just don’t call it null
I called it null once, but I think I got away with it!
Strong null safety doesn’t get rid of null, it just makes it so you have to explicitly mark where it can happen. It tends to make the code cleaner because, turns out, most of the time, you don’t want to allow null values.
If you have a valid reason to allow a value to be null – and they exist, and exist in the Dart API, and will continue to exist even in Dart 3 – you still can. You just have to mark a variable or argument or return value as being nullable. (Which I’m fairly sure is done by just adding a ? to the type name, so instead of “object” you’d say “object?”.)
What the compiler does is insist that every time you dereference a reference that could be null, you check for null. This makes it so that you can prove that a variable that’s marked as non-null can never be null: it must be initialized to a non-null reference, and it must never be set to a reference that could be null.
If you have a reason to return null, it’s still there, ready for use. It just has to be used “safely.”
This works when the compiler is perfect and infinity smart.
Rust with its no Null and borrow checker just works, most of the time. But when it does not work, it literally prevents you from coding. It is fantastic getting the compiler to do more work to verify your program, no one wants to just wrap 1% of their program in `unsafe` just because the compiler is too stupid to understand fairly simply linear code.
And even when it does work it takes code like this V

if(split_str){//null == false
int [] arr = “5,6,3,78,2,4,7,34,6,4,2”.split(split_str);}

if(split_str){//null == false
int [] arr = “5,6,3,78,2,4,7,34,6,4,2”.split(split_str);}
And turns it into this V

if(split_str.is_some){ //need to clone or ref if you need to use split_str again anywhere else I think
let arr = “5,6,3,78,2,4,7,34,6,4,2”.split(split_str.as_ref().expect(“I just checked if this is not null, why do I need to check again?”));}

if(split_str.is_some){ //need to clone or ref if you need to use split_str again anywhere else I think
let arr = “5,6,3,78,2,4,7,34,6,4,2”.split(split_str.as_ref().expect(“I just checked if this is not null, why do I need to check again?”));}

you didn’t handle the problem when your resource allocation did not work ?

you didn’t handle the problem when your resource allocation did not work ?
That’s the ENTIRE point of null safety. It’s not supposed to be optional, then why is it optional? You get the expected type or deal with an exception. That’s all null safety is, a language enforcing that basic premise.
You’re saying don’t shoot the messenger when a null is like having a process server leave a document on a front porch and walk away. That is 100% a messenger problem.
A large proportion of new Android apps are in Dart.
https://stackoverflow.blog/202… [stackoverflow.blog]
So there’s that 😉
Go came and went and now Dart is darting across the language landscape?
They’ve co-existed for quite some time. They have different target use cases. Go is meant for developing server software and command-line applications. Dart is designed for user interfaces, whether in a web app or a mobile device.
Bah! Numerals! If “one, two, many” is good enough for the hunter-gatherers, it’s good enough for you!

Next release: Dart removed digit zero as a way to prevent division by zero errors. Dart will no longer entertain those suboptimal possibilities.

Next release: Dart removed digit zero as a way to prevent division by zero errors. Dart will no longer entertain those suboptimal possibilities.
This isn’t a joke, should a processor figure 8 / 0 = 0 and set an error bit somewhere instead of firing an interrupt? It’s your fault for not checking the error bit after doing a “potentially dangerous” division after all.
If you divide 8 by 0 … it does not matter what the compiler or the hardware is doing, or what exactly the result is: you have a problem.
A compiler or runtime system showing the problem, or even a processor halting: is showing you that you gave a problem
Pretending there is no problem just because there is no ERROR, is idiotic.
Hint:
8 / 2 yields 4
8 / 3 yields 2
8 / 4 yields 2
8 / 5 yields 1
8 / 8 yields 1
I’m sure you notice a trend on the right side. Why the funk you think that 8 / 0 yielding 8 makes any se
huh? 8/0=Infinity… Dart gets that one right..

huh? 8/0=Infinity… Dart gets that one right..

huh? 8/0=Infinity… Dart gets that one right..
Try & Catch In Dart:

void main() {
int a = 18;
int b = 0;
int res;

try {
res = a ~/ b;
}
catch(ex) {
print(ex);
}
}

Output:
IntegerDivisionByZeroException [dart.dev]
Coders everywhere are breathing a sigh of apathy…
For the first time in years, I actually RTFA, and I’ve got to agree. It is a nice gauge of the boredom level of language developers though.
It’s actually surprisingly great.
It’s easy to see ways for the feature to be annoying–nobody likes to spend their time jumping through hoops to make the compiler happy– but fortunately the way it’s designed strikes an extremely fine and good balance between stopping bad things and getting out of your way.
For example, a variable or field can be marked “late” to say: I know the compiler can’t prove this will be initialized before it’s accessed, but I promise to do that, so pretend it’s proved. Then the comp
It’s probably because I’ve been doing this too long that now the only interesting cases of null reference/pointer exceptions are the ones that come out of those situations where you’d have to mark it “late”. The regular, “doh!” cases that this really helps with have been trained out of me…at least until senility sets in.
Will this solve the problem when people’s last name [wired.com] is Null [bbc.com]?
Slashdot user with a similar name [slashdot.org]?
Then you masked away the real the cause for having null references, but that wouldn’t solve anything.
You can do that in Java/C++/C# too, just (in Java as example)
public class X
{
      public static final X null_x = new X();
}
Then you use null_x instead of null, and initialise every object of X with null_x. Voila! No null references. Wouldn’t actually solve anything though.
You’ve missed the point.
The point isn’t to replace null with something else, the point is to create null safety by ensuring that references can only be null if they’re declared to be allowed to be null, and if you ever dereference a nullable reference — or assign it to a non-nullable reference, even implicitly — you must check it for null first.
can relate…
Sounds like Dart is just doing the same thing Swift does (and I’m sure a bunch of programming languages before it).
If a variable can have a value of null, it’s a different data type, e.g.:
var alwaysHere: String
var sometimesHere: Optional[String]
now if you want to assign a value to a never null from a sometimes null, you just have to tell it what to do in case of null e.g.
alwaysHere = sometimesHere or “empty”
They are not getting rid of the concept of null.
There may be more comments in this discussion. Without JavaScript enabled, you might want to turn on Classic Discussion System in your preferences instead.
Source Code for Adobe’s PostScript Publicly Released
Will USB-C Charging Standard Bring Fewer Other Proprietary Parts and Less e-Waste?
“Roman Polanski makes his own blood. He’s smart — that’s why his movies work.” — A brilliant director at “Frank’s Place”

source

Note that any programming tips and code writing requires some knowledge of computer programming. Please, be careful if you do not know what you are doing…

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.