Info on Smalltalk DSLs or Metaprogramming...

On 8/18/06, Rich Warren <[hidden email]> wrote:
> In Ruby this could be done as follows (calls the new_run method and
> passes in a hash):
>
> new_run name => 'my name', id => 0, agent_count =>  200,  target =>
> 30sphere ,error => 1e-10, visualize => true

In fact, this could be Smalltalk, too.  new_run, id, agent_count, etc
would be instance variables and => and , would be messages.  30sphere
is not a legal Smalltalk id but you could use 30 sphere or sphere30.
Comma would be a funny message that took a "setter specification" and
returned a setter, and => would be a message to a setter that set the
appropriate variable.  It would be a pretty complicated solution,
though.

> The same thing in smalltalk would look like this (note, they can be
> in almost any order--'name:' is a constructor and must come first--
> the others can be in any order and can be dropped):
>
> TrialRun name: 'my name'; id: 0; agentCount: 200; target: 30sphere;
> error: 1e-10; visualize: true

This would work.

> or, for a prettier option (but one that sacrifices flexibility)
>
> TrialRun name: 'my name' id: 0 agentCount: 200 target: 30sphere
> error: 1e-10 visualize: true verbose: false

This would work, too.  You could also implement doesNotUnderstand: to
implement optional parameters so you would get back all the
flexibility you want.

> None of them are really as readable as I would like, but any would
> do. The last one is the most readable, but if the number of optional
> flags started to grow--it would quickly become a real pain.

How would you like it?  Invent a syntax, and we'll see if we can turn
it into Smalltalk.

Seems to me the difference between

name: my name, id: 0, number of agents: 200, target function: 30sphere,
maximum error: 1e-10, visualize

And this

TrialRun name: 'my name'; id: 0; numberOfAgents: 200; targetFunction:
#30sphere; error: 1e-10; visualize: true

Are so trivial, why bother with the parsing step at all, just use direct
Smalltalk syntax, if kids can learn Smalltalk, so can users of a DSL.  As
far as samples of DSL's go, I use one daily in the Seaside framework for
generating html http://www.seaside.st/Documentation/GeneratingHTML/, and
another http://scriptaculous.seasidehosting.st/, for generating JavaScript.
Both I think are good examples of embedded DSL's in Smalltalk in daily use.

On Aug 18, 2006, at 6:28 AM, Ramon Leon wrote:

First, thank you so much for the samples. I'll look at them as soon  
as I have time.

As far as justifying the parsing step, my main motivation is to have  
a config file that non-programmers can easily read. I don't want them  
to have to learn anything (or as little as possible). I would like it  
to be simple to write or change by hand too--so they can script their  
own series of trials--but that's a secondary consideration. For the  
actual trial runs, I'll undoubtedly create a large config file  
automatically, in order to ensure a thorough coverage of the possible  
permutations.

But non-programmer readability is the reason I'd love to have multi-
word selectors (instead of things_like_this or thingsLikeThis), and  
the reason I'd like to avoid strange punctuation (like => or the  
Smalltalk semicolons, or syntax to indicate that something is a  
string or symbol). And, finally, I'd like to get rid of any  
unnecessary words (new_run and TrialRun new)--unless I have different  
types of runs, it's just uninformative boilerplate.

Also, the parsed version could easily be case insensitive, allowing  
me to switch to something like this (if I thought it added clarity):

NAME: my name, ID: 0, NUMBER OF AGENTS: 200, TARGET FUNCTION:  
30Sphere, MAXIMUM ERROR: 1e-10, visualize

Or if I was just varying one parameter, and wanted to highlight it, I  
could use all caps for just that selector.

But it's only worth it if it's simple to implement. Case  
insensitivity is trivial. As is stripping off leading (or trailing)  
boilerplate. Replacing 'number of agents' with 'numberOfAgents' is  
also trivial, as is switching from commas to semicolons.

The only slightly tricky part is automatically adding quotes to  
strings and # to symbols--so I may just leave that out.

-Rich-

Rich I would suggest you to read the paper on aconcagua and unit  
published at OOPSLA and ESUG last year by hernan Wilkinson.
They should that extending in a clever way numbers they have a really  
natural way of expressing units and time.
For example, imagine that 1 st, April is a valid Smalltalk expression  
returning a date.

