Seaside (Smalltalk web development framework)

[Giles Bowkett]

http://video.google.com/videoplay?docid=-9059529534041031582&q=seaside

--
Giles Bowkett
http://www.gilesgoatboy.org

[Owen Densmore]

Hmm..this leads me to ask the question:
   Who of us currently uses Smalltalk/Squeak?
   If so, which implementation?

I'd be interested in your experiences.  We often talk about rapid  
prototyping, but we seldom actually do it.  But my friends at PARC in  
the early days, and a couple of hold-outs at SunLabs could perform  
magic very, very quickly.

I like this quote from the Squeak web site:

   You may be familiar with other open source languages like Ruby or  
Python, but Squeak takes these concepts much, much further offering a  
true uniform fully reflective environment - real live objects.

    "The real romance is out ahead and yet to come. The computer
    revolution hasn't started yet. Don't be misled by the enormous
    flow of money into bad defacto standards for unsophisticated buyers
    using poor adaptations of incomplete ideas."
      - Alan Kay


     -- Owen

Owen Densmore   http://backspaces.net


On Sep 12, 2006, at 6:38 PM, Giles Bowkett wrote:

> http://video.google.com/videoplay?docid=-9059529534041031582&q=seaside
>
> --
> Giles Bowkett
> http://www.gilesgoatboy.org
>
> ============================================================
> FRIAM Applied Complexity Group listserv
> Meets Fridays 9a-11:30 at cafe at St. John's College
> lectures, archives, unsubscribe, maps at http://www.friam.org

[Michael Agar]

Owen--I'm curious about this as well. In the late 1990s back in  
Baltimore I asked a SWARM programmer at Hopkins what language I  
should work with to avoid the heartbreak of Java but still be able to  
create ABMs. Squeak, he said. Messed with it some but then the  
Netlogo empire started cranking up and I converted.

I'll be interested to read how FRIAM'ers evaluate it.

Mike



On Sep 13, 2006, at 9:43 AM, Owen Densmore wrote:

> Hmm..this leads me to ask the question:
>    Who of us currently uses Smalltalk/Squeak?
>    If so, which implementation?
>
> I'd be interested in your experiences.  We often talk about rapid
> prototyping, but we seldom actually do it.  But my friends at PARC in
> the early days, and a couple of hold-outs at SunLabs could perform
> magic very, very quickly.
>
> I like this quote from the Squeak web site:
>
>    You may be familiar with other open source languages like Ruby or
> Python, but Squeak takes these concepts much, much further offering a
> true uniform fully reflective environment - real live objects.
>
>     "The real romance is out ahead and yet to come. The computer
>     revolution hasn't started yet. Don't be misled by the enormous
>     flow of money into bad defacto standards for unsophisticated  
> buyers
>     using poor adaptations of incomplete ideas."
>       - Alan Kay
>
>
>      -- Owen
>
> Owen Densmore   http://backspaces.net
>
>
> On Sep 12, 2006, at 6:38 PM, Giles Bowkett wrote:
>
>> http://video.google.com/videoplay?
>> docid=-9059529534041031582&q=seaside
>>
>> --
>> Giles Bowkett
>> http://www.gilesgoatboy.org
>>
>> ============================================================
>> FRIAM Applied Complexity Group listserv
>> Meets Fridays 9a-11:30 at cafe at St. John's College
>> lectures, archives, unsubscribe, maps at http://www.friam.org
>
>
> ============================================================
> FRIAM Applied Complexity Group listserv
> Meets Fridays 9a-11:30 at cafe at St. John's College
> lectures, archives, unsubscribe, maps at http://www.friam.org

[Marcus G. Daniels-3]

Quoting Michael Agar <magar at anth.umd.edu>:

> In the late 1990s back in  
> Baltimore I asked a SWARM programmer at Hopkins what language I  
> should work with to avoid the heartbreak of Java but still be able to  
> create ABMs. Squeak, he said. Messed with it some but then the  
> Netlogo empire started cranking up and I converted.

