Re: Promoting adoption of Smalltalk and Understanding Its Impact For Scripting Languages

"A SERFer" <[hidden email]> wrote in message news:[hidden email]...
> Panu Viljamaa <[hidden email]> writes:
>
> >Eric Clayberg wrote:
> >
> >> In the Java world that may very well be so. IDEs in the Java world
*are*,
> >> for the most part, fairly weak offerings and can't even come close to
what
> >> is available in the Smalltalk world. Even VA Java which is arguably one
of
> >> the very best Java IDEs is a pale shadow of its Smalltalk counterpart.
> >
> >I found the documents on Frost (another thread) illuminating.  The
> >problem seems to be that Java can't be compiled "a method a time", like
> >Smalltalk. Instead there is the notion of  a Java "program" which needs
> >to be compiled as a whole. A running Java program can't alter classes or
> >add new ones at runtime. This is largely caused by static typing.
>
> Not true.  Using VA Java I can recompile the methods of an active class.

I'm very busy preparing SmallScript. But I've made it a habit to try and
keep up with/follow the threads of c.l.s. discussion periodically.  So, I
thought I would chime in here.

The problem, which I think was being referenced in the previous post, has to
do with reflective capabilities and the execution architecture's object
model support for schema and instance morphing. Dynamic languages and the
closely related problems in adaptive systems and aspect oriented programming
are severly hampered by design restrictions in the JVM and for similar
reasons in the .NET platform.

Restrictions that, IMNSHO, are due to lack of understanding and experience
on the part of designers of static language vm's (execution architecture,
object models, and garbage collectors) with regard to dynamic languages and
their implementation. The impact of such limited architectures has a much
broader impact than just enabling Smalltalk, because almost every scripting
language can be most efficiently implemented using Smalltalk style VM
technology rather than (static language) Java style VM technology.

Back to the original line of discussion:
---------------------------------------
Given a class, which has instances, in a running system. The question
becomes, what operations are allowed upon that class and its instance --
WITHOUT requiring the application/program to be shutdown, have objects be
persisted/pickled, and subsequently restarted and objects be
unpickled/reified.

The set of operations allowed plays a significant role in the nature of the
tools you can build for that architecture. Like hi-productivity interactive
IDE's and applications where debugging and code changes can take place at
any time in the running life of the program.

It also has a fundamental impact on the ability of that architecture to
support todays increasing demand for supporting adaptive applications and
their development based on heterogenous mixes of different (unrelated in
terms or original design) components, frameworks, and technologies. I.e.
applications with complex, rapidly and continuously evolving, systems
composed of different [typically designed in unrelated environments]
components and subsystems that are capable of running 24x7; possibly in a
scaleable distributed/clustered form potentially including the ability to
support piecemeal replication of any or all subsystems.

a) Can a class (which may have instances) change its namespace?

b) Can a class (which may have instances) change its superclass?

c) Can a class (which may have instances) change its interfaces?

d) Can a class (which may have instances) change the order of its field
declarations (named inst variables)?

e) Can a class (which may have instances) change the types of its fields?

f) Can a class (which may have instances) add or remove fields?

g) Can a class (which may have instances) replace/update methods?

h) Can a class (which may have instances) add or remove methods?

i) Can a class (which may have instances) aribitrarily have subclasses added
or removed?

j) Can objects change their class (behavior)?

k) Can objects change their physical memory layout including data (field)
representations? I.e., is it technically possible to convert and instance of
class <A> into an instance of some class <B> while retaining the same object
identity. And, how efficiently can that be done, i.e., does it require a
sweep of the object space or can it be done in a few machine cycles?

l) Can one object exchange its (OOP) identity with another object? [This is
very closely related to, but not exactly the same as (k)].

m) Can all references to a given object (OOP identity) be replaced by
another object?

n) Can the object space be enumerated? (I.e., <SomeClass>
allInstancesDo:...)

o) Does the object model and its corresponding metadata architecture support
schema migration and related versioning issues sufficiently to handle the
90/10 cases automatically within packages/modules/persisted forms? And, can
the 10% case be handled using standard language syntax for the languages
hosted on that object model?

p) Does the overall execution architecture support dynamic typing facilities
and related dynamic dispatching support? If not, how will verifiable code
safety be achieved; and at what performance cost?

q) Does the overal execution architecture provide support (or at least
enable the possibility) for closures, continuations, and tail calls?

There are many other items, but these are all certainly at the top of the
short list. For almost all these questions the answer in the limited world
of static language vm's designs epitomized by Java is NO [there are
exceptions in various proprietary/non-standard JVM's]. Or at best, sort-of
but with significant proviso's and/or possibly with unreliable/non-portable
hacks required.

-- Dave Simmons [www.qks.com / www.smallscript.com]
  "Effectively solving a problem begins with how you express it."

>
> >
> >Therefore Java IDEs will probably always remain 'less incremental' and
> >inferior to Smalltalk IDEs.
> >
> >-Panu
> >
> >
> >