A Pragmatic Case for Static Typing

[Russ P.]

I just stumbled across this video and found it interesting:

My apologies if it has been posted here already.

 

[Paul Rubin]

I just stumbled across this video and found it interesting:

My apologies if it has been posted here already.

The slides for it are here, so I didn't bother watching the 1 hour video:

http://gbaz.github.io/slides/hurt-statictyping-07-2013.pdf

I guess for Python programmers looking to expand their horizons a bit,
it's worth at least looking at the slides. But, it may overstate its
case a little bit. Haskell's type system is way cool but the language
introduces other headaches into programming.

 

[Steven D'Aprano]

The slides for it are here, so I didn't bother watching the 1 hour
video:

http://gbaz.github.io/slides/hurt-statictyping-07-2013.pdf

I guess for Python programmers looking to expand their horizons a bit,
it's worth at least looking at the slides. But, it may overstate its
case a little bit. Haskell's type system is way cool but the language
introduces other headaches into programming.

I haven't watched the video, but the slides are worth reading, although
if you're familiar with this:

https://cdsmith.wordpress.com/2011/01/09/an-old-article-i-wrote/

there might not be anything new in it.

I think there is a lot to be said for advanced static-typed languages
like Haskell, as opposed to "dumb" static-typed languages like C, Java,
Pascal etc.


One factor I don't see very often mentioned is that static typing
increases coupling between distant parts of your code. If func() changes
from returning int to MyInt, everything that calls func now needs to be
modified to accept MyInt, no matter how similar MyInt is to int. You have
to make changes just to satisfy the compiler.

 

[Chris Angelico]

The slides for it are here, so I didn't bother watching the 1 hour video:

http://gbaz.github.io/slides/hurt-statictyping-07-2013.pdf

Thanks for that. I have no desire to watch an hour-long video about this!

ChrisA

 

[Roy Smith]

The slides for it are here, so I didn't bother watching the 1 hour video:

http://gbaz.github.io/slides/hurt-statictyping-07-2013.pdf

Thank you for posting that.

My favorite slide (especially since for the past few years, I've mostly
worked in 3 person teams).

 

[Roy Smith]

One factor I don't see very often mentioned is that static typing
increases coupling between distant parts of your code. If func() changes
from returning int to MyInt, everything that calls func now needs to be
modified to accept MyInt, no matter how similar MyInt is to int. You have
to make changes just to satisfy the compiler.

This really ties in with what I was getting at in:

Message-ID : <[email protected]>
Subject: Re: Interface and duck typing woes
Date: Wed, 28 Aug 2013 21:27:34 -0400

Every interface requires certain things and promises certain things
(i.e. the contract). At some point, the caller and the callee have to
agree on what's required, what's allowed, and what's a bug. There's
lots of ways of doing that.

At one end of the spectrum, there's the type bondage languages like C++
and Java. But even there, you have things like:

double sqrt (double x);

which only tells part of the "what's required" story. For the rest of
the story, you have to resort to reading the natural language
documentation:

"If the argument is negative, a domain error occurs"

At the other end of the spectrum, there's Python's duck typing, which
says, "Give me something, and I'll let you know if I can't deal with
it". But we're still not playing 20 questions. Presumably, the callee
gives you some kind of hint about what sort of duck they're expecting.

It seems to me that any time you can encapsulate knowledge about the
contract into something that's machine readable, you've added value.
Now you can have automated tools do something useful with that
knowledge. Maybe that means raising an error at compile time, or when
you run a static analysis tool. Or, more apropos to Python, at function
call time using pep-3107 annotations.

So, let's go back to your original statement (requoted here for
convenience):

One factor I don't see very often mentioned is that static typing
increases coupling between distant parts of your code. If func() changes
from returning int to MyInt, everything that calls func now needs to be
modified to accept MyInt, no matter how similar MyInt is to int. You have
to make changes just to satisfy the compiler.

