[squeak-dev] what is holding back Smalltalk?

Brad Fuller wrote:

> Keith,
>
> That's a great story. We should put that on the website!


You really should:

- STIC
- Squeak

websites.

Though you should really ask if that application is still running.

Claus

Klaus D. Witzel wrote:

> Me thinks that the Smalltalk community is healthy and vibrant--it is  
> "just" a community form one would not expect for Ruby or Python or
> Perl,  etc. To get impression of my impression take a look at what
> *actually*  happened during the *recent* months:

Why would one not expect this community for Ruby or Python or Perl?
Could you please explain what you mean, for this puzzles me ...

Casimiro de Almeida Barreto wrote:

> But at what cost????

It is a high cost at times, granted :>

> Java is more suited for small applications

I am sorry, but could you please explain this?

 > and I guess that Oracle
> people got it right when they started to migrate from old tools to Java
> in order to have better UI development.

What UI development do you mean?

 > But when you have to handle
> large amounts of data and extremely dynamic objects and things like that
> Java performance drops to the point that it is better to use C++ or even
> C...

This sounds interesting - could you please elaborate a bit further?

> Interesting enough, there are lots of re-engineering initiatives for the
> Java VM. Up to the moment nobody was able to create a VM that lessens
> the troubles with the garbage collection system and other performance
> related topics.

Well, one performance related topic is halfway gone: graphics.

I agree and find the "us" vs "them" attitude to be unhealthy.

One should be able to define oneself without comparison to others.


On Nov 21, 2008, at 12:23 PM, Claus Kick wrote:

  Heh, we know a few people that are/were Smalltalkers and even
Squeaker(s) at Google (like Lex and Nathanael), but do we know who are
new hires?

-- Yoshiki

Casimiro de Almeida Barreto wrote:
> [interesting story deleted to save space]
>
> Years later an auditing consultant observed that the best way of keeping
> the status quo is always demanding the excellent even when you don't
> have the satisfactory.

I have been involed in the opposite situation - a teacher was specifying
a Smalltalk educational software I was hired to write and she hated that
the children wanted to play with computers instead of do the assignments
in the workbooks ("but they are so cute and educational!!"). So she
didn't allow me to let the computer do anything that couldn't also be
done on paper. The computer couldn't tell the students whether their
answers were right or wrong (not even give hints) but instead the
teacher would come along later and grade the assignment.

So you can either spec something so perfect it will never be built or
something that is just an awkward version of the status quo so people
won't see the point of it.

> > [Self and Java]
> >  
> Not to mention that Sun not only killed Self but did the same to
> SpringOS... :( Now they face the reality of selling mostly Intel servers
> running RedHat Linux...

Very true, but I can't blame Sun too much for this. Their customers had
suffered greatly in the transition from SunOS to Solaris and now Sun was
talking about yet another change in the future? So they felt they had to
kill SpringOS and yell "Solaris forever!" just to keep their clients
from moving to their competitors. They also tried to kill TCL (they had
previously spun it out and then brought it back in) too, so it was just
their style at the time :-)

-- Jecel

Randal,

your web page doesn't come across like your mailing list  
communication, which has always seemed non-inflammatory and  
reasonable. Two things immediately annoy me on the page you reference.  
Firstly you say 'Damn you GPL'. Second, the comment you quote says  
that the GPL is 'completely unacceptable', which IMO is an aggressive  
(redundant) overemphasis. If it had simply said 'incompatible' it  
wouldn't piss me off, and would merely stand as the warning you intend.

I'm building a commercial Smalltalk implementation that will have  
commercially licensed components e.g. not (L)GPL, or even MIT/Apache/
BSD. I don't support all of Stallman's philosophy - I don't believe  
there is any moral imperative for software to be 'free'. I support the  
concept of DRM etc etc etc. I'm not a GPL or even O/S fanatic,  
although I completely support the right of anyone to use any license  
for *their* work without being criticized for it. I perfectly  
understand Paolo's response to that web page.

