5 ms·

This is the best argument I've seen for dynamic types beyond the prototyping phase: https://lispcast.com/clojure-and-types/ https://lispcast.com/clojure-and-typ

by _bxg1 7y ago

This is the best argument I've seen for dynamic types beyond the prototyping phase: https://lispcast.com/clojure-and-types/ https://lispcast.com/clojure-and-types/ Not sure if I'm 100% won over, but it makes some good points, particularly the section about JSON. Using TypeScript at work, one of the most painful (yet quite common) things is dealing with foreign JSON from an API, which is sometimes just... wrong. And then all our carefully-typed code falls to pieces. The argument is that in a language like Clojure you can skip pretending to make guarantees about messy external data, and trade that for simple and elegant traversal code. Probably this is why dynamic languages tend to gravitate towards "glue code" use cases while static types gravitate towards insulated systems with minimal surface area to the outside world (compilers, anyone?).

hombre_fatal 7y ago
I don't understand your JSON example. If your Clojure code expects an API response's json.{id,username} to exist, and to not exist is a hard violation of your assumptions and thus your code, then how is that any different from formalizing it into: struct UserResponse { id: Int username: String } ? (Damn, rest of the comment is pretty long but let me try to both sympathize and present a solution that I do like). What I will say is that most statically-typed languages I've used do get annoying when there's no 1:1 mapping between your struct and the JSON body. I've dealt with some hairy JSON, like APIs that accidentally re-encode nested JSON strings so they become like triple escaped. Or values that can have like 5 different shapes so you really just want to try 5 different decoders until one is successful. (These cases are trivial in my upcoming code example) For example, Rust's serde and Swift's Codeable are both pretty annoying if you want to apply arbitrary transformations between JSON response -> your canonical representation. Serde, for example, has you implementing the whole trait + visitor if you need to do anything the cute decorator DSL doesn't support. Or you implement a bunch of envelope structs even though you just want to pull out the value at "obj.a.b.c". Or, what happens when you can't simply use a codec from https://app.quicktype.io/ https://app.quicktype.io/? JSON decoder combinators (e.g. in Elm) make JSON pleasant again while retaining static typing. https://package.elm-lang.org/packages/elm/json/latest/Json-Decode https://package.elm-lang.org/packages/elm/json/latest/Json-D... For example, data Role = Member | Admin data User { id: Int username: String role: Role } -- API example body: { id: "12", role: "a", info: { uname: "foo" } } decodeUser : D.Decoder<User> decodeUser = User -- Crappy API gives us either an int or a string (D.field "id" (D.oneOf [ D.int, D.string |> D.map parseInt ])) -- Pull out value from nested object (D.fieldAt [ "info", "uname" ] D.string) -- Arbitrarily transform value and create our own error (D.field "role" D.string (D.andThen (\value -> case value of "m" -> Ok Role.Member "a" -> Ok Role.Admin unknown -> Err ("Unexpected role " ++ unknown)))) That almost compiles despite shooting from the hip directly into this textarea, but the point is that it's a pleasant way to decode JSON while allowing arbitrary transformation, and I think it's the ultimate middleground between static-typing and the sort of on-the-fly decision making you get with dynamic typing.
- armitron 7y ago
  Your example isn’t tied to static typing, it is simply but behind-the-scenes checking types at runtime. You can do that in any good dynamically typed language (e.g Common Lisp) and hide it in a similar way. Closure has definite problems that other Lisps don’t due to a combination of leaky JVM abstractions (incomprehensible stack traces, JAVA pollution), its semantics not really being Lisp semantics and its premature optimization into one paradigm that doesn’t really fit the language or most problems very well.
  - GeneralTspoon 7y ago
    Yes but once the json has been validated once at runtime, you know it's safe for the rest of your program to use. Whereas in a dynamic language (even an immutable one), your data could be mutated during program runtime and no longer conform to the type you expected. Yes you could re-validate it everywhere, but that requires you to exercise every code path when testing at runtime to find bugs. I think the general argument that "You can't static type everything (like your API dependencies), so there's no point in doing it all" isn't a very solid one.
    - int_19h 7y ago
      Your data can't be mutated if you're using immutable data structures. Which is what Clojure defaults to, in fact.
      - GeneralTspoon 7y ago
        I didn't mean literally mutating the same structure in place - but a new version of your data structure could be returned from a function which changes some of the keys/values in unsafe ways.
  - hombre_fatal 7y ago
    Sure, my example isn't tied to static-typing but static-typing is especially helpful any time you're workin with combinators/transformations at a distance. But also, statically-typed languages like the two I brought up tend to be in most need of a nice validation/codec/transformation library because you can't simply procrastinate establishing your domain models like you can in dynamically-typed languages. And this is the sort of pain that leads people to say that dynamically-typed languages are more accommodating here. Though I will have to defend Clojure from your last paragraph. I don't think there has been a lisp that has done so much for lisps than Clojure. For example, until I used Clojure, other lisps were just like any other dynamically-typed, mutation-heavy language. The idea of just shuttling around data and transformations on that data is something that fundamentally changed my approach to writing software. I can certainly come up with worse things to say about Clojure. I kinda grew out of dynamic-typing, for one. And this is never more obvious than if you've ever read a large or complex Clojure codebase while dying to just know what the underlying Java types are. And you're so desperate that you get excited when you see a single ^ChannelHandler type-hint.
