TypeScript 2.0 Released (arstechnica.com) 89
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.
Re: (Score:2)
Yep. Amazing how much stuff gets layered onto Javascript in an attempt to turn it into a usable language.
Re: (Score:2)
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 amount
Re: (Score:2)
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.
Re: (Score:2)
"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
Re: (Score:1)
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: (Score:2)
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 (Score:4, Insightful)
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: (Score:1)
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 (Score:4, Insightful)
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: (Score:2)
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... [bbc.com]
Re: (Score:2)
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: (Score:2)
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
Re: (Score:2)
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 as
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;
Re: (Score:2)
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 e
Re: (Score:2)
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: (Score:1)
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. H
Re: (Score:2)
Re: (Score:1)
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 (Score:2)
But are they webscale?
Re: (Score:2)
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: (Score:2)
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
Re: (Score:2)
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: (Score:2)
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
Re: (Score:2)
So all your lazy programmers turn NREs into InvalidValueException (or worse, just subtle errors where invalid values are used as valid values).
Re: (Score:2)
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: (Score:2)
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: (Score:2)
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
Re: (Score:1)
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: (Score:2)
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"
Re: (Score:2)
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: (Score:2)
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 in
Re:Do away with them (Score:5, Funny)
We want a learning curve, not a learning wall.
The problem with JavaScript is that the learning curve bends in the wrong direction.
Re: (Score:2)
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
Re: (Score:2)
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 nul
Re: (Score:2)
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: (Score:2)
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 whe
Fix OOP (Re:Null values as errors) (Score:2)
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: (Score:1)
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.
Hmmm (Score:2)
null !== undefined...
Re: (Score:3)
Re: (Score:2)
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
Re: (Score:2)
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: (Score:2)
It's just the same thing. Call it None or null, who cares.
Re: (Score:1)
Re: (Score:2)
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 an
Re: (Score:1)
Re: (Score:2)
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
Re: (Score:1)
Re: (Score:2)
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.
Re: (Score:2)
And that is basically what a var in javascript is: a javascript object or null. Null in Javascript is similar to None in python.
What TypeScript is (Score:2)
I wasn't sure what TypeScript is so I looked it up.
https://en.wikipedia.org/wiki/TypeScript [wikipedia.org]
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
Re: (Score:2)
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: (Score:2)
Its main competitor is Facebook's Flow, https://flowtype.org/ [flowtype.org] . They're influencing each other, in a good way.
Re: (Score:1)
I wasn't sure what TypeScript is so I looked it up.
https://en.wikipedia.org/wiki/TypeScript [wikipedia.org]
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... [wikipedia.org]
Re: (Score:2)
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... [github.com]
Re: (Score:2)
Google is also a big proponent of TypeScript. Angular 2 is being written in TypeScript.
Re: (Score:1)
Re: What TypeScript is (Score:2)
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?
Rust gets it right (Score:2)
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 operation
Re: (Score:1)
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 ri
Re: (Score:2)
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
Why use TypeScript when there's (Score:2)
I've been much happier keeping everything in C#.
Re: Why use TypeScript when there's (Score:2)
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: (Score:2)
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 (Score:2)
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.