One could "freely examine the implementation and use as is or derive  
from it to contribute to the squeak project" if Squeak was GPL. I  
guess the GST authors simply don't want people commercially benefiting  
from their work without giving anything back. Fair enough. Even so,  
IMO it is possible to use GST to deliver commercial applications that  
include non-(L)GPL ST source / documentation / resources, and I could  
in fact deliver a commercially licensed Smalltalk using GST, subject  
to some reasonable conditions.

On 21/11/2008, at 11:57 PM, Randal L. Schwartz wrote:

Antony Blakey
--------------------------
CTO, Linkuistics Pty Ltd
Ph: 0438 840 787

I contend that we are both atheists. I just believe in one fewer god  
than you do. When you understand why you dismiss all the other  
possible gods, you will understand why I dismiss yours.
   --Stephen F Roberts




Begin forwarded message:


Begin forwarded message:


Begin forwarded message:

On 22/11/2008, at 1:15 AM, Keith Hodges wrote:

> If the above is true, then its up to the GNU Smalltalk people to  
> change
> things "For Smalltalk as a whole sake"

Or for the Squeak people to change their license "For Smalltalk as a  
whole sake".

Antony Blakey
-------------
CTO, Linkuistics Pty Ltd
Ph: 0438 840 787

If a train station is a place where a train stops, what's a workstation?

>I agree and find the "us" vs "them" attitude to be unhealthy.
> One should be able to define oneself without comparison to others.

One better attitude is to consider complementary and not "vs."
 e.g. the comparation is not valid.

There is not right/wrong answers when
 the question is incorrect.

Smalltalkers do not need to answer why we has had our history
 to people that do not have a history yet.

Each time we compare smalltalk to new formulas (new languages,
 new platforms, new ooxxx++ -now more object oriented- )
 we loose our small resources trying to reformulate
 our peculiarities to be something we are not.

Why do not try to invest our time and efforts
 in the undeveloped direction of Object Technology
 (a la smalltalk) ? as was proposed at first years
 of Squeak project.

We are too near the sea because we are making
 the smalltalk globe go down.

Focusing the on the peculiarities of smalltalk way (not the
 tools, nor the environment, nor it contents, but the activities
 smalltalk make possible) can be more valuable and will
 make people reflect about what they are really doing when
 they write "the same" in other syntax...

Each time we compare, we loose.
Each time we put ourselves in front of another
 alternative (for others) we loose.

IMHO, it is better to feel "complementary to
 the normal people"; e.g. preserve our personality
 (a model we built/grow with smalltalk, not only a POV).
As any complement we do not compete with other
 proposals for "system" development (I must say here
 system definition).
Smalltalk IS marginal, and it is a lot of oportunities at the
 margins in this "empty world" [*].

have fun, and preserve our way,
Ale.

[*] As a by product of OO method, any de-composition
 of the world produce more vacum (uncertanty) that definitions.






----- Original Message -----
From: "Steven W Riggins" <[hidden email]>
To: "The general-purpose Squeak developers list"
<[hidden email]>
Sent: Friday, November 21, 2008 5:37 PM
Subject: Re: [squeak-dev] Nothing much [was: what is holding back
Smalltalk?]

Jecel Assumpcao Jr wrote:
 > [Something snipped on clean room implementations.]
 > But to understand what happened to Smalltalk you must look at the
 > history more than at technical aspects. I don't know a good text I can
 > link to, but Eliot spent some time on this in his AoSTA talk -
 > http://video.google.com/videoplay?docid=-8988857822906068209

I wrote some on this to a Python-related list (Edusig) about two years ago
it various posts. Some excerpts:

   "[Edu-sig] Freedom: some Smalltalk history and Python implications"
   http://mail.python.org/pipermail/edu-sig/2006-August/006871.html
