Info on Smalltalk DSLs or Metaprogramming...

> Thanks for this list.
>
> Call me stupid, but I can't figure out what to do to "change
> SystemWindow borderWidth to 2".  Can you give me a hint?

Literally, I meant, go there and edit the code, from 4 to 2.  The default
borders are far too fat and make squeak look silly.

> Also, is there a way to get rid of the shading of background
> windows - rather just shade the title bar or something?
>
> Thanks,
> Steve

Not sure what you mean here.

On Aug 31, 2006, at 5:52 AM, Eric Winger wrote:

I use FScript--but mostly I use it as a developer's tool. I haven't  
really figured out how to use it to write code yet (other than  
executing simple things from the workspace). Still, it's great for  
poking around, especially when trying to examine existing apps.

Ambrai looks nice. Of course, it's a beta trial release, and I didn't  
see anything on the site about how much the actual release would cost  
(or if there would be a personal version for open source development).

However, both of these are Mac-only. While I use a mac, often I have  
to write code that can be executed on PCs. That leaves me with  
VisualWorks and Squeak. I like the fact that Squeak is open source.

The biggest UI problem I have is the fact that Squeak's private  
window really mucks with my regular work flow. Typically I use Expose  
a lot--it lets me move effortlessly from window to window (I know, a  
lot of people don't like Expose--my wife can't stand it. But it  
really works for me). I can move between apps very quickly. I can  
also move between all the windows of a single application.

There would be a very big efficiency gain if I could manage my Squeak  
windows the same way I manage my other Mac windows.

I think this can be generalized to all UI interactions. The more the  
UI for Squeak resembles the underlying UI of the host OS, the more  
efficient you can be. You can have a UI that is enhanced above and  
beyond the host OS--as long as it follows the same behaviors as the  
underlying OS, users can leverage their existing knowledge and skills  
while working in Squeak.

-Rich-

On 31-Aug-06, at 4:45 PM, Rich Warren wrote:


There are at least two ways you could achieve this:
a) wxSqueak
b) Ariethfa Ffenestri

