"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 > > > > > > |
Free forum by Nabble | Edit this page |