Info on Smalltalk DSLs or Metaprogramming...

On 8/30/06, J J <[hidden email]> wrote:
> I have it downloaded, what do I do with it?  Unit tests can give me examples
> but that isn't very formal, you know? :)

Yes it is, and IMHO it's even one of the most formal ways to give
examples since they actually run (and if they don't you know who to
blame :)

Granted, it would be better if some tests were actually written with a
documentation intent and categorized as such (e.g. describing the
first layer of the code with realistic scenarios, not debugging or
ensuring very basic functionality actually works).

--
 Damien Pollet
 type less, do more

On 8/31/06, tim Rowledge <[hidden email]> wrote:
> Another old friend of mine has also coined the rather nice idea of
> "program the document, don't document the program" to cover a concept
> of merging doc and code in the tools so that you can write spec,
> explanation, commentary, examples and limitations mixed in with
> executable code.

Sure, literate programming is a nice idea but even if there is the
wonderful example of TeX to support it I'm not sure it's agile enough
in it's current form to be smalltalker-compliant :-)
The 3 big programs written and published in literate style that I can
think of are counter examples IMHO because they were written by one
(or very few) people and are not meant to evolve very much if at all:
TeX and metafont were frozen by D.E.K long ago, and pbrt is published
more as teaching material than as a competitive renderer
(http://pbrt.org).
However I'd really like to be convinced that it can actually work for
fast-moving and widely collaborative projects.

What would a documentation debugger look like ?

> late Jef Raskin's idea of The Humane Interface (see http://
> www.raskincenter.org) and it wouldn't be too awful implemented as a
> nice document editor that has a style for 'source code' that actually
> means source code rather than just using a fixed pitch font. Hmm, now

A mix of a smalltalk browser and a wiki ?

> where might we find a document editor with intimate associations with
> a compiler?

emacs :D

--
 Damien Pollet
 type less, do more

On 8/30/06, tim Rowledge <[hidden email]> wrote:

> where might we find a document editor with intimate associations with
> a compiler?

Sophie!

--
How wonderful it is that nobody need wait a single moment
before starting to improve the world.       -- Anne Frank
Paradise is exactly where you are
right now...only much, much better.    -- Laurie Anderson

Damien Pollet schrieb: A long time ago, when I re-implemented a big chunk of TeX in VisualWorks
to create a WYSIWYG TeX editor (WysiTeX), we tried to do something like
literate programming in Smalltalk. My idea was that a Smalltalk literate
program could not possibly have the form of a linear book, since
Smalltalk programs are essentially not linear, so we tried to create a
hyperlinked documentation (using a collaborative hypertext editor also
written in VisualWorks). I was not really satisfied with the result - it
did not have the close linkage to the code, and I don't think that an
outsider would have been able to grok our code with the help of this doc
bettern than without it.

That said, I still feel that something like that would be needed. Since
working with Objectory a number of years ago, I became enamoured with
the idea of traceability - having explicit links between analysis,
design and code. Objectory was a little too waterfallish, an agile tool
would probably have to look a bit different, but still I think that a
really good development environment should be able to keep all this
information in one place, allowing me to create and follow links, to
store document files, drawings, diagrams as well as runtime, building
and test code in one place, with version history all over the place, too.

I know that such a system would not help me much in writing better
method comments (that's still a matter of discipline which I'm a bit
lacking) but it would probably allow me to create overview documents
which allow others to get into the code much more easily.

Cheers,
Hans-Martin

Hi Hans-Martin,

I am very interested in having code as (integrated) part of a document.  
The following describes minimally what I want from a document+with+code, a  
"... two-phased approach that continuously synchronizes between a data  
modeling view and a view on an object-oriented implementation". There we  
see

- a domain analysis view, represented by a data modeling diagram
- implementation objects, related to OO programs at code-time
- population objects, derived from the former, containing actual data for  
running

Found at
- http://prog.vub.ac.be/progsite/Person.php?rdid=25070

I wouldn't care if this where called literate programming or so, as long  
as round-trip engineering allowed me to put comments anywhere I want :)

/Klaus

On Thu, 31 Aug 2006 07:41:16 +0200, Hans-Martin Mosner <[hidden email]> wrote:

On Aug 30, 2006, at 7:39 AM, Ramon Leon wrote:

>> Part of the problem is different people seem to have
>> different interpretations of what a DSL is. In some
>> definitions, any significantly complicated project becomes a
>> DSL (or at least any well- written project).
>
> This is the definition I think most of us have.  We should be more  
> explicit
> and call them embedded DSL.

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.

