Traits or not Traits that is the question

> Edgar> Any against having the Yoshiki modifications in the
> next Squeak image ?
>
> I do.  It's an trivial unnecessary *incompatibility* being
> introduced in an era when cross-compatibility with Cincom and
> Gemstone would be more useful.
> --
> Randal L. Schwartz - Stonehenge Consulting Services, Inc. -

Ditto!  Gemstone's support of Seaside with a free version makes Squeak a
development platform and Gemstone a serious deployment platform,
compatibility is a serious issue.  Assignment should be :=, like every other
Smalltalk.  If I can't paste code into an email or a blog post without it
displaying wrong, then it's wrong.

Ramon Leon
http://onsmalltalk.com

Hi

Assuming interoperability with Java is your top concern (and not with
existing Smalltalk code):
Wait for Java 1.7:
http://blogs.sun.com/jrose/entry/notes_on_an_architecture_for
Use a MOP instead of wrappers/proxies:
http://dynalang.sourceforge.net/

Compromise, use Java where you can. E.g. use ArrayList and HashMap
instead of OrderedCollection and Dictionary.

Cheers
Philippe

2008/2/6, Paul D. Fernhout <[hidden email]>:

Dan Ingalls wrote:
But wasnt Squeak named before Disney days?

Keith

Ramon Leon a écrit :
> Ditto!  Gemstone's support of Seaside with a free version makes Squeak a
> development platform and Gemstone a serious deployment platform,
> compatibility is a serious issue.  Assignment should be :=, like every other
> Smalltalk.  If I can't paste code into an email or a blog post without it
> displaying wrong, then it's wrong.
>

IMO, there are more chances for exotic unicode to be displayed correctly
in navigators and mail viewers than in regular Squeak or any other
Smalltalk image!

Nicolas

> Ramon Leon
> http://onsmalltalk.com
>
>
>

Philippe-

Thanks for the great links, as well as your previous comments on different
JVM languages.

More JVM languages are here:
  "Programming Languages for the Java Virtual Machine"
  http://www.robert-tolksdorf.de/vmlanguages.html
The Smalltalk-like ones listed are: SmallWorld, SmalltalkJVM, Talks2, and
Bistro. None of them are in active development near as I can see, though
Alexandre has a SmallWorld, variant he linked to. Maybe Talks2 is a going
thing, but it's hard to tell from the web site. I think their demo came
before Dan's:
  http://www.architur.de/deutsch/produkte/talks2/t2_demo.html

In planning going forward, it seems Java is going to support dynamic
languages (like by hiring the JRuby folks). Squeak and other Smalltalks can
either be part of that process or not. As near as I can tell, they are not?

It seems to me that a Smalltalk that runs well on, say, Java 1.5, and
interoperates in some way with the JVM and Java objects (ideally, as
smoothly as Jython does, for a much more dynamic language than Groovy) is a
beginning. After that, one could expect that as the years go by dynamic
language support on the JVM would only get better with new Java versions.

A big issue is how to keep the virtues and values of Squeak and Smalltalk at
the same time it might run on the JVM and interoperate smoothly. Of course,
that entails deciding what those are? Maybe we can't even have them all, but
then we have to prioritize them and see if we need them all, and then decide
if it is worth doing. Like wondering if "become:" is still that important if
you have other ways of changing class lookup (as Alexandre brings up). But
even if compromises are made, for me, the real issue is more am I using
Jython (or whatever other JVM language) or am I using Smalltalk with
Squeak's ideals on the JVM.

By the way, Clojure is a dynamic (lisp-derived) language for the JVM
intended to support dynamic (and functional) programming, and to do so in an
incremental way. Of all the languages I've read about for the JVM, it seems
most Squeak-like in some ways.
  http://clojure.sourceforge.net/
  http://lambda-the-ultimate.org/node/2547
"Clojure is a dynamic programming language that targets the Java Virtual
Machine. It is designed to be a general-purpose language, combining the
approachability and interactive development of a scripting language with an
efficient and robust infrastructure for multithreaded programming. Clojure
is a compiled language - it compiles directly to JVM bytecode, yet remains
completely dynamic. Every feature supported by Clojure is supported at
runtime. Clojure provides easy access to the Java frameworks, with optional
type hints and type inference, to ensure that calls to Java can avoid
reflection. Clojure is a dialect of Lisp, and shares with Lisp the
code-as-data philosophy and a powerful macro system. Clojure is
predominantly a functional programming language, and features a rich set of
immutable, persistent data structures. When mutable state is needed, Clojure
offers a software transactional memory system and reactive Agent system that
ensure clean, correct, multithreaded designs. I hope you find Clojure's
combination of facilities elegant, powerful, practical and fun to use."

I tend to lean towards a Smalltalk on top of Scala/JVM, because I'd rather
write a Smalltalk translator to a type-inferencing functional language with
better exception handling than for Java (less code to output, perhaps easier
to support higher level Smalltalk concepts).

But if I was just going to slap Smalltalk syntax on top of an existing JVM
language, Clojure might be a better choice. At the very least, Clojure is a
great proof of concept that Squeak-on-the-JVM with full interoperability
with Java objects is possible. It goes beyond Jython in support for
Squeak-like dynamic development. See:
  http://clojure.sourceforge.net/features/dynamic.html
"First and foremost, Clojure is dynamic. That means that a Clojure program
is not just something you compile and run, but something with which you can
interact. Clojure is not a language abstraction, but an environment, where
almost all of the language constructs are reified, and thus can be examined
and changed. This leads to a substantially different experience from running
a program, examining its results (or failures) and trying again. In
particular, you can grow your program, with data loaded, adding features,
fixing bugs, testing, in an unbroken stream."

Sounds a lot like the Squeak ideal to me. Yes, some things it misses -- the
self-containedness of Squeak, which both good and bad. Maybe it is simply
that the future of Smalltalk should not be to be self-contained but to be
interoperable, and the benefits will outweigh the losses?

