Complexity and starting over on the JVM

Paul D. Fernhout pdfernhout at kurtz-fernhout.com
Tue Feb 5 02:51:40 UTC 2008


tim Rowledge wrote:
> It's exactly as hard as turning any other keystroke into any other
> character in the text stream. We could use any key input from cmd-g
> (which IIRC VW used to make the assign some years ago) to alt-_ to
> cmd-alt-ctl-shift-meta2-RMS  - this time to get an assign instead of the
> ascii portrait I mentioned in another thread. Personally I'd map plain
> shift-- (ie underscore) since
> underscores_have_no_place_in_variable_names. Similarly I'd use ordinary
> ^ for return on the keyboard.

OK, yes if you know something *special* and *non-obvious* you can do it.
Great for experts. But why make it the default?

> I really don't care whether source is readable in non-Smalltalk
> applications 

Most of us don't have the luxury yet of living in one system. We have to
deal with multiple common standards (among the uncommon standards). ASCII is
a bottom line standard for almost everyone these days, especially with UTF-8
encompassing it.

Ask yourself this, would there be more Smalltalk jobs for experts if there
were more novice users because a Squeak successor was easier to use and talk
about and ask questions by email for newbies?  And how long does it take to
get to be an expert Smalltalker? Ten years? Twenty? So these new people
would be little threat to current expert Squeakers' livelihoods. Then, let
us conclude, like Deep Thought of Hitchhikers Guide to The Galaxy: "So long
as you can keep disagreeing with each other violently enough and slagging
each other off in the popular press, you can keep yourself on the gravy
train for life." :-)

>  any more than it annoys me that I can't read jpegs as text.

That annoys me. :-)

Try XPM for bitmaps
  http://en.wikipedia.org/wiki/XPM_%28image_format%29

and BDF for fonts. :-)
  http://en.wikipedia.org/wiki/Glyph_Bitmap_Distribution_Format

> The furthest I'd be inclined to go is to use xml as a transfer encoding.

I'll repeat the classic: "You have a problem. You decide to solve it via
XML. Now you have TWO problems." :-)

I'd rather use Smalltalk source to define image files. :-) I did that in
PataPata using Python to define a world of live objects and it was pretty
neat and successful for what it did. Example:
"/tags/PataPata_v204/WorldDandelionGarden.py"
http://patapata.svn.sourceforge.net/viewvc/patapata/tags/PataPata_v204/WorldDandelionGarden.py?revision=315&view=markup

I went a bit to far with properties and prototypes though. And Python kind
of ran out of gas as far as edit-and-continue support.

I think you could get a Smalltalk VM to do this generically rather than via
some methods/functions I needed to add for Python. And to read in an image,
you evaluate the code.

I would suggest such a default format for a JVM Smalltalk. Disk space is
cheap these days. So is bandwidth. Even exponentially CPU power means
loading such images as the default might not be very noticeable, and how
often do people load images? And they could always be cached somehow for the
special case where it did matter. How much bigger would images really get,
especially if they were modular, with one major application per image,
perhaps referencing a shared common world of core objects, and using XPM for
defining bitmaps and BDF for defining fonts. :-)

Why shouldn't your image be a readable Smalltalk program for constructing a
world of objects?

Or to paraphrase another character or two: "Is a binary image format better,
more evolveable, stronger? No! But the binary image is easier, faster,
quicker. Write it as human readable source, Luke!"

--Paul Fernhout



More information about the Squeak-dev mailing list