kt@msor.UUCP (Keith Tizzard) (05/02/90)
Can anyone please offer an objective comparison of the merits of
Smalltalk-80 and Smalltalk/V on an Apple Mac IIci.
I have experience of ST/V on a PC and have used ST-80 on a Sun/3 on
one or two occasions so am familiar with the superficial differences.
I realise that ST-80 is the 'real' :-) product but I have greater
knowledge of the classes and methods in ST/V. Is is worth learning
the classes and methods of ST-80 which do the same or similar things?
I appreciate that everyone has their own personal preference and mine,
at the moment, is for ST/V, partly because I have adjusted its
environment to my liking; hence my wish for some objective comparison.
Possible questions are:
Are there particular features present in one that are a serious
omission from the other?
Is one noticeably more efficient than the other on a Mac?
Can each of them produce stand-alone executable code for appliactions?
Comments on other aspects would be welcome.
--
Keith Tizzard
MSOR Dept, University of Exeter, Streatham Court, EXETER EX4 4PU, UK
tel: (+44) 392 264463 email: kt@msor.exeter.ac.uk kt@msor.UUCP dpbsmith@well.sf.ca.us (Daniel P. B. Smith) (05/06/90)
I can't compare Smalltalk-80 to Smalltalk/V Mac, but I can tell you about my experiences with Smalltalk/V Mac. The price is right. The manual is very good and has the right amount of tutorial material at about the right level for me. The product has many rough edges as a Mac product. I can't vouch for how it is as a Smalltalk product, but I sense some unevenness their, too. This is my first exposure to Smalltalk and my initial reaction is that all of the lower level stuff (e.g. the collection concepts, the way numbers are handled, the stream concept, etc.) is blindingly elegant, but the higher level stuff (how you put an application model together) is not so wonderful. From the Mac point of view, there are outright bugs. For example, if you are running under the Finder, and you bring up a desk accessory that has a menu (e.g. KeyCaps if you want to replicate the bug -- Acta happens to be the DA I really want to use), Smalltalk/V rewrites the menu bar AFTER the DA has added its menu, i.e. it wipes out the menu. (Workaround: use Multifinder). Another example of an outright bug: the "Directory hasFileNamed: fileName" method is case sensitive; i.e. if a directory contains a file named 'XEROX', Directory hasFileNamed: 'Xerox' returns "false", even though these are equivalent in the Mac environment. Mel Conway believes there is a bug in the way it keeps track of GrafPorts. There are some places where I do not know whether I have a legitimate complaint, i.e. I don't know whether certain things which are irritatingly non-Macish are just sloppy, or whether they are validated by being faithfully Smalltalkish. Mac environments (e.g. MPW, Logo) that have a scrolling worksheet model tend to have a convention that if nothing is selected, and you press the ENTER key, rather than executing nil it assumes that you wanted to execute the contents of the line the cursor is on. I find that convenient. Smalltalk V/Mac doesn't do this. Another problem I have as a Machead is that the model of text editing used in Smalltalk/V, while quite similar in flavor to Mac text editing, is different enough to cause problems. There seem to be no tools for word-wrapping text, and I don't quite know how to describe this but proportionally-spaced text is not handled quite properly. It is shipped preset for the very ugly Mac monospaced font Monaco 12, and one reason is that you tend to find subtle little problems in text display when you use other fonts. For example, Princeton (a math/scientific font in which there are superscripts and subscripts that perhaps go higher and lower than other fonts tend to) tends to overwrite bits of itself on adjacent lines, leave pixel crumbs behind, etc. It looks to me like a respectable, usable port of their Smalltalk into the Mac environment. It does use normal Mac paraphernalia like menus, windows, etc. It does give reasonably good access to the Mac toolbox. I.e. it does not treat the Mac as a 68000 with a raw bitmapped screen. But it is NOT a "real" Mac product. -- Daniel P. B. Smith dpbsmith@WELL 508 967-5599
peter@celia.UUCP (Peter Farson) (05/08/90)
As someone who has had experience with Smalltalk/V Mac, I feel I should
respond to Daniel P. B. Smith's comments on this.
)I can't compare Smalltalk-80 to Smalltalk/V Mac, but I can tell you about
)my experiences with Smalltalk/V Mac. The price is right. The manual is
)very good and has the right amount of tutorial material at about the right
)level for me.
I agree with this.
)The product has many rough edges as a Mac product. I can't vouch for how it
)is as a Smalltalk product, but I sense some unevenness their, too. This is
)my first exposure to Smalltalk and my initial reaction is that all of the
)lower level stuff (e.g. the collection concepts, the way numbers are handled,
)the stream concept, etc.) is blindingly elegant, but the higher level stuff
)(how you put an application model together) is not so wonderful.
I think "a few rough edges" is more accurate than "many rough edges".
I do agree that the way Windows, Models, and Dispatchers (the Digitalk
equivalents to Models, Views, and Controllers) interact is awfully
complicated, and doesn't seem to live up to the promise of simple,
self-contained objects that is the intention of the language (IMHO).
)From the Mac point of view, there are outright bugs. For example, if you
)are running under the Finder, and you bring up a desk accessory that has
)a menu (e.g. KeyCaps if you want to replicate the bug -- Acta happens to be
)the DA I really want to use), Smalltalk/V rewrites the menu bar AFTER the
)DA has added its menu, i.e. it wipes out the menu. (Workaround: use
)Multifinder).
I only noticed bugs occasionally, and with about the same frequency as
with many other Macintosh products I have used, such as MPW, Pagemaker,
Word, and several Midi editors. Also, the bugs almost always were quite
harmless, either affecting the display only or causing a Smalltalk Debugger
prompt to come up. The system would remain functional, and I could continue
what I was doing immediately.
)Another example of an outright bug: the "Directory hasFileNamed: fileName"
)method is case sensitive; i.e. if a directory contains a file named
)'XEROX', Directory hasFileNamed: 'Xerox' returns "false", even though these
)are equivalent in the Mac environment.
This is an example of something that is easy to repair yourself,
since in Smalltalk, you have access to almost all of the source code.
)Mel Conway believes there is a bug in the way it keeps track of GrafPorts.
)
)There are some places where I do not know whether I have a legitimate
)complaint, i.e. I don't know whether certain things which are irritatingly
)non-Macish are just sloppy, or whether they are validated by being faithfully
)Smalltalkish. Mac environments (e.g. MPW, Logo) that have a scrolling
)worksheet model tend to have a convention that if nothing is selected, and
)you press the ENTER key, rather than executing nil it assumes that you
)wanted to execute the contents of the line the cursor is on. I find that
)convenient. Smalltalk V/Mac doesn't do this.
Actually, I found this omission irritating enough that I went through and
altered the methods so that pressing the enter key would execute the whole
line. I also made it so that if you clicked on a parenthesis, square bracked,
or quote, it would select to the matching character. The process of
debugging the latter change in particular was very interesting, and it
was definitely a non trivial problem, making it skip past comments and
character constants (like $$ $ $' $"). I used the source code for the
methods that I was debugging, which conveniently enough, made use of
several of these constants, making it a very appropriate test case.
(Smalltalk can be so self-referential sometimes!)
)Another problem I have as a Machead is that the model of text editing used
)in Smalltalk/V, while quite similar in flavor to Mac text editing, is
)different enough to cause problems. There seem to be no tools for
)word-wrapping text, and I don't quite know how to describe this but
)proportionally-spaced text is not handled quite properly. It is shipped
)preset for the very ugly Mac monospaced font Monaco 12, and one reason is
)that you tend to find subtle little problems in text display when you use
)other fonts. For example, Princeton (a math/scientific font in which there
)are superscripts and subscripts that perhaps go higher and lower than other
)fonts tend to) tends to overwrite bits of itself on adjacent lines, leave
)pixel crumbs behind, etc.
I did run into this problem, and was unfortunately forced to stick with
even spaced fonts. Someone some time ago posted to this newsgroup some
simple changes to the methods to fix this bug. Anyone still have the info?
I'm sure Digitalk must have this fix incorporated into their latest version.
I no longer have much access to a Macintosh, so I haven't been keeping up
with the latest wrt Smalltalk/V.
)It looks to me like a respectable, usable port of their Smalltalk into the
)Mac environment. It does use normal Mac paraphernalia like menus, windows,
)etc. It does give reasonably good access to the Mac toolbox. I.e. it does
)not treat the Mac as a 68000 with a raw bitmapped screen. But it is NOT
)a "real" Mac product.
In summary, I think Daniel has given a rather harsh assessment of
Smalltalk/V Mac. I had a great time using it, and thought it worked
very well. I have used quite a few other pieces of Mac software that I
was much more disappointed with. I would be interested to know what Mac
products he does consider to be "real".
A couple of relevant notes:
1. I am not in any way affiliated with Digitalk.
2. I have never used a Smalltalk-80 system.
--
Mt. Vesuvius exploded | Peter Farson - Rhythm & Hues, Inc.
The Sea of Cortez is heating up | celia!peter@usc.edu
Tabasco sauce is slopped on my breakfast | celia!peter@tis.llnl.gov
Gotta buy some more batteries and meat |cca@newton.physics.purdue.edu (Charles C. Allen) (05/09/90)
What this discussion seems to boil down to is that some people want to use ST/V as a "Smalltalk" development environment, and some people want to use it as a "Mac" development environment. It works fine for the former, but has serious shortcomings for the latter. The big ones are: no way to distribute double-clickable applications (fatal, as far as I'm concerned), half-hearted integration of Mac tools (having all the Mac stuff appear under the "MacObject" class is an indication of this), no equivalent of the interface aspects of MacApp, there *still* is no support of Color Quickdraw, etc. etc. etc. > )proportionally-spaced text is not handled quite properly.... > I did run into this problem, and was unfortunately forced to stick with > even spaced fonts. Someone some time ago posted to this newsgroup some > simple changes to the methods to fix this bug. Anyone still have > the info? I posted some changes that fixed this. The simplest way these days is to get the latest version from Digitalk (1.1? 1.2? I forget...) which appears to solve this problem. > )It looks to me like a respectable, usable port of their Smalltalk into the > )Mac environment. It does use normal Mac paraphernalia like menus, windows, > )etc. It does give reasonably good access to the Mac toolbox. I.e. it does > )not treat the Mac as a 68000 with a raw bitmapped screen. But it is NOT > )a "real" Mac product. > > In summary, I think Daniel has given a rather harsh assessment of > Smalltalk/V Mac. I had a great time using it, and thought it worked > very well. I have used quite a few other pieces of Mac software that I > was much more disappointed with. I would be interested to know what Mac > products he does consider to be "real". I agree with the first poster. It simply is not what most programmers would consider a viable "Mac" development environment. Personally, I find the Smalltalk language to be the most elegant and desirable I've ever used. Alas, it is much harder to produce "real" applications with ST/V Mac than with MacApp (MPW or THINK Pascal 3.0). A "real" Mac product would: allow me to create double-clickable applications, allow me to get rid of the ST/V menus in my applications, not have all the (for my purposes) cruft that allows compatibility with other ST/V platforms but which I don't want, be reasonably up-to-date on system support (Color Quickdraw has been out for YEARS!), and... well, you get the idea. Charles Allen Internet: cca@newton.physics.purdue.edu Department of Physics HEPnet: purdnu::allen, fnal::cca Purdue University talknet: 317/494-9776 West Lafayette, IN 47907