Personally, I was a Java and JVM hater for a long time. I fought against it
for years in favor of Smalltalk (mainly VisualWorks then, but even Squeak)
or later in favor of CPython. I still think Java is an awful language; I
tend to use the terser Jython instead. But, a decade or more later, the JVM
is not that bad. Computers are 1000X more powerful so Swing performs
adequately on most desktops. They have got most of the bugs out of the core
libraries. Multi-threading usually works acceptability if you follow the
guidelines. I still held out because of the "Java Trap" since Sun's Java
wasn't free, but now it (almost) is. The JVM has problems, but so does
everything. :-)

I feel some updated version of the Squeak ideals (like focusing more on
collaborative development than personal development) and related Squeak
applications (even eToys and Croquet) could do quite well running on the JVM
because of the leverage it gives to influence the rest of the world. I used
to think Python could be that vehicle  (before Java was free) but now I see
Python (as Jython) as being just one peer on the JVM, interoperability with
a Squeak/JVM (or whatever it's called).

Still, I can accept that Squeak will loose some of its value as a
top-to-bottom stack., But it's not like the Squeak code or Squeak VMs in C
will vanish. We will just have more choices. There might be some loss of
developers to a Squeak/JVM, but given the potential upside of millions of
Java developers trying Squeak/JVM, I would think ultimately the benefit
would flow both ways as people who like Squeak/JVM start investigating its
origins. Having said that, I am still think gin maybe GNU/Smalltalk would be
a better choice for drawing from for much of the core to avoid licensing
issues. And then Squeak applications (like Croquet or eToys, even the Squeak
debugger, etc.) with whatever licensing could then run on top of that core.

--Paul Fernhout

Philippe Marschall wrote:

Bergel, Alexandre wrote:
> Source code of classes in SmallWorld may be easily extracted. Would be
> easier to do it with Athena however, mainly because I fixed few bugs.

I was thinking of extracting that source, but you need to do a little fancy
stuff for pool dictionaries and such. I did something like that in PataPata
(in Python) where I modified objects to write themselves out as Python
source code which would recreate the original object when run. Actually, I
would be more tempted by the GNU Smalltalk library code than SmallWorld
since I expect it would be more complete (and it is already in source form,
and LGPL licensed I believe, which is not a problem for me, though for
embedded stuff it may get sticky about what that implies if all the
libraries are bundled into some sort of Flash-based distribution).

As I think about it more, I agree. I think Squeak on Java if it is like
Talks2 or Dan's may not really by that much, since Squeak VM already runs on
all the Java platforms. It is when you want to make changes which are
equivalent to changes to the VM, or when you want to include compiled code,
where you see the benefit. For me, one of the biggest advantages is that it
makes it possible to write code almost as fast as C code while still having
it be easily cross platform without #ifdefs and lots of testing. So, even if
it is not interoperable with Java, objects, a Squeak on the JVM is of
interest -- but only if you intend to include fast compiled Java code (for
example, to support numerical operations on matrices -- an issue for me as I
have some code with a 3D turtle).

On this, I think a dictionary (HashMap, whatever) makes sense for
simplifying the compiler and overall system design. It may not be optimal
speedwise. But I'd rather get that to work right first including supporting
dynamic on-the-fly programming  and then worry about optimizing it later.
These sorts of dictionaries work well enough for Jython and Python. I expect
there to be so much overhead anyway, I think the extra loss of not looking
up data by index won't hardly be noticeable. My biggest limit now is just
programmer time.

>> * dictionary of locally overridden methods (for prototype support)
>
> Why?

Well, it isn't really necessarily for Smalltalk. But if lookup code checks
this dictionary first, then any instance could have a local method for any
message. It might also be used to break the whole metaclass circularity
problem, since you can just put class methods in this dictionary for classes
(in fact, with this addition, no object then really *needs* a class to have
behavior). But, I'll agree it isn't plain Smalltalk. And I myself also
question the merits of prototype programming these days.
  http://patapata.sourceforge.net/critique.html
"The biggest issue is that I learned that the seductive idea of prototypes
may not be as powerful as its execution (especially as an add-on to an
existing language). Consider what I wrote to someone else: "I've been
repeatedly confronted with the fact that prototype languages are powerful
and elegant but ultimately, like Forth, end up losing something related to
documenting programmer intent. Documenting intent is one of the most
important part of programming, and that is something that Smalltalk's formal
class structure enforces for most code over Self, just like C's named
variables document intent which gets lost manipulating Forth's data stack.
Plus, it is hard for any great language feature to offset issues like lack
of community or lack of comprehensive libraries." And after at person
suggested you usually need to name things before you can share them, I
replied: "And I agree on the issue of "naming" something in order to share
it. Which gets back to the issue I mentioned of "documenting intent". With
the PataPata system I made for Python, there was a choice point where I
decided that prototypes used by other prototypes as parents needed to be
named (a difference from Self). And I liked that choice. But then, what am I
really gaining over Smalltalk (except not having a class side, which is
nice, but is it worth the extra trouble and confusion?)"
So, this leaves me questioning the whole move to prototypes. That person
also pointed out previous work on "Exemplar based Smalltalk", so that is
something I should look into further, perhaps as a compromise with
Prototypes when I understand such previous work better."

Still, it is possibly a great feature for bootstrapping the system.  :-)

>> * array of Java/JVM objects
>> * array of binary data
>
> What those arrays are for?

Smalltalk typically makes you specify what type of subclass you wont. One
with instance variables as slots. One with an array of binary data. One with
array of pointers. By putting in slots of each of those things, there is no
need to declare this information or worry about transforming such objects.
Every Smalltalk object could then potentially contain binary data or
pointers to Java objects it needed. Again, this is a starting
simplification. Maybe down the road those things might be optimized out.

Well, I'm just trying to be generic here as a first cut. If you look at
Dan's comment in this thread, he specifically mentions not using Java
objects to support become: and enumerating object identities.

