Info on Smalltalk DSLs or Metaprogramming...

Am 02.09.2006 um 14:00 schrieb Michael Rueger:

Actually, the Squeak Doc documentation itself (in Books - Test  
Category) is in english.

- Bert -

Am 02.09.2006 um 12:30 schrieb J J:

> I must say, this sounds promissing I think.  I don't know how you  
> guys are
> finding this stuff. :)

Well, some of us are around for ages and can still remember stuff ;)

> The last update seems to be from 2004, is this a project without an  
> owner atm?

Masashi Umezawa is still around AFAIK, but like most Japanese  
developers he is not active on squeak-dev. You might want to drop him  
a mail.

>> http://www.mars.dti.ne.jp/~umejava/smalltalk/stClasses/dandelion/


- Bert -

At 14:45 02.09.2006, Klaus wrote:
>If you set "classic documentation" := "your doc book approach" then I
>cannot see any difference to what's up nowadays: the doc is always the
>first *or* the next component which is outdated.
>
>/Klaus

Of course not. I am talking about literate programming as proposed by Don
Knuth. Classic documentation is different.

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

Hi mickael

This is cool that you release the cool stuff you have been doing and  
few have been seen.
Impara deserves a broader attention form the community (and  
clients :)) but for that people
need to know that you are cool and excellent!

Stef

On 2 sept. 06, at 14:00, Michael Rueger wrote:

On Sep 1, 2006, at 11:15 PM, J J wrote:


<much snipped>

I'm not sure what this has to do with isolation from the rest of the  
desktop. Let me be clear, I wasn't talking about developing/coding  
issues, I was talking about using the UI.

While I'm coding, I inevitably need to check my e-mail, browse web  
pages, whatever (as research, of course--I'm not just playing  
around). I want to use those (and other tools) on my mac. Having the  
Squeak UI isolated from my OS UI makes rapid shuffling between  
browser windows and native OS tools more difficult than is absolutely  
necessary (at least for the way I typically work).

Also, having a separate UI means I need to learn two UIs. I have to  
constantly shift between the UIs. I have to maintain separate mental  
lists of efficiency tips for each UI. I have to remember which  
keystrokes go with which environment. Again, more work than is  
strictly necessary.

-Rich-

Hello Rich,


RW> Here's an example of what I'm talking about. I'm about to implement a
RW> neural net. I'll be experimenting with many different sizes and
RW> topographies. This is an excellent opportunity for a DSL. I could

I'm in the process of implementing neural networks too. I'd like to
share thoughts (here or off list). This would force me to write down
something:-)

I got stalled due to business demands but hope to find time to put
something on SM some time. From this thread I guess that you should
try the squeak binding to the fann library (fast artificial neural
networks).

Didn't try myself but sounds promising.

The most interesting of my own experiments is a self organising
feature map to cluster the information for a subsequent net. Maybe
because I made a graphic trainer, I'm easily impressed by
graphics :-))

Cheers,

Herbert                            mailto:[hidden email]

Hi,

I don't really know anything about FANN. I was planning on just  
implementing my own (they're not that hard). I'm torn because FANN  
might save time, but it would also make the code less portable (I'd  
need to have the FANN library installed on any computer that planned  
on running the code).

Portability is probably more important than speed at this point, so I  
may just implement my own.

The project I'm working on is actually an aLife simulation. The  
neural nets would only be a small portion (the brains of the agents).  
I like the idea of using them, since the weights can be learned  
genetically (over several generations) as well as modified within a  
single generation (using reinforcement learning).

-Rich-

On Sep 2, 2006, at 9:41 PM, Herbert König wrote:

Hi Rich,

Am 04.09.2006 um 06:55 schrieb Rich Warren:

> Hi,
>
> I don't really know anything about FANN. I was planning on just  
> implementing my own (they're not that hard). I'm torn because FANN  
> might save time, but it would also make the code less portable (I'd  
> need to have the FANN library installed on any computer that  
> planned on running the code).

What's about SNNS (http://www-ra.informatik.uni-tuebingen.de/SNNS/) ?  
It has an C API.....
>
> Portability is probably more important than speed at this point, so  
> I may just implement my own.
>
> The project I'm working on is actually an aLife simulation. The  
> neural nets would only be a small portion (the brains of the  
> agents). I like the idea of using them, since the weights can be  
> learned genetically (over several generations) as well as modified  
> within a single generation (using reinforcement learning).

Could you tell more about this project :-))) ?

Regards


Hans

