Info on Smalltalk DSLs or Metaprogramming...

J J puso en su mail :

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

Ich kann keine Deutsche, but could learn if have time :=)
 
> 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.

And what is that site ?
I could use any web space as I build my SqueakLight images and still don't
could have it in a 24/24 place somewhere.

The centralized site now is minnow, on that site all people could put
tutorials, news, etc.
But regular swiki have some little troubles



       
       
               
__________________________________________________
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

Ich kann kein Deutsch, aber ich könnte es lernen, wenn ich Zeit habe. :)  I
think thats it anyway.  Should be easy for you, the grammer is like a
programming language spec. :)

I am thinking squeak.org is the place to set up shop.  But no one answered
me yet how to
get started and I haven't had time to dig yet but that is what I am thinking
at the moment.

On Wed, 06 Sep 2006 08:57:02 +0200, J J wrote:
Perhaps this lady wants to be employed for a documentation project

- http://sophieproject.org/intro.pdf

/Klaus

Klaus D. Witzel puso en su mail :

> Perhaps this lady wants to be employed for a documentation project
>
> - http://sophieproject.org/intro.pdf
>
> /Klaus
>

Congratulations by outstanding work, but...

That opera singer lady (67,8 Mb) should be accessible to all.

And the most important, all wizards working on it should finish and continue
transfer vital technology breakups to "rest of us" , as Mac add say a long
time ago.

Regards

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

> 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.
> [:masashi | ^umezawa]

That's not abstraction, that's duplication.

And what about UML diagrams?  Isn't that just duplication too?  I mean all
it
is is a different view of what the code says right?

Look, despite my strong feelings about so called "self documenting code" I
am laying off.
If you want to work that way fine, but shouldn't you extend my "side" the
same honor
of not trying to impose your way on people who want some kind of
documentation that
is meaningful for us?

> And what about UML diagrams?  Isn't that just duplication
> too?  I mean all it is is a different view of what the code
> says right?

UML diagrams would be a different view of the code, they can add value, they
let you see the system in a different way.  I didn't criticize this.

> Look, despite my strong feelings about so called "self
> documenting code" I am laying off.
> If you want to work that way fine, but shouldn't you extend
> my "side" the same honor of not trying to impose your way on
> people who want some kind of documentation that is meaningful for us?

I wasn't.  I was calling dandelion duplication because it's only showing
what the existing class browsers already show, it doesn't add significant
value, other than possibly allowing non programmers to read the programmer
comments, which I'll admin, could be of value to someone, it's very much
like javadoc.

Todd Blanchard puso en su mail :

> There is also the Objective-C bridge.
>
> -Todd Blanchard
Todd:

What is the last info , some for read, some for try about the Objective-C
bridge ?

Thanks


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!

"J J" <[hidden email]> wrote:
> Nice.  I didn't see Gjallar on the squeak projects page or on the seaside
> site.  Where are you
> advertised? :)

Gjallar is an inhouse developed issue tracker that has recently been
open sourced by the customer. I work as a consultant. The current web
site is here:

        http://swiki.krampe.se/gjallar

We haven't had time to "advertise" it yet. But it has been announced on
squeak-dev a little while back.

The current release is strictly "developers only".

> Also, do you think those two classes you mentioned could be used to make a
> squeak script
> front end?  I mean, would it be possible to change some classes of how the
> image acts on
> start up to give arguments to classes like those and try to run them?

Possible indeed, rather simple I think - but I am not sure what is
actually needed.

The basic mechanism of executing scripts using command line arguments is
already present in the image and in the VM. I use it to "jump start"
images on headless machines for example. Like a small script that fires
up Seaside, sets some settings etc. It is a bit awkward to specify the
file as a *correct* file URL, but it works.

But granted I am unsure how the current mechanism deals with syntax
errors, undeclared vars, etc. Not sure what feedback you get - if any.
:) So yes, that might be worth looking at - unless someone else has
already done it. It is not the first time this "scriptability" thing has
popped up.

And almost all other issues that have been extensively discussed the
last few weeks on Squeak-dev have also been discussed on numerous
occasions for the last 10 years. Yup, I am not kidding. And I am not
trying to dissuade you all from pursuing these discussions by all means
- but you might want to do some digging in archives. There is a LOT to
be found there.

For example - the problem and ideas around documentation and a
documentation team is a really well known "issue" in the Squeak
community. There have been numerous attempts, numerous ideas (one
example from me even called the Magic Book), numerous failures and also
numerous small successes.

And if you search the Swiki you could find for example:
        http://minnow.cc.gatech.edu/squeak/3004
        http://minnow.cc.gatech.edu/squeak/2997

