Info on Smalltalk DSLs or Metaprogramming...

>From: "Hiren Thacker" <[hidden email]>
>Reply-To: The general-purpose Squeak developers
>list<[hidden email]>
>To: "The general-purpose Squeak developers
>list"<[hidden email]>
>Subject: Re: Thoughts from an outsider
>Date: Thu, 31 Aug 2006 02:03:54 +0530
>
>On 8/31/06, Benjamin Pollack <[hidden email]> wrote:
>>
>>On 8/30/06, Hiren Thacker <[hidden email]> wrote:
>> > Even if you coded right in pure English, I still wouldn't
>> > know *why* you did it the way you did, and therefore I
>> > wouldn't know *why* I shouldn't just change it.
>>
>actually many seniour Squeakers r thr always on #squeak at
>irc.freenode.netor asking on mailing-list also get very quick reply
>> > usually.So i think we can ask, to author or anyone who knows, about
>> > *why* you did it the way you did usually.
>> >
>>
>>Hiren proposes you simply email the list whenever you have a why. That's a
>>waste of everyone's time. The developer has to explain more than once,
>>while
>>users who subscribe to the list have to either preemptively save and
>>categorize important emails or else try to remember enough words from the
>>email that they can google their way to it--and frequently, they give up
>>and
>>ask again anyway. New users, meanwhile, are too scared to ask questions on
>>squeak-dev, which is where you'd have to ask if you really wanted the
>>original coder to respond with a because instead of a more experienced
>>user to respond with a how-to.
>>
>
>Benjamin,
>I think you are taking my english in wrong context.I think JJ was talking
>about "Design level Whys" if you read his that post, which i
>replied."Design
>level Whys" are not important for everyone using it.You should try to solve
>your doubts first by excersing own mind, its not necessary to ask for
>whenever u have a why.
>
>Regards,
>Hiren
>Hiren

>From: "Ramon Leon" <[hidden email]>
>Reply-To: The general-purpose Squeak developers
>list<[hidden email]>
>To: "'The general-purpose Squeak developers
>list'"<[hidden email]>
>Subject: RE: Thoughts from an outsider
>Date: Wed, 30 Aug 2006 13:34:07 -0700
>
>I never said documentation was bad, I was simply responding to the invalid
>accusation that the Smalltalk style of self documenting code is wrong, or
>that we're copping out or lying made by JJ below...
>

>
>Saying we could use more documentation, is quite different than saying our
>practices are wrong, or we are lying, or fooling ourselves with false
>feeling of "self documenting code".
>
>Documents mostly don't exist because there's no one writing them, this is
>after all an open source community and the people in the know are too busy
>writing code.
>
>The entire community, I'm sure, is open to accepting any documentation
>anyone feels like writing, including JJ.  But in a fast moving development
>effort, like Squeak, Seaside, and many other projects I'm sure, there's
>always going to be a lack of documentation, that's just life.
>
>This isn't some big commercial framework where you can point a finger and
>say hey, you should have written more documents.  Those kind of documents
>will naturally evolve as the frameworks settle down and start being used
>more, but don't insult the authors of such frameworks by calling them
>liars,
>seriously, be grateful those guys are writing cool stuff for us to use,
>worry about documents later.
>
>

>From: tim Rowledge <[hidden email]>
>Reply-To: The general-purpose Squeak developers
>list<[hidden email]>
>To: The general-purpose Squeak developers
>list<[hidden email]>
>Subject: Re: Thoughts from an outsider
>Date: Wed, 30 Aug 2006 15:38:40 -0700
>
>
>On 30-Aug-06, at 1:34 PM, Ramon Leon wrote:
>
>>>Communities that tell their users to RTFM find themselves
>>>alone very quickly. We're telling ours to RTFSC. There has
>>>got to be a compromise better than that.
>>>
>>>--Benjamin
>>
>>I never said documentation was bad, I was simply responding to the  
>>invalid
>>accusation that the Smalltalk style of self documenting code is  wrong, or
>>that we're copping out or lying made by JJ below...
>>
>>>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. 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.
>
>Comments in methods ought to offer some help in decoding the  expectations
>for the method as a whole, or for parts of the method.  Class comments
>ought to offer a somewhat higher level view of what  the class is supposed
>to do and the limitations it is known to have.  Other forms of comments and
>documentation are needed to give later  authors some hope of being able to
>use, maintain and improve the  system. You need tutorial type documentation
>to offer newcomers to a  part of the system a chance of getting some sense
>of the system  before they can even begin to understand the actual code.
>
>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?"
>
>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. It's
>not hugely different to some aspects of the  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  where might we find a document editor with intimate
>associations with  a compiler?
>
>tim
>--
>tim Rowledge; [hidden email]; http://www.rowledge.org/tim
>A)bort, R)etry or S)elf-destruct?
>
>
>

>From: Hans-Martin Mosner <[hidden email]>
>Reply-To: The general-purpose Squeak developers
>list<[hidden email]>
>To: The general-purpose Squeak developers
>list<[hidden email]>
>Subject: Re: Thoughts from an outsider
>Date: Thu, 31 Aug 2006 07:41:16 +0200
>
>Damien Pollet schrieb:
> > 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 :-)
>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
>

>From: [hidden email]
>Reply-To: The general-purpose Squeak developers
>list<[hidden email]>
>To: The general-purpose Squeak developers
>list<[hidden email]>
>Subject: Re: Info on Smalltalk DSLs or Metaprogramming...
>Date: Thu, 31 Aug 2006 11:06:40 +0200
>
>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
>

>From: "Chris Barham" <[hidden email]>
>Reply-To: The general-purpose Squeak developers
>list<[hidden email]>
>To: "The general-purpose Squeak developers
>list"<[hidden email]>
>Subject: Re: Thoughts from an outsider
>Date: Sat, 2 Sep 2006 20:24:38 +1000
>
>On 9/2/06, J J <[hidden email]> wrote:
>>Perhaps a javadoc type tool could be written that generates documentation
>>from the code
>>itself?
><SNIP>
>
>Something like Dandelion?
>http://www.mars.dti.ne.jp/~umejava/smalltalk/stClasses/dandelion/
>
>Chris
>

>From: "Giovanni Giorgi" <[hidden email]>
>Reply-To: The general-purpose Squeak developers
>list<[hidden email]>
>To: "The general-purpose Squeak developers
>list"<[hidden email]>
>Subject: Re: why scripting (was: Thoughts from an outsider)
>Date: Thu, 31 Aug 2006 16:56:00 +0200
>
>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
>[...]
>>
>>For bigger programs, clearly yes.  For small programs, though, it can
>>be much more convenient to use a script file.  A file-sized chunk of
>>code is an excellent unit of code exchange.  Good tools make this unit
>>of code exchange nice to work with.
>>
>>There are a lot of things that a script-running program can make
>>easier.  For example:
>>
>>
>>1. Compilation/Loading.  You do not have to deal with when to run the
>>compiler and/or load the code into the running system.  The script
>>runner does whatever is needed to make your code run.
>>
>>2. Dependencies.  If your program needs external libraries, at worst
>>you put a declaration at the top of your file.
>>
>>3. Integration with other tools.  Any tool that can work with text
>>files can work with script files.  CVS, SVN, and pretty much any
>>decent version control system has a convenient way to handle text
>>files.  You can even embed script files into programs in other
>>languages.  Try these things with an image -- it's possible but takes
>>some work.
>>
>>
>>
>>-Lex
>>
>>
>>PS -- If your operating system is Squeak, then yes you can just "do
>>it" to run your code.  But for the sake of argument, let's suppose
>>that you are using some backwards non-Squeak operating system that
>>does not use Smalltalk for its system language.
>>
>>
>>
>
>
>--
>Software Architect
>http://www.objectsroot.com/
>Software is nothing
>

>From: "Ramon Leon" <[hidden email]>
>Reply-To: The general-purpose Squeak developers
>list<[hidden email]>
>To: "'The general-purpose Squeak developers
>list'"<[hidden email]>
>Subject: RE: Thoughts from an outsider
>Date: Thu, 31 Aug 2006 08:44:06 -0700
>
>Idea's don't die, Smalltalk's been around 30+ years, it's not going
>anywhere.
>

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

>From: Marcel Weiher <[hidden email]>
>Reply-To: The general-purpose Squeak developers
>list<[hidden email]>
>To: The general-purpose Squeak developers
>list<[hidden email]>
>Subject: Re: Thoughts from an outsider
>Date: Thu, 31 Aug 2006 15:11:52 -0700
>
>
>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
>
>

>From: "Lic. Edgar J. De Cleene" <[hidden email]>
>Reply-To: The general-purpose Squeak developers
>list<[hidden email]>
>To: squeakdev <[hidden email]>
>Subject: Re: Thoughts from an outsider
>Date: Fri, 01 Sep 2006 06:55:25 -0300
>
>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)
>

>From: "Andrew Tween" <[hidden email]>
>Reply-To: The general-purpose Squeak developers
>list<[hidden email]>
>To: "The general-purpose Squeak developers
>list"<[hidden email]>
>Subject: Re: Thoughts from an outsider
>Date: Sat, 2 Sep 2006 12:39:17 +0100
>
>Hi J J,
>----- Original Message -----
>From: "J J" <[hidden email]>
>To: <[hidden email]>
>Sent: Saturday, September 02, 2006 11:56 AM
>Subject: RE: Thoughts from an outsider
>
>
>..snip...
> > Also, after I did all those things the debugger doesn't highlight code
>right
> > anymore.  I can't tell exactly what code is running because the
>highlight
> > is in the wrong place.
> >
> > Has anyone else seen this?
>
>Yes. It is a known bug in Shout. The latest version on SqueakSource fixes
>this,
>but hasn't been released onto SqueakMap yet. You can get it from here...
>
>http://www.squeaksource.com/shout/Shout.3.15-tween.65.mcz
>
>Note that this version is intended for the current 3.9, so if you are using
>3.8,
>then it is best to stick to the old SqueakMap version. You can also 'fix'
>the
>debugger problem by disabling (i.e. unselecting) both of these Preferences
>-
>     syntaxHighlightingAsYouTypeAnsiAssignment,
>     syntaxHighlightingAsYouTypeLeftArrowAssignment
>
>Cheers,
>Andy
>
>

>
> Also, any idea when it will be officially released?
>
> Thanks again
>
>
> >From: "Andrew Tween" <[hidden email]>
> >Reply-To: The general-purpose Squeak developers
> >list<[hidden email]>
> >To: "The general-purpose Squeak developers
> >list"<[hidden email]>
> >Subject: Re: Thoughts from an outsider
> >Date: Sat, 2 Sep 2006 12:39:17 +0100
> >
> >Hi J J,
> >----- Original Message -----
> >From: "J J" <[hidden email]>
> >To: <[hidden email]>
> >Sent: Saturday, September 02, 2006 11:56 AM
> >Subject: RE: Thoughts from an outsider
> >
> >
> >..snip...
> > > Also, after I did all those things the debugger doesn't highlight code
> >right
> > > anymore.  I can't tell exactly what code is running because the
> >highlight
> > > is in the wrong place.
> > >
> > > Has anyone else seen this?
> >
> >Yes. It is a known bug in Shout. The latest version on SqueakSource fixes
> >this,
> >but hasn't been released onto SqueakMap yet. You can get it from here...
> >
> >http://www.squeaksource.com/shout/Shout.3.15-tween.65.mcz
> >
> >Note that this version is intended for the current 3.9, so if you are using
> >3.8,
> >then it is best to stick to the old SqueakMap version. You can also 'fix'
> >the
> >debugger problem by disabling (i.e. unselecting) both of these Preferences
> >-
> >     syntaxHighlightingAsYouTypeAnsiAssignment,
> >     syntaxHighlightingAsYouTypeLeftArrowAssignment
> >
> >Cheers,
> >Andy
> >
> >
>
>
>
>

> I agree that traits wont come up normally.  But as soon as you get into big
> complicated
> heiarchies traits are probably going to be a better fit.  Not only that, I
> have seen a lot of
> people ask for protocols to be actual queriable objects.  That seems to be
> about what
> traits are afaik.
>
> Many things smalltalk has are just better versions of what everyone else
> has.  I think things
> like this are what everyone will be trying to steal tommorow when they
> finally arrive where
> smalltalk was years ago and see what the problems are.