I've come to believe dynamically typed languages (like Squeak or Objective C)
aren't the best choice for most simulation tasks.   Languages like Haskell or
F# with intelligent type inference systems are a better approach.  The reward
of modelling flexibility isn't worth the risk of hidden mistakes and the
performance problems of dynamic typing.  A superficial appeal of dynamically
typed languages is that they let modelers avoid jumping through so many hoops
defining lots of variable/expression types.  Of course what happens it they get
a model running, and then it crashes (hopefully sooner than later) because it
is not carefully thought out.  Sometimes, but not always, a prototyping
environment can be the same as the production environment(e.g. for doing large
scale sensitivity analysis), but not always.

Some years ago I spent much time writing both Objective C and Java Swarm models
and example code.  Only in a few corner cases did I ever have or find anyone
that had a deep need in a model for typelessness, or even generics.  After
Java/Swarm was done, when I ended-up using Objective C is when I needed the
control of a C compiler for maximum performance, e.g. when searching a
parameter space of a simulation having hundreds of thousands of agents.

Marcus

[Bill Eldridge]

Owen Densmore wrote:

> Hmm..this leads me to ask the question:
>    Who of us currently uses Smalltalk/Squeak?
>    If so, which implementation?
>
> I'd be interested in your experiences.  We often talk about rapid  
> prototyping, but we seldom actually do it.  But my friends at PARC in  
> the early days, and a couple of hold-outs at SunLabs could perform  
> magic very, very quickly.
>
> I like this quote from the Squeak web site:
>
>    You may be familiar with other open source languages like Ruby or  
> Python, but Squeak takes these concepts much, much further offering a  
> true uniform fully reflective environment - real live objects.
>
>     "The real romance is out ahead and yet to come. The computer
>     revolution hasn't started yet. Don't be misled by the enormous
>     flow of money into bad defacto standards for unsophisticated buyers
>     using poor adaptations of incomplete ideas."
>       - Alan Kay
>  

Alright, I give up - why do fun languages like Python or more fun
languages like Squeak
get passed over in the market compared to rather annoying languages like
Java?
How come they haven't been as competitive as say Linux as a server OS
platform?
Why is C++ vs. Java still our fate in 2006? Is there no God? Have we
been bad?

[Marcus G. Daniels-3]

Quoting Bill Eldridge <dcbill at volny.cz>:

> Alright, I give up - why do fun languages like Python or more fun
> languages like Squeak
> get passed over in the market compared to rather annoying languages like
> Java?
> How come they haven't been as competitive as say Linux as a server OS
> platform?

http://www.jwz.org/doc/worse-is-better.html

[Giles Bowkett]

On 9/13/06, Owen Densmore <owen at backspaces.net> wrote:
> Hmm..this leads me to ask the question:
>    Who of us currently uses Smalltalk/Squeak?
>    If so, which implementation?

I've played with it, but that's about it. I spent some time this
morning reading up on OCaml,  my gut reaction is it feels like Python
meets Lisp, but for me obscure languages are much more hobby
programming than business. Pretty much everything I do for a living
(Web development) ends up being in Ruby, Perl, or Java.

The Smalltalk I have is Cincom VisualWorks Smalltalk. I like it but I
think to use Seaside I'll need to download a Squeak. I'm curious about
this stuff, but the tool-centric nature of Smalltalks throws me for a
loop, as I'm much more a text editor guy.

--
Giles Bowkett
http://www.gilesgoatboy.org

[Owen Densmore]

> Alright, I give up - why do fun languages like Python or more fun  
> languages like Squeak get passed over in the market compared to  
> rather annoying languages like Java? How come they haven't been as  
> competitive as say Linux as a server OS platform? Why is C++ vs.  
> Java still our fate in 2006? Is there no God? Have we been bad?

Well asked!  Here are a few reasons:

1 - Languages are hard, especially the bad/verbose ones.  So nobody  
wants to learn one for prototyping, and another for deployment.  Thus  
they get stuck to their deployment language.
     Example: We (Redfish) generally do a "level 0" model in a simple  
environment like NetLogo, then implement a "level 1" model in  
Processing, Blender, and others.  When we tried to teach this to  
another organization, they fought us to the end, only giving in on  
the last day of our class!

