Weblogs Forum - Programming with "Duh" Typing

Articles |
News |
Weblogs |
Books |
Forums

Artima Forums | Articles | Weblogs | Java Answers | News

Sponsored Link •

Weblogs Forum
Programming with "Duh" Typing

370 replies on 25 pages. Most recent reply: Aug 8, 2007 9:54 AM by James Watson

Welcome Guest
Sign In

Back to Topic List

Reply to this Topic

Search Forum

Threaded View


Previous Topic		Next Topic

Flat View: This topic has 370 replies on 25 pages [ « | 1 ... 10 11 12 13 14 15 16 17 18 ... 25 | » ]

Achilleas Margaritis

Posts: 674
Nickname: achilleas
Registered: Feb, 2005

Re: Programming with "Duh" Typing

Posted: Jul 17, 2007 7:30 AM

> I make those mistakes a lot. Maybe it comes from having a
> compiler yell at me for them, and having IDEs underline
> them, so I'm just sloppy in my typing.

You are going to run that code once, aren't you?

>
> The ones on the main paths of the code get weeded out
> quickly enough to not be too big of an issue. In that
> case unit testing is a reasonable substitute for static
> typing. But mistakes tend to linger in codepaths that you
> haven't tested. Ok, maybe tests should cover all code
> paths...but sometimes that takes too much time to do when
> the code is in a high state of flux and you don't know if
> it will ever really be used.

I never ever release code with an untested part. Even in ADA, there can be bugs in untested code, not caught by the type checker. I always run everything at least once. So in this case, static typing is more of an obstacle than help.

Achilleas Margaritis

Posts: 674
Nickname: achilleas
Registered: Feb, 2005

Re: Programming with "Duh" Typing

Posted: Jul 17, 2007 7:32 AM

> > Programming usually goes down two routes:
> >
> > 1) the problem at hand is trivial. In this case, a
> static
> > type system won't help because the problem is trivial.
> >
> > 2) the problem at hand is quite complex. In this case,
> a
> > static type won't help as well, because the code will
> > usually involve lots of subclasses and interfaces.
>
> Oh, that sounds like fun. Let me try!

It does not work that way. Let me explain:

>
> 1) The problem at hand is trivial. In this case, you
> won't have that many types since the program is trivial,
> so a statically typed language doesn't have any overhead
> and is safer.

A statically typed language has the overhead of having to type the type declarations.

>
> 2) The problem at hand is quite complex. In this case,
> you need types even more because the code will involve
> lots of subclasses and interfaces.
>
> --
> Cedric

But the more subclasses and interfaces you have, the more static typing is useless, and the more the chances of having a bug in a subtype increase.

Achilleas Margaritis

Posts: 674
Nickname: achilleas
Registered: Feb, 2005

Re: Programming with "Duh" Typing

Posted: Jul 17, 2007 7:35 AM

> The issue I mention above is not related to subtyping. I
> don't understand how you made that connection.

It's simple: an interface does not guarantee type safety: the wrong class with the right interface can be at the wrong place at the wrong time, thus creating havoc with the program.

And then we have the problem of null...static type checking is useless in this area, unless null is made a type. But then we step into functional programming territory, where nullable types are algebraic.

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: Programming with "Duh" Typing

Posted: Jul 17, 2007 8:16 AM

> > I make those mistakes a lot. Maybe it comes from having
> a
> > compiler yell at me for them, and having IDEs underline
> > them, so I'm just sloppy in my typing.
>
> You are going to run that code once, aren't you?

This takes time. I've had a simple change take me 30 minutes to make in Python because I had to keep running the code and find errors. It's much quicker to see the error instantaneously and fix it.

I recently had a bug where one out of every few lines was being iterated over as a sequence. This took me quite a while to locate because I had added a faux-object in a corner case. In a static language, It takes a few moments to select all the references. I basically stumbled over this by accident after about an error of looking in the wrong places for the error. The error turned out to be that I had declared one of the arguments to a method as field instead of *fields. In a static language I would know about this way ahead of time.

You are focusing on the quality of the finished product. The point that I am trying to make is that dynamic languages can actually slow down development in the long term.

Erik Engbrecht

Posts: 210
Nickname: eengbrec
Registered: Apr, 2006

Re: Programming with "Duh" Typing

Posted: Jul 17, 2007 8:23 AM