Then I think that you should pay attention about the assumption tthat  
you have regarding the syntax your readers can understand.
For example I'm skeptical that : is bad for argument. But you will  
tell us.

Stef


On 18 août 06, at 22:19, Rich Warren wrote:

On Aug 19, 2006, at 12:51 AM, stéphane ducasse wrote:

> Rich I would suggest you to read the paper on aconcagua and unit  
> published at OOPSLA and ESUG last year by hernan Wilkinson.

Thanks, I'll look for this.

> Then I think that you should pay attention about the assumption  
> tthat you have regarding the syntax your readers can understand.
> For example I'm skeptical that : is bad for argument. But you will  
> tell us.

I never meant to imply that colons were bad. In fact, my "ideal"  
syntax would use them. What I meant is, forcing you to use colons at  
the end of methods makes Smalltalk a little less flexible. There are  
some cases where, it seems to me, the colons would be intrusive.  
Particularly in methods that take a single argument.

Let's take the totally hypothetical situation. Say you wanted to  
interpret the words "See spot run".

In Ruby, "See" could be an object, "spot" a method and "run" a local  
variable.

As far as I know, you couldn't interpret the same thing directly in  
Smalltalk. You would need to write "See spot: run", which is where  
the colons become a problem.

Of course, there are other cases where the colon would come in handy.

Having thought about both languages a lot over the last few days, I'm  
pretty sure of the following:

1) Regardless of which language you use, there will be DSL elements  
that appear awkward or clunky (provided you do no string processing).

2) Some things will always be easier to write in the other language.

-Rich-

Ruby might allow parens to be optional allowing run to be sent to spot,
however, it'd look more like...

See.spot run

Hardly any better than

See spot: run

Besides, you could always setup spot as a member of see, then...

See spot run

Is perfectly valid Smalltalk, just like Ruby's...

See.spot.run

However you work it, I think the Smalltalk will come up with a more
natural English looking syntax due to it using spaces where ruby would
use periods and it using periods as a statement separator.

See spot run. Spot go home. Spot wag tail.

Is a perfectly valid Smalltalk statement, can Ruby do that?

On Aug 20, 2006, at 7:20 AM, Ramon Leon wrote:

You're right. I got confused skipping from one language to the other  
(and, as I previously mentioned, most Ruby DSLs are based on method  
calls within a class, not method calls on a class). Typically this  
would be done as chained method calls

see(spot(run)) => see spot run

>
> Hardly any better than
>
> See spot: run
>
> Besides, you could always setup spot as a member of see, then...
>
> See spot run

Of course. This is another valid way of chaining--only running the  
other way (#run is sent to the value returned by #spot.


As I tried to say before, my main point really, I think it depends on  
what you're familiar with. The more I look at both of them, the more  
I see good points (and annoying points) about both.

Basically you have to design the DSL around either language. And I  
really don't see anything in either that's a big win over the other.

Smalltalk's period can be nice, if you can design around it. It's  
better than Ruby's semicolon--but Ruby also lets you use line breaks--
which can lead to very nice multi-line constructions.

Smalltalk works better for multi-parameter methods--Ruby for single  
parameter.

Smalltalk's insistence on self for method calls within a class  
require you to have a class object (which often means an additional  
item you need to plan around--or one more item to use, depending on  
how you look at things).

Smalltalk's continuations are nice, but since Ruby lets you make your  
calls within a class, you can do the same thing with multiple calls.

Ruby's literal hashes are not great from a non-geek legibility  
viewpoint, but if you're making a DSL for coders, they're brilliant.

Overall, I don't see enough of a difference to really argue over.

-Rich-

Rich Warren schrieb:
> Ruby's literal hashes are not great from a non-geek legibility
> viewpoint, but if you're making a DSL for coders, they're brilliant.

Aren't Smalltalk dictionaries equally legible?

{
   'one' -> 1.
   'two' -> 2.
   'foo' -> 42.
} as: Dictionary

- Bert -

On Aug 22, 2006, at 2:36 AM, Bert Freudenberg wrote:

I'd argue Ruby (can be) a little more streamlined. If it's the last  
parameter, you don't need any brackets. And it doesn't need the as:  
Dictionary call.

However, thanks. I didn't know about this idiom, and I'll be sure to  
use it a lot.

-Rich-

Am 22.08.2006 um 21:22 schrieb Rich Warren:

well, if you insist on getting rid of the brackets in your DSL, this  
is legal Smalltalk:

        'one' -> 1, 'two' -> 2, 'foo' -> 42

Challenge: make that expression answer the dictionary as above

Solution: attached, but try yourself first ;)

