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."

Comments

Superior Edit-Run cycles

[G4from128k]

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.

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.

Re:Superior Edit-Run cycles

[LeonardShelby]

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.

Re:Superior Edit-Run cycles

[Haeleth]

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.

Re:Superior Edit-Run cycles

[angel'o'sphere]

The same is true for Java IDEs like Omnicore.com's CodeGuide.
Most code is kept compiled all the time, and even during running/debugging you can hot swap modified classes.

The current beta version can even execute code forward and backward in the debugger. Step over a bug, step back, change the line and step forward again ...

angel'o'sphere

While this may sound... harsh

[TheRealMindChild]

The reason Interpreted Languages are becoming "Ever so important", is a few reasons:

1) A kid (or adult) with some brains, but little actual low level computer knowledge can come up with an interpreter

2)Computers are now at the point where something interpreted isn't even noticed half of the time (speed wise)

3)To build off of #1, if your interpreter is written in protable C, then your new language is that much more portable

This is the time, more so then ever, that we are going to see more of a division in the term "Programmer". You will have your "Interpreted Language Programmers" or "Scripter", then you will have the lower level monkey's writing the interpreter's to interface with the OS, then possibly, a system level programmer, making the OS do what the OS does.

Sure, its been going like this for a while, but I believe the transition phase is coming to an end

Dynamic typing

[WayneConrad]

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.