News for hackers. Stuff that matters.
Re:Is your programming language unreasonable? (2015) by tremon on Saturday October 10, 2020 @07:00AM (#24738091)
Not only that, it implies that there must be a valid null-state for every type, which is also a bad idea.
Re:Is your programming language unreasonable? (2015) by lmm on Saturday October 10, 2020 @07:29AM (#24738202)
No it doesn't; the whole point is to avoid every type having a null state. You only define null states for those types for which it's semantically valid. For most types, you just don't have a null state and don't allow them to be constructed in an invalid state.
Re:Is your programming language unreasonable? (2015) by sullyj3 on Saturday October 10, 2020 @07:26AM (#24738192)
I'm not entirely sure what you're getting at here. Are you saying the author is arguing a call like

  new Customer()
should return something valid? I think the FP way would be to disallow constructor overloads with no arguments, as really, there's no reasonable thing to be done here. If you don't have all the necessary information to initialize a customer yet, you don't get to initialize one, and you pass around a partially applied constructor function instead.

ie, The argument is that (in pseudocode):

  Customer(name = "Jimmy", address = null)
is not really a customer if address is a necessary piece of information, so we should distinguish at the type level by passing around a function that takes the address and returns the correctly initialized Customer like so

  \addr -> Customer(name = "Jimmy", address = addr)

Admittedly, this prevents you from accessing name until you provide an address, but I don't think there are many valid use cases where you want to access data before the Customer value is corrrectly initialized. I'd consider this a code smell to be refactored.
Re:Is your programming language unreasonable? (2015) by learc83 on Saturday October 10, 2020 @08:15AM (#24738417)
> Admittedly, this prevents you from accessing name until you provide an address, but I don't think there are many valid use cases where you want to access data before the Customer value is corrrectly initialized. I'd consider this a code smell to be refactored.

If you really needed to do that you could just define a partial customer with no address field and pass are that around.

Re:Is your programming language unreasonable? (2015) by jackcviers3 on Saturday October 10, 2020 @07:20AM (#24738167)
No, it implies that there must be a generic two-valued datatype to wrap every state:

Just t | None

You can have your null case, and avoid the null-pointer exception, default keyword, chained ? null-check hellscape in which we currently reside.

Re:Is your programming language unreasonable? (2015) by dudul on Saturday October 10, 2020 @07:49AM (#24738296)
No, it implies that you can use your type system to surface the fact that a variable may have no values.