bmyers@dimaggio.ucr.edu (brian myers) (03/25/91)
Well, it's been quite some time since I posted the request for information concerning smalltalk vs Actor and I must say the response has been underwhelming. I received many requests to post the answer to one newsgroup or another or email a response, but there were only two replies providing information. One was from a Parc Place Systems employee and he admitted that the info might be biased, but I heard absolutly nothing from anyone else. I had requests from various people to post the results in these three newsgroups: comp.lang.smalltalk, comp.windows.ms, and comp.windows.ms.programmer. I realize comp.windows.ms is not exactly the proper group but the person who requested the post said he didn't get the comp.windows.ms.programmer newsgroup. Also remember, when referring to Smalltalk here, I am referring to Parc Place Smalltalk. The person who sent me the information was <khaw@parcplace.com>. ------------------------------------------------------------------------- Actor runs on AT class machines. Smalltalk requires at least a 386, and at least 4 MB (real + extended) memory (NOT expanded memory). It appears Smalltalk is better at dealing with large numbers of objects, but isn't as Windows specific as actor. If you're trying to develop Windows specific applications (probably with low level access) it's harder in Smalltalk. Here's why: When you create a method, Smalltalk reduces it to Smalltalk bytecode. When you actually invoke the method, Smalltalk on-the-fly translates the bytecode to machine code and caches it in memory. Subsequent uses of the method then cause the cached machine code to execute with no interpretation overhead. The reasons we use bytecode are (a) compact representation (machine code typically expands to 5 to 10 times the equivalent bytecode), and (b) portability across different machines architectures. Smalltalk release 4 for windows has a fileIn that will access DLLs. Actor has a Library class and a pcall method. Actor comes with a parser class that (supposedly) reads yacc output. It also has a specific Actor language parser built in. Smalltalk has only the specific ST language parser, but the "Advanced Programming" package comes with Parser Compiler which does the same thing as yacc. However, I doubt it's yacc compatible and I'm sure it costs a bundle. It seems Smalltalk has all the windows specific classes like dialog boxes, edit controls and such, and the edit box can contain as much text as there is virtual memory. I don't know how the completeness of the two packages compare in this respect. Prolog/V is part of Digitalk's Smalltalk/V. I was hoping to hear from Digitalk but never did. By the way, I understand Arity has their prolog running with windows now via a C interpreter or something. Appearantly Smalltalk doesn't allow direct SDK calls like Actor, even though Actor doesn't implement the full set of SDK call. To generate .EXEs in Smalltalk you can store the virtual image as a resource in the .EXE file. This sounds rather cumbersome but not quite as bad as Actor's two seperate files. Parc Place does charge royalties. I can't remember right now weather Actor does or not (I don't think they do). More info can be found on PP Smalltalk at email info@parcplace.com. The other person who responded (I believe) was speaking specifically about Digitalk's ST when he stated that a stand alone .EXE file can't be created. He mentioned one other thing too, but I can't remember what it was and I lost his message. Obviously can't refer to his email address either. Damn. g-------------------------------------------------------- "...and why do I have this sudden urge to say -- YO" -Dale | Brian D. Myers Peon UCR graduate student. | D is for (Dale)