>> "Becomes" might be handled by changing the became field to true and then
>> changing the proxy to the new object. After that, the dispatching will
>> work
>> differently and just be passed onto the new object without further
>> processing.
>
> As far as I can tell, most other languages do not provide become. In
> Smalltalk, become is mainly used to do some update in case of changes in
> class definition.

I think it is also used to proxy-object and for some other reasons. You have
an object you want to monitor (by overriding doesNotUnderstand: for example,
to print the messages and then send them onto the proxied object), so you
want all references to the object to become references to the proxy, and for
the proxy to then hold onto the object.

> Why do you want to keep it if this Smalltal on JVM
> will be file-based ?

I'm not sure a JVM Smalltalk would necessarily be file based. Files
(essentially a hierarchical database of text objects) are just options as to
where to get objects or where to store them IMHO. Put objects in a
PostgreSQL database. Put them in RDF files. Put them out over sockets on the
network. Why should I care where the objects go or where they come from
(other than for security reasons)? Still, I'd be tempted to define a way
that images of object memory could be written out as human-readable source
code (which reconstructs the objects in memory when run) like I did with
PataPata, as a way they could be serialized, perhaps with other text-based
representations possible as well (XML, JavaScript-derived, etc.)

Some issues may not be that easy, or even worth the trouble compared to the
benefit. If I had a Smalltalk with Squeak-ish applications over a
GNU/Smalltalk derived core classes, which could inter operate with Java/JVM
objects  as well as Jython (like calling OpenGL or Concord's Molecular
Workbench libraries
  http://mw.concord.org/modeler/index.html
or even just Java or Scala code I might write myself for speed), and if some
exceptions can't be restarted as well as I would like (though still could be
debugged using a JVM-oriented debugger written in Smalltalk), well, that
might still be very nice result. :-) And a result sure to improve as new
versions of the JVM come out with better dynamic language support. :-)

I think I'd rather write Smalltalk->Scala and let the Scala team worry about
optimization. That's the kind of stuff they like to do. :-) But I don't
worry about, say, requiring the Java compiler be present either at the
start, if Smalltalk->Java made more sense. Or using something like Kawa
Scheme (for the JVM) as an included JAR file which has a toolkit to generate
JVM bytecode, and so do Smalltalk->Kawa. See:
  http://www.gnu.org/software/kawa/
"Kawa is: A framework written in Java for implementing high-level and
dynamic languages, compiling them into Java bytecodes. ..."
I could even live with a first cut of Smalltalk->Jython. :-)

Then later more stuff can end up in Smalltalk, like generating JVM bytecodes
directly, and maybe performance would improve if it mattered. Part of using
the JVM compare to Squeak's VM is just a difference in philosophy related to
being polylingual instead of monolingual. Use the best JVM tools and
libraries which exist in whatever languages they are in, then if you want,
port those tools to Smalltalk or invent something new. And, these tools will
probably run well on all JVM-supported platforms, whereas right now with
Squeak, you have to think hard about whether a particular C library you
might write or want to use is going to run on multiple platforms.

Still, I'm not interested in *small* embedded systems these days (I used to
be, and I still have some Forth computers with only a few K memory lying
around .:-) I'm more interested in recent desktops or *big* embedded. So
your needs might differ if, say, bundling in a 2MB JAR file for some
intermediate language like Kawa was problematical, or if there was some
other real-time performance issue. But in practice, most everyone has
gigabytes of disk space and likely-as-not now idle CPU cores, so I'm not too
worried about performance or resources for the kind of things Squeak
currently does (GUI, simulation front-end, lightweight web server),
especially if there is the back door of calling speedy Java or Scala code if
there is some bottleneck.

Things that bother me more than resource constraints are questions like, how
can I have an nice Eclipse-like tool written mainly in a Squeak-ish
Smalltalk which lets me *collaboratively* develop and debug code written in
multiple JVM languages and stored in lots of different ways (files, image,
RDF, SQL databases, WebDAV, SVN, Git, etc.) and running across many cores
and many machines?

For me, that's the development environment and demand I expect in the future.

Squeak is a great answer to the older question of, how do I develop code
dynamically myself when it is all written in one language running on a
single core personal computer in a minimal footprint and with the least
external dependencies?

I guess I'm just asking a very different question here. But at the same
time, I want to respect and honor the, say, 90% of Squeak ideals which still
apply when "the network is the computer", and "the developer is the community".

And these are often ideals (like coding in the debugger) which, frankly,
some non-Smalltalkers have a very hard time getting. :-) See:
  "Debugger use"
http://www.cincomsmalltalk.com/blog/blogView?showComments=true&entry=3237275853
  "When your tools suck..."
http://www.cincomsmalltalk.com/blog/blogView?showComments=true&entry=3370104583

Thanks for all your thoughtful comments.

--Paul Fernhout

At Wed, 06 Feb 2008 08:02:56 -0800,
Randal L. Schwartz wrote:
>
> >>>>> "Edgar" == Edgar J De Cleene <[hidden email]> writes:
>
> Edgar> Any against having the Yoshiki modifications in the next Squeak image ?
>
> I do.  It's an trivial unnecessary *incompatibility* being introduced in an
> era when cross-compatibility with Cincom and Gemstone would be more useful.

  What is your assessment on how this "era" is different from other
eras?

-- Yoshiki

Igor Stasenko wrote:
> Interesting, this subject showing up couple times before my eyes recently.
> What is so precious in being able to interact with java?

I think there are several issues, now that Java is finally "free" as in
freedom (or mostly there anyway).

* Leveraging libraries (typically in Java, but also for other JVM languages).
  "JVM Languages"
  http://www.robert-tolksdorf.de/vmlanguages.html
  "Searching projects gives 15591 results -- for Java"
http://sourceforge.net/search/?type_of_search=soft&type_of_search=soft&words=java

* Leveraging the JVM itself, which is continually improving (hotspot dynamic
code compilation, maybe eventually support for multiple cores). The Squeak
VM is simpler and so less likely to break than the JVM, but the JVM
undoubtedly  has much more testing, especially in mission-critical situations.

