8 ms·

Worthwhile article, if only for reading one of the less biased dynamic vs static typing pros an cons.

by lloeki 16y ago

thesz 16y ago
I should note that author added some unneccessary cons to static types. He said that metaprogramming is hard. The area of metaprogramming is partially covered by higher-order functions. The coverage is big, in my opinion, I haven't missed metaprogramming in Haskell for ten years, at least (I missed it for first two weeks with Haskell). He also said that there's no mechanism to compensate for the absence of duck typing. In Haskell, at least, there are type classes which allow you to make your types as duck as you would wish, maybe slightly less. I think that some Scala mechanisms provide that power.
- dan00 16y ago
  "He also said that there's no mechanism to compensate for the absence of duck typing. In Haskell, at least, there are type classes which allow you to make your types as duck as you would wish, maybe slightly less." I think that type classes are the way to go. Duck typing is mostly popular because multiple inheritance sucks, and because inherting a class to only overload a method sucks. Languages like Ruby, Python or Perl are so popular because they are less verbose than Java or C++, with the disadvantage, that the compiler can't help you that much. Haskell is a language that combines the advantages, less verbosity with a helping compiler, and a static type system that rocks.
  - rit 16y ago
    While this is a statement in some ways of preference it is a reasonable comment; not sure why it's getting downvoted. However, can you clarify why you would argue for type classes over duck/structural typing? You indicate that 'type classes are the way to go' but don't explain why. Scala of course does have a form of Type Classes and while they tend to be what I reach for more often than Structural Types in Scala, it doesn't obviate Structural Types completely and I'd be interested in analysis of the diffs.
    - kscaldef 16y ago
      With dynamic duck typing you just have to hope the object actually quacks. With type classes, the compiler proves it quacks.
    - dan00 16y ago
      "However, can you clarify why you would argue for type classes over duck/structural typing? You indicate that 'type classes are the way to go' but don't explain why." Like kscaldef said, you know at compiletime if something can quack, and the overhead for doing this is quite small. Haskell: instance Quacker MySpecialDuck where quack = "qqquuuuuuaaaaaakkkkk" "Scala of course does have a form of Type Classes and while they tend to be what I reach for more often than Structural Types in Scala, it doesn't obviate Structural Types completely and I'd be interested in analysis of the diffs." In which cases do you need duck typing? Adding dynamically a method to a class?
