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 ... 2 3 4 5 6 7 8 9 10 ... 25 | » ]

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: Programming with "Duh" Typing

Posted: Jul 9, 2007 12:02 PM

> What I would do would be to change the type and then
> follow all the little red marks that pop-up. If I found
> that there was code that required something that my new
> type could not provide, I would stop there and rethink my
> changes. At that point I would have made no changes and
> done no testing.

Sorry, that's not quite accurate. I would actually follow your basic path, minus the testing. As I was working through the one method that necessitated the change, I would find this issue without having to test. The compiler would point out this issue.

Erik Engbrecht

Posts: 210
Nickname: eengbrec
Registered: Apr, 2006

Nonstandard Datastructures

Posted: Jul 9, 2007 12:15 PM

> Let's say that you have a collection of objects and you're
> not quite sure upfront how you'll need to access them, so
> you don't know whether you should put them in a set, a
> list, or a map. You arbitrarily pick a list, since it's
> the safest bet and is easily supported by your language.
>
> Now, you get to writing a complex function that
> manipulates the objects in the collection. This is a
> function that will be called fairly often. On your first
> design of the function, you're fairly confident that you
> only want unique values, so you code the function so that
> it works with a set.
>

At this point I would probably create my own collection by either subclassing or wrapping an appropriate collection class and then providing the needed methods and implementing the needed interfaces. That way I can decouple the implementation of the data structure from the interface(s) it needs to provide. I do this in both static (Java, Scala, C++) and dynamic languages (Python).

IMHO that's just good OO programming. The collection interfaces/protocols provide a well-known interface for the client. The collection classes alleviate the necessity to recode common data structures. The custom class provides objects that do exactly what is needed, and decouple the interface from the implementation. So, for example, you can start with a set and then implement indexing operations using sequential (for unsorted sets) or binary (for sorted sets) search.

Alan Keefer

Posts: 29
Nickname: akeefer
Registered: Feb, 2007

Re: Programming with "Duh" Typing

Posted: Jul 9, 2007 12:25 PM

I think the point about refactoring and static typing is an important one; changes that are simple in a statically-typed language, like renaming a method, are impossible to do automatically in a dynamic language unless you have something like the Smalltalk browser to do it for you. Perhaps Ruby and Python and Javascript, etc., will have that capability some day, but for now that sort of refactoring remains a huge pain. The fact that those languages lead to smaller codebases definitely mitigates that pain somewhat, but in my (limited) experience with such languages, the end result is that you have a disincentive to keep the code clean: I <i>could</i> rename this method to more accurately reflect its purpose, but it'll take a while to get it right, so it's probably not worth it. In a statically-typed language with good tooling, that's a simple, no-risk operation. I'll believe that Ruby and Python and Javascript can have that level of refactoring support when I actually see the tools.

Dynamic typing makes changes much easier during the initial implementation of a piece of code, when the number of references is small; in that case you probably don't need much in the way of refactoring tools, and the lack of ability to use them is greatly outweighed by the fact that any change you make takes only a few keystrokes and magically (if the duck typing works) flows through the system properly. The number of keystrokes in that case is definitely important, as less code means that I can change things more rapidly.

The combined advantages of type inference and static typing are pretty nice, though; it's not quite the best of both worlds, but I think that on balance it's better than either just static typing or just dynamic typing. Combine it with some manner of extensible type system to make it that much more dynamic and it's hard to beat. It reduces the amount of code you write and you get something kind of like duck typing in a lot of cases, while also maintaining the tool-ability, refactor-ability, and error-checking of static types.

Isaac Gouy

Posts: 527
Nickname: igouy
Registered: Jul, 2003

imperative, and functional, and oo, ...

Posted: Jul 9, 2007 12:45 PM

Alan Keefer wrote "... unless you have something like the Smalltalk browser to do it for you... I'll believe that Ruby and Python and Javascript can have that level of refactoring support when I actually see the tools."

I think your skepticism might have gone a little too far ;-)

Maybe we should look more closely at the kind of programs being written in Ruby and Python and Javascript, and the way good programmers use those languages, to understand if there are reasons that refactoring might seem less obviously helpful in those languages.

Bill Venners

Posts: 2284
Nickname: bv
Registered: Jan, 2002

Re: Programming with

Posted: Jul 9, 2007 12:48 PM

> > I'll make no bones about it, I'm one of those that LOVE
> > Python for all the reasons stated. What I'd like to
> see,
> > however, is the ability, if I so choose, to optionally
> > specify a variable's type. I see several advantages.
> >
> > First, it better makes the code self documenting,
> > especially with arguments and return values. Second,
> > there are times where you use assert statements to
> check
> > types, but a type declaration is much cleaner. And
> > finally, I'd argue there are some performance
> advantages
> > if the the type be known, especially where variables
> are
> > used in a function and the variable's type has already
> > been declared and checked.
> >
> > Optional typing would be the best of both worlds.
>
> I think so too. BTW, it's funny that VB has had optional
> typing for years, but that community never seemed to take
> advantage of it.
>
Guido van Rossom wrote about the possibility of doing that in Python in several blog posts:

