Static vs dynamic types
0 likes3,719 views
Static typing is good for large programs as it helps catch errors and supports refactoring and code navigation. Dynamic typing is fine for small scripts but brings maintenance issues for large codebases due to lack of type information. The presenter argues for a compromise with static typing for fields and method signatures but dynamic inference within methods and some downcasting allowed. Empirical studies show developers rely more on static typing over time due to challenges of maintaining large dynamic codebases.
![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](https://image.slidesharecdn.com/staticvsdynamictypes-140307122229-phpapp02/85/Static-vs-dynamic-types-2-320.jpg)
Static vs dynamic types
- 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. 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. 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 x.name} f(new A()) f(new B())
- 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. 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. Can we agree... ● Coder must know (partial) types statically or (s)he can’t access appropriate fields, funcs: o.name, o.save() ● 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. 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. 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. 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. 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. 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. 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(this.id) } } var p : Person = new User() var mask = p.permissions(new file(“...”)) // downcast
- 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. 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