LtU on Dart

http://lambda-the-ultimate.org/node/4377#comment

by sorenbs • 15 years ago

76 32 15 years ago

devin• 15 years ago

Anyone wanna bet this is the article no one reads because it's not link-bait enough? Sorry for being so cynical, but I can't help myself.

sambeau• 15 years ago

It's great to see LtU linked-to on HN. It was also cool to see the link back from LtU to HN.

ot• 15 years ago

Here it is:

http://lambda-the-ultimate.org/node/4377#comment-67585

jazzyb• 15 years ago

The user neelk states that one of the bad things about the language is "Null. In 2011." Can someone clarify for me why having null in a language is bad (other than how dereferencing/calling-a-method on null in most languages results in your program crashing)? Come to think of it, I'm not even aware of a language without null.

jganetsk2• 15 years ago

It's not null that's the issue, it's that everything is nullable by default (and there is no way to statically guarantee something non-nullable).

OCaml and Haskell are not-nullable by default, and things that are nullable have an extra layer around them that must be dealt with. This is quite sensible.

enneff• 15 years ago

Go strikes a nice balance, IMO.

Value types (booleans, numbers, strings, structs, arrays) cannot be null, while reference types (pointers, slices, maps, channels) may be null.

Also, Go calls null 'nil', which is fitting since nil is the zero value of a reference type. (All variables are initialized to their zero value unless otherwise specified.)

sdevlin• 15 years ago

It's not really having null that's bad. What's bad is making types nullable by default. More often than not, null is not a valid value for a variable (in my experience - YMMV). This is a common source of errors.