Based on these definitions, I have always been talking about creating  
an embedded DSL. Yes, people keep recommending that I create an  
embedded DSL. Yes, this is good advice. Yes, this is what I plan on  
doing. For some reason, I keep getting replies that suggest that I'm  
resisting this advice, and that I'm bounding off to create a full  
parser. I'm a little bit confused by this.

Originally I had asked if anyone had samples or tutorials on creating  
embedded DSLs using Smalltalk. I've built them in Ruby and Lisp.  
Especially in Ruby, there are some useful tricks in manipulating  
(some might say abusing) the language to provide a desired syntax for  
your DSL. I was hoping to pick up similar tricks for Smalltalk.

I think the discussion got off track because people asked me a few  
questions (What would your ideal syntax be? Why do you think ruby  
syntax might be better for DSLs?) and I tried to answer them. I  
probably should have changed the subject line or something. So, when  
answering a question, I might have said,  "I'd like to be able to do  
something like XYZ", but that didn't mean I wanted to go out and  
actually implement XYZ. I was simply answering a hypothetical question.

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. Some people  
count it--but to me it seems like that's just programming. C's  
functions, OOPs objects and Lisp's macros all serve the same basic  
function--they allow you to define additions to the language to more-
closely model your domain. Where do we draw the line between  
programming and DSLs?

>
>> When I spoke about DSLs, I was particularly talking about
>> reading in and evaluating text files.
>
> I don't think that is a good definition of a DSL.  Files are  
> orthogonal to
> the issue of DSL or not DSL.

I don't think I meant for this to become a universal definition of  
DSLs. Rather, I think I was trying to explain what I had meant by DSL  
in my earlier posts.

Still, to return to my previous question, where do we draw the line?  
For me (and this is strictly a personal definition, don't feel  
obligated to adopt it), a DSL must be able to interpret code that was  
not part of the original application (support files that ship with  
the application, like configuration files, are OK). I'm talking about  
raw strings that have not been previously compiled. A DSL evaluates  
these strings on the fly.

The code in question could come from a file, could be entered  
interactively at the command line, or could be sent across the  
network. It really doesn't matter where it comes from. The important  
thing is,  in some way the code is external to the executable.

Why do I like this definition? For me, there are very practical  
reasons. Creating a system to evaluate external strings is more  
complicated than simply writing an object or macro. There are the  
obvious IO issues. More importantly, you need to decide whether  
you're looking at each line as a separate command, or whether you're  
dealing with the entire string as a single chunk. Strings can be  
interpreted as new objects and method calls, as method calls on a  
given object inside your code, or as numerous other possible variations.

Also, this definition seems to match closely with the discussion on  
"Domain Languages" in the Pragmatic Programmer book--which has been  
my initial source for all things DSL.

> You seemed hell bent on using a syntax that
> wasn't valid Smalltalk, and I understood you pretty much as Ralph  
> did, and
> wondered, why?  Yes, this is building a DSL, but it's building a  
> custom DSL
> that requires parsing.

I don't think I'm hell-bent on anything. I'm sorry if I gave you that  
impression.