It's not that static typing has increased coupling. The coupling has
always been there, it's just that now it's being enforced at compile
time. What's the difference between int and MyInt? I'm going to
speculate that ints are 64 bit 2s-complement binary and MyInts are
BCD-encoded fixed-width character strings with leading blank padding.
The problem is NOT that static typing forced me to change every place
that calls func(). The problem is that func() has fundamentally
changed, and THAT is what's forcing me to change all my code that calls
it. The static typing just lets me communicate that to the compiler.

I actually think Java was on the right track with interfaces. They are
essentially duck typing enforced at compile time. Rather than saying,
"You must pass me a Duck", you're saying, "You must pass me something
that has quack(), waddle(), and poop() methods". If I later change
func() to also call your_object.fly(), I've changed the contract on you.
And whether you know about it or not, your code and my code are coupled.

The difference is that with static typing, you find out about it
quickly, and with pythonic duck typing, you may not find out about it
until three years later when some unusual condition finally causes the
fly() code path to get executed and you've long since moved on to
another project.

The next step is to understand that the real contract may be more
complex than can be easily encapsulated in a type or annotation or
whatever. The contract may be:

"You must pass me something that can quack(), waddle(), and poop(). In
addition, if it's a full moon, it must also be able to fly()."

So, the big question is, how should I specify that to a human, and how
should I specify that to the computer?

 

[Russ P.]

The slides for it are here, so I didn't bother watching the 1 hour video:



http://gbaz.github.io/slides/hurt-statictyping-07-2013.pdf



I guess for Python programmers looking to expand their horizons a bit,

it's worth at least looking at the slides. But, it may overstate its

case a little bit. Haskell's type system is way cool but the language

introduces other headaches into programming.

I thought the video was amusing, but I am probably easily amused. I noticedthat he did not list my current main language, Scala, as statically typed.I am not sure why, but perhaps because it inherits null from Java. In any case, his main point was that static typing reduces time to working code. Ihave no doubt that is true for large-scale programming, but I doubt it is true for small-scale programming. The question is where the crossover pointis.

 

[Chris Angelico]

Thank you for posting that.

My favorite slide (especially since for the past few years, I've mostly
worked in 3 person teams).

My favorite too. I was reading it on the bus and I cracked up loudly
enough to draw some looks from fellow passengers.

I currently work on a two-person team (the boss/owner and me, nobody
else), reduced from three-person a year and a bit ago by the departure
of our full-time idiot. Since then, my boss and I have completely
rewritten *EVERY* piece of code he contributed to the project; for the
bulk of the project we weren't using source control (I recommended it,
boss reckoned we didn't need it) and just did our own separate
subprojects (I worked on the back end, our resident idiot had control
of the PHP and Javascript front end). Boss now thinks it'd be worth
rehiring the guy, because he had a recommendation/decision batting
record of pretty much .000, so we should ask his advice and then do
the opposite. (I'm still waiting for my boss to notice that it was
Idiot (btw, his moniker, not mine, used in a number of commit messages
removing his code) who recommended that we use PHP.)

Yep. Full-time idiot. Though this may be an extreme and
unusually-literal example.

ChrisA

 

[Nobody]

One factor I don't see very often mentioned is that static typing
increases coupling between distant parts of your code. If func() changes
from returning int to MyInt, everything that calls func now needs to be
modified to accept MyInt, no matter how similar MyInt is to int. You have
to make changes just to satisfy the compiler.

Not if the language has type inference (e.g. Haskell, or C++ templates).

 

[Joel Goldstick]

Not if the language has type inference (e.g. Haskell, or C++ templates).

My personal reason for working with python (dynamic typing) as opposed
to Java or C++ is that (in general) I don't like company environments
that use Java or C++. Its the world of huge software teams. Python
seems to be more in vogue in smaller environments which suit my
interests. I used to write in C and a little C++ back in the Borland
C++ days (90s?). I'm not familiar with Haskell, except having heard
the name, but I also know it isn't as popular in the job market as say
python or ruby or C++ or Java.

So, while I'm off topic, sometimes the reason to choose one
methodology over another has to do less with the merits than on other
factors. That said, python 'feels' extremely right to me. Having
come from PHP for the last dozen years that shouldn't surprise anyone!