- Bert -

Wow, Ralph Johnson mentioned this thread on his blog (http://
www.cincomsmalltalk.com/userblogs/ralph/blogView?
showComments=true&entry=3334257004).

Seems a bit odd, being called "The Ruby guy". Sure, I use Ruby.  
Sometimes. I also use lisp, smalltalk, objective c, java and (when  
forced) c++. Of them, Ruby and Smalltalk are probably my current  
favorites (unless I'm doing a GUI application for the Mac, then  
Objective C is probably the top). Unfortunately, I'm usually forced  
to work in Java, lots and lots of Java. If anything, I'm an unwilling  
Java guy.

Ralph also seems to have misunderstood what I was trying to say. I  
don't want to start a fight or anything, but I thought others might  
also have missed my point (or the larger point might have gotten lost  
when I started answering specific questions). I'd like to clear  
things up, since I think DSLs can be a very useful tool, and are well  
worth learning. I hope others might find them useful.

"...it took a little work to figure out what he meant. Part of the  
problem was that Smalltalkers make DSLs of a certain type so  
effortlessly that they just call it "programming"."

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). After all, we create functions, methods, objects,  
etc. that clearly and simply express the domain. In this sense,  
programming Smalltalk is very much like writing a DSL (though I think  
the trend is even more pronounced in Lisp). However, I don't think  
this definition is particularly useful.

When I spoke about DSLs, I was particularly talking about reading in  
and evaluating text files. The simplest example is a configuration  
file. Several of the online examples also follow this guideline.  
Admittedly, this is more useful for languages like Java (and,  
ironically much more difficult to create), since it lets you change  
an applications behavior without recompiling. There are still some  
clear benefits for Ruby and Smalltalk. Rails, for example, makes  
great use of DSLs.

You could argue that, for Smalltalk, the idea of a DSL is a bit  
strange, since it involves moving some of the code outside the image.  
Especially in Squeak, since (as far as I know) you have to leave the  
squeak environment to edit arbitrary text files.

"The Ruby guy wanted a little more, he wanted a certain syntax."

I'm not entirely sure what this means. I think he means I wanted a  
specific, non-smalltalk syntax. That's not really true. I'll probably  
implement my DSL using a pure smalltalk syntax (or smalltalk with  
minimal text processing). It's close enough for me. However, someone  
did ask what my ideal syntax would be--and so the thread went off on  
that tangent.

In general, yes. The advice to utilize Smalltalk syntax directly is  
good. That is what I had planned to do from the start. Originally I  
was trying to find examples of how others had used Smalltalk syntax  
to do this sort of parsing. I was hoping to learn a few tricks and  
tips by looking at other implementations.

"However, creating good languages is not easy, and few people can do  
it. I think that is the limiting factor in DSLs."

This is definitely true if you're trying to create a Turing Complete  
language for general programming. However, most DSLs are not Turing  
Complete. They are small, focused, little things. They do one thing,  
and they do it as simply and cleanly as possible. As a result, they  
are not typically very hard to write.

Here's an example of what I'm talking about. I'm about to implement a  
neural net. I'll be experimenting with many different sizes and  
topographies. This is an excellent opportunity for a DSL. I could  
create several net-building scripts that are then loaded and  
interpreted by the main application. Then, if someone wanted a  
different topography, they could just write and load their own build  
script. I could even build an object to automatically write out build  
script permutations. The scripts themselves act as both source code  
and log.

-Rich-

Hello group,

I have been reading through the mail list archives and I thought I would
share my thoughts as an outsider (at the moment) to the smalltalk community.
  I appoligize in advance for the size of this email. :)