"""
In the syntax case, I am continuing to point out that Smalltalk's keyword
syntax (e.g. "Point x: 10 y: 20" versus "Point(10, 20)" ) produces code
where all arguments are labeled and so it is easier to read and
understand. As I see it, that is a fact independent of licensing, object
models, breadth of libraries, size or quality of community, or engineering
reliability of the VM, and so on (areas which Python often has as an
advantage over any specific Smalltalk). ... And I am still unable to bring
across the massive decrease in  effectiveness and immersion I feel
programming a large system in Python  compared to Smalltalk, like were when
an exception is raise I cannot immediately change the code and then carry on
from the point in the program where the exception was generated, without
either restarting the entire application. ... Now, I have repeatedly agreed
Python has many benefits over Smalltalk.  You've mentioned some. I'll add,
Python is more "prototypish" than  Smalltalk because it uses a dictionary
instead of fixed slots for  variables (at least, usually) which make it easy
to specialize instances of a class. Python as a major language had a free
license unlike the major Smalltalk dialects (i.e. there are free Smalltalks
but they are still  marginal to the overall Smalltalk community, Squeak
being the closest to  an exception). Python has had its internal complexity
managed fairly well,  compared to say, Squeak because of having namespace
from the start. I like  indentational syntax (though not as much as
keywords). Metaclass support  is nice. And so on.
"""

   "[Edu-sig] Freedom: some Smalltalk history and Python implications"
   http://mail.python.org/pipermail/edu-sig/2006-August/006868.html
"Anyway, I don't want to drift too far off-topic. Suffice to say, if there
is any truth to Smalltalk being a "dead" language, it has more to do with
companies mismanaging the technology, and not the technology itself.
Python has been well managed as a labor-of-love by someone who cares about
it for itself (Guido) and as a community Python could ride the free and
open source software wave without distracting conflicts with "commercial
Python vendors". Squeak tried, but was both a latecomer and not completely
free, and had some other difficulties (including for a long time a core
team with priorities other than stability or supporting industrial use)."

   "[Edu-sig] Python & Smalltalk (was Re: OLPC related: pyGTK)"
   http://mail.python.org/pipermail/edu-sig/2006-December/007476.html
