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

Isaac Gouy

Posts: 527
Nickname: igouy
Registered: Jul, 2003

Re: ceteris paribus - not!

Posted: Jul 9, 2007 1:42 PM

James Watson wrote
> 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.

My understanding was you were concerned that large scale changes could not be accomplished (practically).

"What I find in Python is that I can barely reuse my old code, much less modify it without a lot of pain."

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: ceteris paribus - not!

Posted: Jul 9, 2007 2:00 PM

> James Watson wrote
> > 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.
>
> My understanding was you were concerned that large scale
> changes could not be accomplished (practically).
>
> "What I find in Python is that I can barely reuse my
> old code, much less modify it without a lot of pain."

Yes, that was part of it and all you have pointed out is that different methodologies produce different results in one dynamic language. How am I supposed to compare that to the effort required in a static language?

But the real question is how can this be done automatically and reliably when the point of dynamic languages is that there is no explicit connection between an operation and the type that is being operated on.

Basically you are saying it took this long to make this many changes. I'm not even sure how they are counting changes. I don't know if the kind of changes that were made are the kind of changes I am concerned about. From what I do understand of this document, it does not seem to address the kind of change I am concerned about.

Alan Keefer

Posts: 29
Nickname: akeefer
Registered: Feb, 2007

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

Posted: Jul 9, 2007 2:03 PM

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

My real point was that those tools don't exist for Python, Ruby, or Javascript (as far as I know, at least); the various tools/IDEs I've seen for those languages are painfully bad compared to the Java tools. Bad enough that they make me want to not do cleanup refactorings, at least. And while those languages lend themselves to cleaner code in the short term, I think that the long-term potential for code cleanliness is harmed by the lack of such tools; I, at least, find that my Ruby or Javascript code degrades over time more than my Java code does, mainly because I get lazy and avoid refactorings that I would be more likely to do if they were safer and more automatic. That could just be a personal failing of mine, but I'm guessing that other people have had the same experience. Minimal tools that essentially do little more than a text-based find-and-replace just don't do enough for me to make them useful.

