Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

From what I've read agile development often involves refactoring or reverse engineering code into diagrams. Of course there is much more than that, but if we consider the practices that rely on these two methods, are dynamically typed languages at disadvantage?

It seem staticly-typed languages would make refactoring and reverse engineering much easier.

Is Refactoring or (automated) reverse engineering hard if not impossible in dynamically typed languages? What does real world projects tell about usage of dynamically typed languages for agile methodology?

share|improve this question
3  
Reverse engineering code into diagrams? Why would you do that in Agile? –  CaffGeek Sep 24 '12 at 21:52
6  
Agile doesn't mean "code first, document later". –  Steven Burnap Sep 24 '12 at 21:53
    
@CaffGeek: Some often recommended books suggest to draw diagrams on a whiteboard, then code and finally reverse engineer code into diagrams for the next meeting. –  Gerenuk Sep 24 '12 at 22:05
1  
I think strongly-typed should be removed from tags and text of this question. The question seems to be about static vs dynamic not strong vs weak. –  Winston Ewert Sep 24 '12 at 22:07
    
@WinstonEwert - Good call, I have changed the tags to dynamic-typing and static-typing –  Carson63000 Sep 25 '12 at 3:53

5 Answers 5

up vote 7 down vote accepted

Dynamic languages are theoretically at a disadvantage, all else being equal, because they specify less about how the code works (what the constraints are), and therefore less of the refactoring can be done automatically, and problems that arise cannot be detected automatically as well.

But all else is not equal. The most popular dynamic languages allow for highly compact yet comprehensible code, which generally makes development in them faster, and makes the logic (which may change in refactoring) easier to spot visually. So you might lose some of the relative advantage of working in a dynamic language and still come out ahead, especially if you were planning on doing it by hand anyway.

On the other hand, there exist statically typed languages with essentially the same advantages as dynamic languages (i.e. compact and comprehensible--with types mostly inferred, but very much there): Haskell is perhaps the leading example, but OCaML/F#, Scala, and others are in this category also. Unfortunately, since they are less heavily used than the most popular statically typed languages, they don't have as extensive of toolsets for them (e.g. for refactoring).

So, as a bottom line, I think you'll do adequately with agile methodologies in most languages; I wouldn't say there's a clear winner right now as practice has not yet caught up with theory.

share|improve this answer
    
I think this answer addresses the key points of the question best :) Could you also elaborate on the importance of safe refactoring and reverse-engineering for agile development? I was assuming it played a very important role? Maybe it's less than I thought and tools for dynamics language are just good enough. –  Gerenuk Sep 27 '12 at 21:09
    
@Gerenuk - I do not have sufficient experience with agile development (esp. in dynamic languages) to give an authoritative answer--is the refactoring aspect de-emphasized, left the same, etc.? Keep in mind that other common aspects of the process--test-driven development, for example--can help pinpoint where your refactoring went awry, and if you put a little more effort into, say, the design phase, you may not need to refactor as much. I don't think one particular technique is the key--it's keeping a full set of tools at hand, deployed frequently and collaboratively. –  Rex Kerr Sep 27 '12 at 21:31

Automated refactoring was invented in Smalltalk, a dynamically typed language. So no, its not impossible to have automated refactoring in a dynamically typed language. How hard it is depends far more on other factors besides the typing discipline. C++ and Java are both statically typed, but refactoring tools only really exist for Java. Smalltalk with its introspection and simple syntax was a really good candidate for refactoring tools.

In some ways, dynamic typing actually makes refactoring easier. If you have a good testing suite, you can be sure your refactorings haven't broken anythings. A dynamically typed code base is typically smaller. Additionally, refactorings tend to affect less code. Altogether the effort involved in manually refactoring a dynamic code base is less then that of a static code base.

share|improve this answer
1  
What about reverse engineering then? Is Smalltalk different from Python with regards to typing? It seems a tough problem to deduce all types in Python and thus determine which which method are really identical and not just the same name. –  Gerenuk Sep 24 '12 at 22:11
1  
Smalltalk is not that much different from Python with regards to typing. It is, however, significantly different with regards to tooling. The tools and IDEs that are available for Smalltalk are way better than those available for Python or even C#, C++ and Java. The reason why IDEs for Python are bad is not because Python is dynamically typed, it's because, well, the IDEs for Python are bad. Let's not forget that the IDE we now know as Eclipse used to be called VisualAge for Smalltalk once. The Smalltalk community has 40 years experience building IDEs, and they apply that to Java. –  Jörg W Mittag Sep 24 '12 at 22:52
    
@Gerenuk, Smalltalk's typing isn't any different then python. In other ways, such as introspection, Smalltalk does provide a feature set more friendly to refactoring. Type inferencing in python would require work, but has been done, see PyPy project. –  Winston Ewert Sep 24 '12 at 23:42
    