Hmmm, but I really intended to talk about this in another post, sorry.

regards, Göran

Thanks very much for your honest response (i.e. not holding anything back).

(comments below)

Well, I haven't noticed anyone saying they have done it yet (have seen
different
solutions on different platforms, but not something for squeak yet).

>And almost all other issues that have been extensively discussed the
>last few weeks on Squeak-dev have also been discussed on numerous
>occasions for the last 10 years. Yup, I am not kidding. And I am not
>trying to dissuade you all from pursuing these discussions by all means
>- but you might want to do some digging in archives. There is a LOT to
>be found there.
>

I am not surprised at all.  I know you guys have been working hard for the
whole
time.  But maybe today something will be different to make it work.  Or
maybe
the approach this time can be different enough to work.

>For example - the problem and ideas around documentation and a
>documentation team is a really well known "issue" in the Squeak
>community. There have been numerous attempts, numerous ideas (one
>example from me even called the Magic Book), numerous failures and also
>numerous small successes.
>

But how many of these have not worked because the scope was too big?  I used
to work with a guy in america who was a great programmer and a very bright
man.
But if you wanted a project from him it was going to take months or years.  
Requirements
always change and he just wouldn't release anything that didn't do
everything the customer
wanted.  For a constantly changing definition of "everything".

I think if the initial try is modest, just a quick cut to get us better then
we are right now,
and then move from there it would have a chance.

But I just really think this *has* to get fixed if smalltalk is to go where
it belongs.

Where does smalltalk get the next generation of developers?  College?  
Unfortunatly no.
College has the same financial responsibilities as everyone else.  The
companies that donate
money to them want people who know <insert fad language>, not some language
they
don't know.  The studends want to learn <insert fad language> because most
are there to
get good paying jobs.  To get college to start teaching more smalltalk, more
companies have
to use it.  *Lots* more companies then are using it right now.

Kids?  I appreciate the work that has gone on in this area for sure.  But
this isn't how
smalltalk is going to get the next generation of developers.  These kids
will play with it,
enjoy it, then grow up, go to college and if they even do some CS related
degree they
are going to be learning <insert fad language> because (a) that's what's
taught and
(b) that's what pays.

The place smalltalk gets it's new developers is the place everyone gets
them: mostly from
the existing base of developers.  But if you want to get people from the
existing base then
they have to see that this language is going to help them get their work
done.

This is why so many people switched from Perl to Ruby and Python.  It was a
familiar world
but without all the badness of the world they currently lived in.

I am not saying smalltalk needs to turn into java, certainly not.  But there
need to be some
things that java people recognize.  Like documentation in a form they
expect.  And maybe
a simple script interface for people comming from that side of the house.

I relize it has been tried before.  But I think it has to be tried again
until it works. :)

> The place smalltalk gets it's new developers is the place
> everyone gets
> them: mostly from
> the existing base of developers.  But if you want to get

True

> people from the existing base then they have to see that this
> language is going to help them get their work done.

And they are, Squeak is growing well.

> This is why so many people switched from Perl to Ruby and
> Python.  It was a familiar world but without all the badness
> of the world they currently lived in.

And Ruby draws attention to Smalltalk, since it's heavily influenced by
Smalltalk.

> I am not saying smalltalk needs to turn into java, certainly
> not.  But there need to be some things that java people
> recognize.  Like documentation in a form they expect.  And
> maybe a simple script interface for people comming from that
> side of the house.

Nah, the Java developers are running in droves to Ruby, great, it'll
acclimate them to Smalltalk, Ruby is after all Smalltalk lite.  You can't be
a Ruby programmer, and not hear of Smalltalk, it's only natural to check it
out.

> I relize it has been tried before.  But I think it has to be
> tried again until it works. :)

You assume it isn't working now, but it is, Seaside's bringing many a new
developer to Smalltalk, myself included.  Watch the lists, there's plenty of
new developers popping up all the time.

Maybe.  Or maybe this is momentum which will fade in time if it isn't turned
into something
else.  Seaside is bringing them here, that is 100% right.  But how many are
looking around
at all the cool things in the 3.8 image but can't get anything to work and
can't find
documentation to do anything?

At some point the other languages will have seaside completely duplicated.  
If you haven't
gotten a permanent increase in body count by the time that happens then your
chance
is over until the Avi, Luckas and co. come up with the next killer app.

> Maybe.  Or maybe this is momentum which will fade in time if
> it isn't turned into something else.  Seaside is bringing
> them here, that is 100% right.  But how many are looking
> around at all the cool things in the 3.8 image but can't get
> anything to work and can't find documentation to do anything?

