Become a fan of Slashdot on Facebook

 


Forgot your password?
Close
typodupeerror
×
Announcements

International Workshop on Interpreted Languages 31

Posted by michael from the exciting-world-of-interpreted-languages dept.
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."
This discussion has been archived. No new comments can be posted.

International Workshop on Interpreted Languages More

International Workshop on Interpreted Languages

Comments Filter:

  • Superior Edit-Run cycles (Score:5, Insightful)

    by G4from128k ( 686170 ) on Monday February 23, 2004 @01:12PM (#8363181)
    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.
    • 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.

      Indeed. And what's even more, many interpreted language have an excellent interactive mode, which is especially great when learning the language. It's simply fun to type the lines from a tutorial straight after the prompt and see the response (or the SyntaxError ;-)

    • Or you could get the best of both worlds by using a interactive compiled language, e.g. most Common Lisps.

    • Re:Superior Edit-Run cycles (Score:4, Interesting)

      by LeonardShelby ( 576365 ) on Monday February 23, 2004 @02:10PM (#8363935)

      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 (Score:4, Informative)

        by angel'o'sphere ( 80593 ) <{ed.rotnemoo} {ta} {redienhcs.olegna}> on Monday February 23, 2004 @08:14PM (#8368153) Journal
        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
        • ... how do they undo state mutation? Do they keep an undo/redo stack for the heap? eww...

          I always liked smalltalk's code browser that let you modify your methods while the program was running; this lead to some really fast development.

          I'm wondering whether your experience w/ the hot-swap enabled debugger is the same: that most development is done while debugging. You just stub out your methods, start the program, and add code until it's running on your sample input. (then you sit down and refactor) Or do
    • 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 compil
    • You've confused the word "interactive" with "interpreted." Don't feel bad -- it's a common mistake made by freshmen at bad colleges.
  • A few years ago I did an undergraduate thesis on interpreted languages (created my own). At the time there was hardly anything in terms of books or resources on the subject. Everything was geared towards some variant of lexx or yacc, and I eventually ended up producing a crappy version of something that resembled basic.

    Has this changed recently?

    • stupid sig (Score:2, Funny)

      by Anonymous Coward
      There are only 10 types of users, those that understand binary and those who don't.

      What are the other 8?
    • 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.

  • While this may sound... harsh (Score:4, Flamebait)

    by TheRealMindChild ( 743925 ) on Monday February 23, 2004 @01:48PM (#8363636) Homepage Journal
    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

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

      I'd add that, even if you do have a lot of brains, it's both easier and ensures wider use to develop an interpreter if you're trying to introduce a new language. Writing a good compiler is High Art and by no means identical to language design.

      On that note, interpretation also gives a language designer an amount of conceptual freedom by abstracting the architecture. That's why languages wi

      • Re:While this may sound... harsh (Score:2, Informative)

        by Anonymous Coward
        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++.

        Don't you realise that there are native compilers for Lisp? Haven't you noticed that Haskell, most MLs, Eiffel, and myriad other functional languages are all compiled to native code?

        Haven't you looked at the benchmarks that show Common Lisp and

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

        I don't know much about Prolog, so let's look at current popular Common Lisp implementations:

  • Dynamic typing (Score:4, Interesting)

    by WayneConrad ( 312222 ) * <wconradNO@SPAMyagni.com> on Monday February 23, 2004 @02:30PM (#8364189) Homepage

    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.

    • Re:Dynamic typing (Score:1, Insightful)

      by Anonymous Coward
      Don't forget the wonders of lexical closures, something offered by any self respecting interpreted language.

      And also offered by any [inria.fr] self [haskell.org] respecting [lisp.org] compiled [eiffel.com] language [smlnj.org]. Just because C doesn't have 'em doesn't mean nobody else does, you know.
    • > at least the ones I use, are dynamically typed. It's
      > wonderful being free from the yoke of static type checking.

      On the other hand, there is some satisfaction from getting
      a language like Ocaml to compile. That language in particular
      seems almost self-testing.
  • I always liked MUMPS for it's indirection and execute support. Indirection gave the ability to use a variable as a pointer, which is extremely important where real pointers are not available. But my favorite has to be execution. The ability to construct a line (or lines) of code in a variable and then execute it. Instead of coding for every possible variation of handling something I can just build a module that uses rules to construct the code and then turn it loose on a problem!
  • From the article:
    This world of interpreted programming languages, to which also C# and Java belong, is changing

    Thats a somewhat liberal intepretation of the word "interpreted", I would say.

    I think they should just have left off the word "interpreted", or better yet, replaced it with "scripted". Mentioning Java and C# just confuses the issue.

    • Re:Java & .NET interpreted!? (Score:1, Insightful)

      by Anonymous Coward
      It's an academic conference about interpreters; I think java, C# fit in it perfectly. The label scripting does not.

      • 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#

  • Interpreted Does Not Mean High Level (Score:3, Insightful)

    by swdunlop ( 103066 ) <swdunlop AT gmail DOT com> on Tuesday February 24, 2004 @12:23AM (#8370374) Homepage
    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.

Slashdot Top Deals

What is research but a blind date with knowledge? -- Will Harvey

Close