* Writing your own *cross-platform* fast code in a statically typed JVM
language (Java, Scala, others) which is close to the speed of C, but without
most of the #ifdef and memory management and multi-platform testing
headaches of C.

* Being able to leverage all those Java developers out there who learned
Java (often in school) so they can play a part in free software projects
which are much more dynamic and Squeak-ish -- so, say, they write the 3D
library,
  http://jcrpg.blogspot.com/2007/09/what-is-jcrpg.html
and you write the Squeak-ish application that uses it (perhaps the AI? Or
level-creator tools?).

* Being able to do paid consulting which has to be done on the JVM and
working with Java libraries, where you could possibly bring in Jython or
another JVM language (even a Smalltalk) through the front door in a small
innocent-looking JAR (arguing productivity, and that it's basically
Java/JVM-ish, and it is anyway just a small part of a whole easily replaced
in Java if ultimately necessary, etc.), when you could not possibly float
the entire Squeak Smalltalk balloon over a corporate IT fortress' walls
without that independent balloon being seen as a threat and shot down by
flaming arrows. :-)

There are probably more reasons I have not thought of. There are downsides
of course too, because the whole internal dispatching system gets more
complex compared to Squeak, debugging may get harder sometimes in mixed
systems, and you may hit brick walls sooner (instead of Squeak all the way
down you hit a JAR), etc.

The issue of easily supporting both commercial use and free use is probably
the biggest reason why I use Jython over Squeak. :-) A JVM language lets me
potentially live more easily in both worlds -- paid consulting and free
software. Squeak pretty much forces me to choose to develop on a free
software skillset. Even when I am not doing paid consulting, that issue
still is always in the background when I learn new tools. The two
possibilities build on each other in a synergistic way. As much as I believe
the future will entail mostly a gift economy based on abundance for all,
  http://www.whywork.org/rethinking/whywork/abolition.html
including StarTrek-like self-replicating 3D printers powered by dynamic
languages like Squeak interpreting free 3D designs, :-)
  http://www.reprap.org/
  http://fabathome.org/
  http://www.ennex.com/~fabbers/
that future seems still at least ten years off for most people (my family
included. :-)  Until then, earning ration units (dollars, euros, whatever)
for exchange is important, and JVM-based technologies seem more likely to do
that for most programmers than Squeak IMHO, as neat as Squeak is on its own
terms.

Until that Star Trek future of abundance for all arrives, we have to worry
about mundane things like getting decent software tools into the enterprise
and approved by often indifferent and conservative management. Here is how
it is claimed such managers usually think:
  "Revenge of the Nerds"
  http://www.paulgraham.com/icad.html
"As long as [your manager] considers all languages equivalent, all he has to
do is choose the one that seems to have the most momentum, and since that is
more a question of fashion than technology, even he can probably get the
right answer. But if languages vary, he suddenly has to solve two
simultaneous equations, trying to find an optimal balance between two things
he knows nothing about: the relative suitability of the twenty or so leading
languages for the problem he needs to solve, and the odds of finding
programmers, libraries, etc. for each. If that's what's on the other side of
the door, it is no surprise that the pointy-haired boss doesn't want to open
it."

Maybe Squeak is the best tool sometimes, but at least Smalltalk on the JVM,
like Jython, would be in the middle somewhere there between Squeak and Java,
and in the middle is where a lot of developer live -- a little flexibility
to make their own choices, a little understanding by the boss, a little free
time, and a few projects where no one will argue the language matters much
as long as it smells like Java. :-)

Java and the JVM are already in the enterprise. Add-ons to Java have an
easier time getting through the corporate wall, since corporations are used
to buying or making libraries (and that is all, say, Jython is, a Java
library, when you think about it). Few of us are lucky enough to be among
the few dozens (hundreds?) of people employed using the Squeak VM or working
at similar forward thinking organizations who to a high degree emphasize
productivity over conformity. But hundreds of thousands of people already
make their livings doing stuff on top of the JVM, and a lot of those Java
shops are finally hungry for something better than Java which they can
switch to incrementally, whether Scala or JRuby or Qj4J or Javascript or
Jython. This is true even if they forget that Smalltalkers told them ten
years ago that Java was an inferior language to Smalltalk, and that the JVM
(then) was slow and buggy, and the fact that Java would not be half of what
it is today if it were not built on Smalltalk-derived technologies (like
Swing and Hotspot compiling). The problem is that Squeak (or a derivative)
isn't on that short list of great JVM languages today, and even Dan's
Squeak-on-the-JVM probably won't be enough if it is not oriented around
interoperating (including supporting both funky Morphic GUIs and
straight-forward Swing ones). It may already be too late to get on that
list, but one can hope. :-)
  http://stuffthathappens.com/blog/2008/01/02/scala-will-do/

While Smalltalk on the JVM will likely never have the easy acceptance of,
say, Jython (since Jython looks a lot like Java, being C-like), a
Smalltalk/JVM would likely still find easier acceptance in enterprise
projects than a stand-alone Squeak system where Java is already one of two
major standards (the other being dotnet, which isn't "free" IMHO even if
mono exists, given the threat of software patents or "embrace-and-extend").

Also, to the the extent a Squeak/JVM leverages Java libraries like Swing or
statistics libraries or whatever else, that is all time when programmers are
learning other skills commercially valuable (learning to use those libraries
well) -- making it easier to explain and justify that time to others
(whether managers or spouses. :-)

Still, commercial issues aren't the only reasons for Smalltalk on the JVM. I
did list others at the start which are also important to me (libraries,
multi-processing VM with extensive QA etc., fast portable code, and more
potential collaborators on free software). But commercial reasons have
played a strong consideration in past choices of language for me (for good
or bad) and I suspect they also play a big role for many others.

--Paul Fernhout

On Feb 6, 2008 1:35 PM, nicolas cellier <[hidden email]> wrote:

I have written this to the list before, but unfortunately, I never got around to implementing it.