2 - Performance, at least the myth of it.  Good languages are slow,  
lousy ones fast.  Or at least faster.
     Example: Java is considered slow, so many folks stick to C++, an  
even less "good" environment.  But many performance studies have  
shown that Java really performs surprisingly well (at the cost of  
greater memory use, but...).

3 - Interoperability: No one environment does it all.  This means you  
gotta hope for your language of choice to be able to do everything  
from simple desktop prototyping to XML parsing to web servers to  
scientific programming to plotting/graphing.
     Example: Redfish's last project included NetLogo, Processing,  
Python/Java, Blender and a huge render farm for final processing.  
Very, very hard to get a single environment to do that.

4 - Deployability.  As wonderful as Smalltalk is, it likely will not  
support simple web deployability.  Both NetLogo and Processing do.  
Processing goes further: it builds apps for Mac, Windows, and Linux  
desktops.  Deployability proves to be a very important in the biz.

     -- Owen

Owen Densmore    505-988-3787 http://backspaces.net
Redfish Group:   505-995-0206 http://redfish.com  http://friam.org/

[Owen Densmore]

I just found an interesting Python/Self/Squeak sorta blend -- PataPata:
http://sourceforge.net/projects/patapata
http://showmedo.com/videos/video?name=patapata_tkinter1_fSchnell

The idea is to build a Python/Jython environment that has the direct  
manipulation of Self.  Sorta nifty.

     -- Owen

Owen Densmore    505-988-3787 http://backspaces.net
Redfish Group:   505-995-0206 http://redfish.com  http://friam.org/

[Phil Henshaw-2]

It does make one wonder why things that seem to work great also
frequently get dismissed.  It could just be appearances, that there are
actually problems somewhere that people sense intuitively and turn off
to, without trying to explain their hesitations.  

There are many fascinating issues here, but I think the two main reasons
good stuff gets dumped are that things that work a) usually break rules
that make people feel uncomfortable about change, or b) would put
investors at a temporary disadvantage competitively, and so get filtered
out despite long term advantages.

One of the more curious examples of the latter is conservation, like
investing in technologies that would be competitive in 20 years.   It
doesn't pay in terms of competitive advantage now, so it would do a
business harm to try, and of course we're all goners if we don't!



Phil Henshaw                       ????.?? ? `?.????
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
680 Ft. Washington Ave
NY NY 10040                      
tel: [phone]                
e-mail: pfh at synapse9.com          
explorations: www.synapse9.com    

> -----Original Message-----
> From: friam-bounces at redfish.com
> [mailto:friam-bounces at redfish.com] On Behalf Of Bill Eldridge
> Sent: Wednesday, September 13, 2006 3:19 PM
> To: The Friday Morning Applied Complexity Coffee Group
> Subject: Re: [FRIAM] Seaside (Smalltalk web development framework)
>
>
> Owen Densmore wrote:
> > Hmm..this leads me to ask the question:
> >    Who of us currently uses Smalltalk/Squeak?
> >    If so, which implementation?
> >
> > I'd be interested in your experiences.  We often talk about rapid
> > prototyping, but we seldom actually do it.  But my friends
> at PARC in  
> > the early days, and a couple of hold-outs at SunLabs could perform  
> > magic very, very quickly.
> >
> > I like this quote from the Squeak web site:
> >
> >    You may be familiar with other open source languages like Ruby or
> > Python, but Squeak takes these concepts much, much further
> offering a  
> > true uniform fully reflective environment - real live objects.
> >
> >     "The real romance is out ahead and yet to come. The computer
> >     revolution hasn't started yet. Don't be misled by the enormous
> >     flow of money into bad defacto standards for
> unsophisticated buyers
> >     using poor adaptations of incomplete ideas."
> >       - Alan Kay
> >  
>
> Alright, I give up - why do fun languages like Python or more fun
> languages like Squeak
> get passed over in the market compared to rather annoying
> languages like
> Java?
> How come they haven't been as competitive as say Linux as a server OS
> platform?
> Why is C++ vs. Java still our fate in 2006? Is there no God? Have we
> been bad?
>
> ============================================================
> FRIAM Applied Complexity Group listserv
> Meets Fridays 9a-11:30 at cafe at St. John's College
> lectures, archives, unsubscribe, maps at http://www.friam.org
>
>

[Marcus G. Daniels-3]

Phil Henshaw wrote:
> There are many fascinating issues here, but I think the two main reasons
> good stuff gets dumped are that things that work a) usually break rules
> that make people feel uncomfortable about change, or b) would put
> investors at a temporary disadvantage competitively, and so get filtered
> out despite long term advantages.
>  
I think all of Owen's reasons turn out to be variants of his #3
reason.   If you have the belief that there are preferred tools for
different kinds of jobs, and you do different jobs to achieve a larger
goal, then you should expect to be facile with different kinds of tools.

If the tools conflict instead of complement each other, there is a
problem.  The typical problem with many `beautiful' (e.g. academically
developed) tools is that they have trouble interoperating with standard
tools.  And further, those that claim their tools/frameworks are so
wonderful may in part be right but also may in part be guilty of patting
themselves on the back a bit too much.  While possible, the idea that
university or hobby software can be better than software developed by a
multi-billion dollar corporations doesn't jump out as a likely scenario.

