RV: Scripting languages and IDEs (was: If python goes EToys...)

Reenvio esto , dado los últimos mails que se han visto en este foro.
Creo que es un punto de vista mas que interesante.

------ Mensaje reenviado
De: Colin Putney <[hidden email]>
Responder a: The general-purpose Squeak developers list
<[hidden email]>
Fecha: Thu, 24 Aug 2006 03:09:00 -0400
Para: The general-purpose Squeak developers list
<[hidden email]>
Asunto: Scripting languages and IDEs (was: If python goes EToys...)

Well, I got a lot of flack for my "it's not worth it" response to
Markus' original post. Very well, I'll make another attempt to
explain why I think this idea is a lot harder than it sounds. First,
let me define some terms:

IDE - This is a program that allows one to view and manipulate
another program in terms of it's semantic elements, such as classes
and  methods, rather than in terms of the sequence of characters that
will be fed to a parser. IDEs might happen to display text, but they
also provide tools like class browsers, refactoring and other
transformations, auto-completion of identifiers etc, things that
require a higher level model of the program than text. Examples
include various Smalltalk implementations, Eclipse, Visual Studio, IDEA.

Scripting language - a programming language and execution model where
the program is stored as text until it is executed. Immediately prior
to execution, the runtime environment is created, the program's
source code is parsed and executed, and then the runtime environment
is destroyed. This is an important point - the state of the runtime
environment is not preserved when execution terminates, and one
invocation of a program cannot influence future invocations.

Now, one might quibble over my definition of "scripting language."
Fine, I agree that it's not a good general definition of everyday use
of the term. But it's an important feature of languages like Ruby,
Python, Perl, Javascript, and PHP and one that makes IDEs for those
languages particularly hard to write.

Damien Pollet brought up the key issue in designing a Smalltalk-bases
scripting language - should the syntax be declarative or imperative?
(Yeah, that again.)

Imperative syntax gives us a lot of flexibility and power in the
language. A lot of the current fascination with Ruby stems from Java
programmers discovering what can be done with imperative class
definitions. The Ruby pickaxe book explains this well:

 In languages such as C++ and Java, class definitions are processed
at compile time:
 the compiler loads up symbol tables, works out how much storage to
allocate, constructs
 dispatch tables, and does all those other obscure things we'd rather
not think too hard
 about. Ruby is different. In Ruby, class and module definitions are
executable code.
 
Executable definitions is how metaprogramming is done in scripting
languages. Ruby on Rails gets a lot of milage out of this,
essentially by adding class-side methods that can be called from
within these executable class definitions to generate a lot of boring
support code. In Java, we can't modify class definitions at runtime,
and that's why Java folks use so much XML configuration.

Python does this too - http://docs.python.org/ref/class.html. Perl5
is pretty weird, but Perl6 is slated to handle class definition this
way as well. Javascript doesn't have class definitions, but we can
build up pseudoclasses by creating objects and assigning functions to
their properties.

When writing an executable class definition, we have the full power
of the language available. You can create methods inside of
conditionals to tailor the class to it's environment. You can use eval
() to create methods by manipulating strings. You can send messages
to other parts of the system. You can do anything.

I'm making a big deal out of this, because I think it's a really,
really important feature of modern scripting languages.

Declarative syntax, on the other hand, gives us a lot of flexibility
and power in the tools. Java, C++ and C# have declarative class
definitions. This means that IDEs can read in the source code, create
a semantic model of it, manipulate that model in response to user
commands, and write it back out as source code. The source code has a
cannonical represenation as text, so the code that's produced is
similar to the code that was read in, with the textual changes
proportional to the semantic changes that were made in between.

This is really hard to do with scripting languages, because we can't
create the semantic units of the program just by parsing the source
code. You actually have to execute it to fully create the program's
structure. This is problematic to an IDE for many reasons: the
program might take a long time to run, it might have undesirable side
effects (like deleting files), and in the end, there's no way to tell
whether the program structure we end up with is dependent on the
input to the program.

Even if we did have a way to glean the program structure from a
script, there would be no way to write it back out again as source
code. All of the metaprogramming in the script would be undone,
partially evaluated, as it were, and we'd be stuck with whatever
structures were created on that particular invocation of the script.

So, it would appear that we can have either a powerful language, or
powerful tools, but not both at the same time. And looking around,
it's notable that there are no good IDEs for scripting languages, but
none of the languages that have good IDEs lend themselve to
metaprogramming.

There is, of course, one exception. Smalltalk.

With Smalltalk, we have the best of both worlds. A highly dynamic
language where metaprogramming is incredibily easy, and at the same
time, a very powerful IDE. We can do this because we sidestep the
whole issue of declarative vs. imperative syntax by not having any
syntax at all.

In Smalltalk, classes and methods are created by executing Smalltalk
code, just like in scripting languages. That code creates objects
which reflect the semantic elements of the program, just like in the
IDEs for compiled languages. One might say that programs in compiled
languages are primarily state, while programs in scripting languages
are primarily behavior. Smalltalk programs are object-oriented; they
have both state and behavior. The secret ingredient that makes this
work is the image - Smalltalk programs don't have to be represented
as text.

And that's why a Smalltalk-like scripting language wouldn't be
worthwhile. It leaves out the very thing that makes Smalltalk work so
well - the image. It would have to have syntax for creating classes -
either imperatively or declaratively. We'd end up limiting either the
language or the tools, or if we tried hard enough, both. There are
certainly no shortage of languages that have tried to be "Smalltalk,
but with source code in files."

I'd much rather see a Smalltalk that let me create small, headless
images, tens or hundreds of kilobytes in size, with just the little
bits of functionality I need for a particular task. If they had good
libraries for file I/O, processing text on stdin/stdout and executing
other commandline programs, they'd fill the "scripting language"
niche very well. If they could be created and edited by a larger IDE
image, they'd have the Smalltalk tools advantage as well.

I have high hopes for Spoon in this regard. Between shrinking, remote
messaging and Flow, it's already got most of the ingredients. It just
needs to be packaged with a stripped down VM, and integrated into the
host operating system.

Colin


------ Fin del mensaje reenviado



       
       
               
__________________________________________________
Preguntá. Respondé. Descubrí.
Todo lo que querías saber, y lo que ni imaginabas,
está en Yahoo! Respuestas (Beta).
¡Probalo ya!
http://www.yahoo.com.ar/respuestas




correo electrónico a: [hidden email]


correo electrónico a: [hidden email]

 
Enlaces de Yahoo! Grupos

<*> Para visitar el sitio web del grupo, andá a:
    http://ar.groups.yahoo.com/group/squeakRos/

<*> Para cancelar tu suscripción a este grupo, enviá un mensaje a:
    [hidden email]

<*> El uso de Yahoo! Grupos está sujeto a las:
    http://ar.docs.yahoo.com/info/utos.html