Hernan, I agree with you in a lot of points... but disagree in others
(and since my English is not good, I prefer to explain my point using
very poor sentences).

On 5/12/06, Hernan Wilkinson <hernan.wilkinson at mercapsoftware.com> wrote:
> (...)
> I have worked with Assembler, C, C++, Java and some C#... but Smalltalk
> is a "one way street". You take it and when you understand it, you don't
> want to go back.

This kind of responses are not helping in "marketing"... :P
Yes, in Smalltalk we work different, but not because "we saw the
light". Is just because we have learned the "code" of the language.
(It reminds me the theory of Bernstein in education, see:
http://www.doceo.co.uk/background/language_codes.htm). So I think that
instead  of saying: "go learn! before talk", we have to understand how
is the process of learning smalltalk, to communicate it better to
newbies.

> (..)
> > If you mean the hole environment, then I can't agree with you.
> > One thing Java and .Net have in common, C++ is trying to get and
> > Smalltalk is missing, is a standard
> > library set. Every dialect of Smalltalk has its own set.
>
> I don't see this as a problem. The main classes are similar and I don't
> go from one Smalltalk to other coding. We develop in with one Smalltalk,
> why would I need to use other Smalltalk?.

I think that "standardized" APIs are too restrictive.Because no one
wants to change it...just to follow the standard (ie. the DateTime in
ANSI ST), even when the design proposed by the standard is ugly.
As long you develop in a closed group is easy: just modify St as you
want... but what happens when you want to share it with a community?
Porting and testing in each platform (or merging changes in the same
platform)... may be is not difficult, but it could take a lot of time.
So I see a problem here.

> (...)
> But why do you need to port "libraries"? Anyway, if that's your problem,
> I understand it, but if you want a broad support for different
> platforms, just choose VisualWorks that works in almost all platforms...
> (Squeak also ;-) )

Yes but VW is very expensive for commercial projects, and Squeak
currently lacks of tools and frameworks for doing a "commercial"
software project... someone can say "but you can make a nice UI using
Morphic or Tweak", but in the current state of Squeak this requires a
lot of work compared with other tools (Seaside and web apps is another
history).

The lack of commercial oriented tools, is ok in Squeak because, Squeak
was conceived as a learning tool. We have to take this in account when
comparing Squeak with other languages like Java.... maybe it would be
good to have a "commercial" oriented distribution of Squeak. That's
why I think that Spoon is wonderful, with a correct testing and
modularization it will a allow different distributions of Squeak
without forking the code base... and we can have an equivalent to Ruby
on Rails for commercial purposes :)

Regards,
Diego.-