Slashdot Mirror
International Workshop on Interpreted Languages
Sebastian Bergmann writes "Interpreted programming languages are increasingly gaining importance in both the commercial and scientific world. The 1st International Workshop on Interpreted Languages that will be held during the Net.ObjectDays 2004 conference this fall in Erfurt, Germany takes this into account and will present current developments from the exciting world of interpreted languages. The Call for Papers was recently announced and research papers and industry case studies related to Interpreted Languages can be submitted until April 23rd, 2004."
I've always enjoyed the superior edit-rerun cycle that comes with many interpreted languages. You bang out a few lines of code, hit return and see the results immediately.
You can get close to this with compiled languages that use incremental compilers, like the Eiffel compiler from Eiffel Software. You still have to hit the Compile button (it's an IDE), but it will only compile what it has to. If you've only changed a line or two, the compile step could flash right by. The compiler is even good enough to figure out what has been affected by your change, and only compile those portions (even if they are just at the routine level). All this without a make file, no less.
Then, when you're ready to ship, you compile to native code (the above is more or less interpreted), with full optimizations on, and you're set.
The extra benefit comes when you've got a lot of existing code that may or may not be affected, even in small ways, from your new work. Compiles might take a while in traditional systems, but they don't have to if your compiler is smart enough. All that saved time can add up.
remember Sammy Jankis
I use mostly interpreted languages in my daily work, and have for years now. I love the fast edit/test cycle, but that's not the biggest reason. The biggest reason is that most of them, at least the ones I use, are dynamically typed. It's wonderful being free from the yoke of static type checking. My code talks a more about the problem it's solving and less about how it's solving the problem.
I'm not sure if I'd like dynamic typing if I weren't doing lots of test-first programming, but with strong unit test coverage my tests are doing much more to ensure the reliability of my code than static type checking can possibly do. Static type checking is a weak substitute for real tests, but if you're not doing testing, it's the best test you've got.
Don't forget the wonders of lexical closures, something offered by any self respecting interpreted language. That's another feature that makes code more expressive and less yackity-yackity.
On that note, interpretation also gives a language designer an amount of conceptual freedom by abstracting the architecture. That's why languages with paradigms that don't translate well onto von Neumann-y notions (eg, LISP or Prolog) are interpreted as a rule. Interestingly, some of these concepts can then migrate into compiled languages, for instance the Boost Lambda library for C++.
Compiled languages may be faster for silicon hardware, but interpreted languages are often faster for neural wetware. Given the decreasing cost of silicon and the increasing cost of labor, interpretted langauges should see increase usage for many "small" programming tasks.
So what you really want is the best of both worlds. Modern languages like Haskell or OCaml provide multiple levels of compilation. OCaml, for example, can run in an interactive toplevel loop, or as a fully interpreted script, or compiled to portable bytecode; and when you've finished debugging, you can then compile the final program to a native binary for maximum speed.
I believe you can do similar things with more established languages like Lisp, too. Mistakenly perceiving the choice in programming languages as a choice between C/C++ or Perl/Python/Ruby doesn't do anyone any favours.
This is hair splitting. You could also argue that compiled C code is "interpreted" by the CPU's nanocode. It may be academically true but no one in the field would agree and you would be labeled as an idiot were you to casually refer to C as an interpreted language.
The same is so for Java and .NET languages such as C#. They are not in the same category as interpreted perl or python. You still have to take the extra step to compile programs written in Java or C# before they can be run. Also, Java and C# have support for compile time checking of static typing (which, IMHO, is a good thing).
- CMU CL: natively compiled
- SBCL: natively compiled
- MCL: natively compiled
- OpenMCL: natively compiled
- Xanalys LispWorks: natively compiled
- Allegro Common Lisp: natively compiled
- Corman Common Lisp: natively compiled
- Scieneer Common Lisp: natively compiled
- Embeddable Common Lisp: natively compiled, via GCC
- GNU Common Lisp: natively compiled, via GCC
- GNU CLISP: bytecode compiled
- Armed Bear Lisp: Interpreted, only used as an extension language for an unpopular editor
As for programming constructs introduced by Lisp and other high-level languages, no need to refer to obscure things like the Boost Greenspun^WLambda library. How about garbage collection, recursion, symbolic computing, or conditionals? (Lisp was the first language to have an "if"-like construct, before that it was all FORTRAN-style computed GOTOs)Programming can be fun again. Film at 11.