I also don't think I ever suggested anything that would required a  
parser (except possibly as an answer to a "what would your ideal  
syntax be?" style question). Some of my suggestions did use trivial  
pre-processing of the text. But, no. I don't want to mess with  
parsers at this stage--probably never for this project.

> While a valid approach, it's certainly not the
> easiest or most practical solution, which is all the Smalltalkers were
> getting at.  Even if you did want to build a custom DSL, the practical
> approach would be to prototype it as an embedded DSL first, get it  
> working,
> and then decide after that, if a custom syntax would be useful.  
> Just my
> $.02

I agree with this. I've agreed with it every time it has come up  
(though I may not have commented on it directly--human nature, I  
guess. I tend to comment on things I disagree with). Still, this has  
been, is and will continue to be my plan.

Sorry to repeat myself, but I feel like I've tried to say this  
before--somehow the idea keeps getting lost under the cushions.  
Again, I think this is largely my fault--I should have separated the  
tangential conversations (e.g. the differences between Ruby and  
Smalltalk syntax as applied to DSLs in general) from the main point  
(what are the best practices for developing an embedded DSL to  
process externally provided strings in Smalltalk?).

I'll try to be clearer in the future.

-Rich-

On Aug 30, 2006, at 9:40 AM, Darius Clarke wrote:


It seems like you're taking what was originally a very simple idea  
and blowing it up to ridiculous proportions.

You're right. It is never possible to make any communication  
completely unambiguous. However, that doesn't mean we shouldn't try  
to make things as easy as reasonably possible on others.

To be sure, I wasn't talking about communicating with aliens from  
Mungus Prime. I wasn't even talking about cross cultural  
communication. I know the primary audience personally. It's a small  
group, and only one of them (other than me) is a programmer.

When I said I wanted to make the syntax easy to read, I simply meant  
that I wanted to avoid strange constructs and non-standard  
punctuation that is not part of English grammar. Words "like_this" or  
"likeThis" definitely fall into that category. I also want to remove  
any unnecessary words or punctuation. Boil it down to the simplest  
syntax that will do the job.

Again, I'm planning on running a large number of experiments on a  
computer model--each experiment will have different parameters and  
initial conditions. This will generate a lot of data. I want non-
coding scientists to be able to look at the configuration file and  
understand that, "Oh, the data from run 16 was created using  
configuration XYZ". That's all. It doesn't need to be perfectly  
understandable. It just needs to be as readable as reasonably possible.

-Rich-

Hi Rich!

Trying to give concrete useful (possibly) advice, here are a few things:

        - In Gjallar we have Q2Console and Q2CodeHolder that enable "silent"
running of Squeak code and tries hard to do autocorrections etc as the
live Squeak env does. There are quite a number of messages that needs to
be handled in order to cover all bases, like autoadding local varnames
not declared etc. etc.

        - A useful pattern is to use blocks for "scripts" like: '[:customer
:invoive | ', script, ']' and then call it with the arguments and
explain to the user that he should use "customer" and "invoice" to refer
to those (or whatever) objects in the script. This way you get a more
clearly defined scope instead of just running the script "inside" a
given domain object (and thus expose all instvars etc).

Then of course there are tons of nifty things you can do with actually
building classes dynamically etc. :) And another trick is to subclass
Parser and friends and hook into for example the logic for binding
variables and so on. In my Namespaces implementation on SM there is a
bit of such code that deals with resolving globals for example.

regards, Göran

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.

In general I'm ok just browsing the source code, but I do get upset  
when someone doesn't even bother to add a class comment. I mean,  
really. How long does it take to add two or three sentences? A few  
sentences, that's all I'm asking. A handful of words can save me so  
much time.

Sometimes, when I'm working with a new framework, it can be hard to  
find the door in. Once I find the door, I'm golden. Maybe there are  
tricks to moving through the source code that I don't know (hey,  
maybe they should be documented somewhere). But, it really frustrates  
me when I can't even find the door.

I think there are a couple of other barriers to Squeak in particular.  
I think the user interface is a huge one. Let's just say, the UI for  
3.8 seems a bit...how should I say it...aesthetically challenged. 3.9  
looks like it will be a big step forward, but it's still not great.

There's also a pretty serious learning curve before you can even use  
the interface. I'm sure halos have driven away more than one  
potential user. They seem so foreign at first.

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.).

When I started learning Smalltalk, I originally tried squeak, moved  
to VisualWorks because of the UI issues, then moved back to squeak to  
get access to newer versions of SeaSide. Once I made it over the  
initial learning curve, I discovered that I really like squeak  
(except for being isolated from the rest of my desktop--I still don't  
like that).  I've heard at least one other person on this list  
describe similar experiences. I wonder how common it is? I wonder how  
many people we lose, because they just don't make it far enough?

-Rich-

Rich Warren puso en su mail :

>  I like my mac. I like my mac apps.

Well, Mac in the beginning was a lot different to other common green screens
at the time.

Taking to masses only a part of Smalltalk (as was pointed in this same
thread).

Now all use some of this concepts.

 >I wish Smalltalk could be
> part of that environment.

For Mac exist F-Script, if you still don't have, go for it.
And you could have some more Smalltalk way to deal with the system.

For Squeak, you could program for having any look and function as you wish.

Jim Benson do his Zurgle a long time ago....maybe is time someone look at
his job and resurrect ?

> And it doesn't run on intel macs yet.).
Apple should use the same processor  as X 360 Microsof game console.
Opening the possibility to hackers to copy most of system for running in
cheap clones is a mistake (IMHO)
Most world people are too poor to buy a Mac and not for buy a decent clone

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

