Static vs dynamic types


Published on

Static vs dynamic type systems in computer programming languages.

Published in: Technology
  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Static vs dynamic types

  1. 1. Computer Language Design and Implementation meetup March 6, 2014 Cat people vs dog people The great static vs dynamic typing debate Terence Parr University of San Francisco (You’re all wrong, I’m right)
  2. 2. Definitions (strong vs weak vs untyped) ● Static typing: compiler knows the type of every expression (using type inference here) var i = 3; var j = [“parrt”,”ollie”,”kay”]; ● Explicit static typing: coder gives type int i; List<String> a = new ArrayList<String>(); Explicit doesn’t mean “dirty” var dog : shit yes, a puppy dies every time you type this
  3. 3. Definitions Cont’d ● Dynamic typing: compiler ignores types, values’ types known only at runtime ● “Duck typing”: structural dynamic typing; i.e., the name (nominative) doesn’t matter, only the member list (Java uses interfaces) class A: {var name} class B: {var name} def f(x): {print} f(new A()) f(new B())
  4. 4. Eric Lippert from stackoverflow ● “it is hard to maintain a large codebase, period” ● “there is a strong correlation between a language being dynamically typed and a language also lacking all the other facilities that make lowering the cost of maintaining a large codebase easier” ● So, to focus on static versus dynamic argument, let’s assume...
  5. 5. Assumptions ● Comparing two identical languages, one with and one w/o static typing ● Language has modern facilities to support large projects: modules, perhaps objects, encapsulation, data hiding, etc… ○ E.g., javascript missing lots of that ● Large projects not small scripts
  6. 6. Can we agree... ● Coder must know (partial) types statically or (s)he can’t access appropriate fields, funcs:, ● With perfect human memory of your own code, no explicit types needed... ● ...but what if we call foreign library function or work on a team (i.e., all of us)? ● Must read lib code or doc to learn types
  7. 7. Reality ● Can’t remember type of all vars/funcs in large project (even solo project) ● We have to read lots of code every day ○ We work in teams ○ We use lots of libraries ○ Either we compute type or we read annotation ● Code always morphs over time ○ Explicit type info identifies key variable constraints ○ Code changes but do we update doc always?
  8. 8. Static typing burdens 1. Much faster to physically enter code w/o annotating variables with type info (don’t overestimate this cost) 2. Type annotations can clutter code 3. Harder for newbies to get rolling? 4. Type systems can add a lot of complexity to the language: Java’s generics, Scala, ... 5. Python (others) has structural type equivalence (duck typing) vs nominative (naming) for most static languages ○ Convenient if we care just that obj answers size() ○ Java requires creation of an interface
  9. 9. Dynamic typing burdens ● We exchange type annotation in code with unit/functional testing just to catch typos o. feild, o.methud(). More tests in general ● Should informally add type info in doc, a 2nd spec we must keep in sync ● Lippert: Need “good discipline about naming conventions, about division of responsibilities, about what the public surface of a given object is, and so on.”
  10. 10. Dynamic typing collateral damage ● Often less efficient ● Re-factoring challenging, dangerous, or impossible; can’t even rename safely ● Can’t do auto-completion, find usages/implementations, … ● Changes to type assumptions (in libs, code) introduce hidden landmines ● Can be more effort to read (computing
  11. 11. A compromise ● Annotate: fields (unless initialized), args, return values ● Generics only on built-in types? ● At the very least, use runtime generic type parameters to allow covariance List<? extends Animal> d=...; d.add(new Dog()); ● Type inference inside method bodies ● Allow plausible downcasting Jesus cries every time javac disallows this
  12. 12. Sample compromise class class Person { … } class User : Person { val BADID = 0 var id : string def permissions(name : string) : int { val m = Services.getFileManager() val f = m.getFile(name) return f.permissions( } } var p : Person = new User() var mask = p.permissions(new file(“...”)) // downcast
  13. 13. Speculation ● Static typing is seen as old-school. Younger programmers are always excited by the latest languages and these languages happen to be dynamically typed: JavaScript, Python, Ruby. Scala is the counterexample (others?) ● With experience, comes the pain of maintenance which motivates static typing ● I.e., there is a strong correlation between dynamic typing and youth
  14. 14. Summary ● Static + inferred typing is good, umkay? ● Dynamic typing is great for scripts but not large programs, umkay? ● Yes, we old farts rely more and more on static typing as our brains disintegrate ● People study this empirically see e.g., Andreas Stefik