Nevertheless, it is always painful to me when I hit a wall when learning and using an unfamiliar API from a dynamically typed language. I always think, “if only this API were statically typed, so that when I encounter an error, I can immediately look up what went wrong”.
Here's an example as I've been learning Gradle while evaluating it along with learning SBT, as two candidate build tools for me to switch to out of Maven as my build tool for a primarily Java-based project. Note that Gradle is basically an embedded domain-specific language using the dynamically typed language Groovy, while SBT is an embedded domain-specific language using the statically typed language Scala.
Here's a code example from a book I've been going through while studying Gradle, “Building and Testing with Gradle”:
Unfortunately, this Gradle build file, when executed under the current version of Gradle, dies with an error:
After much searching online, I still could not figure out what properties are supposed to be available from
repositories.localRepository3. I looked at the Gradle documentation, and I looked up the package
org.gradle.api.internal.artifacts.repositories without success.
Gradle's API has changed since the publication of the book, obviously. And in fact, I have been submitting GitHub pull requests as I update the code examples while encountering apparent changes. But sometimes, as in this case, it has been too confusing for me to figure out how to update the code. You could say that this is always the case for any code in any language, but what bothers me is the nature of error messages and documentation in APIs for dynamically typed languages such as Groovy. These experiences remind me that types are documentation, that types are a way for a programmer to tell the world how code is supposed to be used.
Gradle seems to be a promising build tool, and I will continue to evaluate it while skipping over the particular mysterious error I encountered (since it is not really relevant to what I want to do in my builds), but I wish I could have better figured out what went wrong with the book's code example. Meanwhile, it remains to be seen what kinds of problems I will encounter when using SBT. Again, I have to emphasize that my goal is to get things done, correctly and efficiently. Whatever works best, I will use, whatever its drawbacks: in another project, I happily used SCons as a build tool, based on the dynamically typed language Python, and of course, I have used Rake for Ruby projects.