Ultra Smalltalk ? Small UltraTalk ?

[Hans-Dieter.Dreier@materna.de]

--ACa3UMNUeyQlzs6YHRMZuFbRcxk8JN74
Content-type: text/plain; charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable


Hi everyone interested in Ultra,

if there still is someone. I'd like to discuss some thoughts I had in the l=
ast few months concerning "The Ultimate Programming Language".
I'm sure, it's not new; other people certainly have come to the same conclu=
sions (or rejected them) in the past. It's new to me, however.

Lurking around in Usenet news groups, my attention was drawn to Smalltalk. =
I had heard of Smalltalk before, back in the 80's.
At that time I regarded at it as "nice, very slow and too huge" and the syn=
tax was somehow strange:
Sort of english, but not quite, with irritating deviations from what I expe=
cted from my C/Fortran/Assembler background.
It was overkill, both for the applications we used to develop at that time =
and for the machines we had.

Well, things have changed: Memory consumption of Smalltalk nowadays is a no=
n-issue, and speed is acceptable although not really fast.

And, more importantly, my view of programming (and that of a lot of other p=
eople as well) has changed since that time.

When I now look at Smalltalk, I'm amazed to see that back in the 70's they =
anticipated so much of modern software development.
I was amazed to see how close their ideas concerning memory management, vir=
tual machine, IDE customizability come to what I want.

And there are a lot of things where their design simply is splendid.
Take the byte code as an example. Compared to Intel machine code, it is muc=
h more compact.
Actually, it's incredibly compact.
They had to do it that way, of course, because Smalltalk images use to be h=
uge and memory was expansive.

Concerning the IDE: They already had an IDE when everyone else was still us=
ing make files & the command line.
(They had mice & GUI when other people only had keyboard and green characte=
r-oriented screens, too).
Customizability still is superior because you got all the sources and you c=
an change it on the fly while it is running.
I would do the layout somewhat different (more like SqlWindows) though, add=
 IntelliSense and try to further "reduce
the IDE to the max".

Another other issue is speed. Speed is not superior in Smalltalk. Just take=
 a look at Squeak.
There should be plenty of opportunity for enhancements. AFAIK it's all inte=
rpreted.

Type checking & DBC are another issue. Smalltalk being strong dynamically t=
yped, my favourite programming error (95%) is:

Foo DoesNotUnderstand: #bar

That's really annoying. At least a constant could be easily checked by the =
compiler whether it #respondsTo: aMessage.
Another opportunity for enhancements.

There is no native DBC support. (I mean not simply assertions, that's easy;
inheritance & automatic enforcement of constraints is the issue).

Although the syntax is almost as simple as it can be (only that of old my A=
genT language was simpler),
there are some small things I would change to make it even simpler.


So, what I'm asking is:

How about everyone take a look at Smalltalk. Then let's discuss whether Sma=
lltalk could be a basis to build on.
We could look for some free implementation or make our own.
It need not neccessarily be compatible, at least not at the binary level.
I would be nice to be able to use existing Smalltalk sorce.
Or we could simply check which ideas are worth stealing. Certainly there ar=
e lots of them.


--

Regards,

Hans-Dieter Dreier
(Hans-Dieter.Dreier@materna.de)=

--ACa3UMNUeyQlzs6YHRMZuFbRcxk8JN74
Content-type: text/plain; charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable

IDENTIFIKATIONSANGABEN:
a16084a.txt IA5 DX-MAIL X.400 User Agent=

--ACa3UMNUeyQlzs6YHRMZuFbRcxk8JN74--