Is it so hard to use := when storing the code, and just modify the display to render arrows? The same thing for the keybinding as well, always write := in, but allow different ways to display it.

--
Duncan.

Interesting, but I feel there is simply a big difference in project risk
between basing new work on a VM like the JVM that has been under development
for ten or fifteen years and has tons of software for it versus basing a
project on alpha software which doesn't do anything that much different. Of
course, people will now feel free to quote that back to me for anything *I*
do (including a Smalltalk/JVM. :-) Which is why new ideas have at best a few
lukewarm friends and many staunch enemies (Machiavelli?).

Also, there are a lot less users and developers for the GNUStep platform
(even if we include Mac OS X developers, although there are slight
differences).  Still, I have on-and-off considered GNUStep. Lots of good
things about it. It never really clicked for me, despite multiple tries over
many years. And even if GNUStep runs on "windows, mac, and linux", I wonder
(from previous reading on it) how *well* it runs on those platforms. So for
me, the JVM still makes a lot more sense. If this Smalltalk/JVM continues to
proceed at a slow pace, then when the software you link to has been around
for a year or two, then I might more strongly consider it. For me, I know a
lot about Java software libraries and that ecosystem (including Jython), but
I know very little about GNUStep libraries. I know the JVM works fairly well
by now even if it still has problems here and there. If I was a GNUStep
developer, with a good knowledge of GNUStep libraries, then maybe I'd want
to invest my time in that direction. Same if I was a mono developer.

Ideally, a future Squeak might evolve to such a high level of abstraction
that it could retarget itself for multiple such platforms -- jvm, mono,
GNUstep, Lazarus, plain old GNU/Linux+GTK, or bare to the metal.  But it
sure seems easier at first for me with limited time and resources to just
pick one widely used platform which runs on mac, PC, GNU/Linux (like the
JVM) and leverage it. Of course, then it's not clear if the incremental
value of a more dynamic language like Smalltalk over, say, Jython, is worth
the effort. Still, a lot of new things get made because they are interesting
and fun or for other personal reasons, not that they are always the best
investment. :-)

--Paul Fernhout

Damien Pollet wrote:

For me personally, dotnet is a non-starter because it is not "free" as in
freedom. And mono lies under threat of software patents and possible future
"embrace and extend" divisions. If Java and the JVM were not now free (or
just about) then I would not be as interested in a Smalltalk for the JVM.

Plus, there are dotnet Smalltalks. I hadn't know about the DLR:
  http://en.wikipedia.org/wiki/Dynamic_Language_Runtime
thanks for the mention.

--Paul Fernhout

Ignacio Vivona wrote:
> Talking about running squeak on others VM, what about the CLR and the new
> DLR?

On 07/02/2008, Paul D. Fernhout <[hidden email]> wrote:
> Igor Stasenko wrote:
> > Interesting, this subject showing up couple times before my eyes recently.
> > What is so precious in being able to interact with java?
>
> I think there are several issues, now that Java is finally "free" as in
> freedom (or mostly there anyway).
>

Your arguments take too long to read. Sorry, i don't mean any offense,
but such long posts are beyond my abilities to read.

So, in short, your main argument is to make smalltalk catch the tail
of java monster, making a small niche where smalltalkers can make
money from it.

I'm not a purist and never will say 'please keep distance' or anything
like that.
But what i don't like is, that in 95% cases, using such tool built on
top of JVM, and focused on interoperating with java means, that any
developer who might want to work with it should have bold experience
in both areas - smalltalk and java to be successful.

And, by raising the demands, what skills developer should have to be
able to work with it, you effectively increase training time, and
raise costs of development on such platform.
It's okay , for me, for being paid $1000 for an application which
putting 'Hello word' on screen, after half-year of study of new
platform. But i don't think that there is many people in the world who
will pay me such sum for that :)

--
Best regards,
Igor Stasenko AKA sig.

On 07/02/2008, Paul D. Fernhout <[hidden email]> wrote:
> Interesting, but I feel there is simply a big difference in project risk
> between basing new work on a VM like the JVM that has been under development
> for ten or fifteen years and has tons of software for it versus basing a
> project on alpha software which doesn't do anything that much different. Of
> course, people will now feel free to quote that back to me for anything *I*
> do (including a Smalltalk/JVM. :-) Which is why new ideas have at best a few
> lukewarm friends and many staunch enemies (Machiavelli?).
>

Reminds me a google mail, refusing to send mail with .exe file
attached to it, because it's risky.
Smalltalk have more than 30 years development history, so by taking
your argument, i would say, that developing on java is a bit risky
comparing to smalltalk.

The difference between us, that i try product and make my own opinion
what it's worth, i don't care what people say.
See, many people saying that Windows Vista is groovy, but it having
zero chances to be installed on my desktop. I have an
environmentalistic attitude and don't feel that drawing beautiful
icons/windows worth burning twice more oil on power plant.



--
Best regards,
Igor Stasenko AKA sig.

On Thu, Feb 07, 2008 at 02:32:56AM +0200, Igor Stasenko wrote:
> It's okay , for me, for being paid $1000 for an application which
> putting 'Hello word' on screen, after half-year of study of new
> platform. But i don't think that there is many people in the world who
> will pay me such sum for that :)

Ha! Large companies routinely spend thousands of times that amount on
projects that never get as far as putting 'Hello word' on the screen.
I think that you would be offering them a great bargain ;)

Dave

[hidden email] wrote:
>> Why can't Squeak also be for us lazy people who are
>> used to how the rest of the world does things, instead of sending us off to
>> Python or Ruby or wherever? :-)
>
> First of all, Squeak/Smalltalk is not "how the rest of the world does
> things". If it was then it wouldn't be interesting.

I think that is true, up to a point. Different when it is for the sake of
being clearly better is one thing. Different for being just different or to
be compatible with outdated technology is much more problematical.

