Info on Smalltalk DSLs or Metaprogramming...

J J wrote:
>
> This cancerous, destructive idea of "self documenting code" is a big
> barrior to people
> new to the language, and I would be willing to bet that is the main
> reason it isn't taking
> off faster.
+100 Any system that has not been documented may as well have not been
written at all, and I said that on the seaside list years ago.

I myself looked at seaside right from the beginning and was never able
to get my head around it. Actually it is not that difficult, but because
of lack of documentation, I lost 2 years of possible using seaside. And
on numerous occasions I have dropped using squeak for exactly the same
reason. I might have spent 5 more years in the squeak camp if there were
any documentation for morphic, but as yet I still cant get anything
basic working to the standard that I would like.

Keith

               
___________________________________________________________
Try the all-new Yahoo! Mail. "The New Version is radically easier to use" – The Wall Street Journal
http://uk.docs.yahoo.com/nowyoucan.html

>
> I myself looked at seaside right from the beginning and was never  
> able to get my head around it. Actually it is not that difficult,  
> but because of lack of documentation, I lost 2 years of possible  
> using seaside. And on numerous occasions I have dropped using  
> squeak for exactly the same reason. I might have spent 5 more years  
> in the squeak camp if there were any documentation for morphic, but  
> as yet I still cant get anything basic working to the standard that  
> I would like.

But you can also help writing class comments or writing tests on what  
you learn.
There is no magic and "you should write documentation" it does not work.
I would love to have better documentation for Squeak but

On Aug 31, 2006, at 3:10 AM, Lic. Edgar J. De Cleene wrote:

There is also the Objective-C bridge.

-Todd Blanchard

On 4-Sep-06, at 10:44 PM, Rich Warren wrote:

>
> Just to bring this full circle. Now that I've been using Squeak for  
> a while, I've grown used to it's UI. I find that using QuickSilver,  
> I can still pop out of a full-screen Squeak session with just a few  
> keystrokes,
I don't understand why you would choose to use Squeak fullscreen if  
you want to feel connected with your OS; it seems like a strategy  
almost guaranteed to make the worst of squeaks' use of a single  
window. I don't think I've used fullscreen form since 1989 - and  
before then it was simply impossible to do otherwise because my OS  
simply didn't have other windows!

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
For every action, there is an equal and opposite criticism.

> This cancerous, destructive idea of "self documenting code"
> is a big barrior to people new to the language, and I would
> be willing to bet that is the main reason it isn't taking off faster.

Dude, seriously, chill with the negative language, it isn't cancerous, stop
insulting the other side.  You can ask for more docs without being
insulting.

> I can tell you I have done various projects in various
> languages to get a feel for it, and never before have I felt
> like I could do so much so fast, and yet not been able to do
> very much at all.  Why?  Because the state of documentation
> right now is almost impenetrable.  Anything I do, I feel like
> it is probably already there in some system that I don't know
> about and have no way to find out about.

OK, I get it, you aren't comfortable with Smalltalk as a self documenting
system.  There are other places to get info, try the Swiki
http://minnow.cc.gatech.edu/Squeak, or any of the various mailing lists.  

> The main documentation right now, as far as I can tell, seems
> to be the mailing list.
>
> "self documenting code" as a source of documentation is
> simply not valid.  I am pretty surprised that such an obvious
> statement has so much resistance.

It is valid, you just don't like it, or don't get it.  OK, just because it
doesn't work well for you doesn't mean it doesn't work well for others.  As
far as I'm concerned Squeak is the best documented system I've ever seen,
because I read the Class Name, methods names, browse example code, read the
unit tests, ask a question or two on a mailing list if I'm stuck, and away I
go.  I find it far easier to learn how to do something new in squeak than in
say .Net, or Ruby, where I don't have easy access to the code directly from
the development environment.

> If source code is the documentation then the bar for
> becomming productive in the language is the amount of time it
> takes you to absorb the entire Smalltalk class heirarchy from
> the browser.  And if you download a new system, then you have
> to read through every line of source code from that system.  
> And that isn't enough, simply reading the code isn't enough.  
> You have to wrap your brain around *why* it does what it does.
> Otherwise any change you do is probably not going to be helpful.

Yes, you have to grasp the basics of the Smalltalk class hierarchy, once,
but once you get it, you'll get very productive very fast.  It's not like
you have to do this for each program.

Yes, this happens, but documentation won't help this, this is more likely
you bumping into a bug, all this code is so Alpha this happens all the time.
Yes it's frustrating, but this is the kind of thing the mailing lists are
for.  Buggy code isn't exactly newbie friendly, I do sympathize.