> > I make those mistakes a lot. Maybe it comes from having
> a
> > compiler yell at me for them, and having IDEs underline
> > them, so I'm just sloppy in my typing.
>
> You are going to run that code once, aren't you?

Yes, and the code takes hours to run. It's not fun when something is attacking item 99 million out of 100 million and blows up on a stupid typo because it just happens to hit a codepath that the first 98,999,999 items didn't hit.

> >
> > The ones on the main paths of the code get weeded out
> > quickly enough to not be too big of an issue. In that
> > case unit testing is a reasonable substitute for static
> > typing. But mistakes tend to linger in codepaths that
> you
> > haven't tested. Ok, maybe tests should cover all code
> > paths...but sometimes that takes too much time to do
> when
> > the code is in a high state of flux and you don't know
> if
> > it will ever really be used.
>
> I never ever release code with an untested part. Even in
> ADA, there can be bugs in untested code, not caught by the
> type checker. I always run everything at least once. So in
> this case, static typing is more of an obstacle than help.

Who said anything about releasing code without testing it? I have a big heaping pile of data that looks meaningless but someone thinks there's gold buried in it. So I need to come up with an algorithm to find the gold and refine it into a nice shiny piece of information jewelry.

I may to try a whole slew of algorithms. I may never "productionize" the code for general use, because maybe the gold is really just copper so no one cares. Or maybe it's just dirt. But then maybe it does need to eventually be productionized. It's hard to tell at the start.

The point is I usually need to be able to try things fast. I usually use Python, but that's because of the APIs and ability to build abstractions, not because of dynamic typing. Experience has made be scatter runtime type-checks all over my code, despite the fact that it is "un-Pythonic" and lessens flexibility. But that MORE work that specifying static types, and it incurs a performance penalty.

If the code gets productionized, then yeah, it needs thorough testing. But developing a slew of tests for something you may throw away in the morning doesn't seem very productive, especially when a static type checker could catch 90% of the errors because they are just typos.

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: Programming with "Duh" Typing

Posted: Jul 17, 2007 8:56 AM

> > The issue I mention above is not related to subtyping.
> I
> > don't understand how you made that connection.
>
> It's simple: an interface does not guarantee type safety:
> the wrong class with the right interface can be at the
> wrong place at the wrong time, thus creating havoc with
> the program.

There are a couple problems with this argument. First is that it's and example of the 'no perfect solution fallacy'

http://en.wikipedia.org/wiki/Perfect_solution_fallacy

In fact the problem you describe has almost never happened to me when using a static language.

Secondly there is a lot more that static typing does than provides protection against this kind of problem.

Thirdly, it's not related to the problem I was discussing.

Vincent O'Sullivan

Posts: 724
Nickname: vincent
Registered: Nov, 2002

Re: Programming with "Duh" Typing

Posted: Jul 17, 2007 2:25 PM

> > The issue I mention above is not related to subtyping.
> I
> > don't understand how you made that connection.
>
> It's simple: an interface does not guarantee type safety:
> the wrong class with the right interface can be at the
> wrong place at the wrong time, thus creating havoc with
> the program.

I suspect this is an theoretical problem. I can't say I've ever come across it in many years of coding

> And then we have the problem of null...static type
> checking is useless in this area, unless null is made a
> type.

Yes it's a problem. Better null handling would strengthen static typing.

> But then we step into functional programming
> territory, where nullable types are algebraic.

But so what? Are you saying adopting features of functional programming for static typing is bad? It seems to me that all that is happening is that the [dodgy analogy]goal posts in the argument are being steadily shifted whenever a shot is lined up[/dodgy analogy].

Achilleas Margaritis

Posts: 674
Nickname: achilleas
Registered: Feb, 2005

Re: Programming with "Duh" Typing

Posted: Jul 18, 2007 6:56 AM

> > > I make those mistakes a lot. Maybe it comes from
> having
> > a
> > > compiler yell at me for them, and having IDEs
> underline
> > > them, so I'm just sloppy in my typing.
> >
> > You are going to run that code once, aren't you?
>
> This takes time. I've had a simple change take me 30
> minutes to make in Python because I had to keep running
> the code and find errors. It's much quicker to see the
> error instantaneously and fix it.

But you are going to run it afterwards, aren't you?