http://www.artima.com/weblogs/viewpost.jsp?thread=85551

http://www.artima.com/weblogs/viewpost.jsp?thread=86641

http://www.artima.com/weblogs/viewpost.jsp?thread=87182

http://www.artima.com/weblogs/viewpost.jsp?thread=89161

Does anyone know what came out of this?

Also, at JavaOne, Martin Odersky mentioned he was considering some form of optional duck typing for Scala. I'm not sure what he had in mind, nor how I would use it. If anyone has more information on that potential addition to Scala, please post it. I'm curious how it would work and how people might use it.

Michael Hobbs

Posts: 51
Nickname: hobb0001
Registered: Dec, 2004

Re: Programming with "Duh" Typing

Posted: Jul 9, 2007 12:54 PM

> I guess where your example here doesn't make sense to me
> is that in the statically typed language, I wouldn't
> approach it in this way. When I change the type to a set,
> I'd see that I need to access the item by index right
> away. I wouldn't need to run a test to find that out.
>
> What I would do would be to change the type and then
> follow all the little red marks that pop-up. If I found
> that there was code that required something that my new
> type could not provide, I would stop there and rethink my
> changes. At that point I would have made no changes and
> done no testing.

In the end, maybe it does come down to personal preference after all. ;-) It would seem that my experimental coding style is a whiteboard style and that yours is a notebook style. That is, with a whiteboard, it's a lot easier to wipe out a large chunk of writing and redraw something different. I'd wager that you mull over a design in your mind longer than I do before putting it into code.

My design style is highly iterative. I put an idea into code as soon as I deem it to be viable, and then see how well it works in a real system. Considering how often I tend to try different ideas, if I had to track down all the red marks every time I wanted to try a different idea, I'd go crazy. (I would have gone crazy if I had to code back in the era of punched cards where you had to submit your program to the computer operator and then get the resulting output a few hours later, or the next day.)

Nemanja Trifunovic

Posts: 172
Nickname: ntrif
Registered: Jun, 2004

Re: Programming with "Duh" Typing

Posted: Jul 9, 2007 12:59 PM

> I don't see how the C++ code "ostream& cout" could cause
> any problems.

You are right, of course - I admit I didn't even look at the sample.

But the point of my post still holds: for some errors, static typing helps you locate some problems much easier than with dynamic typing and unit-tests.

A unit test will simply pass or fail. A compiler error is likely to point to the exact line where the problem occurs.

Erik Engbrecht

Posts: 210
Nickname: eengbrec
Registered: Apr, 2006

Re: Programming with "Duh" Typing

Posted: Jul 9, 2007 12:59 PM

>
> In the end, maybe it does come down to personal preference
> after all. ;-) It would seem that my experimental coding
> style is a whiteboard style and that yours is a notebook
> style. That is, with a whiteboard, it's a lot easier to
> wipe out a large chunk of writing and redraw something
> different. I'd wager that you mull over a design in your
> mind longer than I do before putting it into code.
>
> My design style is highly iterative. I put an idea into
> code as soon as I deem it to be viable, and then see how
> well it works in a real system. Considering how often I
> tend to try different ideas, if I had to track down all
> the red marks every time I wanted to try a different idea,
> I'd go crazy. (I would have gone crazy if I had to code
> back in the era of punched cards where you had to submit
> your program to the computer operator and then get the
> resulting output a few hours later, or the next day.)

Notebooks are easier to erase than whiteboards. You simply turn the page and have a blank sheet, and they have the added advantage of not loosing their original contents in case you have to revert.

Revision control systems are your friend. Start a branch, merge it back if it works. There's no good reason to lose any of your work.

Michael Feathers

Posts: 448
Nickname: mfeathers
Registered: Jul, 2003

Re: imperative, and functional, and oo, ...

Posted: Jul 9, 2007 1:01 PM

> Alan Keefer wrote "... unless you have something like
> the Smalltalk browser to do it for you... I'll believe
> that Ruby and Python and Javascript can have that level of
> refactoring support when I actually see the tools."
>
> I think your skepticism might have gone a little too far
> ;-)

The Smalltalk refactoring browser is indiscriminate. If you rename a method it renames all methods with that name on all classes in the image.

It's just the most conservative option.

Should be easily enough to do in JavaScript and Ruby, reflective cases aside.

Isaac Gouy

Posts: 527
Nickname: igouy
Registered: Jul, 2003

Re: ceteris paribus - not!

Posted: Jul 9, 2007 1:14 PM