Squeak gets much of the hard stuff right (everything is an object, the GUI
is open ended, all the code is right there, the syntax is extensible in
terms of control structures, and so on), but it only gets about, say, 50% of
the easy stuff right IMHO (the GUI, the assign statement, namespaces). The
problem is that missing the easy stuff makes Squeak unusable for most
people. Kind of like a tennis player who can hit back any impossibly hard
shot but half the time flubs the easy ones because their mind is focused on
preparing for the hard things. :-)

> Sure, we can make things better and easier etc,
> and AFAIK we do try all the time.

Ten or more years later, when I still see many of the same problems
(underscore and assign, licensing, fonts, modularity, newbies confused by
the GUI, etc.) I'm not sure I can agree with that, at least as it applies to
the (theoretically) easy stuff. :-) Of course, if Squeak flubs some of the
easy stuff it must be harder than it looks. :-) Why is that?

Consider this:
   "Debugger use"
http://www.cincomsmalltalk.com/blog/blogView?showComments=true&entry=3237275853
"""
Frans Bourma discusses "edit and continue" in development:
    Debugging isn't about searching for forgotten quotes or a ';' at the
wrong spot. It's about a totally different thing. Let's categorize some
types of bugs to make understanding how to fix them a little easier, shall we?
       1. Functionality bugs. These are the ones at the highest abstract
level: in the functionality the software has to provide. An example of this
kind of bug is the ability to execute script in an email in Outlook
(Express) and enable that feature by default.
       2. Algorithmic bugs. These are the ones at the abstract level below
the functionality bugs. An example of this kind of bug is the (now patched)
flaw in Microsoft's TCP/IP stack which marked the TCP/IP packets with
numbers that weren't random enough which then could lead to data exposure
via sniffing. The code was good, the algorithm used was bad.
       3. Algorithm implementation bugs. This is the kind of bug you'll see
when an algorithm is implemented wrong. This type shouldn't be confused with
the next category, however. Algorithm implementation bugs are bugs which
originate in the developers mind when the developer thinks s/he understands
how the algorithm to implement works and starts cranking out code, however
the developer clearly didn't fully understand the algorithm so a piece of
code was written which will not function as expected, although the developer
thinks it does.
       4. Plain old stupidity bugs.. Everyone knows them: forget to update a
counter, add the wrong value to a variable, etc. etc.
"""

Let me continue counting down from 1 and add a 0 and -1 to Frans Bourma's
bugs types list, related to writing software as an free and open source
software community. :-)

=== 0. Community process bugs.

These are ones where useful functionality is developed in the community and
then lost, or where confusing or useless or overly complex functionality is
adopted or not later rejected or refactored when is is not working out
(Traits?). These bugs can happen from lack of communication, lack of person
power, dysfunctional community culture, or as the legacy of historical bad
decisions. Often these problems show up when the core of a community is
unstable for some reason or overall project complexity is untamed, so people
are always fighting fires (often the same fires, repeatedly) instead of
focusing on new and exciting things at the edges (where they don't conflict)
or even just adding fire suppression apparatus and smoke detectors
(regression tests?). Bitrot is a good indicator of this problem.

Personally, I feel the Squeak licensing issue is also an example of this
problem too (and as long as, say, Disney does not sign off on the core, and
they probably never will, is this licensing issue ever really going to be
resolved?) See my comments here:
  "Belling the cat of complexity (License issues)" Jul 2 18:55:05 CEST 2000
http://lists.squeakfoundation.org/pipermail/squeak-dev/2000-July/007879.html
or here:
  "Belling the cat of complexity (License issues)" Mon Jul 3 23:07:01 CEST 2000
http://lists.squeakfoundation.org/pipermail/squeak-dev/2000-July/010097.html
At which point the "pro bono" lawyer wrote:
> I believe this colloquy has more than exceeded the patience and
> tolerance level of our colleagues.  I will respond to this, after
> which I would suggest instead taking this offline.
(I think my email might have got filtered by his company after that, as I
got bounces. :-) How many years has Squeak suffered under an unusual
not-quite-free-or-open-source license? How much trouble has it caused (like
not getting into Debian main or not having Squeak people at conferences)?
And still causes? How much cheaper to the community to have fixed this seven
years ago? Clearly this was a serious community process *bug*. :-) As much
as I can agree with Alan Kay when he says that copyright laws and legal
proceedings don't make much rational sense, why tempt fate? But, this
licensing failure also stems from a *value* related to the Squeak community,
which my next point, stemming from thinking of Squeak as a personal tool (or
small private group tool) instead of a free and open source software
community collaboration tool.

=== -1. Community vision bugs and related priority setting bugs.

These are ones where the ideals and values of the community result in
undesired outcomes, and this typically comes about when they once made sense
but the world has changed. For example, Smalltalk was originally intended as
a personal creativity amplifier back when a 10MB disk pack was a big thing
and PCs cost $100K, but if now "the network is the computer" and "the
community is the developer" then some ideals might need to change. For
instance, the desire for using ":=" instead of a non-standard remapped
underscore for assign flows out of a desire to collaborate more easily with
others using Smalltalk-like languages, but unless collaborative development
is part of the vision, then this relatively easily made changeover isn't a
priority (even after twelve years) and will be resisted by expected
conservative trends by the community.

See for example, my post to the Squeak list on Dec 25 22:10:47 UTC 2006
"Design Principles Behind Smalltalk, Revisited"
http://lists.squeakfoundation.org/pipermail/squeak-dev/2006-December/112306.html
Excerpt on one of several issues I raise:
"So while I think Dan's original goal [of one person being able to
understand and change the whole system] is a nice ideal, in practice it is
not needed in the extreme, since the creativity of a group sharing, say, a
community mailing list, will still move beyond the creativity of any
individual in the group. So, it is *more* important in the internet age to
have techniques for supporting group creativity, including modularity,  than
it is for the system to not have any barriers. That is probably one reason a
system like Python is actually used in practice by more people to do
creative things than Smalltalk. Python makes it easy for many individuals to
do small things. While Python as a language and as an environment in
practice does not scale as well as Smalltalk, the aggregate amount of all
those individuals doing small things overwhelms what any one Smalltalker can
do (or even a small group of them stepping on each others' toes and watching
their contributions suffer from "bit rot")."

