3 ms·

I was kind of hoping that they would get rid of null or undefined (or both). While I understand that null and undefined are not the same, are both truly needed?

I was kind of hoping that they would get rid of null or undefined (or both). While I understand that null and undefined are not the same, are both truly needed? Seems like a missed opportunity to make the language cleaner. They seem redundant when you have exception handling, which I think makes the flow of the code easier see. Could they be removed?

erokar 8y ago
The point of TS was always to be a superset of JS, so in that sense I doubt they want to get rid of something that exists in plain JS.
saurik 8y ago
Part of the premise (and I think this is very noble) is that they are trying to be descriptive of what JavaScript is, not prescriptive of what anyone wishes JavaScript should have been. (That said, I don't even understand what you mean by saying that both null and undefined seem redundant when you have exception handling... how do you represent "this exists or it doesn't exist" in the type system if you can't do a union type of "X" and "null"? I don't see how exception handling has anything to do with null/undefined.)
- kroltan 8y ago
  > how do you represent "this exists or it doesn't exist" in the type system if you can't do a union type of "X" and "null"? Like this, pick your flavor: https://doc.rust-lang.org/std/option/enum.Option.html https://doc.rust-lang.org/std/option/enum.Option.html https://docs.oracle.com/javase/8/docs/api/java/util/Optional.html https://docs.oracle.com/javase/8/docs/api/java/util/Optional... https://docs.microsoft.com/en-us/dotnet/api/system.nullable-1 https://docs.microsoft.com/en-us/dotnet/api/system.nullable-... https://wiki.haskell.org/Maybe https://wiki.haskell.org/Maybe If you don't want to follow links: Instead of having nulls, have a type which is either a discriminated union (not possible in JS) or is a (isPopulated, value) pair, and accessing the value is an exception if isPopulated=false. Granted, that would be an extremely breaking change for a JS-compatible language, which would make it in fact incompatible. But answering the question, that's it.
- velox_io 8y ago
  I should have been more specific. Yes, the --strictNullChecks switch almost gets you there.. I forget there's also the 'never' type, and '{}', which are very similar to null (I've seen someone use the string null in production). The reason I bring this up is that if you remove null, it removes the need for both of '==' & '===' (could possibly be removed with something like strictEqualityChecks). Exception handling and null checks are both conditional, so there is the potential to replace checking for null with exceptions. Plus, removing the null checks (is an object still an object when most of its properties are null?) could be fixed with better use of inheritance. And the '?' suffix. This is not the first language Anders has been involved in developing, I'm sure remember him talking about his dislike for null somewhere (I could be wrong). Typescript is both an abstraction and adds features to Javascript. So TypeScript has the opportunity to remove such idioms. Scala and Java are very different languages despite running the same underneath. The question at the end of the post was more hypothetical. Could this be done or is the concept of null is so ingrained that it can't be removed? (When Functional programming manages null.) I'm just interested, especially when null is known as the "Billion Dollar Mistake" - that's ignoring inflation.
gr__or 8y ago
How would you remove them while still being fully compatible with existing JS code? I mean they could do it, it'd just be orthogonal to their goal of TS being easy to bring into existing codebases.
mattbierner 8y ago
Modern TypeScript aims to add typings to JavaScript, so eliminating a core language primitive—even a rather appendiceal one like null—is probably out of that scope, especially because some js libraries do differentiate between null and undefined. I highly recommend using TypeScript's strict null checks mode as it makes undefined and null their own distinct types and requires that you explicitly state when a field or argument is nullable. The programming experience is somewhat similar to working with 'optional' types in languages like Scala or Swift. See the 'nullable types' section of this document for more info: https://www.typescriptlang.org/docs/handbook/advanced-types.html https://www.typescriptlang.org/docs/handbook/advanced-types....
tracker1 8y ago
I've used it to differentiate between uninitialized (undefined), and a new record (null, not set yet) in my routing... navigation triggers a reducer action that will "reset" the underlying state if the id doesn't match the loaded record. In the case of a "/type/create" the "id" is null. In the case of "/type/:id/edit" the "id" is ":id" from the route. I can then reset to an object with an undefined Id, and the component can call an action to dispatch a load. Probably a convoluted example, however there are distinctions that can be used between the two. Similar to how I've used null + boolean as a tristate with default, true, false where null is default. Undefinied or uninitialized is useful beyond simply null.