Computers were not my initial profession, so I came in from a learn-as-you
go situation.  But I have been in IT over 10 years now and think I have a
pretty good idea of a possible silver bullet when I see one. :)  Smalltalk
seems to be the perfect development environment and what's more; it deserves
to be used more then the languages that are used right now.

Before I was an effienciency/static typing junky, but smalltalk has made me
rethink the typing at least. :)  After all, how many errors *has* that
really caught for me compared to all the times code didn't compile because
the compiler was confused about something that should work.

Smalltalk even showed me that self generating code could be a good thing.  
When I first heard of, and thought about the possibilities of this years ago
in Perl I cringed.  But the reason I cringed was simple:  Assembly, C/C++,
Perl, Java, everyone else really have two distinct modes:  Design mode
(where your code is layed out and how) and runtime mode (what it actually
looks like as a running system).  Self modifying code in this situation is a
scary thing because it pushes those two modes even further apart then they
were to begin with (which is often pretty far).  But smalltalk opened this
door for me because it doesn't have that problem.  The design and runtime
modes are almost the same thing.  If I impliment a "doesnotunderstand:" that
builds any messages it recieves, let it run for a few days and then come
back, the system will have made my methods for me.  Then I can take that
method out if I want.  Amazing.  But it's ok, since the source code and the
running system are almost one and the same this practice doesn't cloud my
view of what the running system looks like.

As I have been looking through the programming languages out there (have
been between jobs, so I decided to brush up on my programming a bit) you
can't help but see lisp.  I know lisp people hate to hear it, but lisp seems
like the best of research languages.  It seems like every advance in
languages came from lisp at one point or another.  But it feels like
smalltalk has taken the advances and made them usable by the normal man.  
And smalltalk did the right thing taking the real ideas, not a castrated
version of the idea.  The exception mechanism for example (see C++, Java, et
al), smalltalk has method resumes, restarts, everything.

Perl is the classic case of a sense of loyalty taken too far.  A man saves
your life (and perl did save us.  We were programming CGI in C before it
came along and woke everyone up) but as time goes by he has asked to move in
with you (perl decided cgi and sys admin wasn't enough, it wants to develop
all your apps!) and one day you dont see him anywhere but cloths are all
over the floor, perl and your wife are no where to be seen and there is some
uncomfortable noise comming from upstairs.  But he saved your life right?

Perl is a disgusting hack from top to bottom.  It is a filesystem based
language like the rest, but even having a source of more then one file is a
hack.  "Why do I need a 1; at the end of my file again?  Oh right, someone
somewhere might want their file to execute code when it gets included and in
perl TIMTOWTDI!  Since they might, we all must?  What was that you said
about 'simple things simple, hard things...'?".

Ruby is of course appealing because it has something like the smalltalk
syntax.  But in the end it is a script language and to get where it needs to
be to be the best it needs to, well, be what smalltalk is right now.

What about Java?  Well you can build anything you want with turds and glue.  
You can build a big boat, you can build a huge castle, but what do you have
at the end?  A big smelly pile of crap.  That is what Java is in my mind.  
If the universe is "turtles all the way down", smalltalk is "objects all the
way down" and Perl is "hacks all the way down" then Java is surely
"inconsistancy all the way down".  And just as perl has shown, a million
monkeys typing on a million keyboard wont reproduce the works of
Shakespeare, and it also wont turn a big pile of crap into a Ferrari.  But
it might be able to build something to get you to work if you can bear the
smell.

So what went wrong?  You have the right idea, why isn't everyone here
already?

Reading through the list, a few things struck me:

First, Luckas and Andreas fighting over extending functionality vs. backward
compatibiltiy.  Well, I wouldn't presume to take sides in such an argument,
but there are a couple of important points we must always keep in mind:
backward compatibility is a noble cause.  No one wants to work where they
syntax of the language can change before you can even get your program that
used the "old" syntax finished.  But on the other hand, backward
compatibility is an open paracute on your back.

In Estonia in the early 90's it was not uncommon to not have running water.  
Only about 50% of the population had a phone line.  But in 2004 Estonia
became the most technologically advanced nation in all of EU, maybe the
world.  It has the largest % of cell phone users, the government was
completley paperless!  How did they come so far so fast?  Simple: no
backward compatibility what-so-ever.  No one screamming "Wait!  I'm still
using windows 3.1, we can't make that change!"  No open paracute's on
anyones back.