Or as I wrote here:
 http://mail.python.org/pipermail/edu-sig/2007-March/007822.html
"There is once again the common criticism leveled at Smalltalk of being
too self-contained. Compare this proposal with one that suggested making
tools that could be used like  telescope or a microscope for relating to
code packages in other languages -- to use them as best possible on
their own terms (or perhaps virtualized internally)."

Those are simply different ideals than Squeak (or Smalltalk in general)
started out with. And they are ideals we are able to have now in part
because of the very *success* of Smalltalk and Dan's and Alan's (and
others') work and ideals over the last few decades, which have allowed us to
grow from working in proprietary isolation to working in a free community.

> Secondly, and don't take this the wrong way - I am all for everyone
> speaking his/her mind on *all* issues - but it is very easy to talk and
> quite a bit different to do the walk. So along that thought - what would
> *you* be prepared to help out with in all this? Because that is what it
> will come down to at the end of the day. :) :)   (extra smileys added)

Fair enough question. And my admittedly perhaps too harsh reply to Keith on
the value of non-developer contributions aside (sorry, Keith), I would not
have raised this specific issue if I had not already put some work into it
and was willing to put some more.

I've already spent several person months trying to make Python more
Squeak-ish (and Self-ish). I'm not happy with the results, though I think it
was a productive experiment. See:
  http://patapata.sourceforge.net/critique.html
Essentially, I've also hit the limits of Python not being designed for
dynamic development (as in, modifying the code while it is running, like in
the debugger). So, I can either improve Python's core if I continue down
that route of making more Squeakish, or I can instead try to bring some of
the flavor of Python (especially modularity) back to an already dynamic
Squeak. Or I can just give up on it and use an existing JVM language
(Jython, Scala, Groovy, Javascript, etc.. :-)

As another experiment over the next year or so, I'd be willing to spend the
same amount of time trying to get a Squeak-like system on the JVM (through
probably drawing from GNU Smalltalk for the core due to licensing issues),
if there was some serious interest in the idea (and maybe a little help in
testing and such by interested parties).

I've put some time into exploring the possibilities (like the original code
snippet I included at the start). And I'm somewhat familiar with JVM
language from using Jython and looking through the internals. For reference:
"Re: Exploring & decompiling jython _pyx0.class files"
http://osdir.com/ml/lang.jython.devel/2005-11/msg00045.html
"Essentially, this is a somewhat inside-out abstraction from the one I am
used to on debugging through something like the Squeak Smalltalk VM (or
other VMs I have written). I was expecting to see the machinery of stepping
through bytecodes here in this function as Java moves into interpreting
Jython and starts running a bytecode interpreter. What is really happening
is that the Java part of the Jython intepreter application is already
running on top of the same bytecode interpreter that it is going to use to
process the compiled Jython source code, as it has previously compiled the
Jython code to Java bytecodes. So, when the source disappears, the JVM is
leaping into this newly created Jython-source-derived bytecode. So I never
see a stepping through bytecodes. Presumably if I used a different sort of
debugger or understood the Eclipse one better, I could see these bytecode
stepping, but there would still be no obviously transition between the Java
based InteractiveInterpreter and supporting code and the Jython code. This
all may seem obvious now, but coming from experience writing or debugging
byte code type VMs, it is not what I expected. But obviously it is a good
way to go, especially for speed, and a big part of Jython's magic. "

I think what I have in mind would not be *Squeak* as you know it (i.e.
Smalltalk to the metal) but it could be done with an eye to running
Squeak-like software (like Croquet or eToys or whatever). It would draw from
ideas similar to Spoon or Athena (minimal core, remote development) or Self
(embedded compiler) in some ways, and I already have a Smalltalk-ish parser
in Jython which could be used for bootstrapping (previously linked in
another post).

I could even perhaps just reuse the PataPata SourceForge site
  http://sourceforge.net/projects/patapata
to get started. PataPata means "touch touch" in Xhosa and was supposed to
relate to supporting open ended, end-user-modifiable software (for
non-experts), especially intended for learner-directed self-education like
eToys or HyperCard or Microworld simulations and so on. The current blurb on
SourceForge is: "PataPata is an experiment to support "learner-directed"
educational constructivism and "multi-user" stigmergic connectivism on the
Java platform, using Jython and other JVM languages. It is inspired by
Squeak, Design Science, Augment, and Sugar." It could always be moved
somewhere else or renamed if it develops some critical mass. That definition
is now a bit more general and JVM oriented than what PataPata started out
with, which was originally more Python-centric.

But it seems like with Dan's announcement a lot of the thunder is gone from
my suggestion. Even if Dan doesn't have as hip a name as "PataPata" yet. :-)

I guess a corollary to Dan's(?) "Just do it and you're done" is maybe "Just
be patient and Dan will probably do it if it's a good idea". :-)

Still, Dan's result (as I understand it, not having seen the latest) doesn't
fix for me some of the worrisome issues of Squeak, which are bugs at levels
#1, #0 and #-1. :-) Talks2, another Squeak-derivative for the JVM, has some
of the same issues. These include licensing of the core, factoring of the
core including namespaces, GUI expectations, Java interoperability, building
the image from source, lack of multi-jvm-programming-language development
tools, and so on (I've mentioned some other issues in other replies).

And to get those right, I think rebuilding from scratch seems to me to be
the way to go. To be clear, by "from scratch" I really mean maybe, say, 75%
of the time importing existing Smalltalk code one bit at a time from
GNU/Smalltalk or Squeak, of course respecting the license and perhaps using
or writing software that helps track that. The missing 25% would probably be
interfacing with Java, including probably using Java's threading and
concurrency model. I don't really know what those percentages would be, of
course,. That's just an initial guesstimate. I could hope imports are closer
to 95% with a little tweaking. The current Squeak relicensing initiative may
be good enough IMHO to allow relicensed Squeak-ish packages (including the
debugger and browser, etc.) to be used safely enough at the edges of a core
mostly brought from GNU/Smalltalk. In that way, working from a good faith
intent not to infringe anything, the downside risk of a claim against
Squeak's copyright is most likely probably having to have someone else
rewrite a class browser or some such tools, something which a community
could do much more easily than if there were extensive legal problems with
the core. (Although I would be relying on GNU/Smalltalk being clean. :-)

That level of effort would probably just be enough to get something to the
point where the community could decide, is this worth using or porting more
Squeak-ish stuff to? Or, in other words, does if feel Squeak-ish enough to
be worth using? Still, I am trying to fix the #0 and #-1 bugs I list above,
by cleaning up the core step-by-step and by broadening the community
orientation of the softwares. Still, Spoon has been worked on for years and
not gotten the attention it deserves IMHO, so I'm not sure this project
would either, if it even got as far as Spoon on the JVM. (For me, spoon
still has the licensing issue. :-) Squeakers are a tough crowd to please,
given what they are used to. But then so am I. :-)