"""
Smalltalk came out of an industrial research lab (Xerox PARC). The people
who invented and then built it and refined it were paid industrial
employees working in the scope of their duties on company time (though
very unusual ones, even by such R&D standards. :-) Its subsequent history
for decades involved mainly development by commercial organizations
(either as Smalltalk or also as the Macintosh OS which in some sense was a
Smalltalk-derivative, but Steve Jobs just got the window system because he
left too soon. :-).
    http://gagne.homedns.org/~tgagne/contrib/EarlyHistoryST.html

...

Smalltalk's demise as a major player on the commercial scene in terms of
VisualWorks and its predecessor ObjectWorks (*the* leading Smalltalk
product, and still the most comprehensive and definitive and most
cross-platform -- excepting perhaps Squeak is more cross-platform in
theory) was mostly due to greed and mismanagement IMHO by a now defunct
company (the current VisualWorks owners bought it cheaply from them).
IBM's VisualAge Smalltalk's demise, on the other hand, was mostly due to
IBM's decision to back Java (shortsighted and unfortunate I think as IBM
had the clout to push Smalltalk syntax through to the masses IMHO).
Smalltalk is still actively used by many, but is more of a niche player at
the moment (like, say, OCaml or Haskell or Common Lisp), having been
eclipsed by Java. The support community for Smalltalk was (at first)
mostly commercially oriented, and remains so to some degree. While there
were academic users, and in the past decade, especially with Squeak, the
number of people using it for academic or free or open source type
applications has grown, that has not been the bulk of the history. Even
Squeak's most recent evolution was driven by work at Apple and then at
Disney, with the Smalltalk principals reprising their roles as employees
of large industrial research and development labs, with the licensing
ambiguity that sometimes entails in navigating for-profit corporate waters
in an emerging free-and-open-source way (i.e. Alan Kay claims Disney is OK
with the Squeak changes done there being released, but there is no "peace
of mind" letter from Disney signing off on them I am aware of, or related
licensing statement in the code).

Python on the other hand, was started as a hobby by one person who was
based in an academic research lab. It was always given freely. Excepting
one bobble with licensing issues (which was corrected and involved a
not-for-profit), the licensing situation has always been pretty
straightforward from a free software perspective (and is even now GPL
compatible). For most of Guido's time with python (except the last few
years) he was affiliated with one of two non-profits. Even now his job is
at a pro-"open source" corporation which is also releasing several other
free and open source projects. The community that grew around Python,
while with many commercial users, had a very different emphasis to it.
Part of that early community spirit was also from the "Monty Python"
humorous yet playfully radical themes (although Guido has said by now he
has heard enough Monty Python jokes. :-) Python also has one core
definitive free code base as a reference standard implementation (even as
there are spinoffs like Jython).

Personally, I feel Smalltalk is the better syntax for kids to learn as
that purpose was what it was supposedly designed for (if you ignore that
most adult programmers come from Algol syntax and have trouble adapting to
the syntax initially); Smalltalk keyword: syntax is certainly the easier
syntax to use to maintain large bodies of code using powerful tools and is
easily extendable by the end user programmer for many new uses including
new control structures and iteration concepts; Smalltalk historically also
has the better development tools (in part due to the syntax) and also has
a better library architecture (e.g. Streams, Magnitude) and better VMs and
garbage collection(especially in VisualWorks, and less so in Squeak), and
also has benefited from a culture of Smalltalk all-the-way-down (as Squeak
exemplifies); Smalltalk has a powerful notion of bracketed nameless code
blocks and is a tour de force of one paradigm (objects and message passing).

However, Python has the better community (from a free and open source
perspective), better license and licensing history, and better breadth and
modularity of libraries; Python also is more easily taken up by adult
programmers who already know C or a similar Algol-style language because
of its Algol-like syntax and also because you can use familiar
text-oriented tools like emacs or vi or Scite with it (which makes it
easier for it to gain commercial acceptance as a new thing); Python code
is clear and concise and maintainable because of the decision to use
significant indentation instead of braces or brackets (like Occam); Python
also is a standard defined by a reference implementation, which is much
better than a standard defined by an ambiguous or incomplete textual
specification; Python is easier to do small projects in for people who
only know a little of the language, so in that sense it has an easier
learning curve as a system.

I feel, especially with Ruby's increasing popularity [as effectively a
Smalltalk with Algol syntax plus some other bells and whistles], that the
*themes* in Smalltalk are the future of most programming. Even Python
continues to get more Smalltalk-like, such as the "new classes" changes.
Yet, I want to write some programs now, as part of a free and secure
ecosystem of such programs. :-) Ironically, in my own case as a typical
Smalltalk programmer, because of my own history as a Smalltalk developer
working on commercial projects with commercial versions which nonetheless
included source as most Smalltalks do, I am in some ways "contaminated" by
that experience and the current overly broad reading of copyright and that
puts into potential question anything I develop which is a
Smalltalk-derivative (unless I do it very, very carefully, say by using
mostly GNU Smalltalk sources); not to say I ever would use such commercial
code, just that I might face the effectively impossible task of proving I
had not if there was any coincidental similarity at all (which is a much
smaller problem when I am working with something very different like Python).

If I perhaps oversimplify, essentially the choice right now is between
elegant syntax, uniform abstractions, and powerful tools, embodied in a
system originally designed for kids by big corporate R&D (Smalltalk)
versus practical syntax, uniform community history of freedom, and
powerful economic forces, embodied in a system originally designed for
adult programmers by an academic researcher as a hobby project which grew
beyond initial expectations (Python). :-)

Both languages along with their communities have different strengths and
weaknesses, and also both have subcultures which are in opposition to the
main (e.g. mostly commercial Smalltalk has several free versions, mostly
free Python has heavy proprietary commercial usage where no doubt such
users have large interesting and yet proprietary libraries). That the
strengths and weaknesses are so different in different areas and that one
must also assess where trends are heading when embarking on big projects
is why I am in conflict about which to use (especially for writing
educational simulations), and that is why I tried to mix the best features
of the two in the PataPata experiment -- though perhaps ended up with the
worst features of the two in some ways (Smalltalk's . :-).

Barring moving that PataPata project forward somehow, I am left with a
situation that I either have to put a lot of work into a free Smalltalk
(Squeak, GNU, A Little Smalltalk, Bistro, Sharp Smalltalk, etc.) to make
it more to my liking (e.g. mainstream widgets for Squeak, build tools for
GST or Bistro, etc.) or I have can use Python + GTK or wxWidgets or Jython
+ Swing out of the box, and just accept greater maintenance issues down
the road (e.g. debugging and modifying a running program is so easy in
Smalltalk, in Python it doesn't quite work right, even with tools I have
built to make it easier [posted to the Jython list]). While I haven't made
a big point of it, in the past, my choice of Python in the past has also
been motivated by the "contamination" issue I mentioned above as well. It
may well be the deciding factor once again, sadly -- ironic to not be able
to use and improve a wonderful thing you have experienced precisely
because you have experienced it.(*) :-(
"""

   "[Edu-sig] Python & Smalltalk"
   http://mail.python.org/pipermail/edu-sig/2006-December/007482.html
