Timeline for Are dynamic languages at disadvantage for agile development?
Current License: CC BY-SA 3.0
21 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| May 27, 2016 at 15:10 | comment | added | Rex Kerr | Granted, given a really good test suite. You might not know where you should make the change, but you'll know where it caused problems, which at least gives you a lead to go on. | |
| May 27, 2016 at 0:49 | comment | added | Winston Ewert | @RexKerr, I do have a way of finding the places that need to be changed: I run my test suite. If the actual logic has changed, it should show up in the test suite. You can argue the effectiveness of that verses a static type checker, but there is a way to find the problem spots. | |
| May 26, 2016 at 23:29 | comment | added | Rex Kerr | @WinstonEwert - I guess that's technically true, but it's misleading in that you ought to look at all those places anyway because the logic might have changed, except you have no idea where to find them. I'm very skeptical that for any "refactoring" worthy of the name the search time doesn't vastly outweigh the fix time (even done manually). Since the two are inexorably linked, it hardly seems fair--it's like saying, "One way it's easier traveling with an electric car is that you never have to find a gas station." | |
| May 26, 2016 at 23:13 | comment | added | Winston Ewert | @RexKerr, now, you can make a perfectly reasonable argument that its worthwhile having the type signatures to catch other issues that arise in refactoring. I may even agree with it. But, updating the signatures is additional work not required in a dynamic language. It may or may not end up saving time in the end to have the signatures. That's why I said, "in some ways" | |
| May 26, 2016 at 23:11 | comment | added | Winston Ewert | @RexKerr, looking back, its not my finest answer. But I didn't actually say that dynamic programming makes refactoring easier. I said that it was easier, "in some ways." Take for example, type signatures. In a static language, the compiler helpfully tells you where the incorrect type signatures are. In a dynamic language, you don't have to update the type signatures at all, because there aren't any type signatures. | |
| May 26, 2016 at 22:04 | comment | added | Rex Kerr | Your first paragraph makes a really good point. It's just the second that seems (now that I read it) somewhere between shaky and backwards. | |
| May 26, 2016 at 22:04 | comment | added | Rex Kerr | 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! | |
| Sep 28, 2012 at 18:04 | comment | added | Winston Ewert | @igouy, my understand (maybe I'm wrong), is that newer versions of refactoring browser do in fact make some use of type inference in some of the refactorings. Regardless, I think you agree to my overall point: refactoring without static type information seems to work fairly well. | |
| Sep 28, 2012 at 18:03 | comment | added | Winston Ewert | @igouy, I agree that manual refactoring doesn't scale. My point is merely that coding in dynamic languages is less work then dealing with a statically typed language. As such, even if refactoring works less well in a dynamically typed language, I still come out ahead. | |
| Sep 28, 2012 at 16:07 | comment | added | igouy | @WinstonEwert "... type inference ... success of refactoring in Smalltalk" -- ??? Ummm, the Smalltalk Refactoring Browser Rewrite Engine, is based on pattern matching of parse trees. | |
| Sep 28, 2012 at 15:53 | comment | added | igouy | @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) | |
| Sep 27, 2012 at 13:01 | comment | added | Winston Ewert | @scarfridge, there are going to be cases where type inference would have to be less precise than we'd like. i.e. at times we'd have types more general then those actually used. But the question is whether it'd be good enough to be useful for refactoring, given the success of refactoring in Smalltalk, the answer appears to be yes. | |
| Sep 27, 2012 at 8:41 | comment | added | scarfridge | @WinstonEwert This takes us down the abstract interpretation road. Let x = random.random() and y = x and z = 1 if x - y == 0 else "a" - can type inference deduce it is int and not (int or str)? Or suppose a is of type (int or str) - what about b in b = (a,f(a)) with f a type preserving function. The type inferred for b could be ((str or int),(str or int)) which is not very precise or ((str,str) or (int, int)) which means the type inference has to deduce the type preserving property of f (probably unfeasible in general due to Rice). | |
| Sep 25, 2012 at 13:23 | comment | added | Winston Ewert | @Gerenuk, have a look at rope, rope.sourceforge.net, it provides refactoring tools for python. The first refactoring tools for Smalltalk did not use type inference. You can actually do a lot of refactorings without knowing the types of your variables. But, I don't think automatic refactoring is neccessary for agileness. It can be useful, but you can refactor manually, and dynamic languages actually make that fairly easy. | |
| Sep 25, 2012 at 13:20 | comment | added | Winston Ewert |
@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.
|
|
| Sep 25, 2012 at 12:58 | comment | added | scarfridge | @WinstonEwert Full type inference in python seems impossible because of x = 1 if random.random() < 0.5 else "a" | |
| Sep 25, 2012 at 7:55 | comment | added | Gere | @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) | |
| Sep 24, 2012 at 23:42 | comment | added | Winston Ewert | @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. | |
| Sep 24, 2012 at 22:52 | comment | added | Jörg W Mittag | 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. | |
| Sep 24, 2012 at 22:11 | comment | added | Gere | 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. | |
| Sep 24, 2012 at 21:58 | history | answered | Winston Ewert | CC BY-SA 3.0 |