James Watson wrote
> I appreciate your providing the above document but I,
> unfortunately, am not familiar with SmallTalk (although
> I've wanted to learn it) so I think it would take a while
> for me to understand how this addresses my concern.

My understanding was that you were concerned about making changes to "large complex systems written in dynamic languages" - you don't need to be familiar with Smalltalk to understand that they made many changes (>17,000) to a large system (>5,000 classes).

The reason I mention it is - ceteris paribus not.

Their estimate for making those changes manually with the Smalltalk refactoring browser was 8,500 hours - compared with the 235 hours it took them to develop behaviour-changing rewrite rules to make those changes (iirc in IntelliJ it's called sse structural search and replace).

8,500 hours with a refactoring browser - I wonder what that would be with a text editor...

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: Programming with "Duh" Typing

Posted: Jul 9, 2007 1:14 PM

> In the end, maybe it does come down to personal preference
> after all. ;-) It would seem that my experimental coding
> style is a whiteboard style and that yours is a notebook
> style. That is, with a whiteboard, it's a lot easier to
> wipe out a large chunk of writing and redraw something
> different. I'd wager that you mull over a design in your
> mind longer than I do before putting it into code.

I think you may be assuming that I only use static typed languages. I'm actually currently engaged in writing a good bit of Python code.

> My design style is highly iterative. I put an idea into
> code as soon as I deem it to be viable, and then see how
> well it works in a real system. Considering how often I
> tend to try different ideas, if I had to track down all
> the red marks every time I wanted to try a different idea,
> I'd go crazy. (I would have gone crazy if I had to code
> back in the era of punched cards where you had to submit
> your program to the computer operator and then get the
> resulting output a few hours later, or the next day.)

Actually you'd be wrong. My design style is very iterative too. And this is the point that I'm trying to make. Static typing doesn't always slow me down. In fact, it helps a lot when I am making sweeping design changes. In python I'm constantly trying to figure out where something is coming from. I always know in Java. I don't have to remember anything with static typing. With dynamic typing I feel like I must remember everything.

I think the difference is that you see the red marks as a pain and I see them as saving me time. When the design is clean, I don't get these kinds of errors for trivial changes. They appear only for things that are going to have to be changed no matter what, for the most part. I don't feel like Python saves me time in this regard by not doing this. I feel really frustrated that I have to plod along finding one issue at a time. It just takes so much longer to change things. Honestly, I often don't make changes that I would normally make because I find it so problematic. I end up using shortcuts to avoid making the change and that usually creates a bad smell.

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: ceteris paribus - not!

Posted: Jul 9, 2007 1:19 PM

> James Watson wrote
> > I appreciate your providing the above document but I,
> > unfortunately, am not familiar with SmallTalk (although
> > I've wanted to learn it) so I think it would take a
> while
> > for me to understand how this addresses my concern.
>
> My understanding was that you were concerned about making
> changes to "large complex systems written in dynamic
> languages" - you don't need to be familiar with Smalltalk
> to understand that they made many changes (>17,000) to a
> large system (>5,000 classes).

I don't really see how this answers my question. My question has nothing to do with comparing different time estimates to each other. The question is how this is accomplished. Or more precisely how it is determined what needs to be changed.

Michael Hobbs

Posts: 51
Nickname: hobb0001
Registered: Dec, 2004

Re: Programming with "Duh" Typing

Posted: Jul 9, 2007 1:23 PM

> Notebooks are easier to erase than whiteboards. You
> simply turn the page and have a blank sheet, and they have
> the added advantage of not loosing their original contents
> in case you have to revert.

Yes, but it's much easier to erase just a portion of the total on a whiteboard.

> Revision control systems are your friend. Start a branch,
> merge it back if it works. There's no good reason to lose
> any of your work.

Typical revision control systems are a pain, especially when it comes to branching and merging. Plus, where you're in the edit-compile-run groove, adding a "branch" step every time is not only distracting, but often impractical. Doubly so when you're using a dynamic language that has no "compile" intermediary between "edit" and "run".

You seem to be missing the point that I'm talking about exploratory programming where a lot of the changes are going to be rewritten or thrown out anyway. Tools such as revision control or config management become much more practical when doing rigorous coding, which is where static typing shines.

Isaac Gouy

Posts: 527
Nickname: igouy
Registered: Jul, 2003

Re: imperative, and functional, and oo, ...

Posted: Jul 9, 2007 1:25 PM

Michael Feathers wrote "The Smalltalk refactoring browser is indiscriminate. If you rename a method it renames all methods with that name on all classes in the image."

The Smalltalk refactoring browser is indiscriminate when it's configured to be indiscriminate :-)

I think you'll find it will show all the refactoring changes that would be made (side-by-side before and after) and allow you to make them on a case-by-case basis.

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: Programming with "Duh" Typing

Posted: Jul 9, 2007 1:32 PM

> You seem to be missing the point that I'm talking about
> exploratory programming where a lot of the changes are
> going to be rewritten or thrown out anyway. Tools such as
> revision control or config management become much more
> practical when doing rigorous coding, which is where
> static typing shines.

So how I lost track that this was your stance. I actually pretty much agree with you so you don't have to respond to my previous posts.

I would say that I find dynamic coding more appropriate for things that are not large chartered team efforts. For example I am using Python to analyze an export from a tool that we use. It would take a lot longer to use Java (and possibly even Scala) to do something like this. But I don't have to worry if the code has holes in it. If it crashes, I'll just fix it. I don't need it to run when I'm not around and no one really needs to be able to maintain it but me.

Flat View: This topic has 370 replies on 25 pages [ « | 2 3 4 5 6 7 8 9 10 | » ]

Previous Topic

Next Topic