Hacker News Reader

Comment by shadowgovt | Hacker News Reader

Yep. It's probably the case that one should have a more complicated serializer / deserializer for JSON in CL (one that takes into account the expected JSON datatypes) because JSON is yet another type and value system from Scheme's and CL's, but there's an isomorphism from the Scheme one to the JSON one and there's no such similar isomorphism for the primitive CL types (though were one so inclined, one could certainly build one in one's own application).

I'd be willing to argue that this is indicative of JSON's unnecessary complexity (inherited from its source language... why does JavaScript need a false and an empty array and a null and even an undefined?), but reasonable developers can disagree on that point.

View on HN

> why does JavaScript need a false and an empty array and a null and even an undefined?)

Why does Lisp need a 0 and a nil? Because numbers are conceptually different from lists, and the number 0 is conceptually different from no number at all.

Why does JavaScript need a false and an empty array and a null and an undefined? Because all of those represent different concepts. Trying to stuff as many concepts as possible into a single representation doesn't necessarily make a language better (though I'm certainly not claiming that JavaScript is the epitome of good language design).

You want empty lists because you can't iterate a null. So an empty list should be an empty list, otherwise it will require special code to check for the null case.

Do you mean you can't iterate a null in JavaScript or in LISP?

You can't iterate a null in JavaScript, but that's a design decision of the language that could have gone another way; `for (const elem of null) {do();}` could have been specified to be valid JavaScript that never calls `do()`, but it wasn't because it wasn't.

Well if you could iterate a null, you'd also be able to sum 2 nulls. And you'd need null to carry a length (of zero, I presume).

Correct. Which could, of course, all be defined.

- null + null === null ; list + null === list; null + list === list

- null.length === 0 /* should probably make it a runtime error to write this property, or allow it but have the result be a list with length elements, all undefined */

(Note: somewhat hilariously, null + null is already defined in JavaScript. It, of course, is 0. Wat. ;) )

Whether null and empty list should be different or the same is an old argument, and both directions lead to different problems. http://thecodelesscode.com/case/6

Why not just have empty lists instead of null then? :D Seems simpler.

I agree. I use quite a few languages that don't have the "scorpion in a jar" problem where an argument might be an empty list or null (some that address it with static typing, some where the two values are the same value).

I'm not familiar with the "scorpion in a jar" idiom; guessing it's something like [to kill the scorpion you have to open the jar]... care to elucidate?

It's a reference to the "Codeless Code" link I shared upthread: 'All nothings are not equal.' A language that supports null and empty list as separate things opens the risk "what happens when the user passes null to something expecting a list?"

It is, at least, something a language with good static typing can mitigate by disallowing null as a list argument. And then there's Java...

In C you sometimes have to pass int* instead of int, because you want null to signify that you aren't passing a value, rather than passing a value of 0. The two things aren't interchangeable. An empty string and a string of length 0 aren't the same thing. You'd just end up needing an extra boolean parameter for "is_null".

Agreed. I'm not a fan of 0===false===null for equality / truthiness tests. But "null is empty list" is categorically different and fine by me.

> You'd just end up needing an extra boolean parameter

Correct. Or an Option() wrapper or another box. Such an unusual construction is fine because, as you noted, the cases where one would want to distinguish null from empty list are rare. Rare cases should stick out.

The fact that in JavaScript (and Java), every argument that takes an array could also take null and mean something different by it, triggering a runtime error as a result, is a design foot-gun. Rarely are both null and [] as different symbols appropriate; those languages made that a by-default-always-allowed feature.

> I'm not a fan of 0===false===null for equality / truthiness tests. But "null is empty list" is categorically different and fine by me.

Wat?

You might want to signify that you are not passing a list instead of you are passing an empty list. Same way that happens with any other type…

> The fact that in JavaScript (and Java)

Well in JS it's completely insane. With typed python if you say "list of XXX" null is not accepted by linters. You need to specify it's also an option.

JavaScript already has undefined as a primitive that could be used to signify you are not passing a list as opposed to passing an empty list.

I think we are talking around agreement here, which is that JavaScript was not particularly well-designed.

There is no undefined value in JSON. (Of course ommitting something is like an undefined)

https://stackoverflow.com/questions/13796751/json-undefined-...

Reply on news.ycombinator.com