The Smalltalk IDE, which I have no personal experience with (and thus all I'm saying is essentially hearsay and my own muddled understanding of it), constantly gets raised as a counterpoint to the "the tools suck" argument. They did it for Smalltalk, so of course it'll happen for Ruby or Javascript, right? My limited understanding is that doing that for a dynamic language requires that you basically be constantly running the actual code, which seems slow (on a large code base) and heavily reliant on the quality and coverage of your tests. My (limited) personal experience is that code coverage is never as complete as you want it to be, and that relying on test coverage to make refactoring tools work well will generally lead to some poor-quality refactoring tools. My understanding is also that the Smalltalk IDE supported a very primitive set of refactorings compared to what Eclipse or IntelliJ can do for Java.

Again, my personal experience with Smalltalk is nil, so I could just be demonstrating my ignorance here, but my point was really that the tools don't currently exist, and the existence of the Smalltalk doesn't serve as proof to me that they will eventually come or that they'll be any good when they do.

It might be the case that the other advantages of dynamic typing outweigh that, but it's certainly a pretty marked advantage of static typing. So I think some solution that lets you retain that advantage while incorporating the best advtanges of a dynamic language could turn out to be the best option.

Erik Engbrecht

Posts: 210
Nickname: eengbrec
Registered: Apr, 2006

Re: Programming with "Duh" Typing

Posted: Jul 9, 2007 2:06 PM

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

That is precisely my primary use for Python.

The challenge is that I often don't know what efforts are going to expand in large, chartered team efforts and which ones are just going to fizzle after an initial request for analysis...or worse, which ones I'm likely to become the loan coder on some "essential" application that I only I understand.

Just recently I had a group of people tell me that they needed this big, fancy "database" to unify some "distributed" (from "in a central database" to "I think someone has a napkin somewhere") that would generate up-to-the-minute reports for executives based on completely undefined algorithms in completely undefined formats and they needed it in a week.

So I told them I would focus on algorithms and charts instead of an interactive database, because if I couldn't convert that data into something easily understandable there was no point in worrying about anything more complicated.

Now every couple weeks someone emails me some data or send me a CD, I run an analysis, and send them a deck of PPT slides. It takes me about 5 minutes. I sometimes have to tweak the program a bit, because I've grown the normalized data model based on looking on non-normalized data.

But if this becomes big I'm going to be screwed. It was a tough decision for me to use Python, because it basically means I'm the stuckee for maintaining it until I either quit or find a project with sufficient clout to justify hiring someone who knows Python. Java would have taken longer but wouldn't have involved any personal risk.

So what we need is a language that can do both. I'm hoping Scala will fit the bill and become mainstream. If it doesn't become mainstream it only becomes a better Python for me (which is an accomplishment) but it doesn't alleviate the personal risk of using a language that no one has heard of except from me.

Isaac Gouy

Posts: 527
Nickname: igouy
Registered: Jul, 2003

Re: an example

Posted: Jul 9, 2007 3:05 PM

James Watson wrote
> I'm not sure if you use Python but it's generally pretty
> self-explanatory (which is one of the things I really like
> about it.)

I suspect we all fondly imagine the languages we know are pretty self-explanatory - and they are if we know them, otherwise not, so I struggled a bit.

As the handlers are doing general stuff with lists and strings it's not at all obvious to me that they would be any easier to find and change in Java.

Anyway let me turn it into Smalltalk snippets as best I can, so I can step through rather than guess at would would happen.

withAddress: anAddress 
   ^self new address: anAddress

address: anAddress
   address := anAddress

address
   ^address

example
   | p |
   p := Person withAddress: (OrderedCollection new).
   (Foo handler: p address) do: [:each| "do something"]

handler: listProvider
   ^Bar handler: listProvider with: (self itemHandler)

handler: listProvider with: itemHandler
   ^listProvider collect: [:each| each itemHandler]

Starting from the example method,
- right mouse button, select implementors menu item, select handler: from the submenu
- a new window opens listing all handler: methods, select Foo class handler: in the list, and the source of the method is displayed below the list
- right mouse button, select implementors menu item, select handler:with from the submenu
- a new window opens listing all handler:with: methods

(This isn't using the refactoring browser just the find implentors behaviour that has been around for 25 years.)

I've gone back and re-read the rest your questions:
- ...tell me whether my new class has all the required methods?
without static type analysis, I don't think so :-)
- ...tell me which required methods do not exist on my new type
again this is type based analysis.

You seem to be asking how we can get the guarantees provided by static type checking in a language that by definition doesn't provide static type checking :-)

We could try to do type recovery
http://decomp.ulb.ac.be/roelwuyts/smalltalk/roeltyper/
and
http://www.lexspoon.org/chuck/spoon-ecoop04.pdf

but afaik those approaches aren't included as part of default Smalltalk development environments.

Isaac Gouy

Posts: 527
Nickname: igouy
Registered: Jul, 2003

Re: ceteris paribus - not!

Posted: Jul 9, 2007 3:15 PM

James Watson wrote
> Yes, that was part of it and all you have pointed out is
> that different methodologies produce different results in
> one dynamic language. How am I supposed to compare that
> to the effort required in a static language?

Different tools make that much difference in one dynamic language, so how much sense does it make to talk about Java versus Python, when we are really talking about Java+RefactoringIDE versus Python - maybe the difference is the RefactoringIDE not static versus dynamic.

Isaac Gouy

Posts: 527
Nickname: igouy
Registered: Jul, 2003

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

Posted: Jul 9, 2007 3:31 PM

Alan Keefer wrote
> That could just be a personal failing of mine,
> but I'm guessing that other people have had the same
> experience.

No doubt many of us share that personal failing to greater or lesser extent :-)

> The Smalltalk IDE, ... requires that you
> basically be constantly running the actual code

You are mistaken.

> My understanding is also that the Smalltalk IDE supported
> a very primitive set of refactorings compared to what
> Eclipse or IntelliJ can do for Java.

Maybe there aren't as many refactorings that make sense in Smalltalk?

In any case, custom rewrite rules are possible
http://oopsla.acm.org/extra/pracreports/TransformDataLayerReport.pdf

> Again, my personal experience with Smalltalk is nil, so I
> could just be demonstrating my ignorance here...

What can I say :-)

Cedric Beust

Posts: 140
Nickname: cbeust
Registered: Feb, 2004

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

Posted: Jul 9, 2007 3:49 PM

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

