131–140 of 164 posts
Earlier quoted context omitted.
I might choose to rephrase that as "the problem is, some of these languages think that "" and null are equal." :-)
Isn't the lack of strict equality a result of loose typing in those languages?
The problem isn't really that null isn't an object, it's that the type system allows any object reference of a particular class to also be null. After using Typescript for the past couple years, it's such a joy when you define a variable of type Foo and know it won't contain null. Granted, TS also has to deal with undefined vs null weirdness (and even more weirdness in that an object not containing a property is subt…
Seeing all this discussion reinforces the idea that no new programming language should have this "every type implicitly contains null" thing
Earlier quoted context omitted.
I‘d say its the other way around, Java is closing the gap, and I say that as a Kotlin fan. Nullability in the type system is the big remaining advantage.
Scope functions are still huge. Yes, deep let chains can certainly be considered an antipattern (sometimes I like the approach of writing them, then transforming to more imperative for readability, I think readability peaks at a mix of imperative with some shallow .let), but I miss them in any language that is not kotlin. Variables should be the exception, not the norm. I have no patience for names that designate som…
I’d put any one of extension methods, value and data classes, immutable variables, structured concurrency, and top-level functions ahead of scope functions for reasons to switch to Kotlin. But hey, if you’re switching, we’re already friends :) .
Earlier quoted context omitted.
Seeing all this discussion reinforces the idea that no new programming language should have this "every type implicitly contains null" thing
Yes, sum types and generics solve this nicely. It's a shame Java was designed before they had generics, so the core of the language can't take advantage of them.
Earlier quoted context omitted.
> There is a semantic difference between Option > and Option . If I intend to retrieve a setting from a file, the former allows me to differentiate between a missing file or a missing setting Does nesting Option's really has practical use or does it quickly become confusing? In your example, Option > return type doesn't tell me by itself that this differentiates between a missing file or a missing setting. I would ne…
The biggest impact is on generic code - you don't want supplying Foo? as T rather than Foo to mean that there are side effects where successful returns and error cases are both represented by null.
The thing is that nullable covers majority of cases and is quicker to read and write (Foo? vs Option). Doing a?.b?.c is also more elegant than anything equivalent using an Option type.
Is there any languages that successfully combines both, nullable '?' syntax and an Option type?
Earlier quoted context omitted.
I dont think there is something wrong with that once you think about what is a Null Element (or identity) in a group that is represented by a set of elements and a function: Integer, + => 0 Float, + => 0.0 Array, add => [] Hash, merge => {} and so on. I think maybe we can debate the operations/functions, but they make sense. For Integer in some ways you can define almost all other operations that you commonly use bas…
Integers support both addition and multiplication and taking maximum and minimums, and a few other semi-group operations. Do you want to define different Null elements for all of them?
But, for me, it makes sense to have a default representation for Null (that it is not automatically coerced—only if the developer explicitly asks for it) for one of the most common operations in that specific group.
Earlier quoted context omitted.
Scope functions are still huge. Yes, deep let chains can certainly be considered an antipattern (sometimes I like the approach of writing them, then transforming to more imperative for readability, I think readability peaks at a mix of imperative with some shallow .let), but I miss them in any language that is not kotlin. Variables should be the exception, not the norm. I have no patience for names that designate som…
> Scope functions are still huge. I’d put any one of extension methods, value and data classes, immutable variables, structured concurrency, and top-level functions ahead of scope functions for reasons to switch to Kotlin. But hey, if you’re switching, we’re already friends :) .
You missed optional and named arguments in the list, those really change cost/benefit decisions in API design. (and, unfortunately, make argument names part of the public interface, this must be the most controversial part in all of kotlin)
I singled out scope functions because all those other things feel very much like the usual set of language differences, whereas scope functions feel completely orthogonal. They could be added to every single language that has excursions and imperative elements, and they would be about the same improvement everywhere.
I like the way null is handled in Java, I think it’s pretty well thought out, other than the small awkwardness with basic types. Contrast that with SQL, which had my external scorn for null != null So you can do WHERE table.col = Null…. Ugh
The null != null thing is something I quite like, as it simplifies a lot of joins/queries.
and as jraph said, null in relational databases has a very different meaning than null in most programming languages.
Don't know vs not assigned
Earlier quoted context omitted.
I‘d say its the other way around, Java is closing the gap, and I say that as a Kotlin fan. Nullability in the type system is the big remaining advantage.
Scope functions are still huge. Yes, deep let chains can certainly be considered an antipattern (sometimes I like the approach of writing them, then transforming to more imperative for readability, I think readability peaks at a mix of imperative with some shallow .let), but I miss them in any language that is not kotlin. Variables should be the exception, not the norm. I have no patience for names that designate som…
They can be useful, but I can never remember which one of let, run, with, apply, and also I currently need. Also, I've noticed that they motivate overly "clever" code, especially but not exclusively in junior programmers.
The problem isn't really that null isn't an object, it's that the type system allows any object reference of a particular class to also be null. After using Typescript for the past couple years, it's such a joy when you define a variable of type Foo and know it won't contain null. Granted, TS also has to deal with undefined vs null weirdness (and even more weirdness in that an object not containing a property is subt…
Seeing all this discussion reinforces the idea that no new programming language should have this "every type implicitly contains null" thing
https://www.infoq.com/presentations/Null-References-The-Bill...