The Artima Developer Community
Sponsored Link

Weblogs Forum
Refactoring Dynamic Code

24 replies on 2 pages. Most recent reply: Nov 22, 2007 4:04 AM by Daesung Park

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 24 replies on 2 pages [ « | 1 2 ]
Isaac Gouy

Posts: 527
Nickname: igouy
Registered: Jul, 2003

Re: Refactoring Dynamic Code Posted: Oct 18, 2007 11:03 AM
Reply to this message Reply
Advertisement
Rafael Alvarez wrote
-snip-
> Of course, in those static languages that the refactoring
> support is very poor (poor guys), the gain in productivity
> and conciseness of some dynamic languages will give a big
> productivity gain. But for those static language where the
> refactoring support excels, the productivity gain by the
> conciseness of the dynamic languages will be more than
> countered by the loss of productivity when refactoring.
>
> So the problem is that for dynamic languages where the
> number of refactoring that can be automated or are
> supported by tools are small, the cost of changing a
> medium-to-big code base is "big".

Not knowing anything about Perl the idea that there was refactoring support was really interesting!

But then it turned out you were just comparing a text-editor with a refactoring IDE :-(

You only measured one-side of your comparison - you haven't measured whatever productivity gain dynamic languages may or may not give - so you have no basis for making overall productivity claims.

Eivind Eklund

Posts: 49
Nickname: eeklund2
Registered: Jan, 2006

Re: Refactoring Dynamic Code Posted: Oct 19, 2007 6:44 AM
Reply to this message Reply
> Of course, in those static languages that the refactoring
> support is very poor (poor guys), the gain in productivity
> and conciseness of some dynamic languages will give a big
> productivity gain. But for those static language where the
> refactoring support excels, the productivity gain by the
> conciseness of the dynamic languages will be more than
> countered by the loss of productivity when refactoring.

Of course, for those cases where you end up reading code at all, the productivity loss due to verbosity of the static languages will more than counter the loss due to increased costs of some kinds of refactoring.

Or at least that is my experience. To me, this obviously depends on how you work, what context you are in, what people you work with, and what codebase you work with - so there is no global answer.

Eivind.

Frank Silbermann

Posts: 40
Nickname: fsilber
Registered: Mar, 2006

Re: Refactoring Dynamic Code Posted: Oct 19, 2007 8:05 AM
Reply to this message Reply
I think you have two issues to sort out. One is the comparative difficulty of refactoring dynamic code, as compared to languages with static typing. The other is the difficulty of refactoring code whose logic is not confined to a single programming language or notation.

As for the first aspect -- refactoring in a dynamic language -- I don't know the answer. I suspect that it the lack of type information may give the IDE less information to work with. On the other hand, there may be more ways to factor out redundancy in a language with dynamic typing.

Aside from the static vs dynamic typic issue, I do think refactoring is going to be very difficult in any framework that scatters programming logic across a variety of technologies -- technologies such as programming language, XML, JSF component definitions, and JSP scriptlets. And this is likely to be no less of a problem with "configuration by convention" -- as the convention also lives outside of the main programming language.

The problem of diverse and redundant notations has two sources: (1) persistance logic and (2) presentation logic.

Persistance logic is difficult to refactor because redundant logic lives in two quite different technologies -- the programming language and the RDBMS. I don't have much to say about this; perhaps a Hibernate expert can elaborate on the issues.

As for the presentation logic, the main thing is to express all of it as Java code, relying on neither XML, scriptlets, custom tags, nor convention. Unfortunately, this rules out use of the vast majority of web frameworks. However, there are (a very few) exceptions.

One such exception is the Wicket web framework. Wicket allows you to put ALL of your presentation logic in POJOs. Add to that the right persistence framework, and your problem is solved.

Terje Slettebø

Posts: 205
Nickname: tslettebo
Registered: Jun, 2004

Re: Refactoring Dynamic Code Posted: Oct 22, 2007 3:29 AM
Reply to this message Reply
> > This is sometimes referred to as the "continuous tax"
> that
> > dynamic typing languages you to pay as the size and
> scope
> > of your code expands.
>

> template <typename T>
> void f1(T t)
> {
> t.init();
> }
>
> template <typename T>
> void f2(T t)
> {
> t.init();
> }
>

That's correct; C++ templates has much the same problems as dynamical languages in this respect. That's where the "concept"-proposal (aka restricted generics, as also found in languages like Java and C#) comes in, which will likely be included in the next version of the standard (due in 2009).

Using concepts, you could write the above as:

concept SomeConcept
{
void init();
}

template<SomeConcept T>
void f1(T t)
{
t.init();
}

template<SomeConcept T>
void f2(T t)
{
t.init();
}

Changing "init()" to "init2()" in the concept definition, a refactoring tool should also be able to find all instances of uses of SomeConcept, and change those places, too.

Kay Schluehr

Posts: 302
Nickname: schluehk
Registered: Jan, 2005

Re: Refactoring Dynamic Code Posted: Oct 22, 2007 4:33 AM
Reply to this message Reply
> Using concepts, you could write the above as:
>

> concept SomeConcept
> {
> void init();
> }
>
> template<SomeConcept T>
> void f1(T t)
> {
> t.init();
> }
>
> template<SomeConcept T>
> void f2(T t)
> {
> t.init();
> }
>

> Changing "init()" to "init2()" in the concept definition,
> a refactoring tool should also be able to find all
> instances of uses of SomeConcept, and change those places,
> too.

That's very nice.

Note that you can annotate Python 3.0 arguments like this:

class SomeConcept:
def init(self):
pass

def f1(t: SomeConcept):
t.init()

def f2(t: SomeConcept):
t.init()

The language will nevertheless be dynamically typed and the annotations are optional and their semantics depends on particular handlers. That says it's not basically an issue about type systems but about abstraction and the provisioning of metadata.

Terje Slettebø

Posts: 205
Nickname: tslettebo
Registered: Jun, 2004

Re: Refactoring Dynamic Code Posted: Oct 22, 2007 11:08 AM
Reply to this message Reply
> > Using concepts, you could write the above as:
> >

> > concept SomeConcept
> > {
> > void init();
> > }
> >
> > template<SomeConcept T>
> > void f1(T t)
> > {
> > t.init();
> > }
> >
> > template<SomeConcept T>
> > void f2(T t)
> > {
> > t.init();
> > }
> >

> > Changing "init()" to "init2()" in the concept
> definition,
> > a refactoring tool should also be able to find all
> > instances of uses of SomeConcept, and change those
> places,
> > too.
>
> That's very nice.
>
> Note that you can annotate Python 3.0 arguments like
> this:
>

> class SomeConcept:
> def init(self):
> pass
>
> def f1(t: SomeConcept):
> t.init()
>
> def f2(t: SomeConcept):
> t.init()
>

> The language will nevertheless be dynamically typed and
> the annotations are optional and their semantics depends
> on particular handlers. That says it's not basically an
> issue about type systems but about abstraction and the
> provisioning of metadata.

Right. However, note that in the C++ case, any violation of the contract (the interface given by the concept) will be caught at compile-time, whereas I assume that the Python annotations - if they are checked - are checked at run-time, so you only find any violation at run-time, if at all.

However, then we get into that static typing vs dynamic typing debate, again. :)

Also note that - for those who may be new to concepts/constrained generics - a "concept" doesn't specify a specific type, only the requirements of the type (at least the compile-time checkable ones), so that instances of both the following classes would match (or "model", in generic programming speak) the concept above:

class A
{
...
void init() { ... }
...
};

class B
{
...
void init() { ... }
...
}

A a;
B b;

f1(a); // Fine
f1(b); // Also fine

In the current concept proposal, you can specify whether a concept would match a type implicitly (without declaring a type to match it, as long as it has the necessary requirements as specified by the concept, or explicityly, where you have to specify that a type matches the concept).

"SomeConcept" in itself is not a type (it might be considered a set of all the types satisfying its requirements), but "T" in the function templates is a specific type ("A" or "B", in this case).

As I understand the Python example above, "SomeConcept" is a type, and in that case, the example isn't analogous to the C++ one, but rather a case of optional (specific) typing, as in:

void f1(SomeConcept t) { ... }

Here, the value passed in must be of type (convertible to) SomeConcept.

A more useful example may make the point of concepts clearer:

concept LessThanComparable<typename T>
{
bool operator<(T,T);
}

template<LessThanComparable T>
const T& min(const T& a, const T& b)
{
return a<b ? a : b;
}

int a=..., b=...;

int result=min(a,b); // Fine

BigInt a=..., b...; // Some user-defined class

BigInt result=min(a,b); // Also fine

But (using the "A" class defined above):

A a(...), b(...);

A result=min(a,b); // Error, "A" doesn't model the LessThanComparable concept


I also need to correct the syntax for the concept definition in my first posting. The actual syntax should be the following:

concept SomeConcept<typename T>
{
T t;

t.init();
}

Anyway, this is a little off topic, perhaps, but I find "concepts" rather interesting. :)