>
> I recently had a bug where one out of every few lines was
> being iterated over as a sequence. This took me quite a
> while to locate because I had added a faux-object in a
> corner case. In a static language, It takes a few moments
> to select all the references. I basically stumbled over
> this by accident after about an error of looking in the
> wrong places for the error. The error turned out to be
> that I had declared one of the arguments to a method as
> field instead of *fields. In a static language I would
> know about this way ahead of time.

Can you elaborate on the error?

>
> You are focusing on the quality of the finished product.
> The point that I am trying to make is that dynamic
> c languages can actually slow down development in the long
> term.

Not really. It is your approach that slows it down. The correct approach in dynamic languages is to run the program and correct it while it is running. Interactive development is way much faster than anything else.

Achilleas Margaritis

Posts: 674
Nickname: achilleas
Registered: Feb, 2005

Re: Programming with "Duh" Typing

Posted: Jul 18, 2007 7:01 AM

> Yes, and the code takes hours to run. It's not fun when
> something is attacking item 99 million out of 100 million
> and blows up on a stupid typo because it just happens to
> hit a codepath that the first 98,999,999 items didn't
> hit.

No one uses interactive development? I am surprised.

> Who said anything about releasing code without testing it?
> I have a big heaping pile of data that looks meaningless
> s but someone thinks there's gold buried in it. So I need
> to come up with an algorithm to find the gold and refine
> it into a nice shiny piece of information jewelry.
>
> I may to try a whole slew of algorithms. I may never
> "productionize" the code for general use, because maybe
> the gold is really just copper so no one cares. Or maybe
> it's just dirt. But then maybe it does need to eventually
> be productionized. It's hard to tell at the start.
>
> The point is I usually need to be able to try things fast.
> I usually use Python, but that's because of the APIs and
> d ability to build abstractions, not because of dynamic
> typing. Experience has made be scatter runtime
> type-checks all over my code, despite the fact that it is
> "un-Pythonic" and lessens flexibility. But that MORE work
> that specifying static types, and it incurs a performance
> penalty.

>
> If the code gets productionized, then yeah, it needs
> thorough testing. But developing a slew of tests for
> something you may throw away in the morning doesn't seem
> very productive, especially when a static type checker
> could catch 90% of the errors because they are just typos.

But dynamic typing suits you perfectly, especially in code which changes frequently. The trick is to modify the code as it runs, not to start over each time.

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: Programming with "Duh" Typing

Posted: Jul 18, 2007 7:24 AM

> > > > I make those mistakes a lot. Maybe it comes from
> > having
> > > a
> > > > compiler yell at me for them, and having IDEs
> > underline
> > > > them, so I'm just sloppy in my typing.
> > >
> > > You are going to run that code once, aren't you?
> >
> > This takes time. I've had a simple change take me 30
> > minutes to make in Python because I had to keep running
> > the code and find errors. It's much quicker to see the
> > error instantaneously and fix it.
>
> But you are going to run it afterwards, aren't you?

Yes. What's your point?

> >
> > I recently had a bug where one out of every few lines
> was
> > being iterated over as a sequence. This took me quite
> a
> > while to locate because I had added a faux-object in a
> > corner case. In a static language, It takes a few
> moments
> > to select all the references. I basically stumbled
> over
> > this by accident after about an error of looking in the
> > wrong places for the error. The error turned out to be
> > that I had declared one of the arguments to a method as
> > field instead of *fields. In a static language I would
> > know about this way ahead of time.
>
> Can you elaborate on the error?

The star means that the input is a sequence. I was passing a single string to the method. The method iterates over the field parameter. By removing the star, my string became the sequence that was being iterated over. If I were doing this in something where I could declare the type of field as a sequence of strings, a single string would not be an acceptable parameter.

> >
> > You are focusing on the quality of the finished
> product.
> > The point that I am trying to make is that dynamic
> > c languages can actually slow down development in the
> long
> > term.
>
> Not really. It is your approach that slows it down. The
> correct approach in dynamic languages is to run the
> program and correct it while it is running. Interactive
> development is way much faster than anything else.

It doesn't seem feasible for the program I am running. Could I stop it and back up the recursion to the point where I saw the problem?

Can I ask how much programming you have done in static languages?

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: Programming with "Duh" Typing

Posted: Jul 18, 2007 7:25 AM