Interoperability is God, and failing to provide it is a fine reason for
a software project to fail!

[Joshua Thorp]

On Sep 14, 2006, at 3:17 AM, Marcus G. Daniels wrote:

> While possible, the idea that
> university or hobby software can be better than software developed  
> by a
> multi-billion dollar corporations doesn't jump out as a likely  
> scenario.
>
> Interoperability is God, and failing to provide it is a fine reason  
> for
> a software project to fail!

If you are a multi-billion dollar company why interoperate?  Just  
declare the rest of the market for suckers and dilettantes.  
Unfortunately for billion dollar companies its turtles all the way  
down and they struggle mightily just to interoperate with their own  
products--and largely fail.

Seems to me the very concept of a multi-billion dollar company as  
software producer put up against small groups of hackers is absurd  
anyway.  It really hinges on the make up of the small teams of people  
inside that large capital structure that are doing the real work  
anyway.  Plenty of fine coders exist inside and out of such large  
companies and depending on management and marketing or acquisitions  
they may have more or less time to deliver a finished product.  But  
more often than not,  though a billion dollar company may be good at  
well crafted design process, I would bet they find their best ideas  
from  those who do something for the sake of art as an amateur,  or  
to push forward the frontier of ideas as a scholar.

'Can't we all just get along?'

What we are talking around here is just as personal as race and  
politics--where do you fall on the artist<--scientist-->engineer  
spectrum.  Engineers are most comfortable in slow moving vehicles  
with plenty of restraints and air bags.  Artists are most happy in  
new concept cars that are untried and untested--they might die but at  
least it will be a statement of some sort.  And of course testing  
cars is for scientists.  (Some may quibble with this,  but I would  
have to say check out the difference between math departments in an  
Engineering school versus an arts and sciences school -- Engineers  
are most comfortable working with equations from a table and  
processes from a lab manual,  scientists get a big kick out of  
deriving equations that are already in that engineering text.  And I  
think artists are largely there for the drugs and the women..)  I  
couldn't imagine the same languages appealing to all three crowds.  
And why should they?

We can certainly tell a lot by the tools a person uses (and the  
company they keep).  And if you don't like engineers I would say  
better to avoid C++,  project managers,  and multi-billion dollar  
companies.

Another angle to this whole mess is that it is possible to write very  
unstable and largely un-useful code in C++,  it just takes a long  
time to get there.  If you want, you can get there faster in python.

--joshua

 
 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: /pipermail/friam_redfish.com/attachments/20060914/a72ca7a0/attachment-0001.html

[Bill Eldridge]

Joshua Thorp wrote:

>
> On Sep 14, 2006, at 3:17 AM, Marcus G. Daniels wrote:
>
>> While possible, the idea that
>>
>> university or hobby software can be better than software developed by a
>>
>> multi-billion dollar corporations doesn't jump out as a likely scenario.
>>
>>
>> Interoperability is God, and failing to provide it is a fine reason for
>>
>> a software project to fail!
>>
>
> If you are a multi-billion dollar company why interoperate?  Just
> declare the rest of the market for suckers and dilettantes.  
> Unfortunately for billion dollar companies its turtles all the way
> down and they struggle mightily just to interoperate with their own
> products--and largely fail.