So what is the right answer between Luckas and Andreas?  I don't know, but
when we talk about backward compatibility, while we dont want to break
things just to say we did, we also can't get in a situation that takes 15
years to dig out of.  In some cases backward compatibility is the 100% right
answer, but in my mind the backward compatibility side has 1 default mark
against it.  If it is indeed the right answer, then it should be able to
overcome this easily, and perhaps this particular argument is just such a
case.

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 of those
have huge business backing them.  The languages that do *not* have this kind
of backing, but are sucessfull are all script languages, or can run in
script mode.

How hard would it bee to just make an image that looks a little different
then the default image, it expects arguments set up the way they are with
typical #! setups?  And any syntax chosen needs to look as close as possible
to what smalltalk is now.  No new strange constructs that are totally
different inside the image, no meta-programming as a rule.  It needs to look
like it does in the browser.

Tim is right, this would be a step back.  Smalltalk has a much better
environment if you just use the image.  But what is more important at this
point: being right, or getting a bigger base for the language?  I know which
one I would pick.  I know it's frustrating having the solution and having to
stuff it down peoples throats, but if hair dryer companies can put those
stupid labels on hair dryers, can't we give a scripting option?

And hey, when a squeakscript user says "By the way, have you guys got any
kind of debugger?"  Out pops the smalltalk salesman complete with a huge
grin and a cheasy suit saying "Why sure!  Just run this" and presto, when
they see they can change code in the debugger and it just resumes from
there, most of them are going to become converts.  But first you have to
drag them kicking and screaming somehow.

I'm sure the Howard Aiken quote is familiar to all smalltalkers: "Don't
worry about people stealing your ideas. If your ideas are any good, you'll
have to ram them down people's throats."

What smalltalk also needs is a killer app.  Maybe seaside will be that
killer app if the inferier language crowd doesn't steal it first.

But no matter how you get them here, it wouldnt matter one bit today because
they wont stay.  Why?  Because smalltalk documentation is like a ghost town.
  When I found whysmalltalk.com (shows up #4 if you google "smalltalk
tutorial") I was excited about all the examples and tutorials.  After 90% of
the links pointed nowhere I started doing searches on the net to find out if
I was simply too late, maybe smalltalk was dead already.  And your own
squeak site isn't much better.  Nothing screams "no one lives here anymore"
like dead links.  And the more dead links the loader the scream.

One thing I think I disagree with stéphane about (not sure I understand his
point exactly) is the releases.  If a squeak version is released in the
forest and no one is there to see it, will anyone care?  Fixing bugs are
important if that's what you mean by release.  New features to help support
those killer aps are important.  But if you don't have any documentation
anywhere no one will stay.  I stayed because I was determined to fix this
gap in my knowledge and learn this language, dead or not.

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.  If you don't want to document then for God's sake, hand it off to
someone who will.  Not every single method ever of course, but anything the
API user uses directly should be documented.

And it needs to be consistant too.  I'm a "digger", if it is there I will
find it.  But most people aren't.  If your solution is "well go to the class
side, there is maybe some method there that documents the class" then you
don't have a solution.  "Documentation is always on the class side in the
'documentation' protocol (and here is how you find that)" would be much
better.

You have a very friendly mail list, the best I've ever seen to be honest.  
But that doesn't overcome documentation.  People are not trained to look on
mailing lists for documentation.  When thinking about users you have to
think Homer Simpson.  You can scream "look in the news groups" on every page
and he will say "Thanks, what is the link to/program that shows the
documentation?".

I hope someone somewhere finds something I said useful. :)

Hi!

Rich Warren <[hidden email]> wrote:
[SNIP]
> You could argue that, for Smalltalk, the idea of a DSL is a bit  
> strange, since it involves moving some of the code outside the image.  
> Especially in Squeak, since (as far as I know) you have to leave the  
> squeak environment to edit arbitrary text files.

