Andrew,
   
    Thank you for your reply.
   
    However, this only proves my point - your application fits perfectly 
into 'playing with ideas'. Have you ever tried to open 2GB database in 
squeak and make automatic analysis of the data? Another application I 
needed - construction of LDIF files for customer's existing data 
sources. It worked, but it was very slow and the image was not fun to 
touch in the (long) time it ran.

    I don't say I don't like Squeak. I liked it a lot. I just feel it 
could be more suited to my type of 'real world problems'. On the other 
way you can claim that my feeling is based on the fact that I know 
Python better and longer. This might be true. What I wanted is to know 
on what extent the readers of this group do I/O and memory intensive 
tasks with Squeak.

    I don't think this discussion is a troll, though.

        Yoel

Andrew C. Greenberg wrote:

> De gustibus non disputandum est.  Latin for, "its best not to feed a 
> troll."  Nevertheless, I dissent.
>
> The decoupling of Squeak from the OS is, for my practical work, a 
> practical benefit.  I use Squeak to prototype applications and games 
> that I can build cross-platform without effort.  At the time I picked 
> up Squeak, I was trying to use Python for precisely that purpose, and 
> Squeak won hands down.  These applications run pixel-for-pixel 
> identically cross-platform, despite their graphic and multi-media 
> nature, and I can work on each system, back and forth, with equal 
> fluidity.  (My first application for Squeak was a birthday present for 
> my wife, which I wrote on my office PC, and e-mailed over to the house 
> Macintosh just days before delivery -- worked like a charm.  In sharp 
> contrast, TkInter was buggy, unreliable and worked differently on each 
> machine.)
>
> As to your specific points, I have never worried in Squeak about 
> memory management, process or thread scheduling -- that is the virtue 
> of garbage collection and Squeak's built-in coroutining.  I have never 
> really had any problem running multiple processes on multiple 
> applications.  YMMV.  As to documentation, there are now many 
> references for Squeak, both in print and on-line.  As a practical 
> matter, non-beginners rarely have problems working out what they need 
> to know using the awesome system browsing facilities as a practical 
> matter.  Finally, of course, the "marketing" of Squeak has little 
> bearing on its practical utility.
>
> It probably does just come down to a matter of taste.  For my part, I 
> can say that Smalltalk has become my language of choice for practical 
> development of ideas and prototyping of new systems.  I have never 
> been as productive or more efficiently linked to the computing system 
> in any environment as I have found myself in Squeak.  This is not to 
> say that there are things Squeak cannot easily do -- I have many 
> arrows in my quiver.  But when I get excited about reducing an idea 
> into practice, I find myself slipping into Squeak first -- even if the 
> target environment is going to be something else because of, say, need 
> to target a particular GUI or database system.
>
> It is fair for Yoel to say he doesn't like Squeak or prefers Python, 
> but his stated arguments are thin, at best.  They don't really present 
> any meaningful "practical, day to day" distinctions that matter.  He 
> may even be right at end (though I don't think so), but the argument 
> wasn't stated here.
>
>
> On Monday, January 28, 2002, at 02:39 AM, Yoel Jacobsen wrote:
>
>> Hello all,
>>
>>    I'm a computer professional, doing system architecture and 
>> implementation of medium to large directory, messaging and other 
>> (mainly Solaris oriented) systems I have this inquiry sitting in the 
>> back of my head for a long while.
>>
>>     I do LOVE playing with Squeak and implemented some nice ideas 
>> (currently - ASN.1 encoder/decoder to form a basis for an LDAP 
>> implementation).
>>
>>    However, when it gets to practical, day to day programming I just 
>> fill that other languages (mainly - Python) is more practical. I can 
>> transfer my ideas into a running program in a short while.  When 
>> analyzing why it is so, I have reached the following conclusions:
>>
>>    1. Squeak is TOO decoupled from the underlying OS. I want to make 
>> use of Solaris or any other high end UNIX like OS for memory 
>> management, process and thread scheduling, and so forth. I need to 
>> make sure that if managing the memory behavior of Squeak Processes 
>> will be done without affecting the entire environment (I want to work 
>> on code while another process is running in full speed).
>>
>>    Yes, I can create a minimal image and run 'squeak minimal.image 
>> myscript' but it would not give me the advantage of managing a 
>> running process in my development image.
>>
>>    2. Class documentation quality.
>>
>>    3. Squeak is 'marketed' and therefore progress as an idea 
>> exploration tool. I usually explore my idea with the implementation 
>> tool. Python do both for me.
>>
>>    So, the inquiry - Are you using Squeak for any practical use? 
>> Please tell me only about resource intensive applications (currency 
>> conversion does not count as a practical application).
>
>
>
>
>