3 ms·

Not saying he isn't sincere I'm saying it's a common misunderstanding that the improved refactoring and compiler errors are that valuable, that they alone can s

Not saying he isn't sincere I'm saying it's a common misunderstanding that the improved refactoring and compiler errors are that valuable, that they alone can support a strong argument for static vs. dynamic. There are generally very few situations where you have a single method from a single class sprinkled across an entire codebase for a good reason. That always indicates high coupling and design problems. There are even fewer reasons to rename a well designed method. Constant renaming and high-coupling are bad habits that seem to be commonplace when working in strictly static languages and yet they are known to be bad habits even there. At least dynamic languages discourage these anti-patterns. Not to belittle your friend, I found myself falling into these traps constantly when working in C#. Honestly, what I'm saying is that these problems just are not nearly as significant in say, Ruby, as they are often made out to be by static typing proponents. It's a bit disingenuous to point to these trivialities as reasons why static > dynamic. If it were true then there would be little benefit in dynamic languages. Clearly there is.

cageface 15y ago
After 10 years of programming almost exclusively in dynamic languages I'm very much enjoying the refactoring abilities of modern IDEs when I'm doing native mobile development. I rarely have to change a method across an entire code base, but the ability to rename a method or package name in half a dozen files with a single key press is indisputably not only a productivity boost but an encouragement to more extensive refactoring. More generally, the ability of modern IDEs to manipulate code structurally, and not just texturally, has been eye opening for me.
wpietri 15y ago
I agree that high coupling is bad. I strongly disagree about renaming, though. The theory that you can get good design up front depends on having both a stable problem and a stable solution. Most places don't have stable solutions, because creation of software is usually an exploration of the solution space. (If you don't need to explore the solution space, that often means you should just buy something off the shelf.) Quite a number don't have stable problems, either. Some people have innovative competitors; others are doing startup-ish things. As Keynes said, "When the facts change, I change my mind. What do you do, sir?" I think that applies to design as well, method names included.

cageface 15y ago

After 10 years of programming almost exclusively in dynamic languages I'm very much enjoying the refactoring abilities of modern IDEs when I'm doing native mobile development. I rarely have to change a method across an entire code base, but the ability to rename a method or package name in half a dozen files with a single key press is indisputably not only a productivity boost but an encouragement to more extensive refactoring. More generally, the ability of modern IDEs to manipulate code structurally, and not just texturally, has been eye opening for me.

wpietri 15y ago

I agree that high coupling is bad. I strongly disagree about renaming, though. The theory that you can get good design up front depends on having both a stable problem and a stable solution. Most places don't have stable solutions, because creation of software is usually an exploration of the solution space. (If you don't need to explore the solution space, that often means you should just buy something off the shelf.) Quite a number don't have stable problems, either. Some people have innovative competitors; others are doing startup-ish things. As Keynes said, "When the facts change, I change my mind. What do you do, sir?" I think that applies to design as well, method names included.