Well what I meant was working in a smalltalk environment is like
developing your next app from within the app you are building.
So I think you would feel the same isolation if you could develop
from inside of your web browser for example.

But as far as wishing the tools that exist in the image behaved like
your normal GUI, can something be done with themes?  Is anyone
looking into making themes or something like that be set up in such
a way that I could set them to "Mac" and now my image behaves
like a mac or "WinXP" and now it behaves like XP?

Hello Rich,


RW> I don't really know anything about FANN. I was planning on just  
RW> implementing my own (they're not that hard). I'm torn because FANN

no they aren't, so I ended up doing my own too.

RW> Portability is probably more important than speed at this point, so I
RW> may just implement my own.

There is a Squeak implementation of a two layered perceptron with
backpropagation learning by Luciano Notarfrancesco, I decided against
it for it was too slow. Much better Smalltalk and OO though.

I needed speed in computing the outputs and FloatArray is fast in #*
and #sum.

RW> The project I'm working on is actually an aLife simulation. The

I'll take a look, when I'm online again.

RW> neural nets would only be a small portion (the brains of the agents).
RW> I like the idea of using them, since the weights can be learned  
RW> genetically (over several generations) as well as modified within a
RW> single generation (using reinforcement learning).

This (reinforcement learning) is said to be slow. What number of
inputs and how many neurons would such a brain have? How many agents?

With 500 epochs of 400 samples training of a single Perceptron of 64
hidden and 16 output neurons took over an hour on a 1.8GHz Pentium M.
It had 140 inputs.

Do you have any pointers on how to use genetic algorithms on neural
nets? More practical, I'm an EE not a CS person :-)



Cheers,

Herbert                            mailto:[hidden email]

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

I can't help but point out how much Ruby's doc's are just imitations of
a Smalltalk class browser.  How exactly is this better than class and
method comments in Smalltalk directly?  How is dandelion better than a
real browser either?  If you can generate the docs from the code, of
what additional value is the doc?

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

True, that would seem to work, but only with the addition saying all
setters return "this", so properties of those objects can be set in
every possible combination, inline, equivalent to Smalltalk's ;
operator.  I've done this in the past, it's ugly, and non idiomatic, and
confuses other programmers.  It works surprisingly well, once accustomed
to it, but feels like you're working very much against the language.  I
embedded SQL into csharp using this technique, mostly for the experience
of doing so.

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

I do, the Smalltalk ones are closures that pick up variables from the
surrounding environment automatically, the Java one would require
manually passing all such variables, or the introduction of some ugly
inner classes and all the relevant hacks to make them work.

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

Agree, but it's the difficulty in doing so, that separates languages
that you'd want to build a DSL in from those you wouldn't.

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

I think there is, I don't think it's difficult to see DSL's as a style,
and it's easy to see that style in other people's code.  You either
write in the language, or on it.  While it's possible to do a mixture of
both, I think most people pick one or the other.  I see it as similar to
the API vs framework thing, people tend to like one or the other.

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

I fail to see that line, whether code is interpreted or not, imho is
orthogonal to the issue of whether or not that code is a DSL.  I find
your linking of these concepts, odd, maybe it's me, but they simply
aren't related.

 > It isn't the "Smalltalk style".  In the early days of open source taking

I disagree, I think it is the Smalltalk style, maybe I'm wrong, but
that's my opinion.

 > off on
 > the internet everyone thought their code was "self documenting".  And
that
 > includes C and Perl programmers!
 >
 > You take what I said too personally.  I'm not calling *you*, or Luckas
 > or any
 > of the great developers here liars.  I am attacking this ridiculous
 > concept of
 > "self documenting code".  It became popular with the free software crowd

That you are attacking anything, is what bothered me.  You've used
strong insulting language from the start, not against me personally, I
take none of this personally, but against the self documenting style.
You may not prefer this style, but many do, as we've developed a
mistrust of documents not directly linked to code.

 > I did use strong language against the concept, but not as strong as some
 > other
 > people much more important then myself in much more public forums.  I

You place great value on documents, OK, great, but not everyone does, no
need to use such strong language.  You can approach the subject of more
documentation without being insulting to those who disagree with you.
Rather than arguing "for" documentation, you seem to be arguing
"against" less documentation, rather like a creationist arguing
"against" evolution rather than "for" creationism.

 > figured
 > some people would take it personal and get offended (I actually thought
 > a lot
 > more would) and I wouldn't want that, but sometimes it takes strong
wording
 > to make someone notice that something is wrong.
 >
 > Anyway, sorry for offending you.  I am very greatful for all the work
 > you and
 > everyone else has done.

Again, I'm not offended, my skin is much thicker than this, I'm simply
disagreeing with how you approached the subject.

On 4-Sep-06, at 7:06 PM, Ramon Leon wrote:
> If you can generate the docs from the code, of what additional  
> value is the doc?

Modulo the quality of the comments in the code that are being used,  
it's the presentation that can make the difference. A form of browser  
that can gather linked comments from methods and classes and present  
them in a neatly intelligible form is surely an improvement over  
scattered snippets?

But don't forget that crucial first clause above about the quality of  
the  source material.

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Useful random insult:- Always loses battles of wits because he's  
unarmed.

> Modulo the quality of the comments in the code that are being used,  
> it's the presentation that can make the difference. A form of browser  
> that can gather linked comments from methods and classes and present  
> them in a neatly intelligible form is surely an improvement over  
> scattered snippets?

Is not the standard Smalltalk browser such a browser?  How would some
other browser, using the same data, be able to somehow present the
information better than the Smalltalk browser?  If such a great feature
existed, wouldn't we simply add it to the existing Smalltalk browser?

>
> But don't forget that crucial first clause above about the quality of  
> the  source material.
>
> tim

Agreed, well commented code, when and where a comment adds value to what
the code already says.  Often there is value in "no comment".  As
someone earlier said, no one reads a 1000 page document. ;)