wxSqueak uses the wx-whatever libraries as the platform layer and so  
should work on any platform with wx support. Which isn't every  
platform, but quite a few.
Ffenestri (it's Welsh for 'platform windows') provides a relatively  
simple and very low-level interface to ... platform windows. You can/
could open arbitrary host os windows and then draw in them with  
whatever means you like. When developing it we tested with several  
sets of connection to the image but it is essentially a case of you  
get a window object and you bitblt to it.

>
> I think this can be generalized to all UI interactions. The more  
> the UI for Squeak resembles the underlying UI of the host OS, the  
> more efficient you can be. You can have a UI that is enhanced above  
> and beyond the host OS--as long as it follows the same behaviors as  
> the underlying OS, users can leverage their existing knowledge and  
> skills while working in Squeak.
Now that I don't think I can agree with entirely. Yes, for ordinary  
usage using host style is beneficial. For enhanced UI designs I'm  
going to assert (because I'm a big bossy noisy person with no mild  
opinions) that you really need to almost forget whatever your host OS  
does because they are *all* crap. Every one of them. All of them have  
some good points, and all of them have many more bad. Don't get me  
started on menubars. Really. If it were possible to write down the  
most suitable curses about menubars in the original pictograms, the  
baked clay would melt.

Anyway, try wxSqueak if you want a substantially platform-like  
experience and consider Ffenestri if you want to have a chance to  
make something compatible(ish) but to your own taste.


tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Satisfaction Guaranteed: We'll send you another copy if it fails.

Sometimes I forget what it's like to be a newbie, too, but sheesh!  :-)
(pardon me if you're not so new, Stephen, I haven't been reading  
squeak-dev extremely closely)

In case "edit the code" wasn't enough of a hint, here's how I figured  
it out:

- browse to SystemWindow
- with the 'inst var defs...' menu item, find all of the places that  
the 'borderWidth' instance variable is set
- hmm, #borderInitialize looks promising, so browse to it
- see that the initial value is defined by #defaultBorderWidth
- override the implementation of #defaultBorderWidth, and you're done!
- open a browser to test it out

Rats!  It didn't work.  OK, let's debug...

- inspect the result of 'SystemWindow new' in a workspace.  Yep,  
borderWidth didn't change.  Why not?
- highlight the expression again and choose the 'debug it' menu item
- step into the expression and see that the first message sent is  
#hasPrototype.  Sounds suspicious!
- select 'self' in the lower-left debugger pane, and choose 'inst var  
defs...' from the menu to see who defines 'prototype'
- there's a prototype message; let's clear the prototype with:  
'SystemWindow prototype: nil'

Now it will surely work!  But it doesn't.  To make a medium-length  
story short, SystemWindow>>initialize stomps on the value that had  
been properly set by the superclass.

I suppose that this is because I didn't load LookEnhancements first;  
otherwise, the above would probably work.  But I don't care enough to  
try.  BTW, this is in a Croquet image that's basically 3.8 as far as  
Morphic is concerned.

Anyway, I guess I've shown that it's not completely trivial.  Even if  
I had loaded LookEnhancements first, it seems likely that the  
prototype problem would have arisen.  Hopefully someone learned  
something about Squeak debugging.

Cheers,
Josh




On Aug 31, 2006, at 7:33 PM, Ramon Leon wrote:

Wow, I didn't realize I was so unclear, my bad.  First, load
LookEnhancements, then go to SystemWindow, there is an accessor on the class
side called borderWidth, edit it, change it to 4.

On Aug 31, 2006, at 2:45 PM, tim Rowledge wrote:

> Now that I don't think I can agree with entirely. Yes, for ordinary  
> usage using host style is beneficial. For enhanced UI designs I'm  
> going to assert (because I'm a big bossy noisy person with no mild  
> opinions) that you really need to almost forget whatever your host  
> OS does because they are *all* crap. Every one of them. All of them  
> have some good points, and all of them have many more bad. Don't  
> get me started on menubars. Really. If it were possible to write  
> down the most suitable curses about menubars in the original  
> pictograms, the baked clay would melt.

True enough. But at least I've come to terms with the Mac UI. I know  
how to use it efficiently.

So, why should I trade one bad UI (which I happen to know how to use)  
for another (which I don't know how to use). To use both interfaces,  
I'm forced to become proficient in two different systems--and I'm  
forced to mentally jump back and forth between the two systems as I  
work. That just doesn't seem like a good use of anyone's brain-cycles.

I'll check out wxSqueak. I've only heard about it in relation to the  
upcoming 3.9 release, can it run on 3.8 too?

-Rich-

On Aug 31, 2006, at 5:44 AM, Ramon Leon wrote:

> Idea's don't die, Smalltalk's been around 30+ years, it's not going
> anywhere.

Ideas may not die, but communities do. A vibrant community needs a  
constant inflow of new people.

Also, just because something has survived this far doesn't mean it  
will continue to survive into the future.

-Rich-

On Aug 31, 2006, at 6:08 AM, Ramon Leon wrote:

>> As I understand it, the term embedded DSL already refers to
>> DSLs that are created by bending the syntax of an existing
>> language--basically making a new language from building
>> blocks of an old language. The other sort (external DSL) is
>> where you use yaCC or smaCC or something similar to build
>> actual parsers/compilers.
>
> Agreed.

Just to argue with myself, I took another look at the Martin Fowler  
article (http://www.martinfowler.com/bliki/ 
DomainSpecificLanguage.html), where I first saw the embedded/external  
distinction. I thought it was crystal clear--but on reading it again,  
I'm not sure.

Does the embedded/external distinction just capture the no-parser/
parser division? Or is embedded DSL intended to mean something more  
like Paul Graham's Bottom-up programming (http://www.paulgraham.com/ 
progbot.html)? I had always assumed it was the no-parser/parser  
split. But the description is ambiguous. If this technique must be  
given a name, I prefer the name bottom-up programming.

>> I'm still interested in an embedded DSL.
>> However, I'm not convinced that simply altering an existing
>> language so it is closer to the domain should count as a DSL.
>
> That's the very definition of DSL.

I don't like that definition. In my mind, simply moving a language  
closer to the problem domain is just basic software engineering  
(maybe that says a lot about my views on software engineering--and  
probably explains why I like Lisp/Ruby/Smalltalk so much).

Moving closer to the domain is necessary for a DSL, but it isn't  
sufficient.

Having thought about it more, here's the crux of the issue for me. To  
be a DSL it must be (first and foremost) a language in its own right.  
You must be able to distinguish it from the host GPL (general  
programming language). The DSL may not have a name, but it must be  
nameable. You must be able to point to a chunk of code and say, "This  
is written in BlahBlah".

Let's say programming fundamentalists capture me and force me to  
write applications in C. To survive such harsh conditions, I write an  
excellent library, RichBrillanceDSL. Now, I write the rest of the  
application using this library. To me, this doesn't count as a DSL.  
I'm not writing in RichBrillianceDSL, I'm still writing in C using  
RichBrillianceDSL.

On the other hand, if I'm making a Rails web page, and I write an RJS  
template, RJS is a domain specific language. It is clearly separate  
from the Ruby code used in the application's controller. The file has  
its own extension and everything.

To really pick at semantic nits, you shouldn't call bottom-up  
programming a DSL.  Even though it's been highly tuned for a given  
domain, it is still (by definition) a general purpose language. The  
language is still turing complete, and you can still use it to solve  
any general problem (or at least any problem solvable with a GPL).

Of course, I think banishing all turing-complete languages from the  
ranks of DSLs is a bit of an over-reaction (after all, it may be  
possible to misuse an embedded DSL to execute arbitrary code--even if  
that wasn't the original intention), but I do think DSLs need the  
general sense of limited usefulness. A DSL should be highly focused.  
It should only be good at one thing.

The Pragmatic Programmer book has an interesting example:

They recommend creating a mini-language for the sole purpose of  
communicating with the client. Originally, this language will not be  
executable. It is just a simple way for the client to express their  
requirements.

However, once the specifications are in place, you could go the next  
step and turn the specifications into executable code.

That's very different from the bottom-up approach.

-Rich-

Rich Warren puso en su mail :

> The biggest UI problem I have is the fact that Squeak's private
> window really mucks with my regular work flow. Typically I use Expose
> a lot--it lets me move effortlessly from window to window (I know, a
> lot of people don't like Expose--my wife can't stand it. But it
> really works for me). I can move between apps very quickly. I can
> also move between all the windows of a single application.
>
> There would be a very big efficiency gain if I could manage my Squeak
> windows the same way I manage my other Mac windows.
As I say, you could have any UI .
Someone did a Expose like in Squeak, a long ago, but I don't remember who.
Or use John Mac AppleScript hooks for raise real Mac UI elements or use Mac
Services or use Unix under the hood power.

Edgar



       
       
               
__________________________________________________
Preguntá. Respondé. Descubrí.
Todo lo que querías saber, y lo que ni imaginabas,
está en Yahoo! Respuestas (Beta).
¡Probalo ya!
http://www.yahoo.com.ar/respuestas

On Aug 31, 2006, at 11:07 PM, Lic. Edgar J. De Cleene wrote:


While it's true that I can reprogram the Squeak UI however I wish,  
that isn't a trivial process. And it's not really a satisfying answer  
to the problem.

Remember, I'm talking about barriers to entry. Things that might make  
a newbie look at Squeak, but turn away. The user interface (as  
provided) is (for many people) a barrier to entry. Most of us get  
over it, but it's still a barrier.

-Rich-

Rich Warren puso en su mail :

> Remember, I'm talking about barriers to entry. Things that might make
> a newbie look at Squeak, but turn away. The user interface (as
> provided) is (for many people) a barrier to entry. Most of us get
> over it, but it's still a barrier

If things do not change , progress do not happen.

Myself argue against Traits, a long ago, as having Traits cause breaks with
older Squeak and introduce several collateral things , unneeded for normal
projects (IMHO)

My solution is continuing develop SqueakLight, a hand made image what now do
what I wish.

But at the same time , I continue studying, and now try to help the process
leaded by Pavel for in a future have a more modular Squeak what starting
from a unix like console (kernel.image) , could grow to any "app" , loading
what was needed from Web.

You should lobby for a "New Squeak UI" group. Take a look to clever work of
wonder people working on Sophie, and help for things like Rome finish the
travel and could be used by mortals in 3.9 (or 3.10)

Edgar






       
       
               
__________________________________________________
Preguntá. Respondé. Descubrí.
Todo lo que querías saber, y lo que ni imaginabas,
está en Yahoo! Respuestas (Beta).
¡Probalo ya!
http://www.yahoo.com.ar/respuestas

Literate programming (the program as a textbook) looks very interesting,
but it didn't work for me because it is based on a fundamental
misunderstanding: A textbook teaches a stable and well understood subject.
A program is neither. (But it will be interesting to study simon's ref. to
darcs.)


In the early eighties, a colleague and I did a substantial development job
using literate programming. The program itself was a success, but literate
programming was a flop.

We started from a very powerful multimedia authoring tool. We added three
new media: Smalltalk class and method definitions + workspaces.

We could print the document with its embedded code; we could compile the
document and even run tests that were specified in the document. The
project was to develop the OS-like core of a  family of applications.  It
is still alive more than 20 years later.

Literate programming worked beautifully for many months. We wrote a
textbook describing our program, including descriptions of why we did
things in a special way and why some tempting optimizations were very
dangerous. We were doing pair programming and found that we were very
motivated to write down what we were doing while we were doing it. The next
day was too late.

But after more than a hundred pages of literate programming, we found that
we needed to do some refactoring. But that would require a rewrite of
several chapters in our book. We just couldn't do it. The program changes
were fairly small, the book changes substantial. Even the main chapters had
to be rearranged. We ended up with adding appendixes with overrides on
previously written stuff. A total mess. (We even wrote an OOPSLA paper
reporting it: T. Reenskaug and A. L. Skaar. An environment for literate
smalltalk programming. ACM SIGPLAN Notices, 24(10):337--345, October 1989.)

Don Knuth dreamt about a program that was like a textbook. He even wrote
one. But in general, the analogy doesn't hold. A textbook is written over a
well known theme. The substance is stable, the presentation is new. A
program is not stable in this sense; its substance is a moving target. So
the textbook metaphor simply does not apply. Has anybody tried to modify
Knuth's original program?

Cheers
--Trygve


At 10:19 31.08.2006, Klaus wrote:

--

Trygve Reenskaug      mailto: [hidden email]
Morgedalsvn. 5A       http://heim.ifi.uio.no/~trygver
N-0378 Oslo           Tel: (+47) 22 49 57 27
Norway

At 22:11 30.08.2006, Benjamin wrote:
><snip>
>There are three possible responses when someone makes a complaint: you can
>address it, you can argue that it's invalid, or you can attack the
>complainer. I suppose I'm happy that everyone's doing the second rather
>than the third, but I'd rather we were doing the first.
><snip>

Here's an attempt at addressing it:
***********************************
Tests, literate programming, other documentation,... have been suggested.

I have realized that my own coding style doesn't scale to substantial
programs. I use extreme distribution; object structure and object
interaction are implicit in the classes.  I have (almost) never been able
to keep code and documentation in sync.

Adele Goldberg once said: "everything happens somewhere else". Which means
that it may be hard to find what I look for in my code. I am now searching
for a high level coding discipline where important, high-level stuff is
explicit, visible and readable rather than hidden in the details.

In short: A new programming language/discipline/... where readability comes
first, reuse second, efficiency last (for 95% of the program). And less
code doing more.

I believe Smalltalk and Squeak are the way to the future. But we still have
a long way to go.

Cheers
--Trygve





--

Trygve Reenskaug      mailto: [hidden email]
Morgedalsvn. 5A       http://heim.ifi.uio.no/~trygver
N-0378 Oslo           Tel: (+47) 22 49 57 27
Norway

> Does the embedded/external distinction just capture the
> no-parser/ parser division? Or is embedded DSL intended to
> mean something more like Paul Graham's Bottom-up programming
> (http://www.paulgraham.com/ progbot.html)? I had always
> assumed it was the no-parser/parser split. But the
> description is ambiguous. If this technique must be given a
> name, I prefer the name bottom-up programming.

I consider bottom up programming, and embedded DSL's the same thing.

It's not just basic software engineering, because most languages can't be
moved closer to the problem domain.  It's likely you like
Lisp/Ruby/Smalltalk exactly because they can be, but that's why they're
special.  They can be used to build DSL's.  

When I program in Csharp, VB, or Java, I find myself writing a lot of loops,
many of them looking very similar, because these languages offer me no clean
way to stop writing the same loops over and over.  Yet in Lisp, Smalltalk,
or Ruby, you do something a few times, get tired of doing it, extend the
language with a new operator, and program with it.  

If I add a bunch of stuff that makes the language really good at generating
html, say a macro...

(html (:html
    (:head (:title "My Document"))
    (:body (:h1 "My Document")
        (:prin1 (get-universal-time)))))

Or abuse blocks for the same purpose...

SomeObject>>renderContentOn: html
    html
        head: [html title:'My Document'];
        body: [html heading: 'My Document';
                    text: DateAndTime now]

It is most certainly a DSL.  It may also still be valid Lisp or Smalltalk,
and still capable of being used as general programming language, but it's
not being used that way.  I can't do this in most languages.  Most languages
allow you to build libraries and api's, but not DSL's.  I consider them
embedded DSL's because they are still syntactically valid in their native
languages and require no additional parsing.

Agreed, and even with embedded DSL's, you can generally do that.

> Let's say programming fundamentalists capture me and force me
> to write applications in C. To survive such harsh conditions,
> I write an excellent library, RichBrillanceDSL. Now, I write
> the rest of the application using this library. To me, this
> doesn't count as a DSL.  
> I'm not writing in RichBrillianceDSL, I'm still writing in C
> using RichBrillianceDSL.

Because it'll still look like C, a library by definition is not a DSL, you
aren't extending C.  However, if you did it with compiler macro's, I'd say
it was a DSL.

> On the other hand, if I'm making a Rails web page, and I
> write an RJS template, RJS is a domain specific language. It
> is clearly separate from the Ruby code used in the
> application's controller. The file has its own extension and
> everything.

That makes little difference from my point of view, files are orthogonal to
the issue.  But, you point being that the DSL is somehow separate from the
main use of the language, ok, I get that, and in Smalltalk when using a DSL,
they are generally also in separate methods from ordinary Smalltalk code.
So there's a place to point and say "hey, that's written in So and So".

> To really pick at semantic nits, you shouldn't call bottom-up
> programming a DSL.  Even though it's been highly tuned for a
> given domain, it is still (by definition) a general purpose
> language. The language is still Turing complete, and you can
> still use it to solve any general problem (or at least any
> problem solvable with a GPL).

I disagree, as would most Lispers and Smalltalkers I imagine.  Bottom up
programming, where you enhance the language, I think has always been
considered a DSL by those respective communities.

> Of course, I think banishing all Turing-complete languages
> from the ranks of DSLs is a bit of an over-reaction (after
> all, it may be possible to misuse an embedded DSL to execute
> arbitrary code--even if that wasn't the original intention),
> but I do think DSLs need the general sense of limited
> usefulness. A DSL should be highly focused.  
> It should only be good at one thing.

I think how a DSL "is" used, says more about it than how it "could" be used.
Sure, embedded DSL's are still fully capable of doing everything the host
language does, but I don't think that disqualifies them when they aren't
used that way.

As Fowler pointed out, they come from a Unix tradition of "little
languages", they're mostly doing external DSL's, not internal or embedded
DSL's.  It's a different style, but not the only one.

Let me point out two recent literate programming successes -

1. darcs. The (haskell) code and (latex) manual are intermingled and
maintained as a single unit to very good effect. See the manual at
http://darcs.net .

2. ruby. http://www.ruby-doc.org/core and http://www.ruby-doc.org/stdlib 
present current, accessible API docs and also higher level docs with very
little fuss. These are generated from extensive code comments, READMEs,
etc. (Many other languages do this but less effectively.)

Cheers,
-Simon

PS I really like this thread.

On Sep 1, 2006, at 6:16 AM, Ramon Leon wrote:

>> Does the embedded/external distinction just capture the
>> no-parser/ parser division? Or is embedded DSL intended to
>> mean something more like Paul Graham's Bottom-up programming
>> (http://www.paulgraham.com/ progbot.html)? I had always
>> assumed it was the no-parser/parser split. But the
>> description is ambiguous. If this technique must be given a
>> name, I prefer the name bottom-up programming.
>
> I consider bottom up programming, and embedded DSL's the same thing.

A lot of people do. However, I think there's a real benifit in  
distinguishing between  the following:

a) DSL as Bottom-Up Programming using language features
b) DSL as Bottom-up Programming using a full parser (and probably pre-
processor)
c) DSL to interpret external strings using features of the host language
d) DSL to interpret external strings using a full parser.

The ability to process external strings (most often stored in files)  
is not entirely external to the DSL issue since:

a) The techniques used for bottom-up programming and for interpreting  
external strings can be significantly different.

