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.

Comments

yippie

[Anonymous Coward]

Why learn ONE shitty language, when you can learn TWO shitty languages -- Shitty language 1 compiles to shitty language 2, even better!

And wasn't the "billion dollar mistake" the one where somebody decided to make the stack grow upward instead of downward (or whichever way it goes, I can't remember).

Re:yippie

[murdocj]

Yep. Amazing how much stuff gets layered onto Javascript in an attempt to turn it into a usable language.

Re:yippie

[Anonymous Coward]

People make language compilers that transform language X programs into C language programs. Chicken Scheme is an example of this scheme. Does this imply that the C language is less usable than the Chicken Scheme language?

Re:yippie

[Anonymous Coward]

Google programmers are weenies!!

Re:yippie

[garethjrowlands]

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/...).

Re:yippie

[Megol]

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.

Variables never being initialized an error?

[Anonymous Coward]

"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? Does it sing you lullabies while it holds your hand too?

Re:Variables never being initialized an error?

[goose-incarnated]

"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:

var x;
...(hundreds of lines later) ...
if (x>0) { ... }

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.

Do away with them

[Tablizer]

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.

Re:Do away with them

[Anonymous Coward]

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."

Re:Do away with them

[murdocj]

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.

Re:Do away with them

[Trailer Trash]

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.

Re:Do away with them

[ShanghaiBill]

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'.

Re:Do away with them

[ShanghaiBill]

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.

Re:Do away with them

[rasmusbr]

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.

Pretty much, yeah.

Using Type.NULL instead of NULL lets your code fail partially or quantitatively instead of failing completely. Perhaps the value Date.NULL will suffice for the birth date for most use cases. Perhaps it's okay if your system thinks you're employing a bunch of 116-year olds.

The only fatal flaw with this scheme is that it fails as soon as you introduce inheritance, because Person.NULL != Employee.NULL, even though logically speaking the absence of a Person implies the absence of an Employee.

Re:Do away with them

[brantondaveperson]

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.

Re:Do away with them

[Anonymous Coward]

Just what do you think gets inserted into the database when you use Type.NULL? A tub of ice cream?

Type.NULL is a language/api construct wrapping the concept of null. You still have to check for it. It doesn't magically make null go away, it's just easier to reference sometimes. You still have to deal with nulls in any complex queries that have to account for them, stored procedures if any are used, and of course indexes and foreign keys.

Re:Do away with them

[Anonymous Coward]

It is very forgiving of crappy code, which makes it a terrible language for beginners.

On the contrary, that's what makes it an excellent language for beginners. We want a learning curve, not a learning wall. This elitist trial-by-fire nonsense is unbearable.

Re:Do away with them

[Shados]

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.

Re:Do away with them

[Anonymous Coward]

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.

Re:Do away with them

[Anonymous Coward]

Whoosh!

Re:Do away with them

[ShanghaiBill]

We want a learning curve, not a learning wall.

The problem with JavaScript is that the learning curve bends in the wrong direction.

Re:Do away with them

[shutdown -p now]

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.

Re:Do away with them

[BlackPignouf]

It's the same thing for the fappable column in the employees table. What if it's winter and she only wears thick jumpers?

Re:Do away with them

[murdocj]

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.

Re:Do away with them

[rasmusbr]

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.

Re:Do away with them

[Anonymous Coward]

Only an idiot who only works with toy programs would put birthdays into a separate table.

Look, ma. Some junior programmer has an opinion about databases.

I work with data in the scale of billions to trillions of rows. Yeah, we pretty much put everything into separate tables. It's what you do.

I love mah toys.

Re:Do away with them

[SQLGuru]

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 */ }
vs
if (Birthday == null) { /* do something */ }

Re:Do away with them

[raddan]

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.

Re:Do away with them

[godefroi]

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!

Re:Do away with them

[godefroi]

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.

Re:Do away with them

[Tablizer]

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}

Re:Do away with them

[Anonymous Coward]

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.

Rather than try to shoehorn every possible solution in, just use NULL. As in a string 'N' 'U' 'L' 'L' and if a number is expected, return 0. I do that and finis the job quicker and cheaper than my competition. And I know it works in practice because I never get called back to fix bugs. Some other guys? They spend years working over and over on renewed contracts. Not me! Clear sailing to new seas! Onward and upward!

Re:Do away with them

[firewrought]

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.

Re:Do away with them

[devent]

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.

Re:Do away with them

[JesseMcDonald]

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.

Re:Do away with them

[JesseMcDonald]

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.

Re:Do away with them

[devent]

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?
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. // Compiled with --strictNullChecks
let x: number;
let y: number | null;
let z: number | undefined;
x; // Error, reference not preceded by assignment
y; // Error, reference not preceded by assignment

That is just like Java's final keyword.

final int x; // compile error

Re:Do away with them