- riffraff 16y ago
  The only thing missing for some metaprogramming issues in haskell, in my limited understanding, is the ability to have dynamically created names (function/methods or types). But that may be orthogonal to static/dynamic typing (e.g. scala 2.9 has this ability, and javascript doesn't)
- masklinn 16y ago
  > He also said that there's no mechanism to compensate for the absence of duck typing. Whereas, in reality, there's a whole class of static type systems which do the same thing, except statically: structural type systems (example: OCaml's object types). Much as duck typing, they only make sense for object-oriented languages. Structural type systems treat (concrete) objects and object types as method sets (where a method is a triple of name, argument types and return types), where, given the types A and B with A a structural subtype of B, A's methodset will be a superset B's methodset. > I think that some Scala mechanisms provide that power. Scala provides structural types (via type refinements) since 2.6.0: http://programming-scala.labs.oreilly.com/ch12.html#StructuralTypes http://programming-scala.labs.oreilly.com/ch12.html#Structur... http://scala.sygneca.com/patterns/duck-typing-done-right http://scala.sygneca.com/patterns/duck-typing-done-right
bad_user 16y ago
Actually, any comparison between dynamic and static typing is prone to bias, only because such comparisons are focusing on features -- whereas what's important really is style / use-cases. And all the articles about Scala are missing one important detail -- structural typing and type inference are not a replacement for dynamic typing and all evidence to the contrary I've seen are extremely shallow. Truth of the matter is the choice between static and dynamic comes down to personal style and individual use-cases for which one or the other is better.
- shasta 16y ago
  Structural typing and type inference aren't a drop in replacement for dynamic typing, but they cover 80% of the use-cases and the typically the other 20% of cases aren't that painful to encode in a static language. I'm curious which idioms from your favorite dynamic language you find the most painful to adapt to a static language. I think that the path forward for programming will see a convergence between static and dynamic typing, but the amount of static analysis that programmers do will only increase. Certain dynamic practices such as name binding at runtime will fall out of favor, because that practice hampers static analysis. On the other hand, static type systems in use will probably become more flexible, simultaneously increasing the things that they let you automatically track while decreasing the things that the force you to track. Time will tell, I suppose.
  - bad_user 16y ago
    they cover 80% of the use-cases No they don't, it's actually the other way around -- try recreating Rails in Scala. For that matter, give me an ORM written in Scala that's both (a) stable and consistent + (b) usable without me having to bash my head against the keyboard. The reason why you cannot recreate a Rails clone is because Rails works basically by redefining everything at runtime, over and over again ... the whole Ruby language is built from the ground up on redefining classes (for the "class" construct, defining new classes in case they don't exist, that's just a side-effect). I'm not saying you cannot build something better in Scala (time will tell), but that something has to be a lot different and a lot more effort will be required. Yeah, you can do "var a = 1" in Scala, that's nice. the path forward for programming will see a convergence between static and dynamic typing Actually the path IMHO is a bigger separation between static and dynamic, with optional static types introduced in dynamic languages as hints for performance purposes. Basically that's because OOP is inherently incompatible with static types and because type classes are inherently incompatible with dynamic types.

Worthwhile article, if only for reading one of the less biased dynamic vs static typing pros an cons.

by lloeki 16y ago

Worthwhile article, if only for reading one of the less biased dynamic vs static typing pros an cons.

thesz 16y ago

I should note that author added some unneccessary cons to static types. He said that metaprogramming is hard. The area of metaprogramming is partially covered by higher-order functions. The coverage is big, in my opinion, I haven't missed metaprogramming in Haskell for ten years, at least (I missed it for first two weeks with Haskell). He also said that there's no mechanism to compensate for the absence of duck typing. In Haskell, at least, there are type classes which allow you to make your types as duck as you would wish, maybe slightly less. I think that some Scala mechanisms provide that power.

dan00 16y ago
"He also said that there's no mechanism to compensate for the absence of duck typing. In Haskell, at least, there are type classes which allow you to make your types as duck as you would wish, maybe slightly less." I think that type classes are the way to go. Duck typing is mostly popular because multiple inheritance sucks, and because inherting a class to only overload a method sucks. Languages like Ruby, Python or Perl are so popular because they are less verbose than Java or C++, with the disadvantage, that the compiler can't help you that much. Haskell is a language that combines the advantages, less verbosity with a helping compiler, and a static type system that rocks.
- rit 16y ago
  While this is a statement in some ways of preference it is a reasonable comment; not sure why it's getting downvoted. However, can you clarify why you would argue for type classes over duck/structural typing? You indicate that 'type classes are the way to go' but don't explain why. Scala of course does have a form of Type Classes and while they tend to be what I reach for more often than Structural Types in Scala, it doesn't obviate Structural Types completely and I'd be interested in analysis of the diffs.
  - kscaldef 16y ago
    With dynamic duck typing you just have to hope the object actually quacks. With type classes, the compiler proves it quacks.
  - dan00 16y ago
    "However, can you clarify why you would argue for type classes over duck/structural typing? You indicate that 'type classes are the way to go' but don't explain why." Like kscaldef said, you know at compiletime if something can quack, and the overhead for doing this is quite small. Haskell: instance Quacker MySpecialDuck where quack = "qqquuuuuuaaaaaakkkkk" "Scala of course does have a form of Type Classes and while they tend to be what I reach for more often than Structural Types in Scala, it doesn't obviate Structural Types completely and I'd be interested in analysis of the diffs." In which cases do you need duck typing? Adding dynamically a method to a class?
riffraff 16y ago
The only thing missing for some metaprogramming issues in haskell, in my limited understanding, is the ability to have dynamically created names (function/methods or types). But that may be orthogonal to static/dynamic typing (e.g. scala 2.9 has this ability, and javascript doesn't)
masklinn 16y ago
> He also said that there's no mechanism to compensate for the absence of duck typing. Whereas, in reality, there's a whole class of static type systems which do the same thing, except statically: structural type systems (example: OCaml's object types). Much as duck typing, they only make sense for object-oriented languages. Structural type systems treat (concrete) objects and object types as method sets (where a method is a triple of name, argument types and return types), where, given the types A and B with A a structural subtype of B, A's methodset will be a superset B's methodset. > I think that some Scala mechanisms provide that power. Scala provides structural types (via type refinements) since 2.6.0: http://programming-scala.labs.oreilly.com/ch12.html#StructuralTypes http://programming-scala.labs.oreilly.com/ch12.html#Structur... http://scala.sygneca.com/patterns/duck-typing-done-right http://scala.sygneca.com/patterns/duck-typing-done-right

bad_user 16y ago

Actually, any comparison between dynamic and static typing is prone to bias, only because such comparisons are focusing on features -- whereas what's important really is style / use-cases. And all the articles about Scala are missing one important detail -- structural typing and type inference are not a replacement for dynamic typing and all evidence to the contrary I've seen are extremely shallow. Truth of the matter is the choice between static and dynamic comes down to personal style and individual use-cases for which one or the other is better.

shasta 16y ago
Structural typing and type inference aren't a drop in replacement for dynamic typing, but they cover 80% of the use-cases and the typically the other 20% of cases aren't that painful to encode in a static language. I'm curious which idioms from your favorite dynamic language you find the most painful to adapt to a static language. I think that the path forward for programming will see a convergence between static and dynamic typing, but the amount of static analysis that programmers do will only increase. Certain dynamic practices such as name binding at runtime will fall out of favor, because that practice hampers static analysis. On the other hand, static type systems in use will probably become more flexible, simultaneously increasing the things that they let you automatically track while decreasing the things that the force you to track. Time will tell, I suppose.
- bad_user 16y ago
  they cover 80% of the use-cases No they don't, it's actually the other way around -- try recreating Rails in Scala. For that matter, give me an ORM written in Scala that's both (a) stable and consistent + (b) usable without me having to bash my head against the keyboard. The reason why you cannot recreate a Rails clone is because Rails works basically by redefining everything at runtime, over and over again ... the whole Ruby language is built from the ground up on redefining classes (for the "class" construct, defining new classes in case they don't exist, that's just a side-effect). I'm not saying you cannot build something better in Scala (time will tell), but that something has to be a lot different and a lot more effort will be required. Yeah, you can do "var a = 1" in Scala, that's nice. the path forward for programming will see a convergence between static and dynamic typing Actually the path IMHO is a bigger separation between static and dynamic, with optional static types introduced in dynamic languages as hints for performance purposes. Basically that's because OOP is inherently incompatible with static types and because type classes are inherently incompatible with dynamic types.