Carson Gross

Posts: 153
Nickname: cgross
Registered: Oct, 2006

Re: Refactoring Dynamic Code Posted: Oct 26, 2007 9:49 AM
Reply to this message Reply
Why is that hard? You look at all the invocation points of f1 and f2 and rename the methods on the set of types currently invoked at them, all of which should be statically knowable.

_shrug_

It's too bad Java gives static typing such a bad name. All we would have to annotate are our fields, method signatures and a few parameterized constructors if they did a bit of work in the compiler.

Cheers,
Carson

Dick Ford

Posts: 149
Nickname: roybatty
Registered: Sep, 2003

Re: Refactoring Dynamic Code Posted: Nov 1, 2007 2:07 PM
Reply to this message Reply
>
> > This is sometimes referred to as the "continuous tax"
> that
> > dynamic typing languages you to pay as the size and
> scope
> > of your code expands.
>
> This is sometimes referred to as "name calling" - maybe
> Google can find an example of juvenile wit that refers to
> Java as the "continuous tax" :-)

No it's not. Ruby doesn't have feelings. I know you have this insatiable need to troll all the programming forums Isaac, but you're not the defender of Smalltalk or Ruby.

Of course when you're trolling over at James Robertson's Cincom Smalltalk blog you feel that you need to defend Java, so who knows what your problem is.

