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.

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