Author: Justin James
Justin James presents reasons why developers should consider using dynamic languages. He also discusses how these languages trip up some developers.
——————————————————————————————————
Dynamic languages, for the most part, are ignored by the typical business developer. Sure, Perl had its flash in the pan moment during the CGI heyday of Web development, but dynamic languages are usually viewed as a niche item.
If you aren't considering using dynamic languages, I think you're leaving a lot of potential utility on the table. Here are three great reasons to take a look at what dynamic languages can do for you.
Justin James presents reasons why developers should consider using dynamic languages. He also discusses how these languages trip up some developers.
——————————————————————————————————
Dynamic languages, for the most part, are ignored by the typical business developer. Sure, Perl had its flash in the pan moment during the CGI heyday of Web development, but dynamic languages are usually viewed as a niche item.
If you aren't considering using dynamic languages, I think you're leaving a lot of potential utility on the table. Here are three great reasons to take a look at what dynamic languages can do for you.
Metaprogramming is a breeze
Dynamic languages are excellent for metaprogramming. And with that attribute, dynamic languages are a great choice if you're working on a template system,a domain specific language (DSL), a code generator, a parser, or other type of application that can build applications. Can strongly typed, static languages do these things? Sure, but it is typically a lot more work than it is with a dynamic language.
The .NET world contains a number of tools for performing metaprogramming. You can use Reflection.Emit to spit out code; CodeDOM is slightly less painful; and for the current acme of VB.NET or C# metaprogramming, there are T4 templates. Out of those choices, T4 templates are the least effort to use. But by the time you're using T4, you aren't even performing metaprogramming anymore — to begin with, you're programming in a template system. It is my understanding that T4 is essentially just an abstraction layer on top of CodeDOM.
On the other hand, look at what you can do in a language like Ruby, Perl, Python, PHP, or even JavaScript when it comes to metaprogramming. It is a cinch to hash together a templating system. In Perl, for example, the "guts" of one consist of one line of code. Want to make a code generator? That's easy too. And, thanks to eval, you can do some pretty wild stuff in terms of on the fly modifications to business logic, such as allowing per-customer overrides of default functionality while maintaining a single install base in a multi-tenanted application. You can do all of this with very few lines of code and relatively low complexity. The systems practically write themselves.
Cross-platform compatibility
Dynamic languages tend to be much more cross-platform compatible than other languages. The runtime environment takes the guesswork out of the gotchas that you can encounter. There will occasionally be incompatibilities, such as when the language needs to make calls to the underlying operating system. Sometimes the results will not be the same (math functions with large numbers and cryptography are two examples). Even still, you shouldn't need to rewrite or modify the overwhelming majority of applications written in dynamic languages to move from platform to platform.
Code focused rather than structure focused
Dynamic languages often get a bad rap for being too loosey-goosey about architectural principles. Developers who knock dynamic languages on this basis will often call them "scripting languages," with the implication that the languages are really only suitable for gluing together OS functionality or automating an application via an API.
The truth is dynamic languages simply focus on the code. And while dynamic languages can often support the detailed architecture that C++, Java, and C# are capable of, the languages tend to minimize that aspect of programming. This is not always the case. Perl and PHP, for example, have never been truly object oriented at heart, although both are changing in that direction. Languages like Ruby and JavaScript support the kind of enterprise development styles of architecture, but in standard usage, you don't need to deal with it at all.
Possible issues
In my experience, most developers who experiment with dynamic languages find this de-emphasis on structure to be refreshing. Those who do not usually trip up on the following common problems:
Undisciplined programmers writing sloppy code.
In a dynamic language, some of the "safety net" that static, strongly typed languages have is removed. The programmers are trusted to do what the compiler in other languages enforces. While this allows for rapid code writing, it also enables developers who lack discipline to write code that runs but not correctly.
Built-in shortcuts can reduce readability.
Dynamic languages tend to have a lot of built-in shortcuts. Developers who rely on Perl's "implicit variable" usually produce code that is difficult to understand when other developers read it. Ruby has lots of aliases for functionality; this makes the code feel more logical, but it also requires subsequent readers to have an expanded "vocabulary" to know what each of those aliases do.
Flexibility.
Dynamic languages often allow you to override or remove functionality from even the core language. While this can reap huge rewards, it can be confusing. For example, if someone overrides the "print" function (maybe to include application-specific formatting), developers who are not aware of this could end up pretty confused.
Each bullet point shares a common theme: responsibility of the developers (thanks to Chip Camden for pointing me to this post). To put it simply, these languages make the programmer responsible for doing the right thing, instead of enforcing it at the syntax level. Some might compare it to C/C++, but I don't think it's a good comparison. In C/C++, you don't have a choice but to tread on dangerous ground; it's impossible to write anything in C that does actual work without using a pointer. In dynamic languages, all of the potentially problematic features are squarely in the category of features rather than requirements. As a result, you'll find that these languages tend to not expose you to too much danger before you're ready.
Each bullet point shares a common theme: responsibility of the developers (thanks to Chip Camden for pointing me to this post). To put it simply, these languages make the programmer responsible for doing the right thing, instead of enforcing it at the syntax level. Some might compare it to C/C++, but I don't think it's a good comparison. In C/C++, you don't have a choice but to tread on dangerous ground; it's impossible to write anything in C that does actual work without using a pointer. In dynamic languages, all of the potentially problematic features are squarely in the category of features rather than requirements. As a result, you'll find that these languages tend to not expose you to too much danger before you're ready.
Conclusion
Are dynamic languages right for every developer? Of course not. There are some very real problems with dynamic languages, and some of these problems are inherent to their design. Performance will always be a bit slower than other languages (not to say that they are necessarily slow). IDEs will always have a hard time understanding what many areas of code do simply because the code is non-deterministic until runtime. Along the same lines, many pre-runtime tools (such as static analyzers) will not be able to do the same things with dynamic languages that they can do with static languages.
Despite these points, dynamic languages are a potentially useful tool that more developers should consider using in their work.
J.Ja
Posts