Shrinkwrapped software is a tiny minority these days of the total
software pool.
Back end business systems are much larger, and one of their prime tasks
is B2B and B2C operations
to automate sales and distribution, supply chains, information access,
customer tailoring, etc.
Interoperability is a very important component of that task. RPC, CORBA,
XML, Web Services/SOAP, Indigo
are all approaches that are supposed to make this interoperability
easier, but we seem
to always be stuck in unhappy land.

Here's an interesting new attempt:  http://www.zeroc.com

>
> Seems to me the very concept of a multi-billion dollar company as
> software producer put up against small groups of hackers is absurd
> anyway.  It really hinges on the make up of the small teams of people
> inside that large capital structure that are doing the real work
> anyway.  Plenty of fine coders exist inside and out of such large
> companies and depending on management and marketing or acquisitions
> they may have more or less time to deliver a finished product.  But
> more often than not,  though a billion dollar company may be good at
> well crafted design process, I would bet they find their best ideas
> from  those who do something for the sake of art as an amateur,  or to
> push forward the frontier of ideas as a scholar.

Not to get into a flame pit, but isn't that a bit elitist?
Some people are very creative when working on a directed, corporate-goal
style problem.
Many of those goals are very pragmatic, customer- and market-driven, and
so have a pretty
high payoff in satisfaction if solved elegantly - the solution will be
used extensively.

I would also point out one of my long-term examples of how DEC or HP
came up with
a good robust extended file permissions system on Unix, while the open
source world took
years more effort and AFAIK never came up with anything usable for
serious applications.
Yes, it partly comes down to the teams of programmers, plus their
support, their motivation
and incentive, the maintainability of the project, including the
oft-maligned marketing aspect
(even in the open source world, if a good project isn't marketed well,
it won't attract new
programmers, bug reports, etc.)

>
> 'Can't we all just get along?'
>
> What we are talking around here is just as personal as race and
> politics--where do you fall on the artist<--scientist-->engineer
> spectrum.  Engineers are most comfortable in slow moving vehicles with
> plenty of restraints and air bags.  Artists are most happy in new
> concept cars that are untried and untested--they might die but at
> least it will be a statement of some sort.  And of course testing cars
> is for scientists.  (Some may quibble with this,  but I would have to
> say check out the difference between math departments in an
> Engineering school versus an arts and sciences school -- Engineers are
> most comfortable working with equations from a table and processes
> from a lab manual,  scientists get a big kick out of deriving
> equations that are already in that engineering text.  And I think
> artists are largely there for the drugs and the women..)

I think George Michaels and Gary Glitter are there for the boys ;-)

>  I couldn't imagine the same languages appealing to all three crowds.  
> And why should they?
>
> We can certainly tell a lot by the tools a person uses (and the
> company they keep).  And if you don't like engineers I would say
> better to avoid C++,  project managers,  and multi-billion dollar
> companies.  
>
> Another angle to this whole mess is that it is possible to write very
> unstable and largely un-useful code in C++,  it just takes a long time
> to get there.  If you want, you can get there faster in python.
>
> --joshua
>
>  
> ------------------------------------------------------------------------
>
> ============================================================
> FRIAM Applied Complexity Group listserv
> Meets Fridays 9a-11:30 at cafe at St. John's College
> lectures, archives, unsubscribe, maps at http://www.friam.org

-------------- next part --------------
An HTML attachment was scrubbed...
URL: /pipermail/friam_redfish.com/attachments/20060914/13c7f595/attachment.html

[Bill Eldridge]

Bill Eldridge wrote:

> Shrinkwrapped software is a tiny minority these days of the total
> software pool.
> Back end business systems are much larger, and one of their prime
> tasks is B2B and B2C operations
> to automate sales and distribution, supply chains, information access,
> customer tailoring, etc.
> Interoperability is a very important component of that task. RPC,
> CORBA, XML, Web Services/SOAP, Indigo
> are all approaches that are supposed to make this interoperability
> easier, but we seem
> to always be stuck in unhappy land.
>
> Here's an interesting new attempt:  http://www.zeroc.com