[Anonymous Coward]

Depending on context, null can mean empty or blank. Null is simply the absence of a value. In some contexts, this absence can be interpreted to mean empty, like for example the absence of gasoline in a fuel tank is empty. In this context null could also be construed as 0.

If you had a null as a pointer to a page of text, or a text field, then yes, it could also mean blank, as the absence of text is what is usually meant by blank.

If, by chance, you are referring to language-specific implementaions of empty, undefined, missing, blank, then sure, they may or may not vary on a per-language basis as to their implementation of whether these have equality. At the conceptual level, it's context-sensitive, and at the language level, it's an arbitrary decision by the designer. But claiming some overall Right Way (tm) is narrow-minded, and will meet with frustration in practice.

Re:Do away with them

[Anonymous Coward]

Does not compute.

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?

If you know the value, but it's not recorded in the database, it's not known tot the database, and it's absent. If the value is present in the database, then it's certainly known as well (by it's recorded value). So, I guess I don't understand the hair-splitting you seem to be doing with respect to terminology here. Present and known are coincident, as are absent and unknown (from the database's perspective).

I will certainly vouch for the fact that the words don't have identical connotations, but in practice in a SQL database, I'm not seeing a functional difference.

I'm genuinely curious as to whether I'm missing some subtlety here, that is actually worth paying attention to, or whether this is just a distinction without a difference.

Re:Do away with them

[Anonymous Coward]

Oh, I get it now. You have some expectation that null means the same thing in JS versus SQL. I certainly don't. Completely different languages.

Re:Do away with them

[shutdown -p now]

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.

Re:Do away with them

[shutdown -p now]

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.

Re:Do away with them

[JesseMcDonald]

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.)

declare function arbitrary(): string | null;
let x: string;
let y: string | null;
x = arbitrary(); // Error, type 'string | null' is not assignable to type 'string'.
y = arbitrary(); // Fine
x.length; // Fine, x is non-nullable.
y.length; // Error, object is possibly 'null'.
if (y != null) {
y.length; // Fine, y is non-null in this scope.
}

Re: Do away with them

[Billly Gates]

But are they webscale?

Re:Do away with them

[devent]

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.

Re:Do away with them

[godefroi]

So all your lazy programmers turn NREs into InvalidValueException (or worse, just subtle errors where invalid values are used as valid values).

Re:Do away with them

[Trailer Trash]

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.

Re:Do away with them

[Blaskowicz]

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...

Null values as errors

[Anonymous Coward]

And yet,
    if ((file_ptr = fopen("", "r")) == (FILE *) 0) { /* Report error condition */
    }
is so useful. Of course, as a developer you have to be sufficiently disciplined to always check for such things. Perhaps that's why software development is considered a discipline rather than a rote occupation.

Hmmm

[TFlan91]

null !== undefined...

This is stupid

[Anonymous Coward]

Many variables just don't have a valid default value. You gain nothing by forcing a meaningless value.

Re:This is stupid

[ATMAvatar]

Languages without nulls usually solve that problem with option types. Non-existent values get the value None (or some equivalent).

Re: This is stupid

[Anonymous Coward]

Java and C# do that too. Type "Object" but they call it "null" instead of "None".

Re: This is stupid

[fatmonkeyboy]

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.

Re: This is stupid

[garethjrowlands]

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.

Re:This is stupid

[John Allsup]

And that is basically what a var in javascript is: a javascript object or null. Null in Javascript is similar to None in python.

Re: This is stupid

[devent]

It's just the same thing. Call it None or null, who cares.

Re: This is stupid

[DetriusXii]

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.

Re: This is stupid

[devent]

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.

Re: This is stupid

[DetriusXii]

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?

Re: This is stupid

[devent]

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.

Re: This is stupid

[DetriusXii]

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.

Re: This is stupid

[devent]

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.

Null Means Null

[Anonymous Coward]

I mean, you wouldn't ask someone who is sleeping if they want a cup of tea.

(If you don't get this joke, you are better off.)

What TypeScript is

[steveha]

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.

Re:What TypeScript is

[tgv]

It's precisely that: Javascript with type checking and a few features that make programming a bit easier. If you have to write in Javascript, you really owe it to yourself to check it out.

Re:What TypeScript is

[SeaFox]

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.

You left out the part about it being developed and maintained by Microsoft. So it's a language that generally imitates something someone else has done and is already a standard, but adds it's own special new features that are not in the original, thus making a case you should use this new Microsoft technology and not the other.

Where have I heard that before...

Re:What TypeScript is

[garethjrowlands]

The first sentence of that wikipedia page you linked says that it's free and open source (with those words hyperlinked to their definitions). It's developed on github like any other open source project.

The license is Apache 2.0:
https://github.com/Microsoft/T...

Re:What TypeScript is

[garethjrowlands]

Its main competitor is Facebook's Flow, https://flowtype.org/ . They're influencing each other, in a good way.

Re: What TypeScript is

[Anonymous Coward]

*yawn*

Get some new material, Slashdot.

Re: What TypeScript is

[Anonymous Coward]

Are you seriously saying that all open source projects are developed on GitHub?

Re:What TypeScript is

[Karlt1]

Google is also a big proponent of TypeScript. Angular 2 is being written in TypeScript.

Re:What TypeScript is

[balbeir]

Agreed, I'd say Typescript is relevant because of angular2.

Re:What TypeScript is

[Anonymous Coward]

[TypeScript] adds it's own special new features that are not in the original, thus making a case you should use this new Microsoft technology and not the other.

So the TypeScript guys are encouraging you to use TypeScript by adding features to TypeScript? What a diabolical, dastardly plot!

TypeScript trans-compiles to standard JavaScript that runs anywhere, so I'm really not seeing the lockin here. And did you miss the part where it works with standard JavaScript libraries without requiring the libraries to be re-implemented?

Where have I heard that before... https://en.wikipedia.org/wiki/Embrace,_extend_and_extinguish

Since TypeScript is free, open source software with an Apache license, how can Microsoft ever extinguish it? Software, once freed, cannot be un-freed. If you can use TypeScript today, you can use it forever.

Go away, and come back when you have an actual complaint that makes sense.

Re: What TypeScript is

[Billly Gates]

So?

MS like any organization makes great and crappy software.

So they make mediocre operating systems. They do make excellent business software and good development software like C# and visual studio. Gnu makes great operating systems and ok development software.

Use the right tool for the job. It is open source and compiles to JavaScript so no locking. Why can't ms make something good considering no one makes everything good? Are you that biased?

TypeScript is a bad idea...

[Anonymous Coward]

...poorly implemented. Yet another MicroSoft-quality product. 'nuff said.

Rust gets it right

[DrXym]

Rust probably isn't quite a "mainstream programming language" although it's getting close. But anyway it doesn't support null or null pointers for normal safe programming. Objects are created by declaring them so they either are or they aren't.

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.

Re:Rust gets it right

[firewrought]

Unfortunately, habituating your developers to call .unwrap() on everything (with the tacit "oh I know it's bad, but..." approval) doesn't really put you in a better place.

What you have with Result<T,E> and especially Option<T> is the concept of null delivered in a purposefully non-ergonomic form, with the theory being that the extra explicitness will drive developers to write better code by default. However, that unwrap() escape hatch is mighty convenient; time will tell if the theory was right or not.

Re:Rust gets it right

[DrXym]

You don't have to unwrap on everything though. If I have a function that is guaranteed to return something (e.g. a constructor) it just returns that thing. Compare to C++ where anything that returns a pointer is potentially capable of returning NULL even if it shouldn't.

Option and Result are only necessary for actions which might legitimately might return something or might not. e.g. a network request, or retrieving a record from a database. Even there it's not necessary to unwrap since you could say "if let Some(foo) = do_something() { ... } else { ... }" and the object foo will be unwrapped straight into the variable foo.

I think Rust has some very clumsy syntax though especially when types are nested inside boxes, cells or whatever. It'd be nice to have a super unwrap which can reach all the way into a boxed, refcounted thing and just return it with minimal code.

Copyright?

[Anonymous Coward]

Are you allowed to simply cut-and-paste three paragraphs from Ars Technica to Slashdot? Even though you attribute it, it's still a copyright violation.

Re: Copyright?

[Anonymous Coward]

Isn't this site just an alternate front end for Ars where Linux people can bash TEH EVIL MICRO$OFT?

Why use TypeScript when there's

[PJ6]

DuoCode?

I've been much happier keeping everything in C#.

Re: Why use TypeScript when there's

[Billly Gates]

Because websites still use JavaScript for client side stuff. Typescript makes this job easier and oddly use JavaScript like a byte code in Java where it compiles to JavaScript so it works in every browser or mobile app

Re: Why use TypeScript when there's

[PJ6]

Because websites still use JavaScript for client side stuff. Typescript makes this job easier and oddly use JavaScript like a byte code in Java where it compiles to JavaScript so it works in every browser or mobile app

Um, yeah, DuoCode transcompiles C# to JavaScript.

Maybe you should have clicked the link before posting.

Null is there for a reason

[devent]

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.

Fix OOP (Re:Null values as errors)

[Tablizer]

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.)

Re:Fix OOP (Re:Null values as errors)

[Anonymous Coward]

Would have been nice if you'd actually achieved clarity.

As it is, you haven't really explained what you mean by "stiff", or what an alternative might look like.

Re:Fix OOP (Re:Null values as errors)

[Tablizer]

I'll try to find a better way to explain it, perhaps with some kind of pseudo-machine-language to show how the compiler/interpreter processes stuff.