> I spent at least an hour tracking through this and came up
> empty handed.  
> That is bad
> enough for playing around, but in business that would mean
> not using what ever component it was and writing our own from
> scratch.  And if we have to write everything from scrath then
> we are not getting the efficiency from the language.

In business, I doubt you'd be using Morphic, Morphic is an experimental
system, hardly anything I'd be writing biz apps with.  Squeak's main use for
biz system's, I'd think, would be web apps, where Seaside is useful.  For
desktop apps, Squeak isn't what you need, Visual Works or Dolphin would be
more appropriate.

Great, as Ruby has shown, stealing from Smalltalk works, and makes
everyone's life easier, and brings more interest to the Smalltalk community.
I'm not worried about Smalltalk's future, it looks quite solid to me, it was
good enough to hook me in a very short time, I'm sure it'll be the same for
many others.

Great, I'd rather see people contributing, you don't need to convince
everyone that something is broke, you simply need to get like minded people
to help your cause.  You could probably do this better by not using negative
language (cancer, lying, fooling ourselves) and insulting those who
disagree.  

> The original example I gave didn't use any setters--not in
> the conventional sense. For example, body() could simply call
> toString() on anything passed in, concatenating the string
> from multiple arguments. It could then append "<body>" to the
> front and "</body>"  
> to the end. Then it would append the whole string to the
> current document.

I was talking about attributes to the tag, ie..

<body style="bla;" class="bla" borderwidth="0">

To be able to set attributes on tags, you need setters that return self and
you need functions that return tag objects

html(body(h1("Hello")).style("bla").class("Bla"))

html(body(h1("Hello")).style("bla"))

I understand you reasoning, I appreciate the discussion, it's always good to
see how others think, I just don't agree on your redefinition of the word,
and will have to invoke Laynes Law.  

I don't see much further to discuss, you want to call a language a DSL.  We
disagree on fundamental definitions.  You want DSL to hinge on
interpretation or not, it's not a position I can agree with.  IMHO, you
should drop the DS, and just call what you're talking about a language.
Yes, likely a domain specific language, but I'm simply not going to agree on
making everything that's not interpreted "not" a DSL.  Then entire Lisp and
Smalltalk community have been calling their style of programming building
DSL's for far too long to suddenly change the definition and exclude them
because you feel it's too ambiguous.

I did enjoy the discussion, I just don't see where it can go from here.

- Ramon Leon

I have been insulting false ideas, not people.  It seems to me that you have
been
the one bringing out the "well Im sure it's not friendly to newbies", and
"you just dont
get it".

Anyway, this is a pointless discussion.  I appologize to the list for
carrying it on so long.

Source code in smalltalk, just as in the free software world does document
exactly what
is happening.  But that is all.  It is certainly not what the vast majority
of developers and
users are looking for when they want documentation.

> Anyway, this is a pointless discussion.  I apologize to the
> list for carrying it on so long.

Agreed, ditto.

Well, I was wondering if you guys had any kind of documentation team or
project, but I guess if there was someone would have spoken up by now.

So is anyone interested in starting such a team?  I will contribute what I
can
in my spare time.  I know no one *wants* to write documentation, but it will
be a good way to learn the systems.

So what we will need will is:
1) A main web site to host it on (can we use squeak.org for this?  how does
one get started
         adding documentation there?)
2) Some kind of reference manaul like this:
http://caml.inria.fr/pub/docs/manual-ocaml/index.html
       (does something close exist already?  I have been through many
'getting started guide's
       but most actually said 'not complete' before you got into the more
compliated subjects
       like meta programming and meta classes)
3) A list of projects to document.  I don't even know what is out there that
people need to
       get work done.  It seems to be so all over the place at the moment.
4) We are going to need some people that just sit on the various mailing
lists and sumarize
       what is going on.  If I am writing the documentation on Pier or
Seaside, those things are
       moving targets.  If I try to sit on the list and make changes for
every announcement I
       wont ever release anything.  So we need a person or persons to sit on
the list and provide
       me or who ever is doing the documentation with a weekly or monthly,
or whatever works,
       summary of what changes have happened so we can control it more.

And maybe someone else can think of more things.  As a first cut I don't
want to try to make
UML diagrams or anything like that.  Just getting some nice reference
manuals out there in a
central place that new people can find it will be a good first cut.

See what Simon have on http://joyful.com/JoyfulSystems.

Also exists http://www.xs4all.nl/~maartens/ , look for Squeak

The principal site, something unorganized , is
http://minnow.cc.gatech.edu/squeak/

Also exists a great number of specialized sites with his own "community"