b) bottom-up programming lets developers write code that is cleaner  
and easier to maintain. processing external strings can be used as a  
tool for developers; however, they are often used to allow end users  
to modify an application's behavior without opening and modifying the  
application directly.

Unfortunately, the term DSL seems to be used for all the above (and  
more), which really muddies any discussion. I see a fundamental  
difference (both in technique and in motivation) between bottom-up  
DSLs and interpreter DSLs. I wish common usage of the terms reflected  
that difference.

We may have to agree to disagree. I just don't see this. Or at least,  
I don't see it the same way. The code snippets above are (to my eye)  
still Lisp and Smalltalk respectively.

It is possible to move any language closer to the domain. Admittedly,  
it is easier in some languages than in others. But, moving the  
language closer to the domain is still (to my eye) a basic part of  
software engineering, regardless of the language. It's just a matter  
of degrees.

Take C. There are two reasons we might define a function in C. First,  
we might want to capture and generalize a bit of code so that we can  
reuse it. Second, we might want to capture and label a bit of code to  
make reading the source code easier (even if we only use the function  
once). These are not mutually exclusive. The intersection  
(generalizing a bit of code for reuse AND to make the source easier  
to read) seems to be firmly in the realm of bottom-up programming.

Here's a Java html example (imagine your page is a subclass of an  
html class--you override content() to set the page's content.)

