3 ms·

> The only way I can think of making this sound and well-typed, is that null supports any fields and any methods, returning always null. That sounds a lot like

> The only way I can think of making this sound and well-typed, is that null supports any fields and any methods, returning always null. That sounds a lot like NaN, which is often conspicuously absent from diatribes against NULL.

jerf 8y ago
Numeric computation, which I distinguish from simple addition or something to place windows to describe something where you are doing "serious math" of some sort, is too exceptional to be a useful contribution to this discussion, I think. It's a very rigorous mathematical space, but it's not the mathematical space most of the rest of our code is in, which is generally simpler. Another place where I consider math code an exception is that I'm find with numeric operator overloading, but generally think it's a bad idea for "normal programming". Being able to multiply a 5x3 matrix by a 3x8 matrix makes sense. Being able to scrape a web page by multiplying a string by a web scraper does not. "Normal programming" lacks the structure necessary to lay down such a rigorous stack on top of it. (And it's not just because of "lazy programmers"; it truly lacks the requisite structure. Even a very Haskell-y Haskell program in the "normal programming" space doesn't have something that looks like a complicated numeric stack... this is where the applicatives and monads and profunctors come in. Well-structured "normal programming", even very "mathematical" "normal programming", is not structured like heavily-numeric code. That's a sort of "complicated stack" of its own, but even then I'd characterize those abstractions as having a structure where you are almost always building properties up as you go "up" the stack. Contrast with the numeric tower where as you build up, you are generally losing properties; numbers are fully ordered, until you add complex numbers. Complex numbers multiply commutatively, until they become quaternions. Any number can be multiplied by any other until the "numbers" become matrices. Etc. The numeric tower builds in the opposite "direction" from the "normal programming" tower. There's a sense in which you could turn it upside down, but it's not one most people are even going to wrap their head around, let alone want to use.)
barrkel 8y ago
"The only good NaN is a signalling NaN." Delphi's RTL set the FPU flags to default to signalling NaNs, causing some havoc when linked against C and C++ libraries (usually gaming libraries) that assumed otherwise. You usually don't want a divide by zero poisoning your data, for the same reasons you don't want unnoticed nulls infecting your data structures. Exceptions can be made for scoped blocks of code, but it's not a good default.

jerf 8y ago

Numeric computation, which I distinguish from simple addition or something to place windows to describe something where you are doing "serious math" of some sort, is too exceptional to be a useful contribution to this discussion, I think. It's a very rigorous mathematical space, but it's not the mathematical space most of the rest of our code is in, which is generally simpler. Another place where I consider math code an exception is that I'm find with numeric operator overloading, but generally think it's a bad idea for "normal programming". Being able to multiply a 5x3 matrix by a 3x8 matrix makes sense. Being able to scrape a web page by multiplying a string by a web scraper does not. "Normal programming" lacks the structure necessary to lay down such a rigorous stack on top of it. (And it's not just because of "lazy programmers"; it truly lacks the requisite structure. Even a very Haskell-y Haskell program in the "normal programming" space doesn't have something that looks like a complicated numeric stack... this is where the applicatives and monads and profunctors come in. Well-structured "normal programming", even very "mathematical" "normal programming", is not structured like heavily-numeric code. That's a sort of "complicated stack" of its own, but even then I'd characterize those abstractions as having a structure where you are almost always building properties up as you go "up" the stack. Contrast with the numeric tower where as you build up, you are generally losing properties; numbers are fully ordered, until you add complex numbers. Complex numbers multiply commutatively, until they become quaternions. Any number can be multiplied by any other until the "numbers" become matrices. Etc. The numeric tower builds in the opposite "direction" from the "normal programming" tower. There's a sense in which you could turn it upside down, but it's not one most people are even going to wrap their head around, let alone want to use.)

barrkel 8y ago

"The only good NaN is a signalling NaN." Delphi's RTL set the FPU flags to default to signalling NaNs, causing some havoc when linked against C and C++ libraries (usually gaming libraries) that assumed otherwise. You usually don't want a divide by zero poisoning your data, for the same reasons you don't want unnoticed nulls infecting your data structures. Exceptions can be made for scoped blocks of code, but it's not a good default.