erokar 8y ago

The point of TS was always to be a superset of JS, so in that sense I doubt they want to get rid of something that exists in plain JS.

saurik 8y ago

Part of the premise (and I think this is very noble) is that they are trying to be descriptive of what JavaScript is, not prescriptive of what anyone wishes JavaScript should have been. (That said, I don't even understand what you mean by saying that both null and undefined seem redundant when you have exception handling... how do you represent "this exists or it doesn't exist" in the type system if you can't do a union type of "X" and "null"? I don't see how exception handling has anything to do with null/undefined.)

kroltan 8y ago
> how do you represent "this exists or it doesn't exist" in the type system if you can't do a union type of "X" and "null"? Like this, pick your flavor: https://doc.rust-lang.org/std/option/enum.Option.html https://doc.rust-lang.org/std/option/enum.Option.html https://docs.oracle.com/javase/8/docs/api/java/util/Optional.html https://docs.oracle.com/javase/8/docs/api/java/util/Optional... https://docs.microsoft.com/en-us/dotnet/api/system.nullable-1 https://docs.microsoft.com/en-us/dotnet/api/system.nullable-... https://wiki.haskell.org/Maybe https://wiki.haskell.org/Maybe If you don't want to follow links: Instead of having nulls, have a type which is either a discriminated union (not possible in JS) or is a (isPopulated, value) pair, and accessing the value is an exception if isPopulated=false. Granted, that would be an extremely breaking change for a JS-compatible language, which would make it in fact incompatible. But answering the question, that's it.
velox_io 8y ago
I should have been more specific. Yes, the --strictNullChecks switch almost gets you there.. I forget there's also the 'never' type, and '{}', which are very similar to null (I've seen someone use the string null in production). The reason I bring this up is that if you remove null, it removes the need for both of '==' & '===' (could possibly be removed with something like strictEqualityChecks). Exception handling and null checks are both conditional, so there is the potential to replace checking for null with exceptions. Plus, removing the null checks (is an object still an object when most of its properties are null?) could be fixed with better use of inheritance. And the '?' suffix. This is not the first language Anders has been involved in developing, I'm sure remember him talking about his dislike for null somewhere (I could be wrong). Typescript is both an abstraction and adds features to Javascript. So TypeScript has the opportunity to remove such idioms. Scala and Java are very different languages despite running the same underneath. The question at the end of the post was more hypothetical. Could this be done or is the concept of null is so ingrained that it can't be removed? (When Functional programming manages null.) I'm just interested, especially when null is known as the "Billion Dollar Mistake" - that's ignoring inflation.

gr__or 8y ago

How would you remove them while still being fully compatible with existing JS code? I mean they could do it, it'd just be orthogonal to their goal of TS being easy to bring into existing codebases.

mattbierner 8y ago

Modern TypeScript aims to add typings to JavaScript, so eliminating a core language primitive—even a rather appendiceal one like null—is probably out of that scope, especially because some js libraries do differentiate between null and undefined. I highly recommend using TypeScript's strict null checks mode as it makes undefined and null their own distinct types and requires that you explicitly state when a field or argument is nullable. The programming experience is somewhat similar to working with 'optional' types in languages like Scala or Swift. See the 'nullable types' section of this document for more info: https://www.typescriptlang.org/docs/handbook/advanced-types.html https://www.typescriptlang.org/docs/handbook/advanced-types....

tracker1 8y ago

I've used it to differentiate between uninitialized (undefined), and a new record (null, not set yet) in my routing... navigation triggers a reducer action that will "reset" the underlying state if the id doesn't match the loaded record. In the case of a "/type/create" the "id" is null. In the case of "/type/:id/edit" the "id" is ":id" from the route. I can then reset to an object with an undefined Id, and the component can call an action to dispatch a load. Probably a convoluted example, however there are distinctions that can be used between the two. Similar to how I've used null + boolean as a tristate with default, true, false where null is default. Undefinied or uninitialized is useful beyond simply null.