public void content(){

        header( title("My Document));

        body(
                heading("My Document),
                text( currentDateAndTime())
        );
}

This seems as good as the Lisp/Smalltalk examples. Admittedly a C  
implementation would be much messier (we're limited to functions,  
structs, global variables and macros), but it still could be done.

html();

        header();
                title("My Document");
        closeHeader();

        body();
                heading("My Document");
                text(currentDateAndTime();
        closeBody();

closeHtml();


Hmm. That's actually not too bad.

Admittedly, there are very few well written libraries for Java/C/etc.  
But that doesn't mean it can't (or shouldn't) be done.

-Rich-

I'm headed out the door, so I'll respond to the rest later, but..

While I'd consider this an embedded DSL, it's certainly not as good, because
the question arises what can go in a body?   How many args does body take,
nesting function calls like that won't be able to represent the same
hierarchical structure that html can represent, Lisp and Smalltalk can get
around this with anonymous functions, I'm not sure this can.

And this is what you'd have to resort too, and also this actually is how
it's actually done in .Net, open a tag, close a tag, exactly the thing I was
saying made these languages bad at DSL's, they can't represent the semantics
of html with their native syntax, they're missing anonymous functions.
Ruby/Lisp/Smalltalk have a huge advantage here, they could express the html
in a hierarchical fashion, building a nice usable DSL, which I think neither
of these two are.

On Sep 1, 2006, at 1:09 PM, Ramon Leon wrote:

As an example, Body can take a variable number of Tag objects. Java  
methods can be defined to accept variable numbers of parameters, so  
this isn't a problem. Tag objects can also be nested inside other  
tags (allowing us to express complete html hierarchies).  
Alternatively, all tags (including body) could accept any objects--
and internally it calls toString() on the object. This would let you  
pass in a mixture of Tag objects and literal strings.

Given that, I don't see any difference between my nested calls in  
Java and your nested calls in Smalltalk.

While I fully admit that it's easier and cleaner to do bottom-up  
programming in dynamic languages, it is still possible (to some  
degree) to use these techniques in any language.

Any time you create a function, class or whatever, you are bringing  
the language closer to the problem domain. There's no distinguishable  
line between bottom-up programming and simply creating well-
engineered classes and functions. Anyone can look at both ends of the  
spectrum and see that they look different--but that ignores how  
quickly things blur in the middle.

On the other hand, there is a sharp line between interpreted DSLs and  
regular programming. That's one of the reasons I prefer to use the  
term DSL strictly for interpreted DSLs. The term (when used that way)  
has a clear meaning.

-Rich-

STX has a simple script processing client app. as part of their package.
rdoit I think it was called.

Keith

               
___________________________________________________________
The all-new Yahoo! Mail goes wherever you go - free your email address from your Internet provider. http://uk.docs.yahoo.com/nowyoucan.html

Sorry for being away the last few days (work related).  I didn't intend to
throw grenade in and then just leave. :)

To start off I decided to address this point first:

>
>On Aug 30, 2006, at 8:35 AM, Ramon Leon wrote:
>
>I agree that Smalltalk has excellent tools for sifting through the  source
>code. However, this can be a barrier to entry for newcomers.  We need a
>constant supply of new blood, otherwise Smalltalk will  wither and die.
>

Or maybe just tread water when it should be leading the pack.  These
two possibilities are pretty much equivalant in my mind.

>Also, I  hate being isolated from the rest of my desktop. I'm a mac  user.
>I like my mac. I like my mac apps. I wish Smalltalk could be  part of that
>environment. Visual Works gets a few points here. At  least it looks like a
>native interface (Though, the UI doesn't behave  in a consistently native
>manner--which can actually be more annoying  sometimes. And it doesn't run
>on intel macs yet.).
>

You points on the environment look are certainly valid (though I don't mind
it personally).  As far as isolation from the rest of the desktop, let's
look
at how everyone else does it.

In Java, C++, Ruby, Python, et. al. how does one build an application?
1. Determine what your application consists of (or what you think it does)
2. Identify what code has already been written in this area (and hopefully
us
      squeakmap like app to download/install it)
3.  Forevermore remember to import/#include/re/whatever to get the code
     you want visable to your system
4.  Develop the code (glue together the components, try new components, etc)
5.  Package it up and deliver it to the customer.

Now many times you wont identify what you need in step 2, you will see some
*possibilities*.  You may have to try out several of them to see what will
work.
When you change one implimentation for another you have to remember to go
and remove all the references to the previous component.

How does smalltalk do it?  The same as above, just remove step 3.  The cost
is
that step 5 gets more complicated.

Stated another way;  the approach used by other languages is start writing
one
or more files that may use one or more files to build up your application.  
The
smalltalk approach is to build the application from *within* the application
you are writing.  For every new app you write the image *is* effectively
this
new app until you deploy it.  At which point it becomes the next app you
will
wright and so on.

Smalltalk is the only one to get it right IMO.  When someone sets out to
build
a car, airplane, building or whatever they build the peices they need and
make
schematics to describe the different components.  Once a built component is
used in a product it is gone and must be rebuilt for the next product.  Not
so
with digital media.  Once we have the component we have it from then on,
no more component assembly required.  Manufacturing companies have
spent lots of money developing special assembly lines to get as close as
they
can to what we have for free.

Conventional programming languages have this also, but the components
are laying somewhere in a huge garage, you have to go dig all over for them.
In smalltalk you just say "Hammer hitNail" and it is magically in your hand,
unless
you never went and got one in the first place.  But once you get it you have
it.

When you build the smalltalk application you get all your classes working
right,
save the image, then do step 5: remove everything you are not using.  This
seems right to me, it is consistant with the concept of garbage collection:
it
is faster over all to do cleanup all at once instead of every time you
change
something (e.g. removing import statements for components that turned
out not to work for you).  And it can all be done programatically, as
opposed
to the by hand method required with other approaches.  So if something
doesn't get taken out that you thought should have you can go find out why.
More bug protection.

Now, after you deploy the application you start your image up and guess
what,
the application you just deployed is still there.  So now when you make a
new
application it is really simple to refactor the common parts together.  I
did this
with some of my programs in Borland C++ builder.  It worked, but it was much
more complicated then just making a few new classes and doing a little
refactory.

In fact, *every* application that you or anyone else has written is
available in
your image.  Including applications for debugging, playing MPEG's and
everything
else.  But that is ok because these applications will help you build the
next
application you are working on (well, some will help more then others. :)
and it can be automatically removed before you deploy.

If the image feels isolated from the rest of the desktop it is because you
have
never been able to do this before. :)