A Lisper asks, "Am I supposed to like Smalltalk?"

Stéphane Rollandin wrote:
> Ron Teitelbaum wrote:
>> If you really love functions you can have one class and one method do
>> everything!  :)
>
> hmmm... that's a puzzle ?
>
> ok I give up ! what method ?

It's right there on the bottom of page 13 of the Lisp 1.5 manual.

Cheers,
   - Andreas

Dear all,

        I agree with you Colin. I think tht we should think in terms of
technology [see below*]I think that to be worried by number is to think as a
technology evangelizer wich I dont care about. I dont have any intention of
evangelize or convince anybody of anything (even a technology) just because
it is a dogmatic and manipulative thing to do. But I do have intention to
show to everybody the strengths of this technology are more than what it has
been shown to everybody until now. Smalltalk it's much more than a language
and it has a potential to be more than what we saw by now.

        I do think Smalltalk should give a reason strong enough to motivate
all the demotivation a newcomer could have. More than that... That reason
should not be just for that. I could/should exists for several motivations.

[*]
        I can think a reason that could do that: to marry Smalltalk with
assembler. A Smalltalk that makes it's compilations to machine code.

        Imagine a Smalltalk that never will need a JITER because it's cache
is the L1 of the pentium (or other vendor architectures). The peek of the
eficiency in using the CPU hardware by software. Nothing the industry has
seen something near this before. I think Smalltalk are not as far osf this
as other techonogies are.

        Demistify once and for good speed and Smalltalk problem gets so