bitwize 7y ago
Any bit of JSON either resolves to a valid object of some type in your data model, or is erroneous. "Simple and elegant traversal code" often makes assumptions about the data it operates over; when handed JSON that violates these assumptions, the result is undefined. If you use the "parse, don't validate" pattern (https://lexi-lambda.github.io/blog/2019/11/05/parse-don-t-validate/ https://lexi-lambda.github.io/blog/2019/11/05/parse-don-t-va...), by walking the complete data structure early on and ensuring via the type system that the assumptions hold, or failing, your JSON handling code is much clearer and more robust. Static types are an unmitigated win, if you know how to use them.
- bcrosby95 7y ago
  Makes me think a bit of Python's "ask for forgiveness not permission". I have a few problems with "validate then do something if its valid". On top of what that article mentions, there are concurrency issues (e.g. checking to see if a file exists, then if it does, open it... oops, race condition), and general ergonomics (if I always have to do something before I do something else, there should be a function call that effectively does both).
- goatlover 7y ago
  Wouldn't work if you were implementing a library like Pandas when the data can be almost any tabular structure that you need to clean and wrangle into shape before you can be sure what types you're dealing with.
  - fauigerzigerk 7y ago
    Type systems give you a way to specify what you know at design time. If "has any tabular structure" is all you know then that is what you specify. I don't think "but my data is dynamic" is a good argument for or against dynamic typing. It's an entirely separate issue.
    - dkersten 7y ago
      > but my data is dynamic In my experience, most dynamically types code makes assumptions about structure that may not hold later (better have tests!) and when it breaks some kind of validation is needed anyway to select between the correct version of the different dynamic options. In static languages this is simply typically done sooner, since the type system requires it to parse the data. (Or it’s in variants that are accessed without checking that the accesses are valid, sigh)

by _bxg1 7y ago

hombre_fatal 7y ago

I don't understand your JSON example. If your Clojure code expects an API response's json.{id,username} to exist, and to not exist is a hard violation of your assumptions and thus your code, then how is that any different from formalizing it into: struct UserResponse { id: Int username: String } ? (Damn, rest of the comment is pretty long but let me try to both sympathize and present a solution that I do like). What I will say is that most statically-typed languages I've used do get annoying when there's no 1:1 mapping between your struct and the JSON body. I've dealt with some hairy JSON, like APIs that accidentally re-encode nested JSON strings so they become like triple escaped. Or values that can have like 5 different shapes so you really just want to try 5 different decoders until one is successful. (These cases are trivial in my upcoming code example) For example, Rust's serde and Swift's Codeable are both pretty annoying if you want to apply arbitrary transformations between JSON response -> your canonical representation. Serde, for example, has you implementing the whole trait + visitor if you need to do anything the cute decorator DSL doesn't support. Or you implement a bunch of envelope structs even though you just want to pull out the value at "obj.a.b.c". Or, what happens when you can't simply use a codec from https://app.quicktype.io/ https://app.quicktype.io/? JSON decoder combinators (e.g. in Elm) make JSON pleasant again while retaining static typing. https://package.elm-lang.org/packages/elm/json/latest/Json-Decode https://package.elm-lang.org/packages/elm/json/latest/Json-D... For example, data Role = Member | Admin data User { id: Int username: String role: Role } -- API example body: { id: "12", role: "a", info: { uname: "foo" } } decodeUser : D.Decoder<User> decodeUser = User -- Crappy API gives us either an int or a string (D.field "id" (D.oneOf [ D.int, D.string |> D.map parseInt ])) -- Pull out value from nested object (D.fieldAt [ "info", "uname" ] D.string) -- Arbitrarily transform value and create our own error (D.field "role" D.string (D.andThen (\value -> case value of "m" -> Ok Role.Member "a" -> Ok Role.Admin unknown -> Err ("Unexpected role " ++ unknown)))) That almost compiles despite shooting from the hip directly into this textarea, but the point is that it's a pleasant way to decode JSON while allowing arbitrary transformation, and I think it's the ultimate middleground between static-typing and the sort of on-the-fly decision making you get with dynamic typing.

armitron 7y ago
Your example isn’t tied to static typing, it is simply but behind-the-scenes checking types at runtime. You can do that in any good dynamically typed language (e.g Common Lisp) and hide it in a similar way. Closure has definite problems that other Lisps don’t due to a combination of leaky JVM abstractions (incomprehensible stack traces, JAVA pollution), its semantics not really being Lisp semantics and its premature optimization into one paradigm that doesn’t really fit the language or most problems very well.
- GeneralTspoon 7y ago
  Yes but once the json has been validated once at runtime, you know it's safe for the rest of your program to use. Whereas in a dynamic language (even an immutable one), your data could be mutated during program runtime and no longer conform to the type you expected. Yes you could re-validate it everywhere, but that requires you to exercise every code path when testing at runtime to find bugs. I think the general argument that "You can't static type everything (like your API dependencies), so there's no point in doing it all" isn't a very solid one.
  - int_19h 7y ago
    Your data can't be mutated if you're using immutable data structures. Which is what Clojure defaults to, in fact.
    - GeneralTspoon 7y ago
      I didn't mean literally mutating the same structure in place - but a new version of your data structure could be returned from a function which changes some of the keys/values in unsafe ways.
- hombre_fatal 7y ago
  Sure, my example isn't tied to static-typing but static-typing is especially helpful any time you're workin with combinators/transformations at a distance. But also, statically-typed languages like the two I brought up tend to be in most need of a nice validation/codec/transformation library because you can't simply procrastinate establishing your domain models like you can in dynamically-typed languages. And this is the sort of pain that leads people to say that dynamically-typed languages are more accommodating here. Though I will have to defend Clojure from your last paragraph. I don't think there has been a lisp that has done so much for lisps than Clojure. For example, until I used Clojure, other lisps were just like any other dynamically-typed, mutation-heavy language. The idea of just shuttling around data and transformations on that data is something that fundamentally changed my approach to writing software. I can certainly come up with worse things to say about Clojure. I kinda grew out of dynamic-typing, for one. And this is never more obvious than if you've ever read a large or complex Clojure codebase while dying to just know what the underlying Java types are. And you're so desperate that you get excited when you see a single ^ChannelHandler type-hint.

bitwize 7y ago

Any bit of JSON either resolves to a valid object of some type in your data model, or is erroneous. "Simple and elegant traversal code" often makes assumptions about the data it operates over; when handed JSON that violates these assumptions, the result is undefined. If you use the "parse, don't validate" pattern (https://lexi-lambda.github.io/blog/2019/11/05/parse-don-t-validate/ https://lexi-lambda.github.io/blog/2019/11/05/parse-don-t-va...), by walking the complete data structure early on and ensuring via the type system that the assumptions hold, or failing, your JSON handling code is much clearer and more robust. Static types are an unmitigated win, if you know how to use them.

bcrosby95 7y ago
Makes me think a bit of Python's "ask for forgiveness not permission". I have a few problems with "validate then do something if its valid". On top of what that article mentions, there are concurrency issues (e.g. checking to see if a file exists, then if it does, open it... oops, race condition), and general ergonomics (if I always have to do something before I do something else, there should be a function call that effectively does both).
goatlover 7y ago
Wouldn't work if you were implementing a library like Pandas when the data can be almost any tabular structure that you need to clean and wrangle into shape before you can be sure what types you're dealing with.
- fauigerzigerk 7y ago
  Type systems give you a way to specify what you know at design time. If "has any tabular structure" is all you know then that is what you specify. I don't think "but my data is dynamic" is a good argument for or against dynamic typing. It's an entirely separate issue.
  - dkersten 7y ago
    > but my data is dynamic In my experience, most dynamically types code makes assumptions about structure that may not hold later (better have tests!) and when it breaks some kind of validation is needed anyway to select between the correct version of the different dynamic options. In static languages this is simply typically done sooner, since the type system requires it to parse the data. (Or it’s in variants that are accessed without checking that the accesses are valid, sigh)