Thanks for mentioning this, Michael. It's amazing how so many people still claim that the Smalltalk browser solved the "refactoring dynamic languages" twenty years ago while all it did was a simple string replace.

The truth is that certain refactorings are just plain impossible to achieve automatically in dynamic languages (see http://beust.com/weblog/archives/000414.html for an example).

--
Cedric

Alan Keefer

Posts: 29
Nickname: akeefer
Registered: Feb, 2007

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

Posted: Jul 9, 2007 3:50 PM

> > The Smalltalk IDE, ... requires that you
> > basically be constantly running the actual code
>
> You are mistaken.

My apologies . . . I guess rather than running the code all the time, though, you'd need to run the actual code at the time of the refactoring, or at least semi-frequently in order to build up the mapping from code to the actual types (and thus methods) being referenced.

For example, in the paper "A Refactoring Tool For Smalltalk" (http://st-www.cs.uiuc.edu/~droberts/tapos/TAPOS.htm) they describe doing exactly that in order to do a rename method translation:

"1. Using the rename method refactoring, rename the translateBy: method in the Geometric class to translatedBy:. This will rename the method in the Geometric class and all of its subclasses. (All of the subclasses are renamed to preserve the common protocol that all Geometrics understand.)
2. Exercise the application on a test suite. This step is necessary because the rename method refactoring is a dynamic refactoring, which will be discussed in Section 6.3.
3. File out the application and file it into an Objectworks 4.1 image."

So it might not be that you have to constantly run the code, but in order to do a refactoring you have to run the code at some point, which is both slow (at least for a large system) compared to static analysis and reliant on the completeness of your test suite.

I'd certainly be interested to hear if there's some way around those limitations, though.

Cedric Beust

Posts: 140
Nickname: cbeust
Registered: Feb, 2004

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

Posted: Jul 9, 2007 3:52 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.

Right: it's just a simple string replace that requires human intervention. And I can show you a listing that's ten lines long that even humans can't refactor with certainty.

With statically typed languages, it's mathematically provable that the code after refactoring is equivalent to the one you started with, and it's the kind of peace of mind that I am not willing give away for large scale projects...

--
Cedric

Michael Feathers

Posts: 448
Nickname: mfeathers
Registered: Jul, 2003

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

Posted: Jul 9, 2007 3:57 PM

> Right: it's just a simple string replace that requires
> human intervention. And I can show you a listing that's
> ten lines long that even humans can't refactor with
> certainty.
>
> With statically typed languages, it's mathematically
> provable that the code after refactoring is equivalent to
> the one you started with, and it's the kind of peace of
> mind that I am not willing give away for large scale
> projects...

It's hard to know how much peace of mind that is worth considering the fact that there are far more things that are provable than are ever proved.

Cedric Beust

Posts: 140
Nickname: cbeust
Registered: Feb, 2004

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

Posted: Jul 9, 2007 4:03 PM

> > The Smalltalk IDE, ... requires that you
> > basically be constantly running the actual code
>
> You are mistaken.

You are correct, but you seem to be implying that Alan was not giving the Smalltalk IDE enough credit, while he was actually giving it too much :-)

Like we said earlier, the Smalltalk IDE was doing a lot less than even running the code to try to understand it (another dream we are still chasing even today): the only refactorings that it offered were just glorified string search/replaces requiring manual intervention.

--
Cedric

Cedric Beust

Posts: 140
Nickname: cbeust
Registered: Feb, 2004

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

Posted: Jul 9, 2007 4:05 PM

> It's hard to know how much peace of mind that is worth

I'll take a little bit of peace of mind over no peace of mind any day...

--
Cedric

Isaac Gouy

Posts: 527
Nickname: igouy
Registered: Jul, 2003

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

Posted: Jul 9, 2007 4:07 PM

Alan Keefer wrote
> So it might not be that you have to constantly run
> the code, but in order to do a refactoring you have to run
> the code at some point...

I believe that paper was published in 1997, things change, it hasn't worked like that for many years.

Isaac Gouy

Posts: 527
Nickname: igouy
Registered: Jul, 2003

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

Posted: Jul 9, 2007 4:13 PM

Cedric Beust wrote
> Right: it's just a simple string replace that requires
> human intervention.

You are mistaken, it's not just a simple string replace - and I think you've heard that before - it would be a lot easier to implement in Ruby if it was.

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

Previous Topic

Next Topic