13

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?

Improve this question
6
  • 9
    Reverse engineering code into diagrams? Why would you do that in Agile?
    – CaffGeek
    Commented Sep 24, 2012 at 21:52
  • 10
    Agile doesn't mean "code first, document later".
    – user53141
    Commented Sep 24, 2012 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.
    – Gere
    Commented Sep 24, 2012 at 22:05
  • 2
    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
    Commented Sep 24, 2012 at 22:07
  • @WinstonEwert - Good call, I have changed the tags to dynamic-typing and static-typing
    – Carson63000
    Commented Sep 25, 2012 at 3:53

5 Answers 5

Reset to default
14

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 though you might lose some of the relative advantage of working in a dynamic language, you might still come out ahead, especially if you were planning on doing your refactoring 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.

Improve this answer
2
  • 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.
    – Gere
    Commented Sep 27, 2012 at 21:09
  • 1
    @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
    Commented Sep 27, 2012 at 21:31
17

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.

Improve this answer
20
  • 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.
    – Gere
    Commented Sep 24, 2012 at 22:11
  • 2
    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
    Commented Sep 24, 2012 at 22:52
  • 1
    @scarfridge, the type is then (int or str). We'd need to track a set of possible types, but it doesn't prevent type inference from working.
    – Winston Ewert
    Commented Sep 25, 2012 at 13:20
  • 1
    @WinstonEwert "but you can refactor manually, and dynamic languages actually make that fairly easy" -- No, manual refactoring doesn't scale. Tool support for refactoring changes everything even when refactoring is not 100% automatic (see the case study snippets below - programmers.stackexchange.com/a/166594/4334)
    – igouy
    Commented Sep 28, 2012 at 15:53
  • 1
    Almost every point in your "dynamic programming actually makes refactoring easier" is dubious or a non-sequitur. Dynamic programming doesn't mean you have a more comprehensive test suite, just a larger one (because some things need testing that would otherwise be statically caught). You don't offer any support for "refactorings tend to affect less code" (as an addition to "the project is smaller anyway", which is likely true given the current crop of dynamic languages). And the "effort involved in manually refactoring" seems wrong unless you mean you won't even let your compiler help you!
    – Rex Kerr
    Commented May 26, 2016 at 22:04
8

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.

Improve this answer
1
  • "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
    Commented Sep 28, 2012 at 16:17
3

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"

Improve this answer
1

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.

Improve this answer
6
  • 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
    Commented Sep 24, 2012 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
    Commented Sep 24, 2012 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
    Commented Sep 24, 2012 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
    Commented Sep 28, 2012 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
    Commented Sep 28, 2012 at 17:11

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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