Vincent O'Sullivan

Posts: 724
Nickname: vincent
Registered: Nov, 2002

Re: Refactoring Dynamic Code Posted: Nov 2, 2007 6:25 AM
Reply to this message Reply
Code compatability. Despite a general belief otherwise, there is not 100% backwards compatability from later to earlier JREs.

Daesung Park

Posts: 10
Nickname: grayger
Registered: Apr, 2006

Re: Refactoring Dynamic Code Posted: Nov 22, 2007 4:04 AM
Reply to this message Reply
Renaming a variable or class name is easiest refactoring in Java world. But renaming seems to be a unreachable goal in dynamic languages. Tools don't know a programmer's intention of refactoring and can't predict future execution flow.

I feel more pressure to follow coding convention wriging code in static type language than dynamic type language. When writing Java code, I checks code style or probable bugs with PMD and Findbugs. On the other hand, when writing JavaScript, Python, and TCL code, I even don't care variable naming. In fact, there is no counterpart tools for dynamic languages as far as I know.

Flat View: This topic has 24 replies on 2 pages [ « | 1  2 ]
Topic: Refactoring Dynamic Code Previous Topic   Next Topic Topic: Aren't C++ Programmers People Too?

Sponsored Links



Google
  Web Artima.com   

Copyright © 1996-2019 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use