"""
On a practical reality, I fired up the latest Squeak the other day and
beyond my usual confusion with it relating to not mapping right mouse to
popup a context-determined menu, :-) within minutes I was generating
exceptions and so on as I tried to use other-than-trivial code included
with the system (e.g. running the script to change underscores to colon
equals, as well as some other things I forget off hand). I knew more than
one person who in years past inspired by an Alan Kay presentation have
tried Squeak only to encounter lots of bugs and problems with the core
tools or trying to duplicate the demos he shows. Python never has done
that to me. That's why I tend not to recommend Squeak to anybody but
either die-hard Smalltalkers or people looking specifically to stretch
their minds (which of course in theory includes kids :-). Whereas almost
all the people I recommend Python to, on a practical basis, come away
impressed and become users; Python fits into their ecosystem of tools and
existing ideas fairly easily. That makes me sad because I know Smalltalk
does not have to be that way; I know if I recommended, say, VisualWorks to
people, they would not be experiencing those basic problems (and there is
no reason Squeak's features like eToys or 3D Croquet could not run on such
a stable platform, in theory). Unfortunately VisualWorks is not "free" in
a "free as in freedom" sense the mainline Python version is.

Of course I could fix Squeak's specific problems (as I see and experience
them) with enough effort (in theory, with enough free time, which is
limited at the moment), since the source is there. But then I am left with
the licensing issues including the status of Disney contributions (which
the community is slowly moving to resolve). And then I have my own fork to
maintain, which is extra effort. I have wrestled with the Squeak community
before on those issues, and realized, like any community and mailing list,
a self-selection process has already gone on a long time there, so if you
don't like Squeak how it already is, you are probably not hanging around
on the main lists there. So there may be plenty of people who want a
different Squeak, but most of them are not easily reachable (at least via
the Squeak mailing list).

The Python community is more inclusive by comparison, in the sense that
Python as a language is much more agnostic on several points (including
GUI and tools). So there is more room for experimentation there in some
ways. Or, at least, there is a bigger potential audience of users and
collaborators for a successful experiment, like perhaps the Pyglet OpenGL
GUI system you mention. Python better supports such effort in some ways
because of its modularity and community history (which I outlined
previously). Some Squeakers have been so defensive for so long (often,
though not always, with good reason) that innovation or adopting certain
standards is harder there (witness a recent conflict about whether
keyboard input focus should follow the mouse (Squeak) or follow a mouse
click to shift focus (almost everyone else), not to say there isn't a good
argument for the Squeak way).

Plus, the copyright "contamination" issue sadly will always remain; there
is no denying I have exposed to the source of commercial Smalltalk
incidentally in the process of using them. I could never work in a
Smalltalk-rebuilding "clean room" effort. In other free software
development contexts, say, people working on GNU ClassPath as an
alternative set of libraries to Java, the biggest "no, no" is to have seen
a related vendor's source and then contribute to that project. Example:
    http://developers.slashdot.org/article.pl?sid=05/03/17/0155235
"Read the fine license, in particular the definition of Modifications in
SCSL 2.3. Sun claims copyright on any code independently implementing any
portion of the SCSL-licensed technology *if* you agree to their license.
So please don't look at their code if you intend to contribute to free
runtimes in the future. It's the same as Microsoft's Shared Source in a
different wrapping."

There is probably almost no significant Squeaker who has not been exposed
to the core code of one of VisualWorks, Smalltalk/V, Dolphin, VisualAge,
or a few other commercial Smalltalks. Of course, how well an overly broad
attempt against Squeak would stand up in court is a different issue; it
certainly also would not play well politically in terms of negative PR to
the vendor. In some ways, in the end, this single issue may mean the death
of free Smalltalks long term (barring one major vendor freeing their
version) -- the fact that Smalltalk was "open source" (taken literally)
embodied in proprietary products for so long but not "free". Which is one
reason Richard Stallman dislikes the term "open source" as it deemphasizes
the freedom aspect. :-) In essence, the history of Smalltalk is
"brilliance shackled". Since its conception, the history of Python is
"pragmatism unshackled". :-)
"""

