On Mon, 26 Jun 2000 douglas at winetech.com wrote:

[snip]
> I have been watching this Squeak list for about 6 months, and was hoping to 
> see real evidence that we could consider Squeak for our next generation 
> product (see winetech.com).  We currently have software written in a 
> combination of Visual Basic, C++, and the Microsoft Jet Engine for the 
> Access database.

I would have been surprised if Squeak were drop in replaceable for that
combo. (But I might suggest, if you're ok staying on windows only, Dolphin
Smalltalk.)

>   Squeak initially looked promising as a platform for the 
> future, but I am gradually and  sadly reaching the conclusion that it is 
> may never be usable for software like ours. 

Well it *may* as well :) I'll point out that Squeak the evolving system
and Squeak the deployment platform are not necessarily identical.  Keeping
the two distinct and yet separable is a challenge not yet met but one that
will be met sooner if there's an active "deployment group".

I would say that one should expect some "pain" in such a
situation--it's not going to be a one time job. For example, I can see how
to puttogether a simple parceling mechanism out of reference streams, or
image segmants, or FileDictionaries...but the simplest hack that will work
will need (probably) to change when environments are settled. New
features, new simplifications...these will require change. No matter
*what*. The only way to assure "stability" is to fork...which is a
reasonable option in my book :)


> Here are the issues:
> 
> 1. No current orientation toward application deployment at Squeak Central.

True, but if Paul gets the Deployment Fetishists Association (;)) rolling,
that may be a bit moot.

> 2. No stable GUI that provides critical tools for manipulating large slabs 
> of data (particularly Grids that show multiple records and Rich Text boxes 
> that display and edit text while using multiple fonts and 
> colors).

Hmm. This isn't quite true. You can use muliple fonts, colors, styles,
etc. right now in a Workspace (or even a code pane). Or you could use
Scamper for static display (which would let you reuse html).

And there are some tools for sound display, editing, an manipulation. That
might count as large data sets. There is the TableMorph. And
Listboxes. The latter, of course, are not optimized for large data sets
(as lex has pointed out wrt celeste), but might well becomes so, or
at least such an improvement would be welcome and adopted (again, for
both, because of Celeste).

>  Although I realize that many on this mailing list regard these as 
> old-fashioned and boring, they are still necessary for many purposes.

No, I think we all want them. I'm interested in hearing what's missing
from pluggable text boxes wrt rich text, and it's merely a matter of no
one following up (yet) on the other.

>  We 
> would like to use Squeak's wonderful capabilities in addition to these 
> tools, but we cannot start development without them.

Sensible. It might make some sense, however, to try implementing one of
them, as a development test case. Any such work would be welcome, and
you'd get a hands on assessment of the difficulties of filling gaps in
Squeak.

> 3. No database ( We currently have about 50,000 records across two 
> databases, taking up about 100 megabytes).  We need fast access from a 
> variety of different indexes.

There is a MySQL driver (which I may get to test out today! yay!), and
several of us are groaning about other drivers and OBDC access. There is
MinneStore. I certainly have no notion of how difficult it would be to
write a set of primatives for Access..er...access :)

> 4. Not even an obvious ability to store 100 megabytes on BTrieve-like files.

Well, this wasn't obvious to me :) But again, I'm not sure how "big" a gap
this is to cross. It certainly seems that there are "packages" for this
sort of thing. How difficult it is to make them Squeak "active" is unknown
to me. But it's certainly *possible* that the "cost" of adding this is
"made up" in other areas.

> 5. Poor documentation.

Some is poor, some is scattered, some is just incomplete, and some is
quite nice, and much is getting better. But you can't yet just sit down
with a single reference and read through everything there is know about
squeak :)

> While it looks like Squeak has tremendous pluses (Innovative, open source, 
> great functionality, machine independence) , these seem to primarily 
> benefit teaching and research, and not actual application developers like 
> ourselves.

Depends *strongly* on the application.

> I admire Paul's effort to develop a deployable Squeak application, and 
> would consider any success he has as great evidence that we may be able to 
> use Squeak also.

Note that nothing I say is intended to support the proposition "Squeak is
a prime time classic RAD system". It isn't. Dolphin is much closer, though
it isn't cross platform. I think some of use need to start actually
distributing "clunky" apps before we're going to really get "smooth" apps
*out* (forgive the pun) Squeak.

Pauls distinction between Squeak as OS (or "system" as I like to put
it) and Squeak as Application is far better, in my mind, to the research
vs. production one, and one I shall have to think about more.

Cheers,
Bijan Parsia.