Ship it with Squeak
Stefan Matthias Aust
sma at 3plus4.de
Wed Jun 28 21:05:16 UTC 2000
At 08:16 26.06.00 -0400, douglas at winetech.com wrote:
>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. 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.
Why don't you, assuming the project is large enough, allocate 10% of its
time to create the extensions needed? That will might also be a nice
payback to the community ;-) And I'm pretty sure that you can still be
faster that with C++ (VB is probably nearly as nice as Smalltalk).
For example, today we spend 3 hours with a customer to test, debug and fine
tune an application written in Squeak. With other languages like C++, we
coudn't have done that at all and probably would have spent two additional
days development.
>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).
That's unfortunately true and not that easy to change if you want to
achieve the quality (yes really) Microsoft provides with VB or Access. For
a simple grid morph one could derive the TableMorph which was already
mentioned on this list. Adding some in-place editing capabilities and
finished up the stuff might take less than 1 week. Squeaks normal text
input field can already show colors (even working hyperlinks) and one
custom font but one would need to work on this to support multiple fonts,
different indentation, list bullets, paragraphs with different line
heights. To allow text input one probably would need an editor morph
similar to Microsoft's wordpad. As I don't know much about the edit
control, I'd guess about 1-3 weeks of work - including the wordpad editor.
>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.
Depending on what you need, it might be sufficient to keep the data in your
image. The application mentioned above simply keeps 50MB of data which,
after one
Smalltalk collectGarbage
which moves all global data into the old space doesn't affect performance
at all. And it's know pretty easy to use Smalltalk's #select: and
#collect: messages to access the data.
>4. Not even an obvious ability to store 100 megabytes on BTrieve-like files.
Even 100 MB woudn't be a problem on a 256MB+ PC ;-)
>5. Poor documentation.
Well, here you need to look at example, browse the web and ask question on
this list. This can definitely be improved.
bye
--
Stefan Matthias Aust // Bevor wir fallen, fallen wir lieber auf
More information about the Squeak-dev
mailing list
|