Personally, I still feel that now that the JVM is free-as-in-freedom, a
Squeak derivative on the JVM has the possibility of being an amazing success
(perhaps one built step-by-step using GNU Smalltalk parts to deal with
licensing issues). But it would take most of the community here getting
behind it. Maybe once the relicensing is resolved, this might be more
possible. It is the *image* itself where the licensing needs to be cleanest,
given the VM itself is very small. That's the problem IMHO with the current
JVM implementations I've seen (like the one based on Dan Ingall's work) --
they take the image for granted when that is what matters. Spoon was a great
step in the right direction (building the system up rather than stripping it
down), but has received not enough support.

In the meantime, I mostly use Jython on the JVM and pine for the days of
Smalltalk when debugging was easier and classes and their methods were more
consistently named... But I would love to use a great Smalltalk on the JVM
that had Squeak's following. Suddenly a lot of the issues I mention above
would go away and others -- it would be deployable as a jar or with webstart
or as an applet, it would have a new freely licensed core, it would play
well with other code, it would be easy to do part of a system in Smalltalk,
it would have access to standard widgets as well as custom ones, it would
have robust libraries for 3D graphics and sound and other things it could
easily call on all platforms it runs on, and so on. And then gradually,
Smalltalk could expand outwards from there... But it's just a dream and I
have too little time as it is. Sigh.

--Paul Fernhout

On 21-Nov-08, at 7:42 AM, Paolo Bonzini wrote:

>
>> Who would not want Generators in Squeak? It is solely because of the
>> license concern that we can not use the good parts of GNU Smalltalk.
>
> Not really, because I posted at least two implementations of  
> Generators
> in the public domain and people were still saying they were tainted by
> gst's.

Cool! I've been thinking about Generators myself. Can you point me to  
your implementations?

Colin

On 21-Nov-08, at 8:16 AM, Randal L. Schwartz wrote:

Squeak devs are at risk of what? How much risk is there? Are the  
attendant benefits worth the risk?

The mere existence of risk isn't very good argument for or against  
anything - if it were, we would be fools to get out of bed in the  
morning.

Colin

I think there alway will be issues around licensing (and great money
for lawyers) until people understand that they need to change the
perception on what 'intellectual property' means.

As someone said: nobody pays a license fee to the architect who
designed the building each time someone entering it. So why we should
pay a software architect for each copy of his software? People should
be paid for things they do, not for mass-produced copies of their
creation. Making a copy is not an act of creating intellectual
property - its just a mechanic process.


2008/11/22 Colin Putney <[hidden email]>:


--
Best regards,
Igor Stasenko AKA sig.

"What is holding back Smalltalk?" may or may not be a legitimate
question. However, the question is somewhat relative to the audience.
On a Squeak mailing list, the answer to this question is
straightforward: there is nothing holding Smalltalk back.

It would be more interesting to survey a general population (of
developers) with both specific and open questions. This would also
increase the "brand awareness" (Squeak and Smalltalk in general). A
survey passed along to colleagues, teachers, classroms, etc., would
certainly generate more interest, at low costs, and yet the compiled
data could outline the "failing" aspects of Squeak or Smalltalk in
general.

Anyway, it's just some thoughts...

Ian.

On 22/11/2008, at 2:41 PM, Igor Stasenko wrote:

> As someone said: nobody pays a license fee to the architect who
> designed the building each time someone entering it.

In fact, you pay an architect for a design each time you build it. You  
can't reuse an architect's design without paying for it, or  
negotiating a license. The fact that you live in a house designed by  
an architect gives you no rights to the design.

> So why we should
> pay a software architect for each copy of his software?

You first need to prove the applicability of this analogy. And in any  
case, given my comment above, I think this proves the opposite of what  
you intend.

