« AdSense: Now Available in Feeds | Main | About InfoCard »
The Continuing March of Dynamic Languages
Oracle announced Zend yesterday, an integration of PHP with their Oracle 10g database. If I were starting a small Web-based business today, I wouldn’t even consider Java. I’d stick with a dynamic language like PHP, Perl, Python, or (gasp) Scheme.
On Scheme, I don’t think it was possible to use it in production Web systems even four years ago without significant work. I think its possible now. Much of what I’ve been playing around with for the last few months has been aimed at determining whether I’d use Scheme for a production Web system and I’m almost there. Right now, I’m playing with integrating dbXml (from Sleepycat) into mzscheme and build a SOAP client library.
Why Scheme? Because I’ve never been a fan of Common LISP, but happen to believe that LISP offers significantly more abstractive power than other programming languages. You may not agree. In fact, if I’m right, I hope you don’t since that gives me a competitive advantage. :-)
Posted by windley on May 19, 2005 3:26 PM
Comment from Coyote Gulch at May 19, 2005 4:29 PM
Phil,
How would you use test driven development with the dynamic languages? Are there testing frameworks equivalent to JUnit? We're doing well with Java and test first. I'd hate to lose the productivity gains and easier maintenance that test first gives my team.
Coyote Gulch
Comment from Phil Windley at May 19, 2005 6:51 PM
There are test driven development packages for Python, Perl, and Scheme. I'd bet there's one for PHP too, but I'm not aware of it. I can't vouche for their completeness vis a vis JUnit.
Notice also, that I said a "new company." If I already had a Java group that was competent and was working, I wouldn't necessarily change it.
I'm convinced, however, that most small programming teams can be more productive not using Java (or C#, C++, etc.) and using dynamic languages.
Comment from Michael at May 19, 2005 8:41 PM
I am not so sure. One law I learnt a long time ago is "compile errors are your friend"... you lose a lot of that with Dynamic Languages.
However, unit testing is even MORE important for dynamic languages, as it services as a verification step that compilation used to (kind of) and more, so maybe it is not so important.
Also keep in mind that dynamic languages are almost always talked about in the context of web applications. java is used for a lot more.
And I have tried, but I just can't understand Lisp !
Comment from Jack Krupansky at May 20, 2005 10:56 AM
I'm a long-time fan of dynamic languages. I designed an implemented my own C/C++-like OOP language (Liana) back in 1991. My goal was to give the semantic power of LISP, SmallTalk, SNOBOL, LOGO, etc., but with the syntactic simplicity, friendliness, and familiarity of C (and C++), and to do a very easy to use Windows class library. I published an article on it in the July 1992 C Users Journal. There was a little interest, but it had dissipated by 1993. I implemented an embeddable scripting version (CodeScript) in 1993/1994, but interest in it also waned quickly. By 1995 Java was on the scene, but my efforts had already receded into a now-forgotten history.
I looked at using LISP as a scripting langugage for a CAD package I wanted to develop back in 1989, since AutoCAD had a lot of success with their use of a LISP module for scripting, but the problem is that non-trivial LISP code simply isn't readable by mere mortals. The semantics of LISP are great and the syntax for list-oriented data is great, but the syntax of expressions and even moderately complex logic sucks.
LISP may have a role for prototyping, but not for production use.
I suspect that there might be a resurgence of LISP (or at least languages that support the power of LISP's semantics) in a few years as AI-oriented software agent technology begins to emerge with vigor, but LISP really is a poor choice for run-of-the-mill grunt programmming. You may well have success implementing a solution using LISP, but please have pity on the lowly "maintenance" programmers who will be forced to virtually rewrite all of your handiwork.
-- Jack Krupansky
Comment from Gary at May 20, 2005 11:42 AM
Compile errors are fine, but you can get much the same benefit with perl -c, and there are similar tests for PHP, python, etc. I imagine Scheme has something like that, too.
I have to disgree with the assertion that dynamic languages are "always" used for web apps. That might be true of some of them: only rarely have I seen a non-web use of PHP, for instance. But Perl, python and ruby are used more often for non-web apps than for web sites. See, for instance, mailman, the mailing list manager, which is a python app, or FreeBSD's portupgrade, which is in ruby.
I admit, lisp isn't my favorite language type. But, I also have to admit that there are some uses where it /is/ the best tool for the job.
Comment from Chui Tey at May 24, 2005 2:40 AM
In a web services world, compile errors are the least of your problems. You are effectively dynamically linking against remote libraries which could change its underlying implementation or even break your bindings without notice.
It is much much better to think about regular automated integrated functional test to ensure that a function is still returning the correct value.
My take on the evolution of TDD:
static checks -> unit testing -> runtime integration testing