|
|
|
An Interview with TestNG's Cedric Beust
|
|
Page 3 of 3
Dynamic Languages
Indeed, 1.4 support in TestNG is key for many organizations who don't
have the luxury of using 1.5. You are clearly a forward thinker in the
Java community, so I can't help but ask you, what is your take on Ruby on Rails? What about dynamic languages in general?
I have to admit I've never used Ruby on Rails. I've read a lot about it, though, and I am a big Ruby
fan, so it's not short of having my interest piqued. I just haven't had
any Web project to work on recently that would warrant me getting deep
into it.
I am fascinated by programming languages of all kinds, and dynamic languages are no exception. I tried to get into Python,
but didn't get very far, for many reasons, but mostly because it's a
language that was invented when object-orientation wasn't mainstream
and which has tried to catch up since then without much success.
Ruby is the first "new generation" language that received my
complete attention. Native object-oriented-ness and closures were eye
openers to me, but other clever features such as mix-ins and its sheer
elegance really sucked me in. However, I still miss the comfortable
Java syntax and I am bothered by the fact that I need to relearn all
the libraries from scratch.
More recently, I started getting interested in Groovy,
which can be described as "Ruby with a Java syntax." On paper, Groovy
looks a lot like my ideal language, but there are still implementation
issues that plague its daily use. I am optimistic that these will be
fixed soon.
Having said all that, I believe that there is a bigger problem with
dynamic languages in general, and this problem has been completely
underestimated so far, which probably explains why dynamic languages
are not making fast progress in developer mindshare.
This problem is the lack of IDE support.
Auto-completion in IDE's has become extremely smart these past
years. Refactoring is also a practice that modern developers have
become completely hooked on, and for good reasons.
IDE's for dynamic languages come nowhere close to this level of
functionality, and whenever I program in Ruby or Groovy, having to
leave my IDE of choice is not only hard, it sometimes makes me decide
against using the dynamic language, even if it's a clear winner on
paper.
A lot of veteran developers point out that Smalltalk
showed that it was possible to have such an IDE in a dynamic language,
but they are only partially right. Today's IDE's are doing much more
than anything Smalltalk's environment ever did, so the problem is still
wide open (and maybe impossible to solve).
Here is my plea to dynamic language authors: stop working on the
core of your language and allocate an entire month to implement a
decent plug-in for your IDE of choice. Fail to do this, and your
language will forever stay a niche project.
|
|
