Re: Scriptometer: measuring the ease of SOP (Script Oriented Programming) of programming languages

[Ken Anderson <address@hidden>]

I like your ideas, and that this is a good topic for a LL2 talk!
I'd just like to reply to 2 points.
At 12:43 PM 9/23/2002, Paul Prescod wrote:
>Daniel Weinreb wrote
>...
>Type declarations
>
>There has been discussion in the Python community about adding optional 
>type declarations to the next major version of Python.  Although consensus 
>has not been reached, the proposals being discussed would support all of 
>our type declaration requirements ­ declaring the signature when 
>implementing a method, and selecting which signature you wish to call.
>
>However, once we have syntactic support, the compiler will obviously need 
>to be enhanced to take advantage of the declarations.  Indeed, this is 
>probably the biggest issue preventing Python from moving forward with 
>concrete syntax proposals ­ it is still not clear anyone has the time or 
>inclination to enhance the CPython runtime to take full advantage, so 
>therefore the syntax enhancements would be pointless.  If a commitment 
>from the JPython or Python for .NET projects was made to support these 
>enhancements, it may help accelerate the acceptance of these proposals 
>into the Python language specification.

I've had about 20 years of experience with Lisp, and became quite good at 
using its optional type declarations to squeeze C like performance out of 
it, which unfortunately is harder than it looks.  I'd recommend looking at 
Allegro or CMU-CL's implementation and performance to measure Python 
against.  It will certainly show you the level of compiler support you'll need.

For the past 5 years, i've been using Jscheme (or an ancestor) in my Java 
applications.  Jscheme is at least 70 times slower than Java or Lisp, but 
is still surprising useful.

While i haven't used Jython extensively, I'm impressed by how compact it's 
code is (typically about 2/3 the size of Java), and that it can compile 
Jython classes into Java classes.  This should give reasonable performance 
for most applications.  You can trade a large compiler effort for the 20% 
of the code you need to write in Java.  Another worse-is-better tradeoff, 
but this time, i'm willing to buy it.

>Dynamic language support.
>
>Due to Python's dynamic nature, there are some Python features that are 
>difficult to map into .NET semantics.  A simple example is the ability for 
>a Python object to add attributes at runtime ­ although no declaration or 
>other reference to the attribute can be seen by source code analysis, 
>reference to the attribute will succeed at runtime. Python provides many 
>other ways to change object behaviour at runtime that are not captured by .NET.
>
>To support this capability, the compiler will often emit special symbols 
>or code specific to Python.  At runtime, if these features are found they 
>are used, and thus Python can take advantage of these features. This 
>allows Python code compiled in a separate compilation unit (that is, it 
>exists in a separate assembly) to still provide these dynamic Python 
>semantics when the caller is Python.
>
>This dynamic capability is analogous to IDispatch support in COM ­ the 
>ability for a language to dynamically determine or expose an object model 
>at runtime.  .NET is focussed much more towards compile time determination 
>of these attributes, in a clear drive for speed.  However, the very nature 
>of Python and scripting languages in general is that their users have made 
>a conscious decision to trade execution speed for these runtime features ­ 
>although possibly not as much execution speed as Python for .NET is 
>currently costing them.
>
>It is clear such dynamic features may preclude certain other .NET
>features - for example, the performance penalty associated with allowing 
>dynamically obtained methods to be used as virtual methods may mean they 
>are not supported as virtual.  However, there is still enough utility in 
>the feature overlap that would make this a useful, but optional .NET addition.
>
>It should also be noted that there are many languages with dynamic 
>features comparable to Python.  However, with Python and every other such 
>language needing to invent its own dynamic solution, these languages are 
>not able to share such features, even when it would make sense to be able 
>to do so.  Formalization of these features in .NET would allow multiple 
>dynamic languages to interoperate in a natural manner.

Howie Shrobe once told me to optimize for flexibility.  I think the 
importance of being dynamic increases every day.  An open VM for dynamic 
languages might provide and interesting alternative to the Java VM and 
.Net.  Your comments above and Olin's 
proposal:http://www.ai.mit.edu/~shivers/javaScheme.html suggests how you 
could get a more dynamic VM.

However, why don't we start by using the "popular (gag)" VM's and taking 
the performance hit.  We'll be relatively happy.  In exchange for 
performance  we get a giant number of libraries we can provide convenient 
interfaces too, relatively easily.

Wouldn't it be cool if most Java/.Net applications weren't written in Java/C#?