Refactoring not breaking anything: If you don’t use introspection (and you hardly ever need to) a refactor script is guaranteed not to break anything. For most introspection, eclipse is smart enough to figure out something may be going wrong, and sends you on an inspection tour past all dubious spots where eclipse thinks there might be trouble (reflection-using code that mentions a relevant class or method name in a string, for example). Re-ordering tests is not a refactor, AND, furthermore, if changing the order of the tests changes the operation of your testing suite, the full thing was buggy in the first place. Refactor scripts being so good you don’t have to have a unit test to be sure everything still works is a luxury only available to languages with static typing, not latent typed languages.

As far as picking types when you write goes: You don’t have to. You just write ‘void’ as return type, for example, and then type your code. Once you’ve written the return statement, eclipse shows you an error ( red underline) on the return line, as the return type is by definition not ‘void’. You then hit quick-fix (CTRL+1) and pick whatever makes the most sense off of the suggestions for changing the return type. At this point you must already have made the decision of what you will be returning as you just wrote a return statement.

However, none of that is very important. The ‘role’ of an object is its class, or interface, or what not. This is not nearly as obvious in python, but java’s built that way from the ground up. In python you have a class with a ’shoot’ function and if that’s all you are looking for, that’s enough. In java, you need to square that ‘role’ (anything that has a shoot function) away into a superclass or interface.

The importance of doing it that way becomes much more obvious when I decide to accidentally pass an instance of ‘gun’ ot the function that wants anything with a shoot() function, instead of the slew of ‘camera’ instances I’ve been passing so far. Then you shoot yourself in the foot. Namespacing is nice, python doesn’t have it for method calls. You’re not going to call each python function net.productsite.appname.camera.shoot, are you? That would be ridiculous. In java, effectively, everything does have that name, but it’s mostly invisible, and where it isn’t, eclipse ALWAYS generates it for you (automatic import statement generation).

“the earlier bugs are caught, the cheaper they are to fix.” – amen! You’re exactly right. Which is why I like java so much. Over half the bugs are caught as I write them. You can’t catch em any earlier, and they are indeed stupendously cheap to fix. Usually 3 keystrokes. (CTRL+1, zero, once, or twice a tap on the down button, and enter). Programs do spend a lot of their time in maintainance, yes, which is again an argument to go with static typing. The savings of latent typing occur in a phase that is inconsequential in the ‘big picture’, yet without static typing you lose the ability for a whole lot of fun and useful abstractions from automated tools and IDEs to help you maintain it later.

“Refactoring shouldn’t break any behaviour, period”
That’s impossible. Perfectly valid refactorings from a static point of view can break apps that use introspection for instance… in JUnit if you move methods around that will probably change the execution order of the tests. In this case it’s OK but it’s still a change in behaviour. So refactoring really depends on which behavior you want to preserve.

“it’s static typing that helps avoid early choices, and dynamic typing that forces you into them”
Sure you can change a type after the fact, but you did have to think about it in the first place, when what’s actually important is the role of the object, not its static type.

“What kind of weird argument is this for in the first place?”
Simply that the distinction between programming and debugging is not clear-cut. Most of the life of an application is in maintenance, and even in the initial development phase, the earlier bugs are caught, the cheaper they are to fix. So in the end I like to see programming as fixing bugs, the first one being “d’oh, my program doesn’t exist”

Refactoring shouldn’t break any behaviour, period. That’s the point and meaning of a refactor job – to restructure code without changing what it does in any way.

Refactoring IS for avoiding the ‘early choice’ dilemma. Why use refactoring only to correct bad design mistakes? Tell you what, I’ll call it a ‘modification script’ instead of a ‘refactor script’. It’s exactly the same thing, just a differenet name. Would that help?

Your exact example is something you can fix in 5 seconds, with 100% guarantee that everything is semantically unchanged, with an eclipse/netbeans/IDEA refactor script. You can NOT PULL THAT TRICK in python, and while in many cases you don’t need any names, you still need a name for your classes, or your functions, and changing those in python is a major headache job. You’ve got it the wrong way around – it’s static typing that helps avoid early choices, and dynamic typing that forces you into them.

As far as your context menu goes: In small hobby projects that’ll work… somewhat. In large system projects, it won’t. In that contextual menu you’ll get every function in your whole app, because the text editor has no clue what ‘x’ might mean when you do x.(hit auto complete button here), so it gives you everything. In java, you eliminate 99.99% of all possible options just by typing your identifiers. The options that remain are then guaranteed.

programming and debugging are the same thing, but obviously you don’t do them at the same time. What kind of weird argument is this for in the first place? I mean, you’re mix and matching word definitions here.

“Typing does not force early choices – that’s what refactoring is for.”
No. Refactoring is for fixing things when you realise some (often good at the time) choices now appear to be bad because your understanding of the system or the requirements have evolved. By forcing early choices I meant forcing early decisions like choosing the name for an interface to declare a variable when you haven’t written the code that uses that variable yet (ie., you don’t know yet which messages you will send to objects in this variable).

“In latent-typed languages you don’t know where to look”
Yes I do, it’s in the contextual menu well of course, if the method happens to have a popular name and different homonyms are in the current namespace, I have some guessing to do.

“I’m guessing Guido is better at python than you are.”
Yes obviously. And Bjarne is way better at C++ than me. I just happen to have different taste for language design.

“typing and debugging are by no means the same thing.”
I meant programming and debugging.

Typing does not force early choices – that’s what refactoring is for. In practice, most changes of types force you to also change callers, but with java, you at least know, for SURE, were to find those callers. In latent-typed languages you don’t know where to look (short of the 100% code coverage plan).

getUsersNames() -> really? Check some real code. You’ll find tons of ambiguous names. You can NOT stuff the entirety of parameters, return type, and potential fault behaviour into one method name, that’s obvious.

checking your own stack works only during runtime. Ctrl+clicking on any identifier in eclipse works as you write the code. The closest that latent typing languages can get is REPL antics, but that isn’t the same thing.

as to redundancy of putting return type in the docs: The official guideline for pydocs disagree with you there. I’m guessing Guido is better at python than you are.

typing and debugging are by no means the same thing. To wit: I needed some rather odd approach to parsing and writing JSON. In 90 minutes I wrote the whole shebang from scratch, whilst distracted (watching a House episode), and non-automated, post-written tests then showed the whole thing was bug free. With latent typing that wouldn’t have happend, as I correct plenty of redlines as I was typing.

“Typing gives lots of useful hints about implementation.”
Maybe but it also forces too early choices.

“If I see a getUsers() method”
Just the name means that it returns a collection of user objects… it would be named getUsersNames() if it returned strings.

“I can always ctrl+click on ‘User’ and immediatly warp to the User class, check out what’s in there.”
I can always ask for senders of this message and see how the method is used.

“include the ‘return type’ in the docs.”
That would be redundant with the code, and I care more about the role of the object (a subset of it’s protocol maybe).

“outdated, and an officialized notation that allows all IDEs to parse this data and help you along as you type.”
Granted, writing precise completion without static types is more difficult, but it works OK for me.

“As far as your debugger comments: typing is mostly useful while you are writing code, not debugging it.”
Isn’t that the same thing ?

I never claimed any such thing. I merely claimed that using (100% coverage) unit tests to achieve the same thing as what typing can do is a ridiculous idea.