Why interpreters matter (at least for high level programming languages)

Re:Why interpreters matter (at least for high level programm... by jules on Sunday May 13, 2012 @06:33AM (#3966629)

This only applies to languages of the Ruby/Python/Lua/Javascript/etc type. If you remove a bit of dynamicity for metaprogramming in favor of compile time metaprogramming, then compilation becomes both simple and has huge speedups. As an example, see Lisp/Scheme/Clojure.

[ Parent | on HN ]

Re:Why interpreters matter (at least for high level programm... by pwpwp on Sunday May 13, 2012 @06:59AM (#3966679)

(Common) Lisp has at least as much runtime dynamicity as the scripting languages you mention. It's hard to quantify, but I have the feeling that CL errs even more in favor of dynamicity than e.g. Python and JS.

[ Parent | on HN ]

Re:Why interpreters matter (at least for high level programm... by xyzzyz on Sunday May 13, 2012 @08:56AM (#3966868)

It's hard to quantify, but I have the feeling that CL errs even more in favor of dynamicity than e.g. Python and JS.

Especially if you include non-ANSI stuff like metaobject protocol or environments.

[ Parent | on HN ]

Re:Why interpreters matter (at least for high level programm... by jules on Sunday May 13, 2012 @03:16PM (#3967951)

They do, but in a more compiler friendly way. For example in Python the local variable environment is conceptually a map from strings to values: you can look up and set a variable by string name. Another example is objects. A method in Common Lisp is lexically scoped: its name does not matter. In contrast in languages like Python and Ruby, an object is essentially a map from string method and property names to values.

Metaprogramming in Ruby and Python usually takes advantage of these features to add methods to an object at run-time with a DSL (for example attr_accessor in Ruby, belongs_to in Rails), or to intercept method calls at run-time with method_missing. In contrast in Common Lisp or Scheme you'd write a macro that does the same work at compile time. The code that the compiler sees after macro expansion is much saner from a compiler optimization perspective. It means that you do not need profile guided inlining to get reasonable performance (and my personal opinion is that the code is easier to understand too).

[ Parent | on HN ]