Xref: utzoo comp.lang.smalltalk:2527 comp.windows.ms.programmer:624 Path: utzoo!censor!geac!torsqnt!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!uunet!munnari.oz.au!metro!extro!objtch From: objtch@extro.ucc.su.oz.au (Peter Goodall) Newsgroups: comp.lang.smalltalk,comp.windows.ms.programmer Subject: Re: Smalltalk V/Windows tbr Jan 15 Message-ID: Date: 14 Jan 91 19:23:50 GMT References: <20654@netcom.UUCP> <910@ehviea.ine.philips.nl> Sender: news@metro.ucc.su.OZ.AU Organization: Sydney University Computing Service, Sydney, NSW, Australia Lines: 78 Nntp-Posting-Host: extro.ucc.su.oz.au avbalen@ehviea.ine.philips.nl (A.G.M. van Balen) writes: >In article <20654@netcom.UUCP> ergo@netcom.UUCP (Isaac Rabinovitch) writes: >>Digitalk will supposedly release the Windows version of Smalltalk V on >>the 15th. Does anybody consider this a serious alternative to C++ and >>the SDK? Here is my humble opinion: If the Presentation Manager version is an indication, smalltalk fixes a lot of the kludges that appear in window management. Microsoft/(IBM) have tried to create an object oriented system using C. The horrors of this are apparent when you subclass a window in C. You do get get an equivalent to overloading the procedural part of the class, the new classes event-handling loop gets events before the superclasses. You don't get any of the superclasses data. The extra bytes dissapear. Smalltalk lets you create real subclasses of windows. You also get a great deal of leverage over C. in /VPM the code: ApplicationWindow new open gives a standard window with default controls and menu bar open, and ready to go. This seems to take about 40 lines of C, and takes half a day to explain to experienced C programmers notused to event-driven programming. The interface to the rest of the system - called through system DLLs is reasonably tidy, though it does take detective work to understand the parameter passing. Digitalk seems to aim its documentation towards the moderately serious hobbyist, rather that the person building real systems. A big advantage to developing in Smalltalk is that you don't refer to pointers and memeory explicitly. Some experienced C, C++ people start to feel ill when considering memory management and pointer errors under Windows and PM. Automatic, fast (not reference counting) garbage collection is one of the greatest aids to productivity. People who say that GC is too slow have generally tested on baby programs. When you have lots of data flickering in and out of existence, GC really starts to pay its way. Also the program will be more likely to run. When you mention Smalltalk to people who haven't seen it for ten years, they tend to say it's too slow and dismiss your arguments there and then. Smalltalk has come far enough so that people say that, especialy for GUI work, performance is not an issue any more. How I tend to work is: Write the whole application in Smalltalk. Profile the Application (you may have to write your own profiler, or speak nicely to me!) Level the profile in Smalltalk. Write primitives for the hot spots. Recently I've been looking at writing primitives in C++, which seems express the Smalltalk internals fairly naturally. Smalltalk/VPM and I assume the Windows version has very good access to external code. So you can use libraries written in other languages. Could ramble on for weeks here, so better stop. >> >> >I cannot speak for C++, having no experience with Zortech, CommonView >or similar, but I would *love* do have the Smalltalk environment. >Would speed up my productivity, doing 'TopPane new' iso >CreateWindow, WindowProc, RegisterClass, ShowWindow.... >I heard on BIX that the official shipping date will be jan 28th. >Hopefully, guys already loyal to Digitalk (I have ST/V, ST/V 286 and >ST/V MAC) get a discount... Call digitalk an make a telephone order, you should get a discount. >Auke ---------------------------- Peter Goodall Smalltalk Systems Consultant ObjecTech P/L 162 Burns Bay Rd, LANE COVE , NSW, AUSTRALIA objtch@extro.ucc.su.oz.au