Slashdot Mirror
TypeScript 2.0 Released (arstechnica.com)
An anonymous reader quotes a report from Ars Technica: Since its introduction, TypeScript has included new features to improve performance, enhance JavaScript compatibility, and extend the range of error checking that the TypeScript compiler performs. TypeScript 2.0 introduces a big step forward here by giving developers greater control over null values. null, used to denote (in some broad, hand-waving sense) that a variable holds no value at all, has been called the billion dollar mistake. Time and time again, programs trip up by not properly checking to see if a variable is null, and for good or ill, every mainstream programming language continues to support the null concept. TypeScript 2.0 brings a range of new features, but the biggest is control over these null values. With TypeScript 2.0, programmers can opt into a new behavior that by default prevents values from being null. With this option enabled, variables by default will be required to have a value and can't be set to null accidentally. This in turn allows the compiler to find other errors such as variables that are never initialized.
null !== undefined...
Isayletsgetridofwhitespace!Isn'tthismucheasierwaytoprogram? (this was longer, lame lameness filter...)
I say that's just about as good of a suggestion. How on earth could we do this? Those languages that utilize the null paradigm can't be changed now, or else they become different languages. Besides, these little programming language idiosyncrasies are what separates the "weekend programmer" from the "career programmer."
Yep. Amazing how much stuff gets layered onto Javascript in an attempt to turn it into a usable language.
And what do you do when something doesn't have a value? A new employee has been hired but you don't know his birthday? Plug in 1900-01-01? And check for that? Nulls serve a purpose.
Languages without nulls usually solve that problem with option types. Non-existent values get the value None (or some equivalent).
"They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety."
I say get rid of nulls. They cause all kinds of problems and bloat up code. The few times you do "need" them can be handled other ways.
For example, check to make sure the data structure has values (elements) before running an "average" operation on it. If you don't check and there are no elements in it, then it should throw an error rather than produce a null.
Perhaps nulls are used in RDBMS because it's not easy to use conditionals or error handlers in queries to deal with an empty structure or no rows. Maybe have the Average function return two values (columns): one with the result value, and another column with a the count of elements averaged. If the count is zero, then the result value is invalid (not informative), but would be set to zero for consistency.
A potential problem with getting rid of nulls is that languages may have to support them for backward compatibility with existing stuff that produces nulls.
The more you type, the bigger the hole.
In RDBMS terms, "NULL" means "we don't know the value". It's not "empty", 0, false, or anything like that. It is "unknown".
Take this dataset:
0
2
NULL
NULL
4
The average of those is 2 ( (0 + 2 + 4) / 3 ). The count is 3. The sum is 6. The max is 4 and the min is 0. The RDBMS doesn't count null values for those operations because nulls are not known.
Likewise, NULL != NULL and NULL = NULL both give no value because it's unknown.
NULL is not "empty". It is not "undefined". It is not "blank". This is the source of your confusion. NULLs are absolutely necessary in an RDBMS context - at least for people who know what they're doing.
In terms of C programming, "null" usually means a pointer that has a literal value of 0. Unix-based operating systems always set the first page of mapped memory to be inaccessible as an easy way to catch references to 0 pointers. That makes a null pointer an easy way to say "there's no value here yet". But it's really not the same as a NULL value in an RDBMS context.
Do you have ESP?
Perhaps nulls are used in RDBMS because it's not easy to use conditionals or error handlers in queries to deal with an empty structure or no rows.
The problem with RDDMSs is that allowing null is the default, and you have to explicitly declare a column as "not null". It should be the other way around. Uninitialized data should be an error unless you explicitly allow it. This problem is exacerbated because many people writing SQL don't have a strong background in programming, and often don't really know what they are doing.
Javascript has the same problem. It is very forgiving of crappy code, which makes it a terrible language for beginners. For instance, many Javascript programmers don't understand the differences between "null" , "undefined", '', 0, and '0'.
How on earth could we do this? Those languages that utilize the null paradigm can't be changed now, or else they become different languages.
Some languages do it by having an optional "strict" mode that can be invoked for new code. Javascript has "use strict" and so does Perl.
I wasn't sure what TypeScript is so I looked it up.
https://en.wikipedia.org/wiki/TypeScript
It's a language similar to JavaScript that allows you to optionally use types on variables. It "transcompiles" to JavaScript, so you can write programs in TypeScript and then they will run in standard web browsers that only support JavaScript.
It's possible to use standard JavaScript libraries with TypeScript, and further is it possible to write a header file that documents type information for those libraries. So it is possible to use TypeScript and take advantage of its type checking without needing to re-implement all the libraries.
lf(1): it's like ls(1) but sorts filenames by extension, tersely
Well, in a proper database, you'd have a separate table for birthdays, and index into it using the employees ID from the employee table. This is McGuffin's Fifth Normal Form, or something. In this way, you get to replace the concept of NULL, with the concept of... er... not having an row. Which is different from having an entry containing NULL. Somehow. And THEN you get to write a function that is conditional on the existence of this row, rather than conditional on the presence of a NULL value, which is again, completely different.
So, I'm not familiar with TypeScript...but I am familiar with other languages that use this mechanism (e.g., Scala) and there is a big difference between a "None" value (on an option type) and "null" value (on a reference).
Namely - you have to "unpack" an option type before you can access the value and the act unpacking (e.g., via pattern matching) forces the programmer to write the null check because the most natural way of accessing the data doesn't allow you to avoid it.
Now - that said - there are things like Option[T].get() (e.g., in Scala) which *will* unpack the value in an unsafe way. The distinction is still useful though - you generally shouldn't be using ".get()" and it's not the normal way of interacting with Option[] types.
This is opposed to the standard way of accessing nullable values (in, for instance, Java or C#) where the most natural approach to access a property or method on a reference requires you to first check for null.
Additionally - if you are writing a method in these languages which doesn't accept parameters of Option[T] but only accepts parameters of type T, then you can assume you are being given a non-null value because the expectations are very clear. Again, in C# or Java, there is no distinction here and null might very well be a valid value and there's nothing the compiler can do to help you find those types of mistakes.
There's quite a few languages that don't have nulls. They work fine. Null is more than just "this thing doesn't have a value", its "I don't even have a reference to anything, not even a "thing" to say I have nothing"
Maybe types, Nothings, Eithers etc, all do what nulls do while providing you with the tools needed to properly handle those cases. In advanced type systems, the program won't even compile if you don't handle them properly. And even in shitty ones, they at least provide methods to correctly deal with it.
Only an idiot who only works with toy programs would put birthdays into a separate table.
When you want to query your 5 million people for something to do with birthdays, you DON'T want to be joining to another table for no purpose.
We want a learning curve, not a learning wall.
The problem with JavaScript is that the learning curve bends in the wrong direction.
Nulls in programming languages like JS have absolutely nothing to do with nulls in RDBMS (and SQL specificlly).
In SQL, NULL actually means "unknown". Notably, it does not mean "absent". That's why arithmetic, comparisons and aggregations on nulls behave the way they do.
In JS etc, null means lack of value, "absent". And that is not a bad concept, you run into this sort of thing all the time. The problem is that the type system is unsound - every reference type is implicitly considered an option type with null, and yet any operation on a reference is permitted even when it wouldn't be allowed on null - hence, runtime exceptions.
What TS did solves that problem outright. If you have a typed reference, by default, it cannot be null, and any code that's trying to assign to it something that might be null simply won't compile. In those places where you actually want to allow null, you can explicitly spell it out in the type, but then you'll have to do null-checks before you access any member (which effectively changes the type of reference inside the conditional statement to the default never-null type). Again, the compiler enforces all that - so if your entire program was typechecked, there cannot be any runtime null errors.
Effectively, they made null into a true monadic option type, like 'a option in ML, or Maybe a in Haskell.
"This in turn allows the compiler to find other errors such as variables that are never initialized."
Maybe a code smell but not an error, but surely this is more a function of an IDE rather than the compiler?
Once you have a list of memory locations that are never initialised it's trivial to check if those locations are ever used, which is why it's handy to have a list of variables that are never initialised. For example, you *definitely* want to catch the following error:
AIUI, in Javascript that will generate a run-time exception (if it doesn't, it *should*!), while in typescript that will generate an error at the time of compilation, before the code ever even runs.
I'm a minority race. Save your vitriol for white people.
It's the same thing for the fappable column in the employees table. What if it's winter and she only wears thick jumpers?
Well, sure, I just stand down in the face of your incredibly superior logic... of course 50 years of CS is wrong, there's no need for nulls. Wow, amazing no one made that argument before.
No they don't. The Java or C# null is not None. The C# Nullable type is like None. The main practical difference is that _all_ reference types in C# and Java have null but in a language without null, only Option types have None.
Yes! The creators of Chicken Scheme think that it's more usable than C, at least under some circumstances, or they wouldn't have bothered creating it. That's the main point of compilers: they convert from the language you'd like to use into one that some machine will execute. Of course, you _could_ go the other way - C into Chichen Scheme - but nobody has any motivation to build that.
The compiler also guarantees certain properties of the object code. In a language with types, a successful compilation amounts to a proof by construction of the corresponding logical propositions (see https://en.wikipedia.org/wiki/...).
Well the answer to your question is that Type.NULL is something that you define yourself or read about in the docs/code if it is coming from a dependency and use instead of NULL.
There are times when having your software lie to you is better than having it do nothing. That's when you use Type.NULL.
There are also times when having the software crash is better than having it lie. That's what NULL is for.
Of course, if you and everyone on your team always writes correct code then it doesn't matter how you encode non-existent values. Your code will neither crash nor lie. The problem is that writing correct code is sometimes hard and often takes a lot of time.
The stack grown either upwards or downwards depending on the architecture. Both have advantages and disadvantages but in no way is it comparable with the null problem.
Actually the problem of forcing initialization prior to knowing a value (at least in terms of actual data) is that you then no longer know the difference between "just a default" and "actually the same value as the default".
A possible scenario:
A woman becomes pregnant but has not yet had her child. The doctor wants to create a health record for that child for tracking purposes.
Baby.Name = {empty string}
Baby.Birthday = {1900/01/01}
The same doctor also happens to be the doctor for the oldest man in the world.
OldMan.Name = {Mathusala Jones}
OldMan.Birthday = {1900/01/01}
Now, the same doctor wants to run a report for everyone who has a birthday in January because it's time to mail them their annual birthday card. Oops....little Bobby Tables gets a birthday card even though he hasn't even been born yet.
So, you could add an additional boolean for every "nullable" field that tracks "is default".......or you could just use null like everyone else. Your code is basically the same:
if (isDefaultBirthday) { /* do something */ } /* do something */ }
vs
if (Birthday == null) {
And that is basically what a var in javascript is: a javascript object or null. Null in Javascript is similar to None in python.
John_Chalisque
If you have a function that may return an object or may not for some reason, then it must return an Option or a Result (or something of a similar nature) and the caller has to explicitly test and handle what got returned.
Null is only supported for unsafe operations, e.g. calling out to some 3rd party library or a system API.
The answer is the Option type. It's been around for ages, and it's easy to implement yourself in languages that do not support it natively. Scala even comes with a number of handy methods that make working with Java-style (i.e., nullable) data types a bit easier.
The issue isn't that nulls don't serve a purpose. You're right, they do. The issue is that it is very difficult to know statically (i.e., before your program runs) whether you've handled them all correctly or not. Option make this handling a part of the type system, thus if you fail to check for null, your program will not compile. That's a good thing.
Well, an experienced programmer will just set up the inner join such that the whole employee effectively disappears because he/she has no birthday. Problem solved, no NULLs!
Karma: Poor (Mostly affected by lame karma-joke sigs)
Every language that has NULL has the tools to deal with NULL (i.e. the ability to compare a reference to NULL). The problem isn't NULL, the problem is that lazy programmers don't account for the real world, where data is messy and failures in other parts of the system happen all the time.
Karma: Poor (Mostly affected by lame karma-joke sigs)
For one, don't have functions/operations that accept or return nulls.
And we can change the way we think about rows in a table. Instead of this:
{employee name="Martha" salary=70000 birthdate="null"}
Model it like this:
{employee name="Martha" salary=70000}
Table-ized A.I.
Failure is the best default. It's a harsh path that leads to stronger guarantees about data and behavior.
Sentinel values (like 1900-01-01) generate hard-to-find bugs and threaten the trustworthiness of your data. If you can't remember to check for null, you're certainly not going to remember to check for a sentinel value.
The recent shift in language design to favor non-nullability by default is probably a good thing: if you don't need null, it's nice to let the compiler/database enforce that for you. However, if you do need null--if the value of a variable/field can be unknown, for instance--it's best to use it and do the extra work. Muddle things with a sentinel value only if the inevitable consequences are acceptable.
-1, Too Many Layers Of Abstraction
There are also times when having the software crash is better than having it lie. That's what NULL is for.
Yes, please mod him +10. I'm sick and tired of people afraid of NPEs (NullPointerException, Java) or of null. A NPE means you have a bug in your code, and it's better for the app to crash than to corrupt your data, or silently just lose it.
http://www.mueller-public.de - My site http://www.anr-institute.com/ - Advanced Natural Research Institute
DuoCode?
I've been much happier keeping everything in C#.
It's just the same thing. Call it None or null, who cares.
http://www.mueller-public.de - My site http://www.anr-institute.com/ - Advanced Natural Research Institute
every mainstream programming language continues to support the null concept.
Because you cannot do without. The computer cannot guess a value of a variable, so the default is always "Not Set" aka Null. Other languages use a Type.NULL or whatever, but it's just the same as Null. So, every language have a null concept.
http://www.mueller-public.de - My site http://www.anr-institute.com/ - Advanced Natural Research Institute
The problem isn't that the language has nullable references, it's that it doesn't have a reference type which cannot be null. A nullable reference is isomorphic to the Optional or Maybe type available in most "null-free" languages, and this certainly has perfectly legitimate uses. The issue in a language like C, Java or JavaScript is that every single operation on references takes this nullable reference type as input, and the vast majority of those operations assume that the reference will not be null and generate a runtime error otherwise. In a more principled language there would be a type distinction between a reference which may be null and a reference which cannot be null, and the programmer would need to destructure the nullable value into either null or a non-null reference before using it in operations which do not expect null. This eliminates a wide variety of common mistakes by making them type errors at compile time rather than subtle runtime errors which may or may not cause the program to crash, depending on the inputs. If the program is written correctly then this destructuring happens at the same places where you already should be checking whether the reference is null before using it, so it doesn't even make the program significantly longer. You just need to annotate your type declarations to indicate where the reference is allowed to be null.
SQL databases are actually a fairly good example of how null values should be implemented, because you can specify whether a field can or cannot be null in the table definition and this constraint will be enforced by the database.
"The state is that great fiction by which everyone tries to live at the expense of everyone else." - Bastiat
A NPE means you have a bug in your code, and it's better for the app to crash than to corrupt your data, or silently just lose it.
Even better would be to detect the bug statically, at compile time, as a type error, so that your program doesn't crash at some arbitrary point later and lose all the user's data.
The point is not to eliminate the concept of nullable references, which are indeed useful for representing data which is not available. The point is to distinguish between such nullable references and references which cannot be null so that the compiler can check that all the nullable references have been properly handled and warn you about any and all potential null pointer issues in advance.
"The state is that great fiction by which everyone tries to live at the expense of everyone else." - Bastiat
It's actually not. None can considered a subclass of the class Option. It gets the methods defined on Option and one is forced to handle unwrapping the value and placing a default when unwrapping the value. Null have no extra behaviour on them. They can appear at any time and programmers can occasionally forget to check if the value is null. The compiler can help with the Option monad. It can't help catch missing null checks.
As I ranted about in the Java 8 story re lambda hype, the problem is our common languages have a crappy OOP model with "stiff" method definitions.
myFile = file.open(myPath) method openError {display("oh shit!");stop();}
(A "method" keyword may not be needed; it's shown for clarity here.)
Table-ized A.I.
We already have that with static code analyzers. But how would you even do that with dynamic languages, where the type can just change at runtime? // Compiled with --strictNullChecks // Error, reference not preceded by assignment // Error, reference not preceded by assignment
Furthermore, TypeScript is handling null just like Java. So the statement that "every mainstream programming language continues to support the null concept" is even more nonsensical, because TypeScript is one of those languages.
let x: number;
let y: number | null;
let z: number | undefined;
x;
y;
That is just like Java's final keyword.
final int x;
http://www.mueller-public.de - My site http://www.anr-institute.com/ - Advanced Natural Research Institute
Yes, it can. Static code analyzers. But anyway, how does Option is suppose to work? Now every variable is by default Option.None and I have to sprinkle my code everywhere with foo.unwrap(default)? That's convenient (sarcasm). And what does the default should be? I don't have a default, that's the whole point! The value have no default, that's why it's null or Option.None in the first place. And we went full circle, and the only sensitive thing the app should do is either crash or show a big error message and exit. Btw, of course an app should gracefully shutdown, and that is possible even with null.
http://www.mueller-public.de - My site http://www.anr-institute.com/ - Advanced Natural Research Institute
Not sure what you actually mean when you say that SQL NULL means unknown but not absent? Is there a meaningful distinction you are making here?
It makes a difference when you start applying operations.
For example, if you compare a NULL to any value (even another NULL), the result is also NULL, rather than TRUE or FALSE. This doesn't make sense for absent values - two absent values should compare equal (and, indeed, two nulls in JS do). On the other hand, it makes perfect sense if NULL means unknown - if my last name is unknown, and your lastname is unknown, comparing them for equality can only produce "unknown" as a result, since it's not known whether they're the same or different.
Same thing with arithmetic operations. 1 + NULL equals NULL in SQL, again, because NULL is really "unknown", and so when you add an unknown value to 1, the result is also unknown. If NULL were an absent value, the expression should either produce an error, or give 1.
The most telling part, though, is the SQL truth table for Boolean operators that includes NULLs. Specifically:
TRUE AND NULL = NULL
FALSE AND NULL = FALSE
TRUE OR NULL = TRUE
FALSE OR NULL = NULL
Again, this makes perfect sense if and only if NULL means unknown. AND is always false if one of the operands is guaranteed to be false, so FALSE AND NULL is always false, regardless of what the actual unknown value is. On the other hand, FALSE AND NULL is NULL, because the result could be either false or true depending on the unknown value. With OR, it's the reverse - TRUE OR NULL is TRUE, because OR is always true if one of the operands is definitely true, regardless of what the other operand is. FALSE OR NULL is NULL because the result depends on the unknown value.
Philosophically, the difference also exists. Absent value means "I know what the value is, and there isn't one". For example, for a guy from Iceland, you know his last name - he doesn't have one. Unknown value means "I don't know what the value is, and there could be one". For example, you don't know if I'm from Iceland or not, so I may or may not have a last name, and you don't know which one if I do. These are two distinct states, and ought to be reflected as such in the database.
I don't have such an expectation, but the comment to which I replied seemed to, since it's talking about nulls in databases in the context of changes in null semantics of TypeScript 2.0, seemingly conflating the two.
But how would you even do that with dynamic languages, where the type can just change at runtime?
Obviously you can't, which is one of the arguments against programming in dynamically-typed (unityped) languages. This is why TypeScript exists: a statically-typed JavaScript derivative which compiles down to plain JS after proving that the types are satisfied (i.e. performing static code analysis), much as any other statically-typed languages compiles down to unityped machine code.
Furthermore, TypeScript is handling null just like Java.
No, it isn't. Both TypeScript and Java will complain about uninitialized variables, but Java will not produce an compile-time error if you set the variable to null (directly or indirectly) and then try to use it as a reference. TypeScript will, unless you explicitly check that the value is not null before using it. (Checking for null changes the type from nullable to non-null within the scope of the condition.)
"The state is that great fiction by which everyone tries to live at the expense of everyone else." - Bastiat
But are they webscale?
http://saveie6.com/
Option.None is useful to indicate that the value is optional in type signatures or that the return value is optional in type signatures. An API documentation that has public Option foo(B b) indicates that the B is a pure value (is not optional/not null) and that the return value has the potential to not be set. public A foo(B b) would indicate that the return value is not optional and that a meaningful value will always be returned. Option also handles primitives because null can't be assigned to primitive types, likes integers or doubles. An example would be searching a list of primitives. public Option find(List primitives, Func predicateWhereCondition) means that the item in the list matching the where condition may not be found. The classic method of searching usually defaults the value to return value to -1 in public int find(List primitives, Func predicateWhereCondition) when the item isn't found, which is nonsensical when the list can contain negative integers.
If you don't want to unwrap the value, then why aren't you returning the Option type in the return type signature? When you litter your code with foo.unwrap(default), you're being forced to handle the missing foo values. Developers forget to write code on every foo return because they assume that the value is pure, meaning that public List foo() will always return an empty list rather than a null value.
Java has checked exceptions. C# has unchecked exceptions. Option types are similar to Java's checked exceptions (except checked exceptions are more like the semantics of the Either monad). You're not forced to catch the exception. You can throw the exception further up the stack if it doesn't make sense to catch the error. You're not forced to unwrap the Option type. You can throw it up the chain. Why shouldn't your function have the return signature of Option.None if you don't want to deal with unwrapping at the level you're unwrapping your Option types at?
You are correct, Java's final is more like a const. Although I still don't see the point in avoiding null. Obviously you can't, so better to live with it and provide tools to detect a null pointer/reference, i.e. treat access to null like a bug. We already have div 0 bugs, overflow bugs, etc. and we have tools to detect them.
http://www.mueller-public.de - My site http://www.anr-institute.com/ - Advanced Natural Research Institute
Java has checked exceptions. C# has unchecked exceptions. Option types are similar to Java's checked exceptions
How does Option helps in find(), search(), indexOf()? Why not just use exceptions or return null?
If a function can't return a meaningful value, it looks for me like a code smell. It should always return a meaningful value or throw an exception. The return of -1 in the find() method is a code smell and just bad design. Sadly, it's tradition (carried over from C) and we have to live with it. The find() method should throw an exception or return Integer and null if no item was found.
Developers forget to write code on every foo return because they assume that the value is pure, meaning that public List foo() will always return an empty list rather than a null value.
Yes, and that should always be the case, except if it's clear that the method can also return nothing, like in find(). public Integer find() can obviously return null if no value was found, for example. Other methods are search(), indexOf(), etc. Again, those methods should return null and not the idiomatic -1.
http://www.mueller-public.de - My site http://www.anr-institute.com/ - Advanced Natural Research Institute
So all your lazy programmers turn NREs into InvalidValueException (or worse, just subtle errors where invalid values are used as valid values).
Karma: Poor (Mostly affected by lame karma-joke sigs)
In an RDBMS context, NULL and blank are two very different unrelated concepts. If you don't know the difference you'll make yourself look stupid.
NULL in an RDBMS context and a "null pointer" in C have nothing to do with each other beyond the word "null". As you get into different languages these terms may be used in various ways that are unrelated, fully related, or only tangentially related to an RDBMS context or whatever.
Do you have ESP?
I should clarify that I was trying to talk about the Option It tends to give more type information. Some functional programmers believe that the output of the function should only be returned in the return value and not through things like output parameters. But it's still just a style difference. Even throwing exceptions is no different than having a Either foo(int parameter) defined. I would agree that the non-generic Option monad returns no useful information, but the Option tells you what potentially the output of the function is in one place.
I'm still not convinced that Option have any value. It looks more that it complicates development and is only here for null-phobic developers. But thank you for your time.
http://www.mueller-public.de - My site http://www.anr-institute.com/ - Advanced Natural Research Institute
The little problem with spelling out "NULL" :
When Jennifer Null tries to buy a plane ticket, she gets an error message on most websites. The site will say she has left the surname field blank and ask her to try again.
(...)
http://www.bbc.com/future/stor...