Hi
we can browse tests too !  which is useful...  actually I think test
code of a class should be "displayed"  or at least accessible directly
from the browser. Me, I just added test classes related to a class in
the comment pane of OB so that it can be accessible with cmd+b.

I also waiting to see Services Romain are doing because I think that
could really enhance ergonomy.

but I agree that just minimum class comments would be cool. But I
imagine programmer dislike to do that ;)
Maybe we could have a team of commentors ? :) (??)
>
> I think there are a couple of other barriers to Squeak in particular.
> I think the user interface is a huge one. Let's just say, the UI for
> 3.8 seems a bit...how should I say it...aesthetically challenged. 3.9
> looks like it will be a big step forward, but it's still not great.
agree...  except I really like 3.9... but I guess I'm used to the
smalltalk environment now so...

> 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.).
I felt the same first, but now I like the one big windows containing all
my squeak windows (now that I can manage them).
wxWidget will probably go in the direction you want (I don't know for mac).
> When I started learning Smalltalk, I originally tried squeak, moved to
> VisualWorks because of the UI issues, then moved back to squeak to get
> access to newer versions of SeaSide.
same ;) and to get access to open source too !
Actually, I tried recently VW again but this time I prefered the look
and feel of squeak (3.9)
> Once I made it over the initial learning curve, I discovered that I
> really like squeak (except for being isolated from the rest of my
> desktop--I still don't like that).  I've heard at least one other
> person on this list describe similar experiences. I wonder how common
> it is?
this is really common !

First of all, this is important to have a developper image I think,
because an "education" version may look too much as a toy for "serious"
people (and programming is serious :) ).  And maybe derive a newcomer
developer image configured in a way it makes all a bit more accessible
(one browser, some tutorial inside, monticello configured...). I'm using
the DEVInstaller class Torsten sent...

After we might need good tutorials to use the environment. I said that
already, but it took me a long time to really understand how to browse
the code (senders,  implementors,  halting,  writing code in the
debuger, using the debuger, inspecting, exploring, cleaning and
preparing the image, understanding what is an image !)...  During this
long learning curve, I was quite often discoraged when developing
because I was stuck really often and really quickly !  Hopefully it's
kind magic and addicting. I just love the syntax and the dynamic
behavior  ;)

Now it's a bit better, I still get stucked but I can solve problem even
if it takes time... but as a langage said to be for kids, well hitting
the walls made me think programing was just not for me. Just to say that
good programmers will be at ease relatively quickly... but for people
doing that for leisure it's hard !
Php makes people feels programmers, squeak (and smalltalk) just make you
realize you're not really one ;)


Cédrick

Not all thinks this way(may be little but still are there), so you can not generalize that conclusion.

I seriously had one day learning curve with Squeak UI (obviously it differs from person to person) (i came from Java Swing background). I found Squeak UI more initiative and usable.
Personally i don't agree that halos are scary.
I think user aesthetics is personal issue.

Just my 0.002 Rupees
--
Hiren J.Thacker [ www.jroller.com/page/daredevil ]

And there are plenty ways of doing scripting in squeak.
For instance the simpler way is to fire up a Squeak server and send it
the content of a text file (network cat o nc can be used to do it in a
snap) on a pre-defined port.
This is totally unsafe, but pretty fast to do.
My 5 cents (yes I am coming richer!)


On 30 Aug 2006 14:10:53 +0200, Lex Spoon <[hidden email]> wrote:
> "J J" <[hidden email]> writes:
> > Scripting.  Do we need it?  Well Java doesn't have it.  C++ doesn't
> > have it. And those are the two most popular languages afaik.  But both
[...]

--
Software Architect
http://www.objectsroot.com/
Software is nothing

> Php makes people feels programmers, squeak (and Smalltalk)
> just make you
> realize you're not really one ;)
> Cédrick

But that you could be!

> 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.

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

> In general I'm ok just browsing the source code, but I do get
> upset when someone doesn't even bother to add a class
> comment. I mean, really. How long does it take to add two or
> three sentences? A few sentences, that's all I'm asking. A
> handful of words can save me so much time.

Ditto!

> Sometimes, when I'm working with a new framework, it can be
> hard to find the door in. Once I find the door, I'm golden.

Ditto!

> I think there are a couple of other barriers to Squeak in
> particular.  
> I think the user interface is a huge one. Let's just say, the UI for
> 3.8 seems a bit...how should I say it...aesthetically
> challenged. 3.9 looks like it will be a big step forward, but
> it's still not great.

