Thanks for elaborating and I hope you also realise I was just using C as an example of another language (a type-safe one). I think a lot of us have encountered 'big ball of mud C code-bases' in our careers which is what tends to spring to mind for me when anyone is discussing code maintainability.
>> Horrible to refactor. I mean really horrible. You don't get everything right the first time and when it comes to fixing that it's hell
I think dynamic languages like Python and Ruby are an absolute joy to refactor. There is generally less code-junk to be worrying about when making refactorings. I realise this is subjective however, I think it's difficult to make a serious case that any one language is easier to refactor than another. Granted, the refactoring tools in IDEs for Ruby/Python etc. are much more limited than say C#.
I hope you won't mind if I don't get into the indentation or type safety arguments. They've been done to death! :)
I think we're in agreement that if you need something to be really fast you should use a different language. I just don't think that's a reason to not use Python for the rest of your app. And of course as others have pointed out the vast majority of us are not writing apps that require super fast algorithms, we're all far too busy doing the same CRUD stuff over and over right :)
I appreciate your insight on a 100kloc Python project though, I have to admit I've not encountered anything of that size. At work we have a much smaller codebase that has already gotten out-of-hand but I believe that's entirely due to the developer responsible, not the language.
The problem with refactoring dynamic languages is that it's very hard for static code checking to let you know when you've missed a spot.
For example, what functions take class Foo that should now expect class Bar? What functions called method Baz, that now should call Bat?
Static typing makes all of that trivial. You know with certainty, when you've hit all the right spots, because the code won't compile otherwise. Also, a lot of that refactoring can be done automatically through tooling. "Replace all calls of Foo.Baz() with Bar.Bat()". Trivial, done... and it's often impossible to do the same thing in dynamic languages. You have to rely on tests catching everything... and how many of those tests need to be updated now, too? What's testing your tests?
I love dynamic languages, don't get me wrong... but refactoring large code based is way easier to get correct in statically typed languages.
If you need to touch a lot of places for refactoring on a regular basis, that should tell you you're not doing something optimally. If you write your tests so they are dependent on internal details of the other code, that's a warning sign too. Add to that, that at least in my experience, my Ruby code bases tends to end up far smaller than my old equivalent C code, and the problem tends to be a lot smaller than one might imagine.
Yes, you need testing discipline, but you need that with static languages too - if you think you're ok just because the compiler didn't complain.... Well, that's just a false sense of security.
>> Horrible to refactor. I mean really horrible. You don't get everything right the first time and when it comes to fixing that it's hell
I think dynamic languages like Python and Ruby are an absolute joy to refactor. There is generally less code-junk to be worrying about when making refactorings. I realise this is subjective however, I think it's difficult to make a serious case that any one language is easier to refactor than another. Granted, the refactoring tools in IDEs for Ruby/Python etc. are much more limited than say C#.
I hope you won't mind if I don't get into the indentation or type safety arguments. They've been done to death! :)
I think we're in agreement that if you need something to be really fast you should use a different language. I just don't think that's a reason to not use Python for the rest of your app. And of course as others have pointed out the vast majority of us are not writing apps that require super fast algorithms, we're all far too busy doing the same CRUD stuff over and over right :)
I appreciate your insight on a 100kloc Python project though, I have to admit I've not encountered anything of that size. At work we have a much smaller codebase that has already gotten out-of-hand but I believe that's entirely due to the developer responsible, not the language.