Robert Smallshire explores the disconnect between the dire outcomes predicted by advocates of static typing versus the near absence of type errors in real world systems built with dynamic languages.
Robert Smallshire is a founding director of Sixty North, a software product and consulting business in Norway . He has worked in architecture and technical management roles for several companies providing tools in the energy sector for dealing with the masses of information flowing from today’s digital oil fields. Robert is a regular speaker at conferences, meetups and corporate software events.
“BUILD STUFF” Conference is a Software Development Conference created for developers, team leaders, software architects and technical project managers. Our goal is to bring world class speakers to share innovations, latest developments, new trends and directions in software development world to the Baltics.
Are there advanced type systems?
The second problem is that the productivity when first writing a program, does not necessarily represent the full cost of a system. When the original programmers of a dynamically typed system have left then the cost equation may change.
Static vs dynamic typing
As to the point of the lecture, I didn't see it. We were promised to be shown scientific/exprimental proof of dynamic languages making programmers happier and more productive. What the experiments have shown though, is that there is some percentage (1-2%) of type errors amongst all the issues logged for dynamic language projects. That's the errors that could have been avoided by using a statically typed language.
I spent 50 minutes waiting to hear what the tradeoffs were of static typing and at the end of the video an argument was presented where Robert was pointing at a slide with some C++ code and saying it took him days to write it. I didn't see the slide (fire that cameraman!) but I am guessing it was showing a case of having to specify an iterator type explicitly. C# or F# don't have this problem while being statically typed (with support for dynamic typing too, if you prefer).
Still not convinced.
What about Type Inference?
Have been coding F# for over 3 years. It definitely has the feel of a dynamically typed language but gives you all the support of a statically type one.
Hmm I use Python and CoffeeScript
class MyLongClass: # Actually happened to me : (
# 500 lines later
myclass.lol = 5
myclass.lal = 3 # mistyped lol
lol = 3
oll = 24 # i meant to redefine lol
if you use strings for "enums" instead of class namespaces you can also mis-spell it, but if you use classes:
enemyType = EnemyType.Witch
These are all "Write Errors", rather than "Read Errors". If you assume they are equally as likely as "Read Errors" then it bumps it up to 5%-10%. Still not good enough for Static Typing : ).
Fixes for write errors:
<-- Maybe use ":" for defining things, and "=" for redefining things, and disallow class and def to redefining things.
lal = 5
Why don't Dynamic languages have "interactive coercion & typing, and spelling check" where when you write 5 + "5" it asks you whether to fix it(modifying the file, and changing the function) or to error out. You can also automatically fix most errors by saying if you are adding an int and string it will ask you if you want to make both a str or int. If you get a NameError, KeyError, or AttributeError it retries the line of code by spelling checking it over the local variables/Attributes. If you get a AttributeError(Duck Typing error), TypeError because of wrong argument order, all you have to automatically fix the error is to retry calling with a different argument order and see if the error goes away (and you can do this all the way to the top of the stack).
I heard LISP has Edit & Continue, but does Clojure and other languages also have it? I wrote a Python Edit & Continue decorator for individual functions.
A waste of time
The speaker cloaks his disdain and lack of understanding of static type systems and theory behind some pseudo-scientific experiments and lame analogies.
Don’t waste your time watching this. Instead, I recommend presentations by Daniel Spiewak or Martin Odersky on the subject.
An Unreasonable Failure of Domain Modeling
His types should have been :
[<Measure>] type kg
[<Measure>] type m
[<Measure>] type s
[<Measure>] type N = kg m/s^2
[<Measure>] type J = N * m
[<Measure>] type Radian
[<Measure>] type Torque = J / Radian
Had he done this the compiler would have rejected his attempts to add torque to energy.