Easily fixed...

  * load LookEnhancements
  * change SystemWindow borderWidth to 2
  * On windows platforms load WindowsNativeFonts
  * Preferences windows roundedWindowCorners to false
  * Preferences menus roundedMenuCorners to false
  * load eCompletion
  * load Shout4
  * hide unused flaps, delete annoying mouse and goofy trashcan
  * set a nice background graphic (I use mac blue panther graphic)

You're left with a nice professional looking environment with no trace of
Squeaks default silliness, windows that look and act decent, including
minimizing and maximizing when you double click the title bar, nice
intellisense, auto completion and code coloring.

> 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

I sympathize here, I both love and hate that squeak's its own little world.
I've adjusted by dedicating one monitor to squeak, and one to windows, but I
do wish someone would solve this problem.  I don't mind squeak having it's
own windowing system, it's nice to be able to work on a Mac, a pc, and a
Linux box all in the same environment, but it'd be nicer if a morph floated
over the native desktop.

On Aug 31, 2006, at 2:35 AM, Rich Warren wrote:

> 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.).

FScript (mentioned already) & Ambrai Smalltalk http://www.ambrai.com/ 
are two nice smalltalk frameworks for interacting & constructing apps
using the cocoa framework. Fscript is the scripting variant & Ambrai is
closer to a full-featured smalltalk.

Eric

> 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.

> Based on these definitions, I have always been talking about
> creating an embedded DSL. Yes, people keep recommending that
> I create an embedded DSL. Yes, this is good advice. Yes, this
> is what I plan on doing. For some reason, I keep getting
> replies that suggest that I'm resisting this advice, and that
> I'm bounding off to create a full parser. I'm a little bit
> confused by this.

Well, sorry if I misunderstood you, my apologies.  It's just that with the
talk about not liking : for arguments, or not wanting a receiver, and not
wanting to quote strings and such, I was led to believe you didn't want an
embedded DSL, that you wanted to parse your own special syntax.

