6 ms·
I like the concept of encoding properties, like a boolean of non-empty, in an object. Beyond that, this article further convinced me type systems are for the p
by noobiemcfoob 7y ago
I like the concept of encoding properties, like a boolean of non-empty, in an object.
Beyond that, this article further convinced me type systems are for the pedantic. A given function signature is impossible? Seems like just another strength of a dynamic language.
- aidenn0 7y agoWhat does your dynamic language do when you take the first element of an empty list? There is no obvious "correct" thing to do. Furthermore, whatever you do return is unlikely to be the same sort of thing that is returned for a non-empty list. A dynamic language will have a behavior that corresponds to some sort of type signature, and it's not possible to write behavior that corresponds with the type signatures given as examples of "impossible" in the article. A type signature is merely a statement about behavior, so it's nonsensical to make a false statement about the behavior, and Haskell catches this.
- noobiemcfoob 7y agoIt throws an error. Errors are a type of behavior. Some of those error behaviors you can cope with. You catch those. Others you can't. You raise those and either the system can cope or it can't and you crash. What part is nonsensical?
- aidenn0 7y agoThrowing an error should be part of the function signature. Otherwise the statement "This function takes a list of objects of type A, and returns an object of type A" is false; sometimes it will return an object of type A, other times it will signal an error.
- scarface74 7y agoNice in theory but if you want to see how bad it is in practice, look no further than Java.
- aidenn0 7y agoJava did a shitty job of checked exceptions. C++ did worse.
- noobiemcfoob 7y agoIt's better to assume all code could throw an error. No statement is safe. This becomes particularly important in distributed computing as resources may be offline at any given moment. It's from this perspective that type systems afford a false sense of security and appear to be scratching the itches of overactive Type As.
- aidenn0 7y agoI'm not particularly an advocate for typed languages (my daily driver for personal projects is Common Lisp, which is mostly untyped), but I'm having trouble even understanding the point of view that "No statement is safe". If I had a system where the actual type of the expression "1+2" were "3 | Error" I would find a new system. Code that doesn't read from unsafe memory locations, allocate memory, or perform I/O cannot throw an error. Code that does can throw an error. Some systems treat out-of-memory as fatal, removing one of those 3. In some domains you don't want to know if the computation is happening locally or remotely, but IMO most of the time you do because pure computation cannot signal an error locally, but remotely it can. As you mention, distributed computing often runs in this mode, but distributed computing is an overkill for most problems; my phone is powerful enough to locally compute most daily tasks (even when it's done server-side for various reasons); my workstation is powerful enough to perform most daily tasks for 100s of people simultaneously.
- noobiemcfoob 7y agoIt's hyperbole. A lot like systems that require hard type declarations for each and every function. The advantage of type systems is performance. Any correctness guarantees that come along with it are nice sugar but hardly the point and often misleading.
- lmm 7y agoNonsense. A distributed scenario is precisely where an advanced type system becomes really valuable, because you can draw a distinction between local and remote calls while still treating both in a uniform way. Treating every single call as though it were remote is impractical and wasteful.
- millstone 7y agoWhat would be the type signature of, say, Python's `pickle.load()`?
- tome 7y agoIt would be this https://www.stackage.org/haddock/lts-13.21/base-4.12.0.0/Prelude.html#v:read https://www.stackage.org/haddock/lts-13.21/base-4.12.0.0/Pre...
- millstone 7y agoI think that's different. `read` requires you to know what you're deserializing up-front, while `pickle` decodes the type dynamically from the data. Dynamic languages really can have functions whose behavior cannot be expressed as some sort of type signature.
- youerbt 7y agoread :: String -> Maybe PlainPythonObject read :: String -> Maybe Json goes a long way.
- noobiemcfoob 7y agoBut as soon as you're using "Maybe", you're impeding much of a type systems strengths, as the article outlined.
- youerbt 7y agoIt's really a matter of what you care about to accomplish. My point is that Python objects are certain data structure and if you bother to create type for it them then you can use it in function type.
- dllthomas 7y agoOnly if there is actually anything more you can say about String that would let you avoid the Maybe. If this is raw data and you don't even know that the JSON is well formatted (else why can a parse straight to a generic JSON object fail) then there's not any better way to type it. You might want to return an error message on failure, or provide a mechanism for recovery, but those are somewhat specific to the use case and don't really address the key point of the article.
- papln 7y agoWhy would you want a language which extra support for bugs? That's like saying Python is for the pedantic because it doesn't have a flag --crash_randomly, or won't let me write 0/0 and rely on the runtime to pick an abritrary value and keep going, even though I might want that.