@WinstonEwert: Tools can be more friendly, but even if I wanted to write type inference by myself it would be quite tough?! It can even be impossible if the types are hidden behind logic or the executing code is missing? Type inference does not explode in computation time? I should definitely look at PyPy ideas then. It sounds exciting :) Finally for the actual question, would you agree that agile often requires solid type inference? (irrespectively of language tools) –  Gerenuk Sep 25 '12 at 7:55
    
@WinstonEwert Full type inference in python seems impossible because of x = 1 if random.random() < 0.5 else "a" –  scarfridge Sep 25 '12 at 12:58

Refactoring was invented in dynamic languages. Automated Refactoring Tools were invented in dynamic languages. IDEs were invented in dynamic languages. Several Agile Methodologies were invented in dynamic languages.

I really don't see any problem.

share|improve this answer
    
"Smalltalk is not that much different from Python with regards to typing. It is, however, significantly different with regards to tooling." -- Maybe that's starting to change, see jetbrains.com/pycharm/features/index.html –  igouy Sep 28 '12 at 16:17

Lest we forget, the "Agile" way of working which became known as Extreme Programming (XP) was created on a Smalltalk project (and Smalltalk certainly counts as a "dynamic" language).

Here's a case study of industrial use of a refactoring tool provided with a dynamically typed language:

A very large Smalltalk application was developed at Cargill to support the operation of grain elevators and the associated commodity trading activities. The Smalltalk client application has 385 windows and over 5,000 classes. About 2,000 classes in this application interacted with an early (circa 1993) data access framework. The framework dynamically performed a mapping of object attributes to data table columns.

Analysis showed that although dynamic look up consumed 40% of the client execution time, it was unnecessary.

A new data layer interface was developed that required the business class to provide the object attribute to column mapping in an explicitly coded method. Testing showed that this interface was orders of magnitude faster. The issue was how to change the 2,100 business class users of the data layer.

A large application under development cannot freeze code while a transformation of an interface is constructed and tested. We had to construct and test the transformations in a parallel branch of the code repository from the main development stream. When the transformation was fully tested, then it was applied to the main code stream in a single operation.

Less than 35 bugs were found in the 17,100 changes. All of the bugs were quickly resolved in a three-week period.

If the changes were done manually we estimate that it would have taken 8,500 hours, compared with 235 hours to develop the transformation rules.

The task was completed in 3% of the expected time by using Rewrite Rules. This is an improvement by a factor of 36.

from “Transformation of an application data layer” Will Loew-Blosser OOPSLA 2002

Also -- "Tools for making impossible changes - experiences with a tool for transforming large Smalltalk programs"

share|improve this answer

Your principles thought sounds to me correct.

The strongly-typed languages like C# are good candidates for a code base that constantly needs re-factoring. Basically most re-factoring tools (like Resharper, JustCode, etc..) in the market are very effective in statically typed programming languages.

What does real world projects tell about usage of dynamically typed languages for agile methodology?

For development team that practices Agile/Scrum methodology it is very helpful (even critical) to have good set of re-factoring tools under armor. Otherwise, all sudden changes in upcoming sprint may be a nightmare to be modify or re-design.

Thus, agile methodology does not provide advantages to statically typed languages or dynamic once. What it provide is an iterative approach to build a solid application.

share|improve this answer
4  
Dynamic languages had Automated Refactoring Tools long before C# even existed and when Notepad was still the most powerful Java IDE. –  Jörg W Mittag Sep 24 '12 at 22:05
4  
This answer is completely not supported by my experience. Dynamic languages are typically faster to do things in than the more conventional statically typed ones (I have got to learn Haskell or ML or something like that sometime). They're also a whole lot faster to modify if suddenly needed, which led to my conclusion that Common Lisp was the best language when you didn't really know what your were doing. Moreover, where do you think refactoring started? –  David Thornley Sep 24 '12 at 22:15
1  
why are you thinking so, for example javascript is a dynamic language, but Re-sharper does not do the same slick job as it does with C#. Secondly, i did NOT said that "dynamic languages are slower to do the things". –  Yusubov Sep 24 '12 at 23:40
    
From the people who brought you IntelliJ IDEA -- PyCharm -- "Rename refactoring allows to perform global code changes safely and instantly. Local changes within a file are performed in-place. Refactorings work in plain Python and Django projects. Use Introduce Variable/Field/Constant and Inline Local for improving the code structure within a method, Extract Method to break up longer methods, Extract Superclass, Push Up, Pull Down and Move to move the methods and classes." jetbrains.com/pycharm/features/index.html –  igouy Sep 28 '12 at 16:14
    
@igouy, i am referring to Resharper and JustCode in my answer. Thus, it is true for the context which it is referred. –  Yusubov Sep 28 '12 at 17:11

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.