jsv@hpsad.HP.COM (Jeff Vetter) (09/27/89)
I am new to the Smalltalk language and I am interested in purchasing a Smalltalk development environment for my PC AT. I have a few questions about the current offerings. 1. The current offerings seem to be Digitalk and ParcPlace; however, ParcPlace is quite expensive for learning's sake. Are there student discounts on any products that I could check on at college? 2. Does anyone offer a Smalltalk "compiler" to develop stand-alone applications? 3. Since this is my first attempt at object-oriented programming, which book(s) should I obtain? 4. Should I forget Smalltalk and try C++ instead? There seems to be a little more support (ie. books and development environments) for C++. I welcome all suggestions from novice through expert. Thanks for your help. Also, Unix mail responses are encouraged. Jeffrey S. Vetter HP Signal Analysis Division Rohnert Park, CA
peter@ficc.uu.net (Peter da Silva) (09/28/89)
If you have a C compiler, there is a freeware-style "little smalltalk" written in C. It's slightly different from "real" smalltalk, but not in anything that's really important for learning the language. There's an accompanying book, "A Little Smalltalk" by Timothy Budd, ISBN 0-201-10698-1. -- Peter da Silva, *NIX support guy @ Ferranti International Controls Corporation. Biz: peter@ficc.uu.net, +1 713 274 5180. Fun: peter@sugar.hackercorp.com. `-_-' "That is not the Usenet tradition, but it's a solidly-entrenched U delusion now." -- brian@ucsd.Edu (Brian Kantor)
dg@sisyphus.sybase.com (David Gould) (09/29/89)
In article <520002@hpsad.HP.COM> jsv@hpsad.HP.COM (Jeff Vetter) writes: > I am new to the Smalltalk language and I am interested in purchasing a >Smalltalk development environment for my PC AT. I have a few questions >about the current offerings. [questions omitted] >Jeffrey S. Vetter >HP Signal Analysis Division >Rohnert Park, CA Any Smalltalk programmer will tell you that C++ does not have a development environment ;-). This is true. My own experience is that the Digitalk Smalltalk/V is a great product, (I run it on a Mac tho). It is fast, fun, cheap, stable, and has a good manual (one of the books you are looking for). On the down side it is a subset of the ParcPlace product. For learning the choice is clear (to me at least). I believe that both systems can produce standalone applications, but you should expect these to be very large (file & memory size) compared to a C program (but the source will be _much_ smaller). All commercial Smalltalks are compilers, but they all generate bytecodes for the Smalltalk virtual machine, so that makes them all interpreters too. I highly recommend the book: Smalltalk-80, the Language, by Adele Goldberg (Addison Wesley), even if you don't end up with smalltalk. It provides a very good description of the class library, and the class library is the most important thing in any OO language (unless of course you want to write all your own code). There are several other books to look at, and most of them seem worthwhile, but start with Goldberg and you will have the basic ideas and understanding to evaluate the others yourself. As for C++, it is a hybrid of C and object oriented ideas, and while a big improvement on C and likely to be very successful, I can't recommend it for learning OO programming or ideas. In Smalltalk _everything_ is an object, so the language is very consistent and elegant. In C++ nothing is an object, unless you make it one yourself, so it is possible to continue writing C programs without every really developing an object oriented style. Even if you are 100% sure that you will end up useing C++, start out with Smalltalk. - dg ------ All opinions are mine and may or may not represent Sybase Inc. ------ David Gould dg@sybase.com {sun,lll-tis,pyramid,pacbell}!sybase!dg (415) 596-3414 6475 Christie Ave. Emeryville, CA 94608
pick@sdsu.edu (Dan Pick) (09/29/89)
In article <520002@hpsad.HP.COM> jsv@hpsad.HP.COM (Jeff Vetter) writes: > > I am new to the Smalltalk language and I am interested in purchasing a >Smalltalk development environment for my PC AT. I have a few questions >about the current offerings. > > 1. The current offerings seem to be Digitalk and ParcPlace; > however, ParcPlace is quite expensive for learning's sake. Are > there student discounts on any products that I could check on at > college? > > 2. Does anyone offer a Smalltalk "compiler" to develop > stand-alone applications? As far as I know, no such compiler exists. > > 3. Since this is my first attempt at object-oriented > programming, which book(s) should I obtain? > > 4. Should I forget Smalltalk and try C++ instead? There seems > to be a little more support (ie. books and development > environments) for C++. > It sounds to me like you're a programmer trying to produce production code quickly. If so, you'd be much better off learning C++. It's best to approach Smalltalk as a research and learning environment rather than as an applications development environment. In other words, if you're trying to get code up and running quickly, forget Smalltalk. On the other hand, if you really want to learn object-oriented programming, I highly recommend it. -- Dan Pick | USENET: pick@sdsu.ucsd.edu Dept. of Mathematical Sciences | San Diego State University |
toma@tekgvs.LABS.TEK.COM (Tom Almy) (09/29/89)
In article <6366@sybase.sybase.com> dg@sybase.com (David Gould) writes: >[...] Even if >you are 100% sure that you will end up useing C++, start out with Smalltalk. *NO! NO! NO!* You'll hate yourself for having used Smalltalk! If you never use Smalltalk, you might actually like C++, and even think you are using a high technology OOP Language. If you learn Smalltalk, you'll know that C++ is a crock, and you'll hate every line of code you write (and especially every line you have to debug!). Tom Almy toma@tekgvs.labs.tek.com Standard Disclaimers Apply, including :-)
jans@tekgvs.LABS.TEK.COM (Jan Steinman) (09/30/89)
<<jsv@hpsad.HP.COM (Jeff Vetter)>> <<Should I forget Smalltalk and try C++ instead? There seem to be a little more support (ie. books and development environments) for C++.>> You've found a development environment for C++? I'm impressed! The best I've seen is some combination of gnumacs, gdb, cscope and g++. (This might change when Cynergy is released, but not on a hacker's budget.) <pick@sdsu.edu (Dan Pick)> <...In other words, if you're trying to get code up and running quickly, forget Smalltalk. On the other hand, if you really want to learn object-oriented programming, I highly recommend it.> If you're trying to get code up and running quickly, forget C++. On the other hand, if you really want to learn object-oriented programming, forget C++. If, however, you will be forced to work for a living in a profession that is increasingly enamored of trendy ideas shoehorned into old languages that really don't adequately support new concepts, by all means use C++. Okay, serious now. (Did I somehow forget the little smiley face up there?) You seem to have some schizophrenia here. If you want to learn OOP, by all means learn Smalltalk first, so that you'll properly use C++ (and recognize and avoid its numerous warts) when the time inevitably comes. If you want to develop stand-alone application products, forget both of them and stick to a language you already understand well, because you don't really want to be sitting in two unrelated problem spaces when you're getting a product out. There are major commercial applications out there in Smalltalk. They tend to be in the form of easily customizable "application templates", rather than canned, "what you see is what you get" programs. Once you understand both Smalltalk and C++, you will be able to "get code up and running quickly" about 4 to 10 times faster in Smalltalk than in C++. And by the time you include modern user interface libraries and debugging information, a C++ application is often larger and slower than a comparable Smalltalk application. Jan Steinman - N7JDB Electronic Systems Laboratory Box 500, MS 50-370, Beaverton, OR 97077 (w)503/627-5881 (h)503/657-7703
bs@alice.UUCP (Bjarne Stroustrup) (10/02/89)
There seems to be a misconception that C++ is supposed to be Smalltalk (or that Smalltalk and C++ are in some way supposed to be the same). It follows from that view that you should be able to work in exactly the same way with implementations of the two languages, that you should be able to acomplish the same tasks with the two languages, and that when you cannot someone has goofed. I disagree with this premise. People who naively approach C++ and Smalltalk with this premise are going to be disappointed. C++ was NOT designed as an immitation Smalltalk. Had I tried that, I would naturally have produced something much closer to Smalltalk. Actually, I do not see a need for immitation-Smalltalks. Smalltalk is still the best Smalltalk around; it is a very nice language/system and its evolution is in very capable hands. So, C++ is not a very good Smalltalk; it was not meant to be. Similarly, Smalltalk is not a very good C++; it was not meant to be. There are two fundamental differences between C++ and Smalltalk: C++ is a language; Smalltalk is a system. C++ is statically typed; Smalltalk is dynamically typed. These first order differences follow partly from needs and application areas, partly they represent alternative strategies for attacking problems. Many differences follow from them. For example, in general - it is harder to built a high-quality (``modern,'' ``Smalltalk-like'') programming environment for a statically typed language. - it is harder to provide a high-quality programming environment for a language used on a diverse range of systems (rather than being a system in itself). - it is easier to design ``standard libraries'' in a dynamically typed language. - it is harder to produce efficiently running code for a dynamically typed language. - it is harder to cooperate with ``traditional'' systems from a dynamically typed language embedded in a non-traditional standard environment. - it is easier to manage the integration of large systems written by many programmers if statically typed interfaces are used. The list could be made much longer, but as it becomes more specific the specifics become hard to understand in isolation, data is harder to come by, and the issues gets more sensitive to matters of system maturity, application area, economics, and the background of the users. It is clear that both classes of languages/systems evolve to compensate for their weaknesses. The style of programming and the approach to design is (and I think ought to be) strongly influenced by the language/system used. The choice of language/system chosen for a job should be done with a degree of understanding of both the strenghts and the weaknesses of the alternative languages/systems. There is no reason to believe that a single language/ system will be the best choice for all applications - even if a particular user may have the luxury of working exclusively on projects where a single language/system has a fairly constant overall advantage. A novice's questions deserve a better answer than a polemic blast. The various ``object oriented'' languages do have something basic in common (for example, see my paper `What is Object-Oriented Programming? in IEEE Software Magazine, May 1988) and if people apporaching OOP is wellcomed by a blast from a parochial regigious war it reflets badly on all such languages. There is no language/system in existence that can serve the range of applications/needs that is currently served by various ``OOP languages'' - let alone the range of needs they could serve. C++ and Smalltalk were DELIBERATELY placed at the extreemes of the spectrum of reasonable design choices for practical languages at the times they were developed. That makes comparisons between them interesting (but tricky) and they support each others' growth as much as they compete for resources. I conjecture that there are many more Smalltalk programmers now than there would have been had C++ not existed - and visa versa. I suspect we could have a rather interesting debate about these issues, but I and many others will be at OOPSLA all of next week so we might have to wait a bit. One thing I'm looking forward to at OOPSLA is a panel/debate on almost this topic. The basic observation is that there are far too many silly ``religious'' arguments over language choices and that many such unconstructive debates are based on ignorance of and disrespect for other peoples' problems, needs, basic assumptions, backgrounds, and strenghts (and worse: often heavily influenced/biased by commercial interests). Dan Bobrow (from PARC) proposed a panel where people would present what they like about each other's languages: Gregor Kiczales (PARC) will present Smalltalk, Peter Deutsch (ParkPlace) will present C++, I will present CLOS. This could be interesting and definitely a change from the more traditional ``technical panels'' that IMHO are often no better than the commercial hype found on the exhibition floor.
toma@tekgvs.LABS.TEK.COM (Tom Almy) (10/02/89)
In article <9987@alice.UUCP> bs@alice.UUCP (Bjarne Stroustrup) writes: >There seems to be a misconception that C++ is supposed to be Smalltalk >(or that Smalltalk and C++ are in some way supposed to be the same). >It follows from that view that you should be able to work in exactly >the same way with implementations of the two languages, that you should >be able to acomplish the same tasks with the two languages, and that >when you cannot someone has goofed. > >I disagree with this premise. Good! And I'm saving your posting. Here there was a high level management induced aborting of Smalltalk, with a simultaneous embrace of C++, with C++ being pushed as having all the advantages of Smalltalk, without the resource cost. Anybody that actually compared the languages knew they were as different as apples and oranges. When people ask me about Smalltalk I tell them it is a great concept and program (particularly algorithm) development environment. When people ask me about C++, I tell them that it is superior to C, and that all C based projects should be done in C++ (given that appropriate compiler and debugging tools are available). But I can't bring myself to say that C++ is an OOP Language. (I've also used Modula-2 a little, and proponents of that language claim it is object oriented -- also "not true"). The fact is that Smalltalk spoils its users such that most language's OOP claims bear about as much credibility as a used car advertisement! Tom Almy toma@tekgvs.labs.tek.com Standard Disclaimers Apply
mitsu@well.UUCP (Mitsuharu Hadeishi) (10/31/89)
Yet I disagree that the gap between C++ and Smalltalk is so
unbridgeable. Consider the following design, which I implemented as
an advanced development project at Electronic Arts last year (what
follows includes some improvements on what we did, and I should note
that I no longer work for EA as an employee so I cannot speak for that
company, and though my company is now considering implementing another
version of the system, we may not have the adequate resources or time to
do so, and if anyone out there is interested in funding such a project
please contact us!):
One replaces the virtual function table method lookup system with
some type of fast hash message selector scheme. One then creates a
system which is a hybrid of C++ and Smalltalk: an interpreter which
uses dynamic typing, though also includes compile-time type checking,
and a compiler which uses static typing, though uses the hash table
method-lookup scheme if a method is marked "virtual" (or whatever term
you choose). You set up the system so that a compiled method may call
an interpreted method and visa-versa, and if a compiled method calls
a compiled method, it is either a direct C function call or a method-lookup
followed by a C functional call indirect via a function pointer.
The upshot is you have a system with compiled speed but
interpreted flexibility. You can change or add interpreted methods
even while the application is running, and you can change compiled
methods to interpreted if they are marked virtual (i.e., if they are
called via a message lookup, which means the system can replace the
compiled method's entries in the lookup tables with the interpreted
method). Since message lookup is via a true hash table lookup scheme
(of whatever sort you prefer to implement) you have full dynamic typing
for those objects you wish to treat dynamically.
For those objects you wish to not have the overhead of a pointer
to a lookup table, since they are completely statically typed and are
never treated polymorphically, the interpreter simply keeps around some
"fixed-type" lookup tables for these types. They can still have interpreted
methods, but there is no polymorphism for these types.
Well, actually, not quite none. In some cases you may wish to
write completely generic code which can even handle these "fixed" types,
in which case you simply pass the lookup table pointer and the object
value separately. For example, one can implement a generic Dictionary
that could associate numbers (i.e., a C int) and objects OR objects
and objects with no difficulty. One could distinguish the arguments
to these methods by calling the argument type "Generic*" (or whatever)
instead of "Object*". That is, a Generic* is really a lookup table
and a value (either a pointer or a numeric value) and an Object* is
simply a pointer.
Now, what do we have here? We have a system with all of the
potential efficiency of a C++ (i.e., one could write a straight C-like
program in it, whatever the syntax you choose, not necessarily C)
but with the potential flexibility of an immediate feedback
polymorphic system like Smalltalk. I prefer C++ memory management
(with some changes and cleaning up here and there) so no garbage
collector, and I prefer the separation of the environment from the
application for C++, so I'd keep these. Of course, if you write the
program editor *in* itself, you'd be able to edit *it* while editing
your application (you'd probably need two running, one editing the
application and one editing the editor, whew!).
Is it all possible? Well, in a word, yes. Like I said
my group at EA already implemented one version of it, and it worked
fine (though it didn't have some of the enhancements I mentioned in
this article, it did have the compiled/interpreted flexibility and
the ability edit programs while they were running). Efficient as C++?
In a phrase, very close:
We wrote a prototype adventure game complete with tiled
graphics, input windows, user interface classes, and so forth.
When doing a performance analysis, we found the message send code
usually didn't even show up on the profiler, and when it did it was
taking up about 1% of overall execution time, hardly noticeable.
As for the interpreted code? Well, most of the high-level user-
interface code was written in interpreted code, since we were changing THAT
a lot. The thing spent from 3% to 7%, averaging about 5% of its time
in the interpreter. The point being, the stuff you needed to change
the *MOST* was also the stuff that was being run the *LEAST*. Most
of the time was being spent moving bits around on the screen or
doing low-level user interface stuff, like spitting text into the text window.
Once that stuff had been debugged, it was locked down and compiled
and ran perfectly fast, yet was still fully accessible to be called
by the interpreter.
Memory use? LESS. That is, though method lookup tables are
an overhead, bytecoded interpreted code typically took up about
HALF the space of compiled 8086 code. Thus overall we used LESS memory
than a typical C++ implementation.
What does this mean? It means you can have your cake and eat
it, too. Fast, and without getting overweight.
As I say, Electronic Arts owns that original implementation,
which is why I'd like to see the different version mentioned above
implemented. Either by myself or someone else (like I said, our
company is willing to work with others to help get this thing accomplished!)
Logical platforms for implementation would be the Macintosh, Windows,
OS/2 Presentation Manager, OpenLook, and OSF Motif.
Mitsu Hadeishi
Open Mind
1460 W. 182nd Street
Gardena, CA 90248
(213) 532-1654
mitsu@well.sf.ca.us
{apple,ucbvax,lll-lcc}!well!mitsu