No. I just tried to teach Pharo to do several things in parallel: Seaching stings in several 1 GB files, opening and reading several databases at once in parallel, handing results over sockets to several clients. Try it yourself. Whatever you do with Pharo, you won't get any smooth IO, even if you use COGMT. Smalltalk code is not yet adapted, it seems. Same with eventhandlers. Try editing while copying and filtering a file in background. Happy waiting!
I had much success with Smalltalk MT, LUAJit, medium success with node.js ... Don't get me wrong, but business develops to realtime filtering of concurrent information streams coming from different sources (twitter, facebook, mail, irc, p2p, databases, homepages, rss, XML, Soap ) and that intelligently presented in realtime on my Desktop. We did intensive testing of several interpreters. I personally really prefer Pharo, because it offers a outstanding, very complex construction kit for doing marvellous things, beginning from "abstract connectors" that combine filters with editors with gui, web, streams, databases, over to very good IDE up to certain (decreasing) compatibility to squeak and its mass of "toy apps". I think, that, when a deeper understanding of how to acheive parallelism, realtime, concurrency comes to Smalltalk programmers (not just starting coroutines and hoping, the kernel gets it right, claiming everything is multithreaded), Pharo very soon could be business ready! :-) And it is good to understand, *why* Wikipedia now uses LUAJit (a highly dynamic language, like Smalltalk), Blizzard (World of Warcraft), Steam (realtime control of complex game worlds) use LUAJit, EVE uses Stackless Python with continuations. Smalltalk would be very well suited, but its implementations are missing important features, realtime qualities, real concurrency, not just one at the surface, claiming apps being "multithreaded". Seaside, e.g. immediately drops to under 1/second, at even 10 simulaneous clients, when data comes from SQL or even OODB, means case of cache misses. Pharo becomes unresponsive. For me, good architectures can be recognized, when they smoothly go on serving, even at 50 times overload, still keeping small memory footprint. Compare to Linux at high loads (sshd, telnetd not answering) and FreeBSD (you can still login, even if 50.000 clients connected). You might still laugh at me... i don't. Have fun, Guido Stepken Am 01.03.2012 10:29 schrieb "Henrik Johansen" <[email protected] >: > > On Mar 1, 2012, at 10:03 AM, Guido Stepken wrote: > > As long as GC, recompile, (see blocked UI during updates), ffi database > drivers completely block Smalltalk execution or do not access external > databases smoothly in parallel (also see async I/O, MP) i see only one > laugh here - that's indeed you! > > Have fun! > > Guido Stepken > > > Aaah, the good ol' "If you can't hit with a rifle, switch to a shotgun" > approach, haven't seen that in a while. > > Have fun! > Henry >
