Continuing from my last post, here's my take on the broader aspect of static and dynamic languages in the Enterprise Application Development. Some would say this is a moot question and shudder at the thought of using so called 'scripting' languages like Perl, Python and Ruby. But that'd be living the in past, burying your head in the sand. Before you write these languages off for large scale development, consider that sites like Amazon, TicketMaster, Shopping.com use Perl and Google, YouTube are essentially Python shops. Here are the common reasons I hear people give against these languages:
How fast is fast, really? Remember, we're talking about Enterprise Application Development. No matter how fast your middleware performs, you will ALWAYS be limited by the database speed. It simply doesn't make business sense to tweak out every last bit of performance from your middleware language. You're probably trying to solve the wrong problem, if you're stuck optimizing your middleware language performance.
That said, Languages are Perl are actually pretty fast now a days. Decades of hacking into the language implementation has squeezed out almost every bit of performance. Then, consider the trend of porting these 'scripting' languages to Virtual Machines like JVM. The same JVM which makes Java so fast will also host Python and Ruby and no doubt will make them as fast, if not faster.
JVM already performs faster than C++. So, the evolution has fixed 'Java is slow' problem and it'll fix 'Dynamic languages are slow' perception as well.
Too Terse? Of Course!
Why not? Sure, you should not be having golf contests for production code but otherwise, a smaller code footprint leads to smaller maintenance efforts and less bugs. Number of lines of code is directly proportional to number of bugs in the code - one of the first principles of Software Engineering.
I find it amusing that programmers complain about a language being 'too powerful'. Only programmers can get away with such a ridiculous argument. Why wouldn't you use a powerful tool? Why use an inferior tool? Would a carpenter or a plumber ever reject a tool which makes his/her life easier?
If your programmers are complaining about terseness, you need to find real programmers.
No Support of OO?
All the scripting languages mentioned above (except Perl, possibly) are actually Object Oriented from grounds up.
The modern features supported are actually far better than mainstream languages like Java, C# and C++. Yeah, while Java people consider Reflection to be somewhat 'advanced', Perlers and Pythoners have been able to tinker with class definitions at run time for years. Waiting for Closures in Java 7? These have been available for a decade. Mixins? How many Java and C# programmers even know about Mixins?
Lack of IDE
OK, this is where statically typed languages actually win. IDEs like Eclipse, NetBeans and Visual Studio can definitely cause envy for dynamic language programmers. In my opinion, two areas where IDEs excel are keyword completion and debugging. Since Dynamic languages are hard to parse to start with, keyword completion will never be as smart as in C# and Java. However, almost all modern Editors support 'word' completion which probably takes care of 90% of word completion needs. I hear NetBeans support for Ruby is excellent but haven't tried it. For me, personally, Emacs pabbrev mode is more than enough.
As far as debugging goes, again, Netbeans might have great support. For me the ruby-debug package has worked so far, but I definitely see the value in a fully graphical debugger.
Although, far too many programmers (on MSFT platform at least) confuse debugging with logging and forgo logging since they can debug in Visual Studio. It can be a serious and costly mistake not to have logging in your Application. You can't always expect Visual Studio to be installed on production machines. Logging lets you see what was happening when a bug hit the production code.
But then again, Real Programmers use vi/emacs and shell :)
Spaghetti Code?
Let's face it -more often than not spaghetti code is a manifestation of bad design. Bad design can be done in ANY language. In fact, Dynamic languages powerful features many times help you in hiding complex details in well written libraries. Features like AOP and method interception are very easy to implement in Ruby/Perl/Ruby, whereas, in Java, one must resort to low-level compile time hooks. How about catching references to missing methods? How about the language generating code for you for mundane get/set methods dynamically? How about detecting the calling context of a method and doing different things based upon it (Perl's list vs scalar context)? Depending upon your point of view, these features can seem like magic and hence unmaintainable, or, simply brilliant and helpful in reducing code clutter. Although, if you're performing such magic in your library, you should properly document these 'features'.
Reduced code size alone can be a winning factor with these dynamic languages. It means less maintenance and faster time to delivery. Also, dynamic nature of these languages make writing tests easier since it's MUCH easier to mock objects and behaviors and so on. Irrespective of the language, your development time will be much smaller than the maintenance time of the product. It pays to design your software so it's easily maintainable. Wouldn't you rather have fewer lines to code to maintain ?
Nothing is permanent. Wouldn't you pick a language that lets you make changes quickly?
Of course, the downside of picking a powerful tool is, it's difficult to find people who know how to use it effectively and properly. It doesn't help that computer science schools are churning out graduates who have almost no background in functional programming. In the long run, you're still better off hiring smart programmers and spending time and money teaching them these tools which our schools are not.
- Slow
- Too Terse
- No Support for 'modern' OO Software Design Methodology
- Lack of decent IDE
- Too easy to write spaghetti and unreadable code
How fast is fast, really? Remember, we're talking about Enterprise Application Development. No matter how fast your middleware performs, you will ALWAYS be limited by the database speed. It simply doesn't make business sense to tweak out every last bit of performance from your middleware language. You're probably trying to solve the wrong problem, if you're stuck optimizing your middleware language performance.
That said, Languages are Perl are actually pretty fast now a days. Decades of hacking into the language implementation has squeezed out almost every bit of performance. Then, consider the trend of porting these 'scripting' languages to Virtual Machines like JVM. The same JVM which makes Java so fast will also host Python and Ruby and no doubt will make them as fast, if not faster.
JVM already performs faster than C++. So, the evolution has fixed 'Java is slow' problem and it'll fix 'Dynamic languages are slow' perception as well.
Too Terse? Of Course!
Why not? Sure, you should not be having golf contests for production code but otherwise, a smaller code footprint leads to smaller maintenance efforts and less bugs. Number of lines of code is directly proportional to number of bugs in the code - one of the first principles of Software Engineering.
I find it amusing that programmers complain about a language being 'too powerful'. Only programmers can get away with such a ridiculous argument. Why wouldn't you use a powerful tool? Why use an inferior tool? Would a carpenter or a plumber ever reject a tool which makes his/her life easier?
If your programmers are complaining about terseness, you need to find real programmers.
No Support of OO?
All the scripting languages mentioned above (except Perl, possibly) are actually Object Oriented from grounds up.
The modern features supported are actually far better than mainstream languages like Java, C# and C++. Yeah, while Java people consider Reflection to be somewhat 'advanced', Perlers and Pythoners have been able to tinker with class definitions at run time for years. Waiting for Closures in Java 7? These have been available for a decade. Mixins? How many Java and C# programmers even know about Mixins?
Lack of IDE
OK, this is where statically typed languages actually win. IDEs like Eclipse, NetBeans and Visual Studio can definitely cause envy for dynamic language programmers. In my opinion, two areas where IDEs excel are keyword completion and debugging. Since Dynamic languages are hard to parse to start with, keyword completion will never be as smart as in C# and Java. However, almost all modern Editors support 'word' completion which probably takes care of 90% of word completion needs. I hear NetBeans support for Ruby is excellent but haven't tried it. For me, personally, Emacs pabbrev mode is more than enough.
As far as debugging goes, again, Netbeans might have great support. For me the ruby-debug package has worked so far, but I definitely see the value in a fully graphical debugger.
Although, far too many programmers (on MSFT platform at least) confuse debugging with logging and forgo logging since they can debug in Visual Studio. It can be a serious and costly mistake not to have logging in your Application. You can't always expect Visual Studio to be installed on production machines. Logging lets you see what was happening when a bug hit the production code.
But then again, Real Programmers use vi/emacs and shell :)
Spaghetti Code?
Let's face it -more often than not spaghetti code is a manifestation of bad design. Bad design can be done in ANY language. In fact, Dynamic languages powerful features many times help you in hiding complex details in well written libraries. Features like AOP and method interception are very easy to implement in Ruby/Perl/Ruby, whereas, in Java, one must resort to low-level compile time hooks. How about catching references to missing methods? How about the language generating code for you for mundane get/set methods dynamically? How about detecting the calling context of a method and doing different things based upon it (Perl's list vs scalar context)? Depending upon your point of view, these features can seem like magic and hence unmaintainable, or, simply brilliant and helpful in reducing code clutter. Although, if you're performing such magic in your library, you should properly document these 'features'.
Reduced code size alone can be a winning factor with these dynamic languages. It means less maintenance and faster time to delivery. Also, dynamic nature of these languages make writing tests easier since it's MUCH easier to mock objects and behaviors and so on. Irrespective of the language, your development time will be much smaller than the maintenance time of the product. It pays to design your software so it's easily maintainable. Wouldn't you rather have fewer lines to code to maintain ?
Nothing is permanent. Wouldn't you pick a language that lets you make changes quickly?
Of course, the downside of picking a powerful tool is, it's difficult to find people who know how to use it effectively and properly. It doesn't help that computer science schools are churning out graduates who have almost no background in functional programming. In the long run, you're still better off hiring smart programmers and spending time and money teaching them these tools which our schools are not.
No comments:
Post a Comment