Another interesting product:

http://dev.mainsoft.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: /pipermail/friam_redfish.com/attachments/20060914/2daaef6e/attachment.html

[Frank Wimberly]

 
 
On Sep 14, 2006, at 3:17 AM, Marcus G. Daniels wrote:



While possible, the idea that
university or hobby software can be better than software developed by a
multi-billion dollar corporations doesn't jump out as a likely scenario.
 
Interoperability is God, and failing to provide it is a fine reason for
a software project to fail!
 
Let's see.  I have worked for multi-billion dollar companies (Bell Labs
when it was part of AT&T, General Motors and Westinghouse).  And I have
worked for Universities (Carnegie Mellon University, University of
Pittsburgh and the University of West Florida at the Institute for Human
and Machine Cognition).
 
At Bell Labs I worked on software administration methodologies for No.
5ESS.  At the time I left there were about 200 software developers
working on various components of the "switch" (call processing, OS,
database and many others).  My colleagues used to complain that we had
to spend almost all our times in meetings.  The language used was C and
development occurred across many machines (Vaxen) and had to be
integrated.  Standards were necessary and became a great point of
contention.  So did tools.  Sometime someone would say, "You know if you
could just get the 10 right people in a room together you could get this
developed much more quickly."  In the meantime we were hiring masters
level developers at a very high rate.  The technical staff would say to
the management, "Haven't you read 'The Mythical Man Month'" and the
bosses would answer, "Yes, keep hiring."
 
I left there to go to CMU's Robotics Institute.  This was about 1980.
Brian Reid was a graduate student who had developed the Scribe Document
System alone or with a very small team.  Emacs had been developed by one
guy (rms) at MIT and James Gosling converted it for use on Unix.  Rick
Rashid and a few graduate students developed the kernel of the Mach
operating system.  Now, none of these projects were on the same scale as
the ESS software, where the target was a distributed processor with
extremely high demands for real-time reliability but they still seemed
to yield very impressive products.
 
It seems to me like there are two different kinds of software projects
and they have different needs in terms of types of resources and
approaches.  It is interesting, however, that Rick Rashid has been VP
for research at Microsoft for many years.  I assume he still is.
 
 
Frank
 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: /pipermail/friam_redfish.com/attachments/20060914/33c88411/attachment-0001.html

[Marcus G. Daniels-3]