I prefer to be an optimist, I've been studying and learning Smalltalk for
about 3 years now, and I've seen nothing but growth in the community. I have
no reason to fear that will change.

> At some point the other languages will have seaside
> completely duplicated.  

Not likely, if it were so easy to do, Smalltalk wouldn't have been chosen as
the implementation language.  I believe Ruby was Avi's initial choice, but
he ran into problems with it's continuations (I could be wrong).  And most
languages don't even have continuations, they aren't suitable to do this.

> If you haven't
> gotten a permanent increase in body count by the time that
> happens then your chance is over until the Avi, Lukas and
> co. come up with the next killer app.

Smalltalk has nothing to fear from other languages, seriously, they can't be
everything Smalltalk is without becoming Smalltalk, and none of them are
even close at the moment.  Smalltalk is much more than just a language, it's
an environment, something those other languages haven't figured out yet,
Lisp excluded.

On Sep 6, 2006, at 3:14 PM, Ramon Leon wrote:

I wrote something about that history here:
http://smallthought.com/avi/?p=4

Seaside itself could probably be duplicated on another platform  
(especially on Ruby), but then, you wouldn't have Smalltalk - and to  
a large degree I see Seaside as a (good) way to write web  
applications in Smalltalk, not Smalltalk as a way to support Seaside.

Avi

Not sure why I missed Ramon's email, but I will respond to both below.

M.C. Hammer was an optimist too, he had been sucessful for a few years,
and he had seen nothing but growth in his bank account.  He had no reason
to fear that it would change.  But it did.

>>Not likely, if it were so easy to do, Smalltalk wouldn't have been  chosen
>>as
>>the implementation language.  I believe Ruby was Avi's initial  choice,
>>but
>>he ran into problems with it's continuations (I could be wrong).

I didn't say it was going to be easy to do.  But it can and will be done.  
It's
being worked on right now.

>I wrote something about that history here:
>http://smallthought.com/avi/?p=4
>
>Seaside itself could probably be duplicated on another platform  
>(especially on Ruby), but then, you wouldn't have Smalltalk - and to  a
>large degree I see Seaside as a (good) way to write web  applications in
>Smalltalk, not Smalltalk as a way to support Seaside.
>
>Avi

Thanks for that Avi.

I think Ramon is overlooking the general populations dislike of change.  
When ever
someone sees seaside, and gets what is really cool about it, the first thing
99% of them
will do is look to see if something like that exists (or is being worked on)
in their favorite
language.  If it is, most of them wont look any further.

I'm an optimist too, when my bases are covered.  But if major bases are
*not* covered
then any cofidence in sucess is not optimism.  It's naiveness.

On Sep 4, 2006, at 10:44 AM, Herbert König wrote:

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

Regarding reinforcement learning, I've seen this complaint form other  
EE people, and I never really understood it. Perhaps you could give  
me an example. In my opinion, it really depends. I believe the "no  
free lunch" principle shows that all learning systems are identical  
when averaged over all possible problems--so efficiency really  
depends on the specific problem.

Reinforcement learning has a number of advantages: it can work very  
well on systems where you receive intermitted rewards or punishments--
especially if the rewards only come after a series of actions (for  
example, games). Reinforcement learning can also continue after the  
agent/software has been deployed, allowing it to continue to update  
its behavior in the real world.

  Also, for many domains, learning speed isn't much of an issue. You  
train the system, save the trained state, then run it from the  
trained state. The training should be a one-time cost.

As for the details on my project, I don't know. I'm still in the  
planning stages (and pouring through a lot of biology/evolution  
papers right now).


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

I've worked on projects where we have trained the system for several  
days. Again, this is a one-time cost. If I put in a month of coding  
time, a few days of training (which can run over the weekend) doesn't  
seem that much. Many ML techniques can take a long time to train, but  
the end results can be very fast in use.

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

Not off hand (though I always recommend searching on http://
citeseer.ist.psu.edu/). If you're just trying to train the weights,  
you can just read the bits into an array and use that as your genome.  
If you want to evolve both the weights and the size/topography, you  
need more sophisticated methods. I know some people have worked on  
different ways to encode neural nets (basically compressing the  
layout/weight information, much the way our DNA compresses all the  
information needed to build a human body).  I can't find the  
reference in my notes right now, however.

-Rich-

On Sep 5, 2006, at 6:51 AM, Ramon Leon wrote:

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

Here's the thing (then I'll shut up, I promise), I don't think I'm  
redefining the term. Almost all the information I originally read  
about DSLs discussed them from an interpreting, internal DSL  
standpoint. I think there are a large number of people who use DSL  
this way. A lot of people use it the other way. Some are sloppy in  
their usage. All of this leads to a great amount of miscommunication.