> > Yes, and the code takes hours to run. It's not fun
> when
> > something is attacking item 99 million out of 100
> million
> > and blows up on a stupid typo because it just happens
> to
> > hit a codepath that the first 98,999,999 items didn't
> > hit.
>
> No one uses interactive development? I am surprised.

Can you explain how that would make a difference in this context? If it takes hours to hit the problem why would interactive development make that faster?

Erik Engbrecht

Posts: 210
Nickname: eengbrec
Registered: Apr, 2006

Re: Programming with "Duh" Typing

Posted: Jul 18, 2007 8:09 AM

> > > Yes, and the code takes hours to run. It's not fun
> > when
> > > something is attacking item 99 million out of 100
> > million
> > > and blows up on a stupid typo because it just happens
> > to
> > > hit a codepath that the first 98,999,999 items didn't
> > > hit.
> >
> > No one uses interactive development? I am surprised.
>
> Can you explain how that would make a difference in this
> context? If it takes hours to hit the problem why would
> interactive development make that faster?

I think in LISP and maybe Smalltalk you could change the code and then restart execution rather than starting over.

But that assumes that the root cause of the error is where the error was raised (or close to it). Often times it is not (unless I stick in all my isinstance checks), so the actual error entered the application state an hour ago, the consequence just wasn't felt until later. But then in a Smalltalk environment I suppose you could go manual fiddle with the objects that have bad values.

I personally would still just start over. I'd eventually have to start execution from the begining, anyway, and such object twiddling gives me the willies.

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: Programming with "Duh" Typing

Posted: Jul 18, 2007 8:16 AM

> But that assumes that the root cause of the error is where
> the error was raised (or close to it). Often times it is
> not (unless I stick in all my isinstance checks), so the
> actual error entered the application state an hour ago,
> the consequence just wasn't felt until later. But then in
> a Smalltalk environment I suppose you could go manual
> fiddle with the objects that have bad values.

It also assumes there is an exception. I often have errors in code (the kind that static typing captures) that don't manifest themselves as exceptions.

Erik Engbrecht

Posts: 210
Nickname: eengbrec
Registered: Apr, 2006

Re: Programming with "Duh" Typing

Posted: Jul 18, 2007 8:41 AM

> > But that assumes that the root cause of the error is
> where
> > the error was raised (or close to it). Often times it
> is
> > not (unless I stick in all my isinstance checks), so
> the
> > actual error entered the application state an hour ago,
> > the consequence just wasn't felt until later. But then
> in
> > a Smalltalk environment I suppose you could go manual
> > fiddle with the objects that have bad values.
>
> It also assumes there is an exception. I often have
> errors in code (the kind that static typing captures) that
> don't manifest themselves as exceptions.

Me too. But usually (for me) those are algorithmic and wouldn't have been caught by static typing.

One thing that occured to me is that I don't always take the most "testable" approach. I could refactor me code so that it is more resumeable. If I memoized certain results to disk so they could be reloaded instead of computed, or took a more granular staged approach to the computation, it would be better. But then I'm dealing with tangential issues when I want to be developing an algorithm.

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: Programming with "Duh" Typing

Posted: Jul 18, 2007 9:17 AM

> Me too. But usually (for me) those are algorithmic and
> wouldn't have been caught by static typing.

It's not that I don't get those too but some things would be caught, like the field vs. *field thing above. I also find that I use standard types in Python for things I would use custom types for in, say Java. This is good in one way as I am freed from creating those types but when I am trying to figure out why my code isn't working, I miss having that information.

> One thing that occured to me is that I don't always take
> the most "testable" approach. I could refactor me code so
> that it is more resumeable. If I memoized certain results
> to disk so they could be reloaded instead of computed, or
> took a more granular staged approach to the computation,
> it would be better. But then I'm dealing with tangential
> issues when I want to be developing an algorithm.

Well this is one of those things that is ignored when people claim that dynamic languages are faster to develop in. The testing burden is a bit higher (even if people don't want to admit it) and the documentation burden is much greater. Once you take these things into account, I'm not sure that it's true that it's much faster. If you don't do these, then it seems like you are really speeding along but in the long term you pay for it. For things that are small enough to fit in ones brain all at once, I think the benefits of a dynamic language like Python far outweigh the costs.

Flat View: This topic has 370 replies on 25 pages [ « | 10 11 12 13 14 15 16 17 18 | » ]

Previous Topic

Next Topic