social.omar.website

@omar CoffeeScript is *right there*

I mean, it's no TCL, it's no Lisp. But it is a little bundle of joy you can use to have a better time writing JS.

paradigm shift from 'the type system is there to let the compiler compile stuff' (so it can know that a variable is a 16-bit integer and needs that much space, etc) to 'the type system is there to help the programmer' (it's like a very advanced linter, has nothing to do with compilation or execution)

@omar Most dynamically typed languages don't really need in the expressiveness department so in TypeScript's case that seems like a reasonable balance.

@omar Regarding expressiveness, the stuff I always found lacking in JavaScript as a Python refugee is that you can't overload equality, hashing, etc, if you want to use the fast built-in collections. This reduces the value of user-defined data types. You can try to reimplement all those collections in the language itself on top of custom equality and hashing functions but that's not going to be as fast as a native implementation.

@omar But it does seem (empirically, not intrinsically) that lightweight object/value models like in JavaScript and Lua and classic Lisp tend to end up with very closed, non-dynamic semantics for those sorts of data type operations and predicates. Which is kind of funny when you consider their reputation as highly dynamic languages.

@omar Last I checked, if you wanted to use a pair of numbers as a key for a map in JavaScript using the built-in Map type you still have to "bottom out" in a built-in type like a number or a string or an object (with pointer identity as equality). So you either have to convert the pairs of numbers to a string to use as a key or use nested maps where each map level is indexed by one component of the key tuple.