No, you do not need to leave Squeak for that. Filelist and friends edits
files.
But writing Smalltalk code in a file from within Squeak is definitely an
odd way of doing it, unless you have a specific goal doing that.

Eh, "utilize Smalltalk syntax" (and not actually *use* the available
Compiler) seems less useful.
I mean, if you want Smalltalk syntax - why not use *Smalltalk* and not
just the syntax?
Use the Compiler that we already have and that is battle proven etc.

And if *I* would do it I would just use Smalltalk. :) IMHO specific DSLs
tend to get outgrown. They look simple from the beginning, and then you
bang your head against the roof. And the effort to create them often
(IMHO) does not pay off that much compared to "just use Smalltalk" (or
Lisp etc).

In Gjallar we use Smalltalk as the "DSL" for defining the workflow graph
for example, it looks simple enough for most readers AND we can easily
do special things when we need to. And no time spent writing a custom,
half buggy parser. :)

Thing is - it is fun to make languages and I think DSLs often are
created just because it is fun to do it. Or you simply don't have a
language where the parser/compiler is so readily available. I mean:

        Compiler evaluate: '3+4'

regards, Göran

Hi J J,

you seem to already know all the best kept secrets in and around Smalltalk  
and Squeak, you're not really an outsider :)

Thanks for sharing your thoughts.

/Klaus

J J wrote:

> Java is surely "inconsistancy all the way down".  

ROFL

> I'm sure the Howard Aiken quote is familiar to all smalltalkers: "Don't
> worry about people stealing your ideas. If your ideas are any good,
> you'll have to ram them down people's throats."

Yup, and we Smalltalkers usually are way to polite to do this ;-)

> What smalltalk also needs is a killer app.  Maybe seaside will be that
> killer app if the inferier language crowd doesn't steal it first.

Seaside is certainly the killer app in the website application area
demonstrating a viable alternative to scripting.

Another one could be Sophie (OK, I'm one of the developers ;-) ).

> I hope someone somewhere finds something I said useful. :)

Thank you, thank you, thank you :-)

Michael

On Aug 29, 2006, at 10:34 PM, [hidden email] wrote:

> But writing Smalltalk code in a file from within Squeak is  
> definitely an
> odd way of doing it, unless you have a specific goal doing that.


You're not writing Smalltalk code in an external file, you're writing  
DSL code (text that happens to be interpreted and parsed as Smalltalk  
code). It's a subtile difference, but I think an important one.

And you might not write any code at all. You could be passing  
messages as strings between remote agents. You could be automatically  
parsing Unix log files. You might be scanning a text document for  
tags which will be automatically replaced with computer-generated  
content (for example, putting actual source code into an article  
about computer programming at the last minute, so you don't have to  
worry about copying-pasting and keeping things in sync as you edit  
both files).


> Eh, "utilize Smalltalk syntax" (and not actually *use* the available
> Compiler) seems less useful.
> I mean, if you want Smalltalk syntax - why not use *Smalltalk* and not
> just the syntax?
> Use the Compiler that we already have and that is battle proven etc.


I'm not sure why I'm having so much trouble expressing myself on this.

Of course I'd use the compiler.

Compiler evaluate: 'some text from file'.

This is exactly what I'm talking about (and why people recommended  
using smalltalk syntax directly as opposed to creating my own syntax  
and building a parser).


That is certainly a valid option.

For something like this, planning a DSL can be a really helpful  
experiment. Even if I end up implementing it directly, I end up with  
a set of classes/methods that are cleaner and easier to use.

Also, who might use the DSL. If the end-users might want to modify  
the code, then it may be better as a DSL (unless the end-users are  
smalltalk programmers).

And DSLs can often serve dual purposes. A single source file might  
generate both code and documentation (or in my example, function as  
both executable code and as a log file).  You can gain a lot by  
having a single, authoritative copy of the important information  
(provided you back up that copy, of course).

But, if you're not going to get anything out of it, just implement it  
directly.

>
> In Gjallar we use Smalltalk as the "DSL" for defining the workflow  
> graph
> for example, it looks simple enough for most readers AND we can easily
> do special things when we need to. And no time spent writing a custom,
> half buggy parser. :)

Again, I'm not talking about making a full parser. Maybe some light  
preprocessing of the input (maybe), but you should use Smalltalk for  
the heavy lifting, where possible.

