The Artima Developer Community
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

Go back to the topic listing  Back to Topic List Click to reply to this topic  Reply to this Topic Click to search messages in this forum  Search Forum Click for a threaded view of the topic  Threaded View   
Previous Topic   Next Topic
Flat View: This topic has 370 replies on 25 pages [ « | 1 ... 11 12 13 14 15 16 17 18 19 ... 25  | » ]
James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: Programming with "Duh" Typing Posted: Jul 18, 2007 9:21 AM
Reply to this message Reply
Advertisement
> 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.

The other way static typing would have helped here is that if I had declared this method in an interface or trait, the compiler would have told me this version was there. With duck-typing, I was able to have this method defined in different ways in different objects and everything still 'worked'.

Isaac Gouy

Posts: 527
Nickname: igouy
Registered: Jul, 2003

Re: other tools Posted: Jul 18, 2007 11:17 AM
Reply to this message Reply
James Watson wrote
> > > It doesn't help you create a design.
> >
> > I think verifying a design iteratively and
> incrementally
> > as we create a design "helps" us to create a design -
> so
> > I've no idea what you're talking about.
>
> I don't care to help you understand at this point. It
> seems very simple to me but I've actually used the tool.
> Why don't you download Alloy and try to use it and if you
> u feel that I am wrong, you can give specific reasons why.
> That would be a meaningful discussion. This is not.

Previously I have downloaded Alloy and worked through some of the tutorials and read Daniel Jackson's book "Software Abstractions".

I have not tried to use Alloy to "solve real problems" because I don't know Alloy well enough yet. I don't want to make judgements about how useful a tool is when it might simply be that I don't know how to use it.

Isaac Gouy

Posts: 527
Nickname: igouy
Registered: Jul, 2003

Re: Programming with "Duh" Typing Posted: Jul 18, 2007 11:42 AM
Reply to this message Reply
James Watson wrote
-snip-
> 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.

Does the 'no perfect solution fallacy' only apply to other peoples arguments or might it also apply to your arguments?

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: other tools Posted: Jul 18, 2007 12:00 PM
Reply to this message Reply
> Previously I have downloaded Alloy and worked through some
> of the tutorials and read Daniel Jackson's book "Software
> Abstractions".
>
> I have not tried to use Alloy to "solve real problems"
> because I don't know Alloy well enough yet. I don't want
> to make judgements about how useful a tool is when it
> might simply be that I don't know how to use it.

That 'could' be true for any tool. Hitting myself in the head with a mallet 'might' make my headache go away it I do it enough. There's no way to prove that another whack won't do the trick. It makes no sense to recommend something because you don't know that it isn't worth the effort.

My assessment of Alloy was based on trying it and the usage and problem space that it's creators stated it addressed. These problems are not what I struggle with. Specifically, I rarely have problems with incorrect designs that don't meet known requirements. The problems I have are with creating a design that can be implemented as maintainable, efficient code and with the cost of turning a design into a working application and with implementing design changes as requirements change (alternately better requirements would suffice.) Based on what I know about Alloy, I don't believe it addresses any of those issues. I don't have time to explore all tools, especially those that I don't expect to be fruitful. If I learn something new that puts that assessment in question, then I would rethink it. 'I might not know Alloy well enough yet' does not pass this test.

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: Programming with "Duh" Typing Posted: Jul 18, 2007 12:10 PM
Reply to this message Reply
> James Watson wrote
> -snip-
> > 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.
>
> Does the 'no perfect solution fallacy' only apply to other
> peoples arguments or might it also apply to your arguments?

It does if I actually had used that fallacy. I never said that integrated development should not be used.

Stating that seat-belts do not eliminate deaths in accidents is not the 'no perfect solution' fallacy. The fallacy is using that as an argument to say seat-belts should not be required is.

My argument is that in dynamic programming can actually be slower than static programming in certain contexts. I was told that this was absolutely not the case. Why should I not be allowed to question that? If someone suggests that something is a perfect solution, then the 'no perfect solution' fallacy does not apply.

Erik Engbrecht

Posts: 210
Nickname: eengbrec
Registered: Apr, 2006

Re: other tools Posted: Jul 18, 2007 12:18 PM
Reply to this message Reply
> That 'could' be true for any tool. Hitting myself in the
> head with a mallet 'might' make my headache go away it I
> do it enough. There's no way to prove that another whack
> won't do the trick. It makes no sense to recommend
> something because you don't know that it isn't worth the
> effort.

Hmmmm...the halting problem applied to bludgeoning...

Achilleas Margaritis

Posts: 674
Nickname: achilleas
Registered: Feb, 2005

Re: Programming with "Duh" Typing Posted: Jul 19, 2007 5:39 AM
Reply to this message Reply
> > > > > 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?

My point is that static typing is reduntant, since you are going to test the code anyway.

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

Did you run the code? wasn't the error visible when you run it?

