On Wed, 30 Dec 2009, Guido Stepken wrote:
1. What classes are compatible to other smalltalks? When i follow
mailing-lists of Dolphin, Squeak, VW, VA Magma - there still is a bunch of
porting problems. Why?????? What classes should i give preference to
minimize porting cost?
Why would you like to port your app?
2. Interfaces ... hmmm, well ... there are many programmes thinking in
categories of "interfaces", "libraries", "class dependencies", e.t.c. Of
course, Smalltalk is something completely different, but it makes it
difficult for s.b. e.g. coming from Java or C++, to find into Smalltalk
concepts. Gofer - till now, i have just a wage imagination, what it's
good for ...
Reading a book is generally helpful when someone is learning a new
language. But it's not necessary with smalltalks since the system is
so open that, one can learn by exploring it.
4. Multitasking, green threads, ... There are really missing some pointers,
howto code e.g. a background process that is fetching some data from e.g.
MySQL or reading/writing large files, sending data over network - without
freezing the GUI.
As others pointed out, these are implemented with blocks. What would you
do if, say you wanted to know how to do threading in java? Reading a book
or googling is helpful:
- http://www.google.com/search?q=squeak+threads
(I guess a chapter on processes would be useful in PBE/SBE.)
5. Standards: XML-RPC, SOAP, RMI, CORBA, .... encryption (SSL) ... Without
having a precise idea, where to find working examples to exchance data with
other systems, i would hesitate to begin to do projects with Pharo/Squeak...
Some of this crap is available at squeaksource/squeakmap.
6. Databases: Magma seems to be fine as database, but also dog slow. I
really hesitate to start serious projects with Magma.
7. Speed, Memory consumption, Quality of modern algorithms: When working
with Seaside, PIER ... that stuff is dog slow, memory consuption is hardly
predictable. That makes webhosting e.g. on vservers absolutely impossible,
the whole system quickly becomes unstable. IMHO in Pharo there are routines,
Tuning the garbage collector (which one should do when deploying an image)
may help here. Btw I didn't experience such problems with seaside (2.8 & 3.0).
that really waste a lot of memory, that could be programmed in a more
intelligent way, expecially collection's algorithms ... ;-)
Perhaps Donald Knuth books ("Art of Computer Programming") could help?
Can you point out a few examples?
Where e.g. is 'fulltext hash' or 'fulltext search' implemented in Magma, e.t.c.?
What does Magma have to do with Pharo in this context? Where did you read
that Magma has full text search? (Btw if you have a data structure that
has full text search capabilities then voila, Magma has full text search.)
Whole world works with fulltext databases (Google, MySQL, PostgreSQL, even
MSSQL, Oracle). Thats 'state of the art'!!!!!!!! Search in TB databases
in milliseconds!
If you need an RDBMS then use one, there are several drivers available.
Levente
so far my 0.0199999999˙˙
Keep up the good work on Pharo, it's still a long way to go!
regards, Guido Stepken
--
_______________________________________________
Pharo-project mailing list
[email protected]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