>
> Thing is - it is fun to make languages and I think DSLs often are
> created just because it is fun to do it. Or you simply don't have a
> language where the parser/compiler is so readily available. I mean:
>
> Compiler evaluate: '3+4'

I really think we're talking about the same thing, just using  
different words. '3+4' is too trivial to be a DSL, but this could work:

run: 'name' trainingSet: 'training file name' testSet: 'test file name'

And, with the right classes (and preprocessing) it could be parsed  
and interpreted directly as code.

e.g.: Compiler evaluate: 'myClass ', lineFromFile.

There's no half-buggy complier. Smalltalk does (almost) all the work.  
And yet, this is exactly the type of DSL I have been talking about.

I hope I'm starting to make more sense.

-Rich-

When I first saw squeak 2 years ago, I just gave up immediatly and
started with vw... Then I decided to use seaside and the vw port was
just starting so I choose to use squeak and I don't regret it now that
I'm used to it...  and for me 3.9 is more appealing than the previous
version which is cool (Thanks all)!

I don't think mainstream anymore  ;)

>> What smalltalk also needs is a killer app.  Maybe seaside will be
>> that killer app if the inferier language crowd doesn't steal it first.
>
> Seaside is certainly the killer app in the website application area
> demonstrating a viable alternative to scripting.
Actually, I find it's even a bit more (than just web site application),
a kind of showcase of the power of the whole stuff :)
... it's an entry points to squeak and also a real alternative GUI
(multiplatform etc...).

Indeed, I think it would be really cool to have a web2.0 IDE (just for
outsider to start to familiarize)... a bit like here:
http://mmm.seasidehosting.st/seaside/liveWeb  (not working now...)  with
a cool live browser (like the class browser of scriptaculous). I'm sure
such an app would call people's attention to squeak ! And once you're
in, you're addicted :)

Cédrick

"J J" <[hidden email]> writes:

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.

Thanks. :)  I will go out and look at Sophie.  I don't recall hearing about
it yet.

And I certainly plan on writing some code once I figure out what is needed.  
Network
Management has traditionally been my space so I had planned on making an
SNMP
client library if one doesn't exist already.  I see telnet already had some
packages.

>>>>> "J" == J J <[hidden email]> writes:

J> Perl is the classic case of a sense of loyalty taken too far.

Your opinion of Perl is interesting, and not uncommon.  But if you haven't
seen what we're doing with Perl6, you might be missing something.

The object system of Perl6 (and necessarily of the Parrot VM below it) borrows
a significant amount from Smalltalk and Self.  The designers are fans.  The
formal introspection and malleability of Perl6 will rival Smalltalk, and
that's a Good Thing.  The Parrot VM design is quite nice, and will allow a
CLR-style interoperability amongst many languages.  I'm hoping someone will
port Squeak to it, in fact.

One thing to keep in mind (considering VHS vs Beta, Windows vs Unix), is that
a "successful" item isn't necessarily the "best" item: it merely has to be
"good enough".  In that case, we can compare the number of applications today
running Perl vs running Smalltalk, and we see that Perl is "successful", and
Smalltalk a "failure", by that measure.

Personally, I had discovered Smalltalk in 1981, running on a Magnolia at Tek
where I had essentially unlimited access for two months.  And I've been
disappointed in nearly everything else ever since, and especially mad that
Steve Jobs took only the surface features of ST80 for the Mac, leaving the
elegant underpinnings as a discardable novelty.  I still rave about how in
1981, I could get a full source-code stacktrace of the running application
just by pressing a key, but that the backtrace was *live*, allowing full
inspection/edit and *continue*, some thing that still doesn't exist today.  In
1981.  On a 1 MHz processor.

But I had to make a living, so the theoretically cool gets tossed aside, and
the practical takes over.  I still dabble with Squeak, but I make my living
with Perl.

Maybe a future version of Squeak will be deemed "practical" enough to shake
the "smalltalk is slow" or "smalltalk is weird" syndrome to rival Perl6
(et. seq.).  That'd be great.

But I'm not holding my breath, or betting my company on it.  :)

--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<[hidden email]> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!