I love that writing Python, Ruby or Javascript requires so little boilerplate. I love simple functional constructs. I love the clean and simple syntax.

However, there are three things I'm really bad at when developing a large software in a dynamic language:

Navigating the code

Identifying the interfaces of the objects I'm using

Refactoring efficiently

I have been trying simple editors (i.e. Vim) as well as IDE (Eclipse + PyDev) but in both cases I feel like I have to commit a lot more to memory and/or to constantly "grep" and read through the code to identify the interfaces. This is especially true when working with a large codebase with multiple dependencies.

As for refactoring, for example changing method names, it becomes hugely dependent on the quality of my unit tests. And if I try to isolate my unit tests by "cutting them off" the rest of the application, then there is no guarantee that my stub's interface stays up to date with the object I'm stubbing.

I'm sure there are workarounds for these problems. How do you work efficiently in Python, Ruby or Javascript?

3 Answers
3

Good. Thinking is good. I find that "learning" leads eventually to "memory".

Constantly "grep" and read through the code to identify the interfaces.

This is typical. If you can't remember them, then they're too complex, aren't they? Time to simplify.

Simple is hard to create. But when you have trouble remembering, it's a symptom of bad design.

I use grep. It works for me. My Komodo Edit has lots of nice search. So does Notepad++

Identifying the interfaces of the objects I'm using

Doc Strings and the help() function work. I use them. Daily.

Refactoring efficiently...
it becomes hugely dependent on the quality of my unit tests.

That's not news. That's always been true, even in a static language.

In a static language, we often get lazy, assuming that -- as long is it compiles -- it's really likely to work. This is manifestly false, but we get lazy.

I'm sure there are workarounds for these problems.

These aren't "problems" and don't require "workarounds".

A dynamic language is precisely about not knowing the type of the objects you manipulate. When you receive a parameter, you assume it defines a "quack()" and a "feathers()" method, but you don't know where there documentation is (in fact, they will have multiple docstrings in their multiple implementations).

"not knowing the type of the objects"? Really. When I design the client of an object, I know what type I designed.

When I define a service, used by multiple clients, the "exact" type is not relevant, when I have a defined the required interface of quack() and feathers().

Finally, I have the Read-Execute-Print-Loop and other tools to determine the "exact" type in the rare cases when I have a subtle problem. That's what I actually use every day.

>>> x = some_mystery_factory( some, args )
>>> type(x)
>>> dir(x)

Doesn't seem too difficult -- at least in Python -- to unwind the type of an object. Must dynamic languages have a REPL, making it pretty easy to see what's going on.

You don't know the expected parameter order either. It seems hard for an IDE to help there.

That doesn't make much sense. help() works.

And my IDE can often locate the definition. Not always -- some convoluted dynamic constructs can easily conceal the base class. In that case, I have to actually think about the object's class to locate the method definition. Of course, I'm writing the code, so there's little (or no) mystery there.

I feel like I could argue that being forced to commit more to memory gives you less capacity for thinking...
–
NickCFeb 2 '11 at 21:32

@Renesis: Memorization isn't evil if there's any kind of pattern or system to the interfaces.
–
S.LottFeb 2 '11 at 21:33

1

I agree with @Renesis memorizing interfaces takes my mind away from the real thinking. I couldn't care less how another coder on my team decided to order the parameters. The fact that a large codebase uses a lot of different libraries with different naming standards is not infrequent, and it is often impossible or impractical to simplify or unify these components.
–
Philippe BeaudoinFeb 2 '11 at 23:46

Re: Doc strings, they're fine when you know the type of the object, but often you don't and you have to look that up.
–
Philippe BeaudoinFeb 2 '11 at 23:53