Being productive in dynamically typed languages


#1

On the job, almost everything I’ve done is in a statically typed language (C, C++, Go) and the JavaScript I write on my side project uses Flowtype to get static types, so I haven’t done much work using in dynamic langs on big projects, but have struggled through making sense of Python code (like figuring out how to right click my way up the call stack when a lot of inheritance is going on, what type a given parameter should be, etc). Folks who’ve done a lot on large dynamically typed codebases, what do you do to stay productive writing code, and especially getting the lay of the land reading code other people wrote? Any books, general tips, editor plugins, etc you’d recommend?


#2

Common problems with python code base:

pep8 compliant code can get quite long once people start carrying over code to multiple lines to fill the char length of 80 chars.

solution: code preview
For this to work the code should be documented well (define function name, arg inputs, etc).

multiple levels of inheritance
solution: a good ide that supports code preview when you select the class being instantiated, and auto completion of class names as you are typing in

My 2 cents…a good IDE for python is one that

  • supports auto completion for classes
  • good for debugging python where you can view values of var in debug mode
  • has code preview (you click on function or class and info shows up in a small window)

While I am a fan of vscode for js and go, I think I am most productive writing python using eclipse IDE with the pydev package.

Cons of eclipse include slowness because it is quite bloated. However the code base I have worked on (with success) has had multiple levels of inheritance and this IDE has been great to navigate that.

cons with eclipse:

  • not as nice as vscode (looks)
  • renaming files is kind of annoying
  • git package is annoying

#3

I find it to be true that with a dynamically typed code base you generally have to hold much more state in your head, which is obviously not great for us mushy brained monkeys! A few practices really help to make this suck less:

  1. Naming things: it’s one of the hard problems for a reason. But if you name variables, classes, and methods such that they explain what they do really well, it means you don’t have to necessarily go hunt down the implementation to figure it out.
  2. Modularize and make public interfaces obvious: If you work to reduce the complexity of your system by removing connections between modules it means that you should be able to work within the context of a module while keeping the rest of the system safely outside of working memory.
  3. Write unit tests liberally while exploring new ideas and APIs: And use some kind of file system watcher to run your tests on save. The lack of a compiler and static type checking gives a lot of flexibility, but it also lands you with a lot of responsibility to check things with testing. But unit tests, and the REPL too (run python at the command line and just play around), are great ways to explore your own code and new, unfamiliar APIs in action. Learn the APIs built into the language for exploring objects. Often times you can get direct access to docs in REPL. e.g. help(my_function) will display the doc string for the function or method in the REPL for you.

#4

unit tests (or, really, any sort of automated testing) is a really underappreciated technique for dealing with this issue. every time i swing back to php from a month or so in scala, i always have this sense of terror that the compiler isn’t there to goalkeep stupid errors. solid tests with decent coverage really helps fill that gap!