>
> > >
> > > 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
> t where I saw the problem?

It depends if your language saved the old values. But even if it did not, you could pause the program, fix the error, then resume it.

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

Perhaps you should ask me how much programming I have done in dynamic languages!

I have been using statically typed languages at 99% of my programming efforts. I have only recently started playing with Smalltalk and LISP, and I have found productivity to triple.

Achilleas Margaritis

Posts: 674
Nickname: achilleas
Registered: Feb, 2005

Re: Programming with "Duh" Typing Posted: Jul 19, 2007 5:40 AM
Reply to this message Reply
> > > 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?

Of course it depends on the nature of the problem, but in most cases it pays off to be able to pause the program, alter it and then resume it.

Achilleas Margaritis

Posts: 674
Nickname: achilleas
Registered: Feb, 2005

Re: Programming with "Duh" Typing Posted: Jul 19, 2007 5:44 AM
Reply to this message Reply
> 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.

The testing burden in dynamically typed languages is not greater than the testing burden of statically typed languages, provided that you do functional testing for all your requirements. Actually, the testing burden is equal in both cases.

The documentation burden is also equal in both cases. Even with static typing, types do not tell us anything about how the variables are used, so they have to be documented.

Personally I document every variable and member attribute/method of my classes either in Java or C++. It feels incomplete if I do not do that.

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: Programming with "Duh" Typing Posted: Jul 19, 2007 6:33 AM
Reply to this message Reply
> My point is that static typing is reduntant, since you are
> going to test the code anyway.

Preventing errors is not what I consider to be the chief advantage of static typing as I have stated repeatedly in this thread. It is a strawman.


> Did you run the code? wasn't the error visible when you
> run it?

Again, yes, but the time it took was much much greater than than if I was using a static language.

> It depends if your language saved the old values. But even
> if it did not, you could pause the program, fix the error,
> then resume it.

You didn't answer the question. I would need to back up, perhaps thousands of stack frames. Otherwise the process would have to start over. Could I back the process up?

> It depends if your language saved the old values. But even
> if it did not, you could pause the program, fix the error, > then resume it.

But everything in the program depends on what came before in the current branch. This is worthless to me.

> I have been using statically typed languages at 99% of my
> programming efforts. I have only recently started playing
> with Smalltalk and LISP, and I have found productivity to
> triple.

This is approximately the same as my experience level with dynamic languages.

How much maintenance of dynamic code have you done? My experience (as I have repeatedly stated) is that the initial development is much faster but maintenance is much slower.

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: Programming with "Duh" Typing Posted: Jul 19, 2007 6:42 AM
Reply to this message Reply
> > 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.
>
> The testing burden in dynamically typed languages is not
> greater than the testing burden of statically typed
> languages, provided that you do functional testing for all
> your requirements. Actually, the testing burden is equal
> in both cases.

I disagree. There are no perfect tests. I can make changes in a static language that require no testing. I know they will not break anything and they do not. With a static language testing is required mainly at the end of a unit of work. With dynamic languages, testing is required pretty much after every trivial change. Otherwise, it's easy to become hopelessly lost.

Functional testing is required for any application but I am not talking about that. I'm talking about testing just to capture typing errors or anything else that a static language will tell you you have done wrong. If you are waiting until functional testing to verify that you haven't fat-fingered anything, then perhaps we have different ideas about functional testing.

> The documentation burden is also equal in both cases. Even
> with static typing, types do not tell us anything about
> how the variables are used, so they have to be
> documented.

The types have to be documented. But I don't need documentation to know what the expected types of a given methods arguments are.

> Personally I document every variable and member
> attribute/method of my classes either in Java or C++. It
> feels incomplete if I do not do that.

But in a dynamic language you should be documenting every variable in addition to the above.

Erik Engbrecht

Posts: 210
Nickname: eengbrec
Registered: Apr, 2006

Static Type Checks are not Tests Posted: Jul 19, 2007 6:55 AM
Reply to this message Reply
> The testing burden in dynamically typed languages is not
> greater than the testing burden of statically typed
> languages, provided that you do functional testing for all
> your requirements. Actually, the testing burden is equal
> in both cases.

I've thought about it, and I've decided that static type checks are not tests. Tests are dependent on codepath. Each test excerises a different codepath (well, more-or-less, some may validate that several different inputs have the same codepath). While static type checking is completely independent of codepath.

More generally, tests are purely empirical, while static type checks are purely deductive.

The point of my comments is that static type checking immediately detects a class of errors that I commonly see in my own code that are very difficult, or even impossible, to detect via testing except by chance.

Unit tests are not enough, because often times the place where the error is introduced (e.g., a member variable is set to a tuple instead of an integer) is often distant, both within the code and within execution of the program, from where the error causes failure (when arithmetic operations are attempted on the tuple). Only integrated testing can detect these errors, and even then a huge set of tests is required. Unless, of course, you specify the types of the member variables on the object and validate them at runtime or check all of them in your tests. In which case you've lost both the time savings and flexibility gain of dynamic typing.