On Sep 4, 2006, at 12:13 AM, J J wrote:

No. My web browser is integrated into my desktop environment, so I  
can rapidly switch between programs. This lets me leverage any tool  
on my system in a tightly integrated way.  I actually have done some  
seaside development from inside my web browser, and I didn't feel the  
same sense of isolation from the desktop (though I have a certain  
amount of isolation from the squeak environment in those cases).

I really don't see how development styles relates to the issue of  
feeling isolated from the OS. They seem like completely different  
issues in my mind. One of the things I love about Smalltalk is the  
way applications are built. When I do strictly Mac work, I'll often  
use FScript as a support tool, since it helps me capture a similar  
feeling.

Or, to put it another way, when I develop in VisualWorks (on my old  
mac, it still doesn't run on my new mac, which makes me sad), I don't  
feel as isolated from my OS. A little bit, since the UI doesn't  
function in a 100% native manner.  In Ambri Smalltalk, I don't feel  
isolated at all. In all three cases (Squeak, Visualworks, and Ambri),  
I am using the same style and techniques to develop the code. Squeak  
is the only one which makes me feel isolated from my desktop .

What I have been trying to describe is strictly a Squeak UI issue. It  
has nothing to do with Smalltalk in general.

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, check the email message that relates to the problem at  
hand, do a little web research on the topic, then slip right back  
into Squeak. But this involved bending my normal workflow around  
Squeak (where, ideally, Squeak would just slip transparently into my  
regular workflow).  Even if Visualworks was running on intel macs, I  
would probably keep coding in Squeak. However, the UI was a real  
barrier to entry, and it can drive off new users (which was my  
original point).

-Rich-

On Sep 4, 2006, at 4:28 PM, Ramon Leon wrote:

Um, it doesn't need to be that difficult. Java basically treats  
variable length arguments as a collection. You could simply iterate  
over the arguments and add each one (in order) to the tag object.

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.

Alternatively, each tag could keep its contents as a list of subtags  
and raw string, and everything only get converted to strings (with  
the relevant tags added) at the end.

It would still be uglier than Smalltalk, but it could be a very  
simple solution. Of course, I'd still prefer to do this in either  
Smalltalk, Ruby or Lisp.

OK, clearly you think the issue of interpreted/non-interpreted is  
orthogonal to the issue of
DSL/non-DSL. I don't think we're going to agree on this, so let's set  
it aside for now. For the following discussion, assume everything is  
a DSL unless explicitly stated otherwise.

In other words, let's discuss the difference between bottom-up  
embedded DSLs and interpreted embedded DSLs.

For me all Bottom-up DSL and regular, non-DSL code  lie on a  
continuum. You can clearly point to either end and say "This is a  
DLS" or "This isn't", but most code lies somewhere in the middle.  
And, the middle gets muddy.

There's a quote I've seen many times (with slightly different  
wording). "Any sufficiently complex project becomes a DSL".  This is  
exactly the type of blurring I'm referring to, and it results in a  
general loss of meaning. If everything becomes a DSL, then the term  
DSL has no meaning.

On the other hand, interpreted DSL and non-interpreted code is not a  
continuum. There is a clear line between the two cases. Something is  
either designed to interpret external strings, or it isn't. There's  
no ambiguity.

Secondly, interpreted DSLs require different techniques than bottom-
up DSLs. As far as I know, C, C++ and Java cannot natively evaluate  
arbitrary strings the way Ruby and Smalltalk can. In those languages,  
you cannot even write code to interpret external strings without  
building a parser of some sort (thus creating an external DSL). Even  
in Smalltalk and Ruby, evaluating strings requires (at minimum) an  
additional method call. More importantly, you have to decide what  
context you are evaluating the string in.

There are also other decisions that need to be made when building an  
interpreting DS that don't have to be made (or cannot be made) when  
simply building a bottom-up DSL. For example, how do you handle EOL  
symbols? Most Ruby DSLs interpret a line at a time, treating each  
line as a separate command. On the other hand, you could interpret  
the whole text as a chunk and treat EOLs just like any other white  
space.

As you can see, even if you're just repurposing the host language,  
building an interpreting DSL  requires an additional layer of tricks,  
tips and techniques that are not required for bottom-up DSLs.

Finally, there's the underlying reason behind why you're using the  
technique. Bottom-up DSLs are simply a tool for developers.  
Interpreting DSLS can also simplify the development task for  
developers; however, they also give end-users tools to change the  
application's behavior after it has been deployed. So, interpreted  
DSLs can solve a much broader range of problems than bottom-up DSLs.

All of this (unambiguous meaning, clearly different set of  
techniques, and broader range of intentions) are reasons why I prefer  
to limit the term DSL to interpreted DSLs. To my mind, there seems to  
be obvious ambiguity between what is a bottom-up DSL and what isn't  
(as exemplified by the "every significantly complex..." quote).  
Bottom-up DSLs don't require any specialized techniques--you're  
simply creating useful methods, classes and operators. And Bottom-up  
DSLS are simply another type of source code--they don't add any  
additional value outside development (here I'm including maintenance  
and testing--basically everything that's done in-house).

Bottom line is, my definition would make DSLs more obviously  
different from other, more mundane programming techniques.

-Rich-

Well then, I reassert my previous question:  Is it possible for someone to
do something with themes?  Is there a way to have "WinXP" theme, "Mac"
theme,
"Smalltalk-80" and "Squeak" themes that change everything to behave how one
would expect in those environments?  And maybe by default the theme is
selected
based on the platform?

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.

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.

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.

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.

As an example, I downloaded 3.8 from the web site and started trying to run
a cool 3d
example I saw on one of the tutorials.  Everything worked fine until I tried
to bring up
a viewer for my fish so I can make it move and stuff.  It brought up a
debugger because
the "costume" message wasn't understood.

I took your advice and went all around trying to understand the code.  In
the end it looks
like maybe the "WonderlandActor" class might have been a subclass of Morph
at some point
and isn't anymore.  Maybe it changed to a composite patern.  So I tried to
see if there was
a reference to something I could forward the message too.  But I didn't see
any morph's in
his instance variables, so at this point what?

All I can do is post a message on a mailing list.  I don't know who changed
what or why, I don't
know how it was suppost to work and I have no clue where I would look for
some kind of
documentation.

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 efficiencey from the language.

>You place great value on documents, OK, great, but not everyone does, no
>need to use such strong language.  You can approach the subject of more
>documentation without being insulting to those who disagree with you.
>Rather than arguing "for" documentation, you seem to be arguing "against"
>less documentation, rather like a creationist arguing "against" evolution
>rather than "for" creationism.
>

The arguments "for" documentation are obvious and I (and others) have stated
them.

Smalltalk has some good momentum right now because of what various folks
have done with
Seaside and the subsystems based on it (Pier and co.).  But momentum doesn't
mean anything
unless you can sucessfully turn it into something else before you lose it.

All the other languages will steal everything you have.  Anything good,
revolutionary, etc. will
be recreated in those languages and then they don't feel the need for
smalltalk anymore.  It
happened with Steve Jobs in the beginning, it happened with Java when it
started and it will
happen with Seaside eventually.

And I am not just throwing out insults, I intend to help fix the problem.  
But first the problem
must be identified and acknoledged (no one will work to fix something they
feel is not broken),
then possible solutions have to be explored.

What I saw from dandelion that looked interesting was the ability to export
directly to a UML tool.  Then you would have the ability to see the links
between
the classes visually.  At least that's how it looked to me.