251–260 of 377 posts
You know who works on a platform with NULL but doesn't have quite so many problems with it? DBAs. There's some need to draw a distinction between the basic idea of NULL, and the way that NULL has been implemented in most high-level programming languages. In most RDBMSes, values can't be null unless you say they are. Sometimes explicitly, as in table definitions, sometimes implicitly, when you select a JOIN type. Eith…
Earlier quoted context omitted.
>This is not the source of the vast majority of pointer errors. >Checking for (and trapping) NULL pointer dereferences is trivial, what is more difficult is the rest of the pointer range that doesn't get checked but is equally invalid, i.e. the other 4-billion (32-bit) possibilities. I think we write vastly different types of software. I can assure that that null-related errors are extremely common in situations besi…
Two things are getting conflated here. Pointer issues (that I was referring to) and a failure indication. The most trivial pointer issue is a NULL pointer. This is such a trivial issue to catch its hardly even an error, yet people use that case as the exemplar for NULL issues. detecting (and handling) failures on the other hand is very much different and more in the spirit of what the option-type arguments are about.…
How can you claim that NPEs are "hardly ever an error." NPEs are the most common error there is! They are indeed easy to catch, but you need to do so nearly everywhere, obscuring the code and introducing potential for error. There is no real, conceptual difference between something like a malloc returning null or a database query result containing a null. It is the same thing.
A null absolutely is an error if you don't catch it. By not using Options, it's vastly easier for that to happen.
The problem is in tooling. If all compilers/builders out there could detech null for us, those kinds of error could be taken care with much more ease.
Earlier quoted context omitted.
That's not really NULL's fault that it causes confusion in SQL. That's just ternary logic. People who don't handle NULLs in SQL aren't really mishandling the NULL. NULL is just a value. They're simply failing to understand the Boolean value of UNKNOWN and what that means. They're so used to thinking only in bivalent logic that the additional complexity throws them off. However, "It's more complex for me to think abou…
> Or arguments about zero-based array indexing. These concepts aren't difficult. They're just more complex. Negative numbers aren't difficult, but they're more complicated than just cardinal numbers. Fractions and decimals aren't difficult, but they're more complex than integers. Multiplication and division aren't difficult, but they're more complex than addition and subtraction. We usually consider it a good thing w…
Earlier quoted context omitted.
If you know something can't be null, then don't use an option. Simple as that. For example, a SQL library can return a non-nullable column of String as just a String, not an Option[String]. Thus, you actually get a solid distinction that you don't get with null pointers. There's no reason to include sentinels that will randomly blow up your program.
No. The point is that the data structure can't know if there's a NULL since the data structure is static. Context is dynamic. Code is dynamic as well, and it can know that some things must exist based on other dynamic conditions. So this "solid" distinction often is just noise and actually blurs the intention of the programmer: An explicit unwrap is required syntactically while it should not be required semantically…
In this fashion, you have type safety everywhere, and you deal with the case of a missing value in a predictible way, in a single spot.
Anyway, my feeling is that I don't understand what people expect to happen here. Due to a misunderstanding, bad assumption, or other error, you expected to have something when you actually don't have the thing. A null-reference exception (or equivalent) is just the symptom. Null isn't the problem, our dumb brains that constantly make dumb mistakes are the problem.
Option/Maybe does force you to deal with the case that you didn't get anything when you asked for something. But as Hickey points out in his talk, it isn't all benefit, there is a cost, and nobody ever talks about the cost. When I provide you an id and ask for a Book object in return, I want a Book back, not a `Maybe Book`. This concept does not map to anything in the real world, and it has problems in practical usage as well.
(e.g. My function changes from maybe giving you a Book or maybe not, to definitely providing you a Book. So I change its return type from `Maybe Book` to `Book`. Except, oops, I just broke every single caller of my function, even though I strengthened the guarantee of the data my function will provide. That shouldn't break anyone.)
https://www.youtube.com/watch?v=YR5WdGrpoug (Discussion of Option/Maybe starts 6:50)
Earlier quoted context omitted.
The major criticism towards NULL's does not apply to dynamic languages. The problem in languages like Java is that nullability is not represented in the type. This criticism is not relevant in a language without static type checking. The criticism is also not relevant in a language like TypeScript where nulls are specified in the type. In short, the problem is not nulls per se, the problem is static type systems whic…
The OP specifically calls out ways that nulls cause problems in dynamic languages. In fact, they're very similar to the problems nulls cause in statically typed languages, just ignoring some of them because danger is already priced in with a dynamic language. Dynamically typed programs are usually informally "duck typed," since it's impossible to do something meaningful with truly arbitrary types most of the time. Bu…
But of course you can make bugs involving nulls. The OP shows an example in a dynamic language where null is returned instead of the regular value if a lookup key is not found. Obviously this is ambiguous when the found value can also be null. But the problem is not the null per se, the problem is using a sentinel value to indicate a special condition when the same value is also a legitimate regular value. This is just bad API design.
Earlier quoted context omitted.
Yes, option types are awesome. No, they are not nulls. Algebraic data types are not direct support "no data found at the type level". Algebraic types are really just a fancier enum/union type. It just so happens that inventing special sentinel values is awesome when you have an algebraic type system to check your work.
Take a look at Kotlin or Typescript†. Basically, they decided to fully design the language with support for null-as-option. That means several things: * T (non-nullable) and T? (nullable) are different types. T? = T | null * Where T is expected T? is not accepted, but where T? is specified T is also accepted * T? is automatically cast to T in the places where it's asserted to be not null, e.g. within an if(x != null)…
(Previously said T?? rather than T?, thanks to corrections in replies)
Earlier quoted context omitted.
I think it would be nice if `NOT NULL` was set by default on columns. However there are a lot of legitimate use cases that can't be (practically) solved by restructuring. Data can be incomplete. Maybe only because it is not (yet) known. If NULL values were impossible it would create the need for one additional table with a foreign key relationship for every attribute that can be independently NULL. Sometimes this pat…
>I think it would be nice if `NOT NULL` was set by default on columns Then make sure to have explicit defaults?