3 ms·
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 metapr
by jules 14y ago
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.
- pwpwp 14y ago(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.
- xyzzyz 14y agoIt'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.
- jules 14y agoThey 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).