Hi!

I am not really arguing here - just mentioning some pointers about these
bullets that might be interesting to hear about:

Kendall Shaw <queshaw at pacbell.net> wrote:
> If your program doesn't look exactly like every other program and use 
> exactly the same procedure they've had to use for every program, then 
> game over, you might as well not have even bothered to write the program.
> 
> In squeak, the controls don't look or behave like the other controls a 
> user will use on their computer, so game over, you might as well not 
> have even bothered to write the program.

http://www.wxsqueak.org

...or just use Dolphin for win32 apps - it is really nice for that.
Or turn the app into a localhost webapp, like we are currently doing
with the issue tracker we are writing.

> It doesn't matter what I think about it. It's what the user is likely to 
> think about it.
> 
> Most importantly though, I can't open emacs on squeak's desktop.

wxSqueak doesn't "force" a deskop. Try the demo. And even so - why not
run Emacs on the side? :) Or inside Squeak:
	http://map.squeak.org/packagebyname/svi

And then we have Areithfa Ffenestri or what the heck it is called. ;)
(the code for supporting multiple windows from within Squeak - but
wxSqueak already gives you that actually)

> Also, I can't easily check a squeak application into a version control 
> system, separate from other squeak applications, but together with other 
> source files in other languages, and other files.

Mmmmm, "easily"... well. There have been numerous approaches of
mirroring Smalltalk code into files for that like MonticelloCVS or
CVSTProj. I even hacked up a almost fully functional cvs pserver
protocol implementation. ;) But these days Monticello is so convenient
to use and just needs a file dir or an ftp server for team work - there
is no real incentive to bother. Especially not now that MC2 is seeing
the light.

And if the idea is to just "bundle" a snapshot with other snapshots of
software - then just dump the .mcz into your choice of repo, no big
deal.

> I can't run find on a combination of squeak classes and other files.

You shouldn't. ;) But apart from that aspect - adding a mirroring
mechanism of source into files that is "live" shouldn't be that hard if
someone really wanted to do it.

> I can't easily include it in a test procedure involving multiple languages.

Hmmm, why not? I mean - what makes Squeak harder to use in a test
procedure than *any other* mixing of languages?

> I don't think you could easily distribute it as an rpm or a debian 
> package etc. and deal with dependencies between squeak applications.

You can very easily deploy a Squeak app as an rpm or deb. The simplest
way is to just bundle the VM with the image. No external deps at all.
And I can't see why Squeak would add any further obstacle than any other
language in that respect.

> I can't use installshield to integrate it into someone's squeak applications.

Not sure what you mean. Making an "installshield" installer for a Squeak
app is trivial. Just test:
	http://swiki.krampe.se/gohu/23

That is old though, Cees has improved it a bit and I am using it right
now for our issue tracker.

regards, Göran