> People should
> be paid for things they do, not for mass-produced copies of their
> creation.

You would need to provide supporting argument for this assertion to be  
evaluated.

Antony Blakey
-------------
CTO, Linkuistics Pty Ltd
Ph: 0438 840 787

Some defeats are instalments to victory.
   -- Jacob Riis

Well, I think that the problem is simply answered by: People do not understand the ideas of "simplicity" and "precise" like we encourage smalltalk code to be.  this is a very interesting issue, and, at some point, I would like to create a SWOT(look it up on Wikipedia) analysis of smalltalk, to see just what is going on.
David Zmick
/dz0004455\
http://dz0004455.googlepages.com
http://dz0004455.blogspot.com

On Fri, 21 Nov 2008 21:23:13 +0100, Claus Kick wrote:

> Klaus D. Witzel wrote:
>
>> Me thinks that the Smalltalk community is healthy and vibrant--it is  
>> "just" a community form one would not expect for Ruby or Python or  
>> Perl,  etc. To get impression of my impression take a look at what  
>> *actually*  happened during the *recent* months:
>
> Why would one not expect this community for Ruby or Python or Perl?  
> Could you please explain what you mean, for this puzzles me ...

There are (almost uncountable ;) many things which shape these  
communities; perhaps I focus on some of the obvious from a day-to-day  
perspective:

- starting+using Smalltalk is always starting+using the whole system,  
there are no parts, in an absolute sense, and there is no way to change  
that

- the Smalltalker has generally broader knowledge about his *whole*  
system, think of navigating "implementers of" as an example

- the Smalltalker has generally deeper knowledge about his *whole* system,  
think of navigating "senders of" as an example

This (and more ;) naturally orients the community along completely  
different dimensions, beginning with the learning curve, through things  
you can change+reuse, up to things you can achieve (like VMMaker+Simulator  
or Etoys or Scratch or Croquet or Moose or DabbleDB or Sophie), with a  
handful of people, in the Smalltalk community.

/Klaus

--
"If at first, the idea is not absurd, then there is no hope for it".  
Albert Einstein

2008/11/22 Antony Blakey <[hidden email]>:
Right, you pay for design, but nobody pays the fee for entering his
authentic house (read - get a copy).

>> So why we should
>> pay a software architect for each copy of his software?
>
> You first need to prove the applicability of this analogy. And in any case,
> given my comment above, I think this proves the opposite of what you intend.
>

How do you like the following: these words is my intellectual
property, and once you read them you have to pay $$ to me as license
fee. Ignoring this would lead to prosecution in court. :)



--
Best regards,
Igor Stasenko AKA sig.

On 22/11/2008, at 6:14 PM, Igor Stasenko wrote:

No, not 'get a copy'. The appropriate equivalent is 'use the software'.

And in any case, there are buildings for which you are charged entry,  
and sometimes purely on the basis of the architect. Falling Water  
might be like that (although I think I read that it's no longer open  
due to structural issues).

Anyway, this argument is off-topic for this list, so I'll leave it to  
you to have the last word ... :)

Antony Blakey
--------------------------
CTO, Linkuistics Pty Ltd
Ph: 0438 840 787

75% of statistics are made up on the spot.

>> Not really, because I posted at least two implementations of Generators
>> in the public domain and people were still saying they were tainted by
>> gst's.
>
> Cool! I've been thinking about Generators myself. Can you point me to
> your implementations?

One is in GNU Smalltalk's examples/Gen3.st.  It is GPL but I am ok with
relicensing it to MIT.  It uses separate processes, so it is not very
exception friendly.

Anyway, the best one is for VW and is at

http://groups.google.com/group/comp.lang.smalltalk/browse_thread/thread/5274ae013723329?ie=utf-8&oe=utf-8&q=generators+smalltalk+bonzini&pli=1

Squeak does not have the Promise class (a ValueHolder that runs in a
separate process but forwards exceptions to the process who sent
#value), unfortunately, so it won't work there out-of-the-box.

Of course, you need to figure out what it does from the usage I make in
the Generator class.  Otherwise you'd be tainted by VW's source code and
Squeak would face being sued by Cincom for copyright violation.  Sorry,
couldn't help it.

Paolo