For example, most of the Ruby DSL stuff on the web is about  
interpreting external files (or at least, most of what I've found).

I actually haven't found any authoritative references that use DSL  
for either Smalltalk or Lisp in the way you describe. The  
authoritative piece on programming lisp (from OnLisp) that describes  
using these techniques refers to them as 'bottom-up programming', not  
DSL. Don't get me wrong, I'd love to be proven wrong here (heck, I'd  
love to see any decent descriptions of using lisp or Smalltalk for  
writing DSLs, for any possible value of DSL).

I'm fine excepting your definition of DSL. However, I still think  
there should be a way to describe the more specific, interpreted  
case. There's a lot of value in looking at the interpreted case as a  
separate technique. And that's hard to do if you say DSL and everyone  
just makes their own assumptions.

-Rich-

On Sep 5, 2006, at 5:21 AM, tim Rowledge wrote:

Space for more windows. Space for organizing windows. There's never  
enough space.

I've gotten lazy on my mac desktop. I can have dozens of windows open  
and because of the way I work (a combination of Quicksilver and  
Expose) I can dance between them with ease.

When working in Squeak, I like to have as similar a setup as  
possible. I often have two or three browsers open (all on different  
parts of code). I will have at least one workspace and a transcript--
at a minimum. Other windows rapidly accumulate.

It's not as easy to shuffle between windows, so I like to lay them  
out so they are as visible as possible (or so it's easy to bring the  
desired window to the foreground with a single mouse click).

Quicksilver and Expose make this a partial solution. I can still jump  
from Squeak to my desktop and back with ease. What I can't do is  
place a small browser window over a near-full screen safari window,  
so I could reference information from a web page while I code without  
having to move anything.

-Rich-

(Just to be clear to everyone who has already commented on possible  
solutions for this, I'm not ignoring you, I'm just trying to answer  
the question at hand.)

Hello Rich,


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

RW> Regarding reinforcement learning, I've seen this complaint form other
RW> EE people, and I never really understood it. Perhaps you could give
RW> me an example. In my opinion, it really depends.

regarding slowness, I'm an absolute beginner on neural nets and only
read about how much rounds of training it needs. Currently I'm in the
stage of: "Is my data representation suitable for processing by a
(which type of?) neural net?"

Going through: training the net -> evaluate network performance ->
change data representation or network topology .....
feels slow in absolute terms.

And a single layer perceptron behind a self organizing feature map
trains much faster than a multilayer network (only a few of the nodes
are trained) with comparable results (in my special case).

As soon as I know that a training will yield the "best possible"
result, I will be cool if a computer needs to run a weekend to train a
network.

On the other hand, soon after I reach that state, the subject will get
boring :-))

RW> Not off hand (though I always recommend searching on http://
RW> citeseer.ist.psu.edu/). If you're just trying to train the weights,
RW> you can just read the bits into an array and use that as your genome.
RW> If you want to evolve both the weights and the size/topography, you
RW> need more sophisticated methods. I know some people have worked on
RW> different ways to encode neural nets (basically compressing the  
RW> layout/weight information, much the way our DNA compresses all the
RW> information needed to build a human body).  I can't find the  
RW> reference in my notes right now, however.

Thanks!


Herbert                            mailto:[hidden email]

On Sep 6, 2006, at 11:40 PM, Herbert König wrote:

I was actually asking about reinforcement learning. I've heard other  
EE people complain about reinforcement learning, saying it was too  
slow. However, I've used it to good effect on a few projects. It  
makes me wonder if they're using it for the wrong purpose, but I  
never got a chance to ask anyone for details (or rather, the one time  
I did ask, the EE professor just scoffed at me and said "they're just  
to slow!" without explaining anything).

Reinforcement learning  can, however, be really fussy when it comes  
to training neural nets. Some of the early research showed great  
results training neural nets, but the researchers were already  
experts at implementing neural nets for the given domain, so they  
knew how to represent the data effectively. I think the issue here  
has been the neural nets, not the reinforcement learning.

Neural nets are really fussy. You have to grey-code all incoming  
numerical data. There's no good a priori way to determine how many  
nodes or levels you should have. It's hard to know how much you  
should train it, since they are subject to overfitting.  
Experimentally trying to determine these settings can take a lot of  
time (alter...train...test...iterate).

That's one of the reasons I'm interested in trying out genetic  
algorithms for building neural nets.
If it's possible to have neural nets that automatically grow to  
reasonably fit the problem space, then that would be a big help.

So far, however, I've only played with static neural nets, training  
them using either backpropogation or reinforcement learning.

-Rich-