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.
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.
Two wrongs don't make a right, but three lefts do.
There are only 10 types of users, those that understand binary and those who don't.
What are the other 8?
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
"When life gives you lemons, don't make lemonade. Make life take the lemons back!" -- Cave Johnson
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.
There's a little book called SICP, or, the Structure and Interpretation of Computer Programs. It covers stuff like writing interpreters, but it's mostly aimed at college freshmen without any previous computer experience, so it doesn't go into any great depth.
It certainly wouldn't cover interpreted languages as deeply as a college senior writing a thesis on interpreted languages would appreciate.
Slashdot is jumping the shark. I'm just driving the boat.
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).
Reviewing the comments made thus far, despite the fact that most are simply trolls honing their skills, it seems to bear pointing out that just because a language is high level, does not mean that it is interpreted. While many high level languages are interpreted, and many interpreted languages are high level, there are many exceptions to the rule.
Common Lisp, which has been mentioned here as the great shining hope for compiled environments is a fairly high level, abstract language. Java is, at its basest level, the jvm, an interpreted, primitive system, although the byte code compiler has made Java increasingly higher level.
Many of the arguments made from one side or another are commentary on the relative merits of high level and low level languages, not a discussion of platform neutrality, execution performance and various methods of using optimization to reduce the penalty of interpreters.
For my two cents on the whole performance issue, an indirect-threaded Forth is in many ways an interpreted language which is very low level and quite fast. It wasn't designed by a pubescent teenager, and Forth images are often smaller than comparable C programs, despite having the interpreter included in the image.
Weapons of Mass Analysis
There is also the paper "The Art of the Interpreter" by the same author (one of the Sussmans) - other papers by Sussman available from http://library.readscheme.org/page1.html. The Art of the Interpreter is all about implementing mini-languages in interpreters. Using Lisp. Making an interpreter in Lisp is easy, since the whole language runtime gives you an interpreter, so you just define your parser and your evaluator...
Posters recognized by their sig,