little that anybody will ever think in that again just because that
technology will have no match. At least not a reasonable one (you allways
could do in assembler everything, but think in making 3DStudio all in
assembler, it's insane).

        I think this technology is feasible with a considerable effort. More
than that I saw a little *proof of concept* of this idea based on a largely
modified squeak image. To give you an idea that limted prototype makes sends
about x54 times than Exuperys do. And please don't get me wrong, I do like
Exupery, but I think we could get a lot longer than that.
       
        Smalltalk will never be small again. A Smalltalk like that will be
the technology of the tecnologies for the software industry. People will
start to talk of IT sice this technology. It will became *a must* and will
be that just for it's owns strenghts, wich the most of them (99.99%) it
already has.

        I wanted to post this because I want to know if anybody has ever
thought about this and if so why it don't became a project. In the other
hand, if is the first time to think in this here, what do you think about
making Squeak to be married with assembler this way and what are the
posibilities of this group to make a project to materialize this?

        best regards,

Sebsatian Sastre

On 17-May-06, at 4:09 PM, Sebastián Sastre wrote:


> I can think a reason that could do that: to marry Smalltalk with
> assembler. A Smalltalk that makes it's compilations to machine code.
That's (indirectly) been done since 1984 or thereabouts. Peter  
Deutsch and Allan Schiffman did the work at PARQ and wrote a very  
famous paper for POPL (L. Peter Deutsch and Allan M. Schiffman,  
"Efficient Implementation of the Smalltalk-80 System", Conference  
Record of the Eleventh Annual ACM Symposium on Principles of  
Programming Languages, January 1984, pp. 297--302)
This was a specialized VM targetted at the 68k architecture and a  
couple of years later it was redone and extended and made portable as  
part of developing ParcPlace's HPS VM. At various times that has run  
(to my knowledge) on 68k, 386/486/pentium/blahblah, PPC, POWER, ARM,  
MIPS under a wide range of OSs. I did the first working ARM version  
in '94.
HPS compiles Smalltalk to bytecodes and then the VM converts those to  
quite well optimised machine code at need; it was a JIT many years  
before the javanauts made the term popular.

Compiling straight to machine code is certainly doable; it simply  
involves a lot more work since you have to develop and optimise and  
debug a *lot* more stuff. For example, you'd have to rewrite the  
compiler, the debugger, the InstructionStream related classes and  
tools, any system that expects to write out methods, etc etc. Send  
enough money and I will arrange it for you. Discussions could start  
at, ooh, One *Million* Euros.

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

With regard to the idea of making tools to edit Smalltalk in large  
chunks, like those dead languages do, one needs to see Smalltalk as a  
huge and (hopefully) elegant library of Haiku rather than a second  
hand bookstore filled with tattered copies of Stephen King effluvia.  
Sure, the King verbiage sells more than Haiku. But which is likely to  
be remembered in a 1000 years time?

The tool/media combination you use has a very notable effect on what  
your write and how; when carving in stone was the only option it was  
important to think carefully how you said it. When many reporters  
used the little epson hx-80 (?) laptop/tablet or the Tandy 100 (?)  
with the dinky 4-8 lines screens they wrote much tighter prose than  
you will see on the prairie like screens of a 17" laptop.

The typical Smalltalk browser is well suited to writing code haiku.  
That encourages reusability by keeping methods small and intelligable  
and responsible for one small job that can be made use of again and  
again. A vast slobbering tract of Kingish code is as much use as a  
chocolate teapot and about as reusable.It might seem like a sweet  
idea to start with but you'll soon realise it degenerates into a  
wishy-washy mess that just gets stuck to everything and leaves a  
nasty stain no matter how you try to wash it off.

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
If you must choose between two evils, pick the one you've never tried  
before.

Andreas,

Ok now it's my turn to byte.  So while I'm sitting here looking up the Lisp
1.5 manual I'm thinking to myself I hope this joke is better then mine.
When I got there this is what I found:

evalquote is defined by using two main functions, called eval and apply.
apply
handles a function and its arguments, while eval handles forms. Each of
these functions
also has another argument that is used as an association list for storing
the values
of bound variables and f unction names.
where
apply [fn;x; a] =
[atom[fn] - [ e q [ f n ; ~ ~ ~ ] - caar[x];
e q [ f n ; ~ ~ ~ ] -- cdar[x];
eq[fn; CONS] -- cons[car[x]; cadr[x]];
e q [ f n ; ~ ~ ~ ~ ] -- atom[car[x]];
eq[fn; EQ] - eq[car[x]; cadr[x]];
T - apply[eval[fn;a];x;a]];
eq[car[fn]; LAMBDA] -- eval[caddr [fn]; pairlis[cadr[fn];x;a]];
eq[car [fn]; LABEL] - apply [caddr [fn]; x; cons [cons[cadr [fn];
c addr [f n]]; a]]]
eval[e;a] = [atom[e] - cdr[assoc[e;a]];
atom[car[e]] -
[eq[car QUOTE] - cadr [el;
eq[car[e]; COND] - evcon[cdr [el; a];
T -- apply[car [el; evlis[cdr [el; a]; a]];
T - apply[car [el; evlis [cdr [el; a]; a]]
pairlis and assoc have been previously defined.
evcon[c; a] = [eval[caar [c]; a] -- eval[cadar [c]; a];
T -- evcon[cdr [c];a]]
and
evlis[m;a] = [null[m] - NIL;
T - cons [eval[car [m];a];evlis[cdr [m];a]]]

So other then an offhanded joke about Elvis I have to admit I don't get it!

:^D

Ron

tim Rowledge wrote: holy crap, Tim. Nice imagery - especially the last paragraph!
And, I learned a new word today:

effluvia
Etymology: Latin /effluvium /act of flowing out, from /effluere/
*1* *:* an invisible emanation; /especially/ *:* an offensive exhalation
or smell
*2* *:* a by-product especially in the form of waste

On 17-May-06, at 4:51 PM, Brad Fuller wrote:

> tim Rowledge wrote:
[snip]
I live to serve. The question is - to whom am I going to serve you?


tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Strange OpCodes: MAW: Make Aggravating Whine

 > I learned a new word today: effluvia...

        Sure, as in "the effluent upper class". Or was it "affluent"... :)


-C

--
Craig Latta
improvisational musical informaticist
www.netjam.org
Smalltalkers do: [:it | All with: Class, (And love: it)]

And, the act of modifying the executing program is done by nothing more
than sending messages to the executing objects in this same program that
started executing thirty years ago.

Which I would argue makes even the concept of "source code" an ambiguous
concept in Smalltalk.

What is Smalltalk source code?

An argument could be made for defining Smalltalk "source code" as a
transcript of the messages sent by the programmer (i.e., the contents of
the changes file).  This wouldn't be a widely accepted definition, but
never-the-less, I believe a good argument could be made for defining it
this way.

Another argument could be made for defining Smalltalk "source code" as
the string (text) result of asking each of the contents of the method
dictionaries of the classes to print themselves.  This would be a more
popularly accepted definition, but why?  Why would this definition be
any more correct than the previous one?

I would argue that there really is no "source code".  At best, you can
ask the system to recreate a sequence of message sends that you hope,
when replayed, with transform the internal state of the executing
program from one known state into another known state that you need and
want.  That's what a file-out is.  It is a synthesized sequence of
message sends, synthesized by the executing Smalltalk system, in a hope
that it can be replayed by yet another Smalltalk system to transform it
into what you want.

Thus, I would argue that Smalltalk really doesn't have source code.  It
has message sends, sent to live objects.  And I like it just fine that
way, thank you.

If you choose to define "source code" as a printed sequential list of
some known subset of message sends that can later be replayed, then you
can argue that Smalltalk has source code.

Nevin

tim Rowledge wrote:

>
> Compiling straight to machine code is certainly doable; it simply  
> involves a lot more work since you have to develop and optimise and  
> debug a *lot* more stuff. For example, you'd have to rewrite the  
> compiler, the debugger, the InstructionStream related classes and  
> tools, any system that expects to write out methods, etc etc. Send  
> enough money and I will arrange it for you. Discussions could start  
> at, ooh, One *Million* Euros.

Doable, but not really a good way to implement Smalltalk.
You'd lose the binary portability and in turn gain a lot of weight,
since bytecodes are so much more compact than machine language.
IIRC, Peter Deutsch stated that dynamic compilation of bytecodes to
machine language is actually faster than paging pre-compiled machine
code into memory.

Cheers,
Hans-Martin

P.S.: Tim certainly knows that, but he'd use every trick he can pull to
get at One Million Euros for doing something Smalltalk-related :-)
P.P.S.: If you have One Million Euros to spend on something
Smalltalk-related, *do* give it to Tim. You won't be disappointed.

Perhaps another way of thinking of "Smalltalk source code is not text", at least in Squeak, is how one can embed links (allowing for more literate programming), color code it and change font face, like a document (before there was html), and even embed audio commentary in the code (or at least links to it) which I think is a greatly under utilized possibility, adding comments and documentation faster than that typing drudgery until transcribed by the more diligent. Longer lasting documentation than a podcast on how to use it. Maybe embedded screencasts or code browser automation for illustration and training would be next. The code can sing and speak Haiku to us more than just figuratively.

Hi!

Hans-Martin Mosner <[hidden email]> wrote:
And so what do you guys think of Exupery? I had the distinct impression
that Exupery is exactly this (a sophisticated machine code compiler for
Smalltalk) - and as long as Exupery can mop the floor with the regular
VM performance wise - then why would it be "not really a good way"?

If the reader don't know what Exupery is then look at the movie or read
the handout:

        http://goran.krampe.se/blog/Squeak/ExuperyTalk2006.rdoc
               

regards, Göran

tim Rowledge puso en su mail :
Several times I dreamed about this, as Sebastian said.
Could be found the VM somewhere ?
PPC version preferible.

About one million of Euros, I send a check as soon I win the "Quini", local
lottery :=)

Edgar



               
____________________________________________________
Esa persona especial te espera en Yahoo! Encuentros.
¡Dejate encontrar!
http://ar.encuentros.yahoo.com/ 

This (smalltalk has no source code)is kind of an interesting aspect involving
(commercial?) institutions. In some work environments there exists the concept
of source code and the manner of QAing source code is to be done in a very
proscriptive manner involving paper. I am not saying that QA can not be done
since smalltalk has been around for quite a while now and commercial vendors of
the language do exist. But doing QA in a manner consistent with the form
expected by such institutions has probably turned more than one ST enthusiast
away from using the language in favor of
fortran|cobol/basic/pascal/modula/c/c++/VB/java-choose according to decade/date
and location (commercial/academic). This fate is probably true of LISP too. It
is ironic, however, spreadsheets get by with little of no QA in this culture.
Yawn :O)

So who cares, why not enjoy ST or LISP or even fortran for the intellectual
leverage it buys you in a given circumstance. It is the 'aha' that we chase and
there is plenty of that still around.

Regards,
Michael Grant


--- Nevin Pratt <[hidden email]> wrote:


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around
http://mail.yahoo.com 

Dear Goran,

        I'd love to see Exupery reach it's objetives and run squeak for
Windows (as I guess other would love to see it in Mac). Is a good project
Squeak have. I'm favorable in all means to the improvements exupery's is
trying to bring. I think is all "profit" for us all.
 
        cheers,

Sebastian

There is no "program" in Smalltalk.

If we want to create(instantiate) aProgram in Smalltalk...
 we must create the class Program and then instantiate it.

IMHO, it is not correct to use the word "program" in smalltalk,
 if we want to talk about an abstract specification that
 instantiates aMachine, we must use "framework".

The use of the word "program" is valid
 in first stages in Smalltalk introductions
 and tutorials.

best,
Ale.


----- Original Message -----
From: "Nevin Pratt" <[hidden email]>
To: "The general-purpose Squeak developers list"
<[hidden email]>
Sent: Wednesday, May 17, 2006 10:15 PM
Subject: Re: A Lisper asks, "Am I supposed to like Smalltalk?"

>Peter Deutsch stated that dynamic compilation of bytecodes to
> machine language is actually faster than paging pre-compiled machine
> code into memory.

Then th eproblem is when to throw it away...
Can anyone give more information on this?
Any statistics or any other valuable information?

Ale.


----- Original Message -----
From: "Hans-Martin Mosner" <[hidden email]>
To: "The general-purpose Squeak developers list"
<[hidden email]>
Sent: Thursday, May 18, 2006 1:17 AM
Subject: Re: Technology of the technologies (WAS: A Lisper asks, "Am I
supposed to like Smalltalk?")

Göran Krampe wrote on Thu, 18 May 2006 10:55:58 +0200
Exupery translates bytecodes to x86 (for now) machine code, so it is
like the alternative Hans-Martin mentioned instead of the solution Tim
said wasn't a good idea.

The SOAR (Smalltalk On A RISC) project at Berkeley did actually
translate directly to machine code and skipped the bytecodes altogether
and one of the lessons learned was that it wasted memory and didn't gain
any speed compared to the dynamic translation alternative. Smalltalk X
also started as a pure translations system (to C rather than directly to
machine code) and later added bytecodes to the mix to make interactive
use faster. Smalltalk MT is, as far as I know, a bytecodeless system.

Sebastián Sastre wrote:
> I think this technology is feasible with a considerable effort. More
> than that I saw a little *proof of concept* of this idea based on a largely
> modified squeak image. To give you an idea that limted prototype makes sends
> about x54 times than Exuperys do. And please don't get me wrong, I do like
> Exupery, but I think we could get a lot longer than that.

The only way I can see that a "limited prototype" could make sends
faster than what Exupery does is by extensively inlining code, and that
is something which future versions of Exupery will have as well (it has
been on the roadmap since the beginning). If you have any more
information about this, I would love to see it.

As we saw in Self, when combined with other optimizations inlining can
actually make sends take a negative number of clock cycles as measured
by benchmarks! Trying to match that with a hardware solution (like the
ones I build) is, obviously, not possible.

-- Jecel

Lic. Edgar J. De Cleene wrote:
It's the VisualWorks VM. I'm running it on a PPC Mac with Debian Linux,
but MacOS is also supported :-)
You can have it with the VisualWorks noncommercial download, however,
the VM source code is not included (as a commercial customer you can
have that, too).

Cheers,
Hans-Martin

Hans-Martin Mosner writes:
 > Doable, but not really a good way to implement Smalltalk.
 > You'd lose the binary portability and in turn gain a lot of weight,
 > since bytecodes are so much more compact than machine language.
 > IIRC, Peter Deutsch stated that dynamic compilation of bytecodes to
 > machine language is actually faster than paging pre-compiled machine
 > code into memory.

Today, I'd suspect that the time to fetch code from main memory will
change the dynamic. It's possible that bytecode is the fastest
technology for code that's not run frequently. If you combine bytecode
execution with aggressively optimised machine code for many programs
we may have the ideal solution. Exupery is designed to provide the
aggressively optimised machine code.

 > P.S.: Tim certainly knows that, but he'd use every trick he can pull to
 > get at One Million Euros for doing something Smalltalk-related :-)
 > P.P.S.: If you have One Million Euros to spend on something
 > Smalltalk-related, *do* give it to Tim. You won't be disappointed.
 >

I could do something interesting with Exupery for a mere 100K Euros or
so. Anything less isn't enough to give up the day job for a year or
so. More money would of course buy more features and a larger
team. ;-)

Bryce