6

This question appears to be fairly well tread, for example:

However, most questions and answers seem to compare statically typed languages like Java and C++ with dynamically typed languages like Python and JavaScript. This seems to be a different comparison - Java and C++ are verbose, non-interactive, and generally difficult to work with for reasons outside of their type systems.

I'm more interested in using static languages like Swift or Haskell as the basis of the comparison.

  • These languages have REPLs, interactive coding, or equivalents
  • These languages have type inference (as does C++)
  • These languages have easy-to-use "generics"
  • These languages have ADTs, which solves problems like JSON parsing

We can imagine a variant of Swift with a form of Structural Typing, where:

func foo(bar) { return bar.baz() }

Is valid syntax for any call in which an object with a baz() member is passed, and the return type is that of the object's baz() - effectively creating an anonymous protocol Foo<T> with member func baz() -> T.

This can be translated to JavaScript by s/func/function/g, but all of the type safety would be lost.

What's the advantage of dynamic typing, compared a static typed language with a good type system?

Improve this question
3
  • 1
    I'd like to see this discussion, but I have to admit that this might get closed as too opinion-based.
    – Katana314
    Jun 5, 2015 at 16:03
  • There isn't any advantage, but you're comparing apples with oranges.
    – Robert Harvey
    Jun 5, 2015 at 16:30
  • I don't feel qualified to answer this, and I have a bias for static typing, BUT what I love about dynamic typing like in JS is I can simply do this: object.property = value or object.property = function() { return value; } So annoying to deal with this in static languages!
    – TheCatWhisperer
    Jun 5, 2015 at 20:06

1 Answer 1

Reset to default
3

Fundamentally, if the type system is there, the programmer has to deal with it. It can be made rather "flexible" (i.e., stays out of your way in situations where type system like Java's would be a pain) and implicit (so type annotations can be left out when they don't add value), but the programmer has to deal with it. Even if every practical, correct program needs no type annotations at all and "just works" (a pipe dream IMHO), programmers do write wrong programs — catching those mistakes is the whole point of a type system, after all.

Presented with an type error, the programmer then needs to understand the type system to understand the error. In general type systems that allow more implicitness and are more flexible (in the aforementioned sense) are more complex and harder to understand. Of course, for a given degree of implicitness and flexibility, good design and good error messages can make a difference, but there is a limit. That is not to say this is a bad trade off, but it is a trade off.

In practice, the type systems you name don't fulfill the above condition of correct programs "just working". You may argue that they enforce better programming style, and I'd agree, but they reject valid programs of the style people actually write. This causes friction. There are many upsides, of course, but you seem to suggest that one can just stop writing JavaScript and get all the correctness guarantees for free. That is not true, one has to understand the type system and get used to phrasing programs in a way the type system understands. As an example, in Haskell you can't just have subtyping and inheritance. This is a trade off that buys Haskell certain advantages, and it's a perfectly valid school of design, but it also makes different designs harder to implement.

Improve this answer
1
  • One thing to note though is that sometimes the inverse can happen where programs actually wouldn't work were it not for the static typing. Specifically polymorphic values / return type polymorphism in Haskell, e.g pure 5 read "Foo", mempty etc. Without the type being later inferred and thus forcing a meaningful monomorphic value, the expressions would not actually be usable.
    – semicolon
    Jul 17, 2016 at 4:17

Not the answer you're looking for? Browse other questions tagged or ask your own question.