Some languages (I'm thinking of ML and Haskell) require you to opt into nullability with an option type (e.g. http://www.standardml.org/Basis/option.html).

What's worse is that many mainstream languages do not allow you to opt out of nullability. I.e. most or all types are always nullable.

sgk284• 15 years ago

The problem with null is that when anything can be null, your type system is always lying to you and as a result you don't get the full benefits of a real type system (see Haskell for a great type system).

When a var is a boolean, you can't assume it's true or false, because it could also be null. Or when you pass a Car object into a function, you've been promised a Car but were lied to because it might also be null.

In a proper type system, if you ask for a boolean, you know that variable is either true or false and when you ask for a car, you're guaranteed to get a car.

Of course, you can always have the option of allowing null values, but you should explicitly have to state that it's okay.

robinhouston• 15 years ago

There’s a strand of thinking which holds that null references are a common source of avoidable errors that the compiler could have prevented in a better-designed language. The objection is not so much that nulls exist, but that it’s impossible to declare a reference variable as “not null” in a way that the compiler can check.

Tony Hoare recently (2009) called null references his “Billion Dollar Mistake” [1, 2, 3].

1. http://qconlondon.com/london-2009/presentation/Null+Referenc... 2. http://www.infoq.com/presentations/Null-References-The-Billi... 3. http://lambda-the-ultimate.org/node/3186

losvedir• 15 years ago

My dabbling in Haskell has given me a new perspective on null.

Previously, to me "null" was just "that other value that a variable gets if the function doesn't work or something unexpected happens." It was useful if ugly. I didn't fully grasp how much that null possibility permeated my code, since I didn't know any other way.

However, in Haskell, if something is an integer, it really is an integer of some sort. Null is not allowed.

So if you're writing a function that works with numbers, you really have to think about what are valid inputs and outputs. If you're working with a function whose domain really is all integers, then you can indicate that with a Integer -> Integer function, and you're on rock solid ground.

However, if you're writing a function like, e.g. square root, where the domain is not all integers, then you have to worry about what happens if you get a negative one. Now you can choose to bring in "null" as an allowable value, but it will have to be explicitly indicated and dealt with. Your function, for all the world to see, will be Integer -> Maybe Integer, and then any other function that uses that function will be forced to deal with the fact that a null might happen.

timclark• 15 years ago

This is Haskell esoterica, any value can set as undefined an equivalent value to null. However, you never see code using undefined as null since Maybe a is so much clearer.

cachemoney• 15 years ago

An alternative is an option type. In scala, you have the abstract type Option[T], which has implementations Some[T](value: T) and None[T].

Alternately, you have Either[A, B], with implementations Left[A](value: A), and Right[B](value: B).

So you can define a function that takes an Either[Int, ErrorMessage], rather than an Int or null. Getting a None[Int] is better than null, because it won't throw NullPointerExceptions if you access it sensibly.

Examples:

    def x2or0(i: Option[Int]): Int = i.getOrElse(0) * 2

    def x2(i: Option[Int]): Option[Int] = i.map(_ * 2)

    def x2danger(iOrPossiblyNull: Int) = i * 2
    // throws NullPointerException on null input

rayiner4• 15 years ago

The responses below are an adequate summary of what would be the case if a statically typed language (Haskell, ML) featured nullable types.

However, they're all largely inapposite for Dart. Dart's type system can't even ensure, at compile-time, that you'll never see an integer in a variable typed as a string. It can catch a lot of such cases, but it's fundamentally a dynamically-typed language and can't make really any guarantees at all statically. So non-nullable types in Dart would be a fiction. Any object typed anything might end up being null at runtime.

ericbb• 15 years ago

I haven't read much at all about Dart yet so forgive me if I'm missing something but it seems to me that dynamic-typing capabilities do not rule out absence-of-null.

Doesn't Dart's use of optional typing mean that it really behaves as a statically-typed language in some contexts? The Go language sort of has this via interface types. Consider the following:

    type Foo struct { a, b int }

    func Bar(x interface{}) Foo {
        if f, ok := x.(Foo); ok {
            return f // x is a Foo at runtime so return it
        }
        return Foo{0, 1}
    }

There is no need for the Foo type to have a null value. Go does have general zero-values for all types but that's somewhat different from null and not the only solution either. I think a Haskell-like model (neither null nor zero-value) could also work.

azakai• 15 years ago

> The user neelk states that one of the bad things about the language is "Null. In 2011." Can someone clarify for me why having null in a language is bad (other than how dereferencing/calling-a-method on null in most languages results in your program crashing)?

That right there is the reason. Those crashes are a huge burden on the software industry, it's even been called the "billion dollar mistake",

http://lambda-the-ultimate.org/node/3186

And of course it is possible to have references which cannot be null, for example, even C++ has this: References as opposed to pointers. Many new languages have adopted the non-null approach, off the top of my head, Rust.

bartwe• 15 years ago

Compiletime enforcement that a reference isn't null in a language like java is very powerfull, more useful then c++ const in my opinion.

rayiner4• 15 years ago

Reading LtU makes me sad that an entire generation of computer science students were raised to think programming language design is coextensive with type system design.

Not that I think that Dart is particularly creative from a PL design standpoint, but I read the complaints about covariant genetics and think: who cares about the type system? It's optional after all!

nandemo• 15 years ago

I don't think LtU is all about type system design. There are plenty of discussions about parsing, semantics, programming language implementation and so on.

And type system is optional? Besides Assembly, I can't think of any widely used programming language that is untyped.

Yes, there are plenty of languages with weak typing or dynamic typing, but that's very different from no typing at all.

rayiner4• 15 years ago

I mean there are articles on LtU about typing parsers, expressing semantics through typing, etc. Which is fine its a forum with a specific niche, what is sad is that niche has come to totally dominate PL design in academia.

And at least the static type system in Dart is optional. Yet all I hear about Dart is digs at its static type system. Can't express non-nulity, has covariant generics, etc. Who really cares? It's designed to throw up a warning when you pass a string to Math.min, not to allow expressing every static invariant possible through the static type system.

simcop2387• 15 years ago

And to be fair even Assembly might be considered to be typed on most architectures. You've got multiple different sized integers, and possibly floating point registers.

yassim• 15 years ago

Dart (from what I've heard) is actually a form smalltalk. strongtalk[1] is also an optional typed system.

[1] http://www.strongtalk.org/

barrkel2• 15 years ago

Ehud drops heavy hints when things wander too far from the academic and theoretical mainstream (which happens to be proving more and more things with type systems, by and large). Discussing pragmatics that tread into territory covered by existing books is discouraged.

JeremyBanks• 15 years ago

You've misunderstood the type system. It's not untyped, it's the static typing that is optional. It's mostly just your typical dynamic type system with optional type checks in debug mode and (incompletely) at compile-time.

LtU on Dart

Related Stories