4 ms·
If you are counting on typing for salvation then you are doomed.
by m0llusk 6y ago
If you are counting on typing for salvation then you are doomed.
- whateveracct 6y agoi feel pretty good so far (7 years in.) i barely use my brain to write haskell compared to the python or even go i write. feels like the types and purity are to blame.
- casion 6y agoI think those are low-hanging fruits. I write in CL and Clojure and feel similar. It's a matter of how easy it is to reason about complexity, typing is just a method of dealing with it.
- whateveracct 6y agoi've written a lot of Clojure and Scheme as well, and you make a good point that typing goes a long way immutability does go a long way. and clojure gives good way to document your functions, and encourages compositional design for sure even so, there's nothing quite like spending one sitting writing types only, another filling in all the `undefined`s, and iterating back and forth. i am always able to pick up my half finished haskell and not miss a beat thanks to how i capture my thinking in types. i think clojure would be strictly better with a basic HM type system on top, even if it were optional. now that i consider it, macros could allow for super ergonomic type-level programming - and type-safe program generation from types
- rowanG077 6y agoTyping in fact is the only sound way to handle validation. Unfortunately mainstream languages aren't there yet.
- m0llusk 6y agoTyping validation can only check type and so in most contexts is not validation.
- rowanG077 6y agoYes it can only check types. That's why you model your types to only contain valid data.
- whateveracct 6y agogiven a sufficiently expressive type language, you can express any validation
- curryst 6y agoTyping validation can only check the type, but there are a lot of facets of the type that most languages don't use. Types are a way of encoding your assumptions about the data in a way that the language can understand. Types can be defined so that only a subset of values is acceptable. I could do something like: UserID = int where value is less than 1000 my_user_id: UserID = query_database(username=my_username) And the type system could throw an error/warning that says "my_user_id could be greater than 1000" because I never check whether that value is actually valid for the type. Or if the language and the type system are integrated, it could transparently do the assertion for you and throw an error if the data doesn't match its type. You could do likewise with regexes for strings, lengths of integers, etc, etc. You can also encode complex relationships among objects. If you change how user IDs are formatted and don't migrate legacy users, you could express something like "if creation_date is older than 1/1/2000, user_id is an integer less than 30,000. Else user_id is a string that matches this regex".