5 ms·

Me too, to be honest. Still, for example - I can see that dynamic types reduce a certain quantity of boilerplate. If you just don't make the kind of mistakes t

Me too, to be honest. Still, for example - I can see that dynamic types reduce a certain quantity of boilerplate. If you just don't make the kind of mistakes that make static checking necessary, then you could be more productive that way. I think a lot of boilerplate stuff is a bit like that. I wouldn't be - but still.

loup-vaillant 9y ago
Explicit typing adds boilerplate. Static typing, not so much. Type inference is bloody effective at removing boilerplate. To the point where it can take you quite close to the best of the world: static checks, without boilerplate. Boilerplate isn't the reason why static typing might be worse than dynamic typing. Undecidability is. Inference algorithms tend to reject some correct programs. The real question is then, are we interested in those programs? So far, my experience has been "not really". I know of a few cumbersome exceptions, but overall, Hindley-Milner type inference basically lets me write the programs I want. It's not like Java is a worthy ambassador for static typing.
- ScottBurson 9y ago
  The killer app for dynamic typing is when you want to develop the program concurrently with executing it. I don't know that it's technically impossible for a statically-typed language to support that usage mode, but I've never seen it done.
  - yyhhsj0521 9y ago
    I prototype and test with ghci a lot while I'm writing Haskell. Not really impossible.
    - kqr 9y ago
      Does GHCi no longer flush the entire application state when you reload a module? I know it's not as much of a big deal in Haskell where mutable state is limited, but I still remember it being an annoyance to have to manually breakfast out my data to disk and then reload it again.
- millstone 9y ago
  Boilerplate can happen at a higher level than just writing down type names. A good example is "variadic" functions. Consider computing the max of three numbers. Clojure's `max` takes any number of arguments, while Haskell has `max` that takes two arguments, or `maximum` that takes a list of arguments; both require some boilerplate to apply if you have exactly three. It's impossible to write down a Haskell function equivalent to Clojure's `apply`. You have to work around its absence, e.g. with awkward folds. Or for a more immediate example, compare Clojure's flexible `map` to Haskell's big 'zip' family: zip1, zip2, zip3, zipWith5...
  - tome 9y ago
    Meh. I hardly consider max [a, b, c] to be boilerplate.
  - loup-vaillant 9y ago
    The zip family has more names than just `map`, but boilerplate? You have to select the right name for your code but you don't have to select more names. And at the implementation side, it's not like map's flexibility came from nowhere. I wouldn't be surprised to find out that Clojure's `map` is just as verbose as Haskell's entire 'zip' family. The whole concept of an `apply` function is a bit alien to me. I generally just call the damn function. Also, Haskell has an `apply` function. It's the `$` operator, defined thus (the first line is optional): `$` :: (a -> b) -> a -> b f $ x = f x It helps that Haskell functions all have one argument (that with being curried by default). If you want several arguments, just apply them one by one: f $ x $ y (This is sometimes used to avoid parentheses in some cases. I personally tend to just use the parentheses.)
    - kbp 9y ago
      > The zip family has more names than just `map`, but boilerplate? You have to select the right name for your code but you don't have to select more names. Well, you have to select one of the zip functions in addition to map. Those are more names. > Also, Haskell has an `apply` function. It's the `$` operator That isn't what apply does. Apply takes a function and applies it to a list of arguments, (f x y) is equivalent to (apply f (list x y)).

loup-vaillant 9y ago

Explicit typing adds boilerplate. Static typing, not so much. Type inference is bloody effective at removing boilerplate. To the point where it can take you quite close to the best of the world: static checks, without boilerplate. Boilerplate isn't the reason why static typing might be worse than dynamic typing. Undecidability is. Inference algorithms tend to reject some correct programs. The real question is then, are we interested in those programs? So far, my experience has been "not really". I know of a few cumbersome exceptions, but overall, Hindley-Milner type inference basically lets me write the programs I want. It's not like Java is a worthy ambassador for static typing.

ScottBurson 9y ago
The killer app for dynamic typing is when you want to develop the program concurrently with executing it. I don't know that it's technically impossible for a statically-typed language to support that usage mode, but I've never seen it done.
- yyhhsj0521 9y ago
  I prototype and test with ghci a lot while I'm writing Haskell. Not really impossible.
  - kqr 9y ago
    Does GHCi no longer flush the entire application state when you reload a module? I know it's not as much of a big deal in Haskell where mutable state is limited, but I still remember it being an annoyance to have to manually breakfast out my data to disk and then reload it again.
millstone 9y ago
Boilerplate can happen at a higher level than just writing down type names. A good example is "variadic" functions. Consider computing the max of three numbers. Clojure's `max` takes any number of arguments, while Haskell has `max` that takes two arguments, or `maximum` that takes a list of arguments; both require some boilerplate to apply if you have exactly three. It's impossible to write down a Haskell function equivalent to Clojure's `apply`. You have to work around its absence, e.g. with awkward folds. Or for a more immediate example, compare Clojure's flexible `map` to Haskell's big 'zip' family: zip1, zip2, zip3, zipWith5...
- tome 9y ago
  Meh. I hardly consider max [a, b, c] to be boilerplate.
- loup-vaillant 9y ago
  The zip family has more names than just `map`, but boilerplate? You have to select the right name for your code but you don't have to select more names. And at the implementation side, it's not like map's flexibility came from nowhere. I wouldn't be surprised to find out that Clojure's `map` is just as verbose as Haskell's entire 'zip' family. The whole concept of an `apply` function is a bit alien to me. I generally just call the damn function. Also, Haskell has an `apply` function. It's the `$` operator, defined thus (the first line is optional): `$` :: (a -> b) -> a -> b f $ x = f x It helps that Haskell functions all have one argument (that with being curried by default). If you want several arguments, just apply them one by one: f $ x $ y (This is sometimes used to avoid parentheses in some cases. I personally tend to just use the parentheses.)
  - kbp 9y ago
    > The zip family has more names than just `map`, but boilerplate? You have to select the right name for your code but you don't have to select more names. Well, you have to select one of the zip functions in addition to map. Those are more names. > Also, Haskell has an `apply` function. It's the `$` operator That isn't what apply does. Apply takes a function and applies it to a list of arguments, (f x y) is equivalent to (apply f (list x y)).