Joshua Thorp wrote:
> If you are a multi-billion dollar company why interoperate?  Just
> declare the rest of the market for suckers and dilettantes.  
> Unfortunately for billion dollar companies its turtles all the way
> down and they struggle mightily just to interoperate with their own
> products--and largely fail.
Because you definitely risk not staying a multi-billion dollar software
company if you do that.
Microsoft, for example, has not actually done that.  For example, it's
easy to make SOAP web services with Visual Studio.  They were also early
to put XML support into not only their middleware but also primary
applications.  .NET cross-language support is really pretty impressive.  
To match Java, they aligned all of their language support (significantly
including C++ and Visual Basic) on one publicly documented virtual
machine platform while also making a good competitor to Java in the
process, C#.   Further, they made them all interoperable with the same
libraries, both for fast within-box legacy calls (COM) and cross box
(SOAP).   Sun might have liked to lock people in to `pure Java', but now
they've also been forced to innovate in Java itself and the runtime.

I think Linux and free software definitely made these companies be
better than they would have been otherwise.  A strong commons helps to
make them somewhat honest.  In 1990 it was barely possible to get work
done on entirely free systems.  Tremendous progress has been made since
then.

[Marcus G. Daniels-3]

Joshua Thorp wrote:
> But more often than not,  though a billion dollar company may be good
> at well crafted design process, I would bet they find their best ideas
> from  those who do something for the sake of art as an amateur,  or to
> push forward the frontier of ideas as a scholar.  
>
Or they get big enough they can have a research divisions and buy up
most of these people!
It's cheap insurance..  (MSR, Xerox PARC, IBM, etc.)
> What we are talking around here is just as personal as race and
> politics--where do you fall on the artist<--scientist-->engineer
> spectrum.
Let's all do our part to pollute that space with inconvenient blobs
scattered about.  :-)

[Owen Densmore]

I'd like to get back to the task at hand -- evaluating rapid  
prototyping environments.

> Hmm..this leads me to ask the question:
>    Who of us currently uses Smalltalk/Squeak?
>    If so, which implementation?

So I presume the answer is nobody is currently using the contender  
for most successful rapid development environment on the planet?  The  
one going into Negroponte's One Laptop Per Child project?  
Astounding! (BTW: Python is apparently going to be onboard too)

WedTech'ers: I'm buying the currently most popular Squeak book  
recommended by the various sites:
   http://tinyurl.com/zukkf
I'll take a look to see if it'd be worth a wedtech chat.  Could one  
of our python experts try PataPata?  Its a very new project, but has  
gotten a fair amount of interest:
   http://sourceforge.net/projects/patapata
I'll also check out Groovy in Action and maybe play with it a bit --  
I'm getting the chapters as they are published by Manning via their  
MEAP project.  Got 10 already!

BTW: I'm starting to think answer is that rapid prototyping has  
splintered into pieces:
   Excel: great for fast exploration of data
   R: great for fast statistical evaluation
   Gnuplot: great for fast and simple plotting of data
   NetLogo: sorta smalltalk for simulation
   Processing: Killer 2D/3D visualizations
   Sh/Bash: Lightning fast trivial hacks for unix folks
   Python: Scripting++ and more
   JavaScript: Great access to browsers for both users & AJAX
   .. and so on.
So thus there really is an explosion of application specific  
environments rather than the old smalltalk which was pretty universal.

     -- Owen

Owen Densmore    505-988-3787 http://backspaces.net
Redfish Group:   505-995-0206 http://redfish.com  http://friam.org/

[Owen Densmore]

Friam'ers: Oops .. didn't mean to be exclusionary!  If *anyone* would  
like to explore one of these, or some other interesting environment,  
let us know.  I think we could easily have a Skype or similiar  
wedtech including the rest of our world-wide Friam.

> WedTech'ers: I'm buying the currently most popular Squeak book
> recommended by the various sites:
>    http://tinyurl.com/zukkf
> I'll take a look to see if it'd be worth a wedtech chat.  Could one
> of our python experts try PataPata?  Its a very new project, but has
> gotten a fair amount of interest:
>    http://sourceforge.net/projects/patapata
> I'll also check out Groovy in Action and maybe play with it a bit --
> I'm getting the chapters as they are published by Manning via their
> MEAP project.  Got 10 already!

     -- Owen

Owen Densmore    505-988-3787 http://backspaces.net
Redfish Group:   505-995-0206 http://redfish.com  http://friam.org/

[Phil Henshaw-2]

Owen types:
> I'd like to get back to the task at hand -- evaluating rapid  
> prototyping environments.
... clip

> BTW: I'm starting to think answer is that rapid prototyping has  
> splintered into pieces:
>    Excel: great for fast exploration of data
>    R: great for fast statistical evaluation
>    Gnuplot: great for fast and simple plotting of data
>    NetLogo: sorta smalltalk for simulation
>    Processing: Killer 2D/3D visualizations
>    Sh/Bash: Lightning fast trivial hacks for unix folks
>    Python: Scripting++ and more
>    JavaScript: Great access to browsers for both users & AJAX
>    .. and so on.
> So thus there really is an explosion of application specific  
> environments rather than the old smalltalk which was pretty universal.

Probably off topic, but has any of them solved my problem?   I can only
limp along with my live systems data analysis using home made lisp
routines on a graphics platform because of the standard grid model of
data that seems to be used elsewhere?    All my data streams come with
different, and often irregular, time periods and a vector graphics
program is the only one I can find that allows direct interrelationships
between sequences with different periods.  I'm also doing analysis of
various ways to reconstruct the points in-between the points.   Excel
and others have no place to put them.   Is there an affordable and
flexible stat package that treats all scales as continuities?

Phil