> I think the discussion got off track because people asked me
> a few questions (What would your ideal syntax be? Why do you
> think ruby syntax might be better for DSL's?) and I tried to
> answer them. I probably should have changed the subject line
> or something. So, when answering a question, I might have
> said,  "I'd like to be able to do something like XYZ", but
> that didn't mean I wanted to go out and actually implement
> XYZ. I was simply answering a hypothetical question.

Ah!

> 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.

> Some people count it--but to me it seems like that's just
> programming. C's functions, OOPs objects and Lisp's macros
> all serve the same basic function--they allow you to define
> additions to the language to more- closely model your domain.
> Where do we draw the line between programming and DSLs?

When I read the code, do I see C, or do I see lot's of stuff related to the
problem domain.  If reading Lisp, do I see lot's of cons, car, cdr, map,
filter, or do I see something more domain specific.  Some people program
"in" the language, some people program "on" the language.  It's all just
programming, doing a DSL is just a style.

> >> When I spoke about DSL's, I was particularly talking about
> reading in
> >> and evaluating text files.

I would consider that an interpreter, and an external DSL, not an embedded
DSL, unless the text needed no preprocessing to evaluate.  If you have to
pre-process it first, it's an interpreter, and an external DSL.

> Still, to return to my previous question, where do we draw the line?  
> For me (and this is strictly a personal definition, don't
> feel obligated to adopt it), a DSL must be able to interpret
> code that was not part of the original application (support
> files that ship with the application, like configuration
> files, are OK). I'm talking about raw strings that have not
> been previously compiled. A DSL evaluates these strings on the fly.

Hmm, I think an interpreter evaluates strings on the fly, a DSL is just a
description of the possible syntax, and is orthogonal to evaluation.

> The code in question could come from a file, could be entered
> interactively at the command line, or could be sent across
> the network. It really doesn't matter where it comes from.
> The important thing is,  in some way the code is external to
> the executable.

Again, I don't see this at all related to being a DSL.  I could do this with
the syntax of any language that supported some kind of eval function.  Being
a DSL is about syntax, not about where the code comes from.

> Why do I like this definition? For me, there are very
> practical reasons. Creating a system to evaluate external
> strings is more complicated than simply writing an object or
> macro. There are the obvious IO issues. More importantly, you
> need to decide whether you're looking at each line as a
> separate command, or whether you're dealing with the entire
> string as a single chunk. Strings can be interpreted as new
> objects and method calls, as method calls on a given object
> inside your code, or as numerous other possible variations.

It seems your definition of DSL == my definition of interpreter, no wonder I
misunderstand you so much.

> Also, this definition seems to match closely with the
> discussion on "Domain Languages" in the Pragmatic Programmer
> book--which has been my initial source for all things DSL.

Unfortunately, I loaned my copy out and it seems to have disappeared. :(

No problem, happy to continue the discussion, I find it fascinating.

"Giovanni Giorgi" <[hidden email]> writes:
> And there are plenty ways of doing scripting in squeak.
> For instance the simpler way is to fire up a Squeak server and send it
> the content of a text file (network cat o nc can be used to do it in a
> snap) on a pre-defined port.
> This is totally unsafe, but pretty fast to do.
> My 5 cents (yes I am coming richer!)

Try it, and you will find that there are a lot of details you have to
worry about.  Where is the image and VM you use for running the
scripts?  How do you access stdin and stdout?  How do you define
methods and classes?  Where does the output go when there is a syntax
error or runtime error in your script?

These are all simple issues, but there are a lot of them.

-Lex

On 31/08/06, Ramon Leon <[hidden email]> wrote:
>   * load LookEnhancements
>   * change SystemWindow borderWidth to 2
>   * On windows platforms load WindowsNativeFonts
>   * Preferences windows roundedWindowCorners to false
>   * Preferences menus roundedMenuCorners to false
>   * load eCompletion
>   * load Shout4
>   * hide unused flaps, delete annoying mouse and goofy trashcan
>   * set a nice background graphic (I use mac blue panther graphic)


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?

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

Thanks,
Steve

On Aug 30, 2006, at 15:38 , tim Rowledge wrote:
>>> And dont go down the road that "smalltalk is simple so the
>>> code documents itself".  The code NEVER documents itself,
>>> that is a cop-out and a bold face lie.
>
> Well I have bit of experience in Smalltalk and I find myself  
> substantially in agreement with JJ here. Sure, senders and  
> implementors are fabulous tools to have but they offer nothing to  
> help understand what is likely to happen with exceptions and very  
> little for Tweak signals etc.

That is because the code at that point is not "straightforward", that  
is, it doesn't directly reflect what is going on because it is  
actually implementing a different architectural style (in some sense a  
different language) using what is available in OO/Smalltalk.

> No amount of staring at source code will tell you what the author  
> might have *wanted* the code to do, nor what misbegotten changes  
> somebody made after misunderstanding the intent of the code at a  
> later point. Source code tells you what *actually* happens, not what  
> is *meant* to happen. Anybody that tries to tell you that the code  
> does exactly what it it supposed to is almost certainly lying.

I have found that a combination of TDD-style unit tests and "intention  
revealing" programming style works really, really well at documenting  
what I *meeant* to happen.  Which is kind of funny because it doesn't  
require any new technology, just technique.

However, it turns out that there are things this combination doesn't  
cover, and those tend to be the above case of indirectly programming  
in a different style/language using our current mechanisms.  So it  
appears to be a good indicator of when you need to start twiddling  
with the language itself.

>
> Adele Goldberg expressed it once as "if the code isn't documented,  
> it doesn't exist" since without reasonable doc there is no way to  
> count the code as usable in the long term. I tend to add the  
> corollary clause "and if it doesn't exist, what did we pay you for?"

Funky.  At the last OOPSLA there was a very similar definition of  
"legacy code":  code that doesn't have tests.  I thought that was  
really great.  If it doesn't have tests, I can't understand it, and  
can't evolve it safely.  I would also claim that, despite the fact  
that I like the fuzziness of natural language, unit tests are better  
to have than comments, because whereas comments tend to always be out  
of sync with the actual code, we have a simple way of ensuring that  
the unit tests and the code do not diverge.

> Another old friend of mine has also coined the rather nice idea of  
> "program the document, don't document the program"

Essentially very similar to TDD...write the spec/tests/doc, then code  
it up.  The nice thing about tests is that they can tell you when  
you're done.

That said, it would be interesting if it is possible and/or useful to  
integrate these notions, maybe similar to what was done in the PIE  
system:  first write documents describing fuzzily what you want, the  
possibly replace/augment with tests.  Only when either one or both are  
available add code to make it do what the doc/tests say.  I guess you  
could even have some sort of automatic linkup such that it only makes  
sense to add code in response to one of these documentation/test nodes.

Marcel