Rusty Wright

Posts: 8
Nickname: lumpynose
Registered: Jul, 2007

Re: Programming with "Duh" Typing Posted: Jul 19, 2007 5:25 PM
Reply to this message Reply
> The documentation burden is also equal in both cases. Even
> with static typing, types do not tell us anything about
> how the variables are used, so they have to be
> documented.

I see the documentation burden on dynamic languages being much higher because the variable declarations in a static language are a form of automatic documentation. For example, in java, if I'm looking at someone else's code and I see

Map<URI, Date> dates = someObject.getSomething();

I immediately know that the dates variable is a Map of Dates with URI as the key. If I haven't forgotten what the usual methods are on a Map I immediately know what methods I can use if I need to modify the code.

With a dynamic language I'd have to trace back through the code to find what methods I can use on that object.

Achilleas Margaritis

Posts: 674
Nickname: achilleas
Registered: Feb, 2005

Re: Programming with "Duh" Typing Posted: Jul 20, 2007 7:46 AM
Reply to this message Reply
> > My point is that static typing is reduntant, since you
> are
> > going to test the code anyway.
>
> Preventing errors is not what I consider to be the chief
> advantage of static typing as I have stated repeatedly in
> this thread. It is a strawman.

It's not a strawman when the type system is good enough to catch errors. But unless fully dependent type systems are incorporated into the programming languages we daily use, they are more of a burden than help.

>
>
> > Did you run the code? wasn't the error visible when you
> > run it?
>
> Again, yes, but the time it took was much much greater
> than than if I was using a static language.
>
> > It depends if your language saved the old values. But
> even
> > if it did not, you could pause the program, fix the
> error,
> > then resume it.
>
> You didn't answer the question. I would need to back up,
> perhaps thousands of stack frames. Otherwise the process
> would have to start over. Could I back the process up?

what do you mean by 'back up'?

>
> > It depends if your language saved the old values. But
> even
> > if it did not, you could pause the program, fix the
> error, > then resume it.
>
> But everything in the program depends on what came before
> in the current branch. This is worthless to me.

Even if you spot the problem in a previous branch, you can pause the program, change the values, and let the program continue from the previous branch, or divert it so as that the previous branch runs at some point in the future.

>
> > I have been using statically typed languages at 99% of
> my
> > programming efforts. I have only recently started
> playing
> > with Smalltalk and LISP, and I have found productivity
> to
> > triple.
>
> This is approximately the same as my experience level with
> dynamic languages.
>
> How much maintenance of dynamic code have you done? My
> experience (as I have repeatedly stated) is that the
> initial development is much faster but maintenance is much
> slower.

I actually started with maintaining a Smalltalk program written by someone else.

Achilleas Margaritis

Posts: 674
Nickname: achilleas
Registered: Feb, 2005

Re: Programming with "Duh" Typing Posted: Jul 20, 2007 7:51 AM
Reply to this message Reply
> I disagree. There are no perfect tests. I can make
> changes in a static language that require no testing. I
> know they will not break anything and they do not. With a
> static language testing is required mainly at the end of a
> unit of work. With dynamic languages, testing is required
> pretty much after every trivial change. Otherwise, it's
> easy to become hopelessly lost.

The only changes that do not require testing are the very trivial ones, which is a very limited set of changes.

>
> Functional testing is required for any application but I
> am not talking about that. I'm talking about testing just
> to capture typing errors or anything else that a static
> language will tell you you have done wrong. If you are
> waiting until functional testing to verify that you
> haven't fat-fingered anything, then perhaps we have
> different ideas about functional testing.

But you can't be sure, even with a static type system, that your code is correct. For example, an int erroneously converted to short can create great problems. Only functional testing can reveal the problems.

>
> > The documentation burden is also equal in both cases.
> Even
> > with static typing, types do not tell us anything about
> > how the variables are used, so they have to be
> > documented.
>
> The types have to be documented. But I don't need
> documentation to know what the expected types of a given
> methods arguments are.

Actually, you do. Declaring a function to take type 'int' does not say much. You need to document, for example, if that integer is to be used as an index in an array, if negative values are valid, what will happen if I pass 0, etc.

>
> > Personally I document every variable and member
> > attribute/method of my classes either in Java or C++.
> It
> > feels incomplete if I do not do that.
>
> But in a dynamic language you should be documenting every
> variable in addition to the above.

But I already said "I document every variable". I do not see any additional work.

Flat View: This topic has 370 replies on 25 pages [ « | 11  12  13  14  15  16  17  18  19 | » ]
Topic: Programming with "Duh" Typing Previous Topic   Next Topic Topic: Python 3000 Plea for Help


Sponsored Links



Google
  Web Artima.com   

Copyright © 1996-2017 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use - Advertise with Us