Anyway, that is how I see it. It sill might not be worth doing if people
here don't like the idea or don't see the value in interoperability. Jython
and other JVM languages are pretty nice even if they are not as dynamic as
Squeak, and I've already had success with them.

I can also understand other people have different perceptions of risk vs.
reward and different levels of investment and comfort with Squeak-as-it-is.

--Paul Fernhout

Hi all,

I can't resist a story.  The company I worked for a long time ago, before
they hired me, hired a consulting company and spent over 1/4 million on a
system design.  When I started working I asked what that big ball of paper
was on the shelf.  They said it was a $250,000 basket ball.  (It was just
about the size of a basket ball).  It turned out that after months of work
the company delivered a huge stack of completely useless paper that very
clearly showed they hadn't understood the requirements.  I said so why did
you mash it up into a ball and put it on the shelf.  They said well at least
that was fun, and it cost so much it was a shame to throw it away!

Ron Teitelbaum

Igor Stasenko wrote:
> But what i don't like is, that in 95% cases, using such tool built on
> top of JVM, and focused on interoperating with java means, that any
> developer who might want to work with it should have bold experience
> in both areas - smalltalk and java to be successful.

It depends what the developer want to do. Let's say I build a "HyperCard"
like system on top of it. Consider:
http://www.mactech.com/articles/mactech/Vol.03/03.10/HyperCardProgramming/index.html
"Hypercard appears superficialy as a simple program because most of its
structure and functionality is hidden from the user. There are 5 user levels
within Hypercard. The top most level, and easiest to use, is Browsing. This
allows the user to navigate through Stacks and look at information but not
to add or modify it. The next two levels Typing and Painting allow the user
to add or modify written and graphic information. The last two levels are
Authoring and Scripting. Authoring allows use of the Field and Button tools
and Power Keys (short Cuts). The Scripting level allows full use of the
Hypercard programming language called Hypertalk, and the use of instant
commands called “Blind Typing”."

So, one might be able to do a lot without learning either Smalltalk or Java.
And then one might only need to learn more as one's desires increase to do
more complex tasks. Obviously you are right that one need to learn both
Smalltalk and Java to be *really* successful as a hard-core developer, but
that might only be 1% of the users who need or want to do that.

Certainly in Squeak-as-it-is you can do things with eToys or editing text
without knowing Smalltalk coding.

> And, by raising the demands, what skills developer should have to be
> able to work with it, you effectively increase training time, and
> raise costs of development on such platform.
> It's okay , for me, for being paid $1000 for an application which
> putting 'Hello word' on screen, after half-year of study of new
> platform. But i don't think that there is many people in the world who
> will pay me such sum for that :)

In the corporate world, it's always an issue of investment (and risk) versus
reward. There are a lot of Java programmers out there. If one of them can
spend a few weeks learning a new software library and make valuable results,
then it may be a very good investment. Something like 10% of worldwide IT
budgets are spent on training. IT worldwide is a trillion dollar (US)
industry (most spent on bespoke custom in-house solutions not shrinkwrap
software), so that is like 100 billion dollars (US) annual budget to help
people learn this new system (if it was popular. :-) OK, so maybe only 0.01%
might be spent on learning this new system at first even if it was terrific,
but that would still be US$10 million a year for training in it. At US$100K
per person typical annual costs for a big corporation, that's about one
thousand person months a year in the worldwide IT budget.

But personally, I see this more as a tool for use in education and in my own
personal free projects. But I didn't think it would hurt much to show people
how they might get some financial benefit out of it in theory down the road.
:-) But maybe it could hurt? So, forget about that. There is no commercial
value in it. Forget everything I said about that. It's just fun and useful
for me. :-)

--Paul Fernhout

On 6-Feb-08, at 7:01 PM, Ron Teitelbaum wrote:
> was on the shelf.  They said it was a $250,000 basket ball.  (It was  
> just
I can certainly add at least two, possibly three zeros to the end of  
that sum.

The sad truth is that perhaps 99% of all software projects never  
result in anything useful at the end. I consider myself  
extraordinarily lucky to have worked on some half-a-dozen projects  
that have shipped and sold. I suspect that that is better than most  
can hope for.

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Useful Latin Phrases:- Gramen artificiosum odi = I hate Astroturf.

So, you proposing surrender to Paul's ways and for the rest of your
life keep making things which is then turn into a pile of paper, and
didn't thrown away,  just because it costs too much money to produce?
:)

On 07/02/2008, Ron Teitelbaum <[hidden email]> wrote:

--
Best regards,
Igor Stasenko AKA sig.

On 07/02/2008, Paul D. Fernhout <[hidden email]> wrote:
I don't buy arguments like:
- there are many people doing X, so what are you waiting for? Hurry
up, join them to do X.

Be it Java, C# or any other kind of technology , which success mainly
happens due to marketing and huge investments to develop them.
This is exactly the $250 000 basket ball story for me :)

--
Best regards,
Igor Stasenko AKA sig.