Awhile back I ranted against using dynamic languages like Ruby, Python etc. Recently, I’ve been using Python as a way to test Resteasy’s SMIME integration. It was an extremely frustrating experience that would have been much better if Python was statically typed. Why? Well, take a look at this documentation for doing SMIME with Python and M2Crypto. The problem was is that the examples are interacting with Python’s mail API. I needed to be able to send SMIME over HTTP. So, I needed to understand the M2Crypto API a little bit better. If you look at the example code, you have no idea which additional methods are available, and more frustratingly, when types of objects these methods return. The auto-generated javadoc-like docs for M2Crypto were even less helpful. What I had to end up doing was diving into the M2Crypto codebase to figure out exactly what was going on.
Moral of the story? Programming in dynamic languages can be a lot of fun. But when you run into APIs you’re not familiar you’re pretty much at the mercy of the documentor. If the documentation sucks, you’re pretty much up shit creek and forced to dive into the code to understand what is going on.
Aug 30, 2011 @ 17:01:39
You know I love Ruby, but I actually agree 100% with you on this. And I’m as guilty as the next guy in terms of failing to document APIs, at times.
I think the culture of dynamic languages should promote documentation as much as it does testing. Open-source is great because you have the source if you need it. HAVING to use the source on a daily basis to figure out an API is pretty freaking goofy.
Aug 30, 2011 @ 17:46:44
If you’re relying on IDE reflection, docs, examples, and source exclusively, you’re missing the crucial benefit of dynamic languages: being able to interact with them directly and immediately, i.e. “exploratory programming”. Though I agree it can be a pain to learn an API in a dynamic language, jumping to your conclusion without even mentioning how convenient it is to explore an API in an interactive shell is a bit disingenuous.
Aug 31, 2011 @ 14:34:24
Not disingenuous because working with the interactive shell, just to figure out an API is quite tedious. Would be much easier and productive if I just could see the return type in an IDE or pythondoc.
Aug 31, 2011 @ 14:36:07
BTW, its even worse if method parameters are not documented. Then browsing through the interactive shell isn’t gonna help you much.
Aug 30, 2011 @ 17:52:07
Why, when that happens, you put a breakpoint and dynamically introspect the variable to see it’s class/methods/properties.
Aug 30, 2011 @ 19:13:41
So, undocumented API sucks, not dynamic languages 😀
Aug 31, 2011 @ 14:28:49
At least with an undocumented Java API, I know what the return types of methods are. This was what I was trying to articulate. With Python I had to downlaod the source code to figure out what objects were being returned by which methods. Not very fun and really aggravating.
Aug 31, 2011 @ 16:17:14
I agree with you, thinking that having types is better than nothing… But, after knowing types, you will need to know what kind of information you will put in that field. So, the problem still there if you don’t have an documented API 🙂
Sep 01, 2011 @ 08:00:50
I think interfaces (or abstract classes) in C#/Java can be a big help in these cases too. Provoiding a well named abstraction can make it much easier to understand some new piece of code.
But yeah without them and without information about types documentation becomes more important for sure.
Aug 31, 2011 @ 16:19:01
sorry, typo : /s/an/a/g 😀