Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #53455 > unrolled thread

A Pragmatic Case for Static Typing

Back to article view | Back to comp.lang.python

Contents

  A Pragmatic Case for Static Typing "Russ P." <Russ.Paielli@gmail.com> - 2013-09-01 21:24 -0700
    Re: A Pragmatic Case for Static Typing Paul Rubin <no.email@nospam.invalid> - 2013-09-02 01:10 -0700
      Re: A Pragmatic Case for Static Typing Steven D'Aprano <steve@pearwood.info> - 2013-09-02 09:44 +0000
        Re: A Pragmatic Case for Static Typing Roy Smith <roy@panix.com> - 2013-09-02 09:37 -0400
        Re: A Pragmatic Case for Static Typing Nobody <nobody@nowhere.com> - 2013-09-03 02:10 +0100
          Re: A Pragmatic Case for Static Typing Joel Goldstick <joel.goldstick@gmail.com> - 2013-09-02 21:36 -0400
      Re: A Pragmatic Case for Static Typing Chris Angelico <rosuav@gmail.com> - 2013-09-02 22:04 +1000
      Re: A Pragmatic Case for Static Typing Roy Smith <roy@panix.com> - 2013-09-02 08:41 -0400
        Re: A Pragmatic Case for Static Typing Chris Angelico <rosuav@gmail.com> - 2013-09-03 08:43 +1000
      Re: A Pragmatic Case for Static Typing "Russ P." <Russ.Paielli@gmail.com> - 2013-09-02 11:33 -0700

#53455 — A Pragmatic Case for Static Typing

I just stumbled across this video and found it interesting:

http://vimeo.com/72870631

My apologies if it has been posted here already.

[toc] | [next] | [standalone]

#53459

"Russ P." <Russ.Paielli@gmail.com> writes:
> I just stumbled across this video and found it interesting:
> http://vimeo.com/72870631
> 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.

[toc] | [prev] | [next] | [standalone]

#53464

On Mon, 02 Sep 2013 01:10:34 -0700, Paul Rubin wrote:

> "Russ P." <Russ.Paielli@gmail.com> writes:
>> I just stumbled across this video and found it interesting:
>> http://vimeo.com/72870631
>> 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.

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.



-- 
Steven

[toc] | [prev] | [next] | [standalone]

#53482

In article <52245df4$0$2743$c3e8da3$76491128@news.astraweb.com>,
 Steven D'Aprano <steve@pearwood.info> wrote:

> 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 : <roy-DFB5E5.20525231082013@news.panix.com>
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?

[toc] | [prev] | [next] | [standalone]

#53547

On Mon, 02 Sep 2013 09:44:20 +0000, Steven D'Aprano wrote:

> 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).

[toc] | [prev] | [next] | [standalone]

#53550

On Mon, Sep 2, 2013 at 9:10 PM, Nobody <nobody@nowhere.com> wrote:
> On Mon, 02 Sep 2013 09:44:20 +0000, Steven D'Aprano wrote:
>
>> 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).
>
> --
> http://mail.python.org/mailman/listinfo/python-list

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!

-- 
Joel Goldstick
http://joelgoldstick.com

[toc] | [prev] | [next] | [standalone]

#53477

On Mon, Sep 2, 2013 at 6:10 PM, Paul Rubin <no.email@nospam.invalid> wrote:
> "Russ P." <Russ.Paielli@gmail.com> writes:
>> I just stumbled across this video and found it interesting:
>> http://vimeo.com/72870631
>> 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

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

ChrisA

[toc] | [prev] | [next] | [standalone]

#53480

In article <7xfvtnwsn9.fsf@ruckus.brouhaha.com>,
 Paul Rubin <no.email@nospam.invalid> wrote:

> "Russ P." <Russ.Paielli@gmail.com> writes:
> > I just stumbled across this video and found it interesting:
> > http://vimeo.com/72870631
> > 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

Thank you for posting that.

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

> Brian's Observation:
> 
> At 3 people on a team, there is a 50% chance that 
>> at least one of them is a full-time idiot.
> 
> As the teams grow larger, the probability of not 
> having an idiot on the team falls rapidly to zero.

[toc] | [prev] | [next] | [standalone]

#53536

On Mon, Sep 2, 2013 at 10:41 PM, Roy Smith <roy@panix.com> wrote:
> In article <7xfvtnwsn9.fsf@ruckus.brouhaha.com>,
>  Paul Rubin <no.email@nospam.invalid> wrote:
>
>> "Russ P." <Russ.Paielli@gmail.com> writes:
>> > I just stumbled across this video and found it interesting:
>> > http://vimeo.com/72870631
>> > 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
>
> Thank you for posting that.
>
> My favorite slide (especially since for the past few years, I've mostly
> worked in 3 person teams).
>
>> Brian's Observation:
>>
>> At 3 people on a team, there is a 50% chance that
>>> at least one of them is a full-time idiot.

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

[toc] | [prev] | [next] | [standalone]

#53523

On Monday, September 2, 2013 1:10:34 AM UTC-7, Paul Rubin wrote:
> "Russ P." writes:
> 
> > I just stumbled across this video and found it interesting:
> 
> > http://vimeo.com/72870631
> 
> > 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.

I thought the video was amusing, but I am probably easily amused. I noticed that 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. I have 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 point is.

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.python

csiph-web