When you have "Squeak for dummies" or "Learn Squeak in ten days" book what
lets you meet the beautiful ladies Fame and Fortune, send notice to this
list. :=)



       
       
               
__________________________________________________
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

I relize there is a possibility to write a book on all this and maybe get
rich, but I would
rather write the book for free, make smalltalk more well known/lucrative and
then
write 10 books to get rich off of. :)

On 5-Sep-06, at 1:06 PM, J J wrote:

> I relize there is a possibility to write a book on all this and  
> maybe get rich, but I would
> rather write the book for free, make smalltalk more well known/
> lucrative and then
> write 10 books to get rich off of. :)

We-ell, writing a book on squeak doesn't seem to be a particularly  
good way to get rich. Been there (at least in part, a group of us  
collaboratively wrote the 'nu-blu' book) got the $200 cheque.... I  
had much more success getting rich writing Smalltalk than writing  
about Smalltalk.

The key problem with any sort of traditional doc for a system like  
Squeak is that by the time you have written the outline it is so out  
of date that you have no chance of ever catching up. This is why I'd  
like to see some sort of image based doc-tool; at least it would have  
some hope of being up to date. I *don't* think that merely  
aggregating class and method comments is anywhere near enough.  Nor  
do I know exactly what *would* be enough, sadly. I am pretty sure  
that it needs to combine a way of presenting the raison d'être of the  
code, the reasoning behind the design, the known limits and tradeoffs  
and invariants expected and the tests, examples, demos and even the  
method and class commentary.

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Strange OpCodes: HSJ: Hop, Skip and Jump

Oh, and thank you for the leads, I will look into it first thing in the
morning.

Any more information out there?  And anyone else interested in helping write
this
stuff?  People new to smalltalk would be the best for this probably, since
this
lets us make a very big contribution fairly quickly.

J J puso en su mail :

> People new to smalltalk would be the best for this probably, since
> this
> lets us make a very big contribution fairly quickly.
If you could find a Spanish speaking person , (a child is better), we have
some begginners info and site in:
http://ar.groups.yahoo.com/group/squeakRos/ (Group)
http://wiki.gnulinex.org/squeakros (Swiki in Spain)
http://ar.geocities.com/edgardec2001/Welcome.html (Beginners tutorials ,
most in Spanish)
ftp://[hidden email]/
password: elpelotero  (on approximate 09:00 to 20:00 GMT, dig and take what
you like, at your own risk)




       
       
               
__________________________________________________
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

Klaus,

I don't seem to be able to send you emails from here.  But I wanted to say
thanks.  And you
brought up a good point:

We will also need documentation reviewers to make sure the doc we write is
correct and
promoting best practices.  It looks like I have one volenteer.  Anyone else?
:)

I know that is true for some of the projects, but all of squeak?  It seems
to me
like squeak, while moving, is stable.

And I think smalltalk should do to everyone else what they have done to
smalltalk
for so long.  We should steal vigorously from them. :)  There are lots of
great
documents out there on many other languages.  I plan to use those documents
as
a template of what works and what people expect.  So that way I don't have
to
come up with the outline from scratch, and that traditionally is what takes
me
the most time. :)

>tim
>--
>tim Rowledge; [hidden email]; http://www.rowledge.org/tim
>Strange OpCodes: HSJ: Hop, Skip and Jump
>
>
>

Hi,

>From the author's point of view, Dandelion is basically a tool for generating
inter-operable meta models in various formats. HTML output was actually
just an sample, though I added some frills.

For just browsing Smalltalk code, I think SystemBrowser is better.

The advantage of Dandelion is abstraction. For example, it stores
analyzed code info in a repository. The analyzed data is independent of the
current code and it can be retrieved later for further analysis.

2006/9/5, Ramon Leon <[hidden email]>: --
[:masashi | ^umezawa]

Hi,

Sorry for the late reply. I was disconnected from the net for a while.
(long trip to Prague (ESUG)).

I think Dandelion is in a sort of stable state. Although I have a few
things that I would like to add, the priority is not so high for me.
(But if there are real demands, I would do the action).

What I'm thinking are:

- The new release should be a MCZ based SAR file
- Support of analysis of MCZ packages
- Embed auto generated class graphs in html output
- Add code metrics analysis and CSV output

2006/9/3, Bert Freudenberg <[hidden email]>: --
[:masashi | ^umezawa]

Well I hope you had a great trip!  Those things you suggest sound good to
me.  And thanks
for your contributions. :)

I intend to learn spanish some day.  But let me get german down first. :)

And I want to get all the documentation centralized in one place so everyone
can find it.  It would be great if a spanish speaker went to squeak and they
just automatically see all those spanish documents by default.  But of
course
they need to be on the main site too for all the multi-lingual people.