danr@autodesk.com (Dan Rosenfeld) (12/05/90)
Does anyone know of any interface builders available for Smalltalk systems? By "interface builder" I mean a program which allows an application`s interface, or interface elements, to be composed graphically. Thanks, Dan Rosenfeld [danr@autodesk.com] --
dbuck@ccs.carleton.ca (Dave Buck) (12/05/90)
In article <danr.660381587@melange> danr@autodesk.com (Dan Rosenfeld) writes: >Does anyone know of any interface builders available for Smalltalk >systems? By "interface builder" I mean a program which allows an >application`s interface, or interface elements, to be composed >graphically. > >Thanks, > >Dan Rosenfeld > >[danr@autodesk.com] >-- The book "Inside Smalltalk II" contains the implementation of a "window maker" program that allows you to design windows interactively. You can add text windows, buttons, etc., align them on the screen, and specify the messaging protocol for them all. Check the book for more details. It should be available in bookstores by now. It works for Smalltalk-80 Version 2.x. David Buck dbuck@ccs.carleton.ca -- _____________________________________________________________________ | David Buck | My employer is not responsible for| | dbuck@ccs.carleton.ca | my opinions. I'm not even sure | | | I am. |
csq003@umaxc.weeg.uiowa.edu (Jet Pilot) (12/06/90)
My group is currently working on a programming tool for smalltalk and I was wondering if any one has used the Window maker example in Inside Smalltalk II and if you have do you know a place I can can get the st files for the classes. I'm being very lazy - I hate to type. Any help with window maker is appreciated. Carmelo Interone
benson@blake.u.washington.edu (Dan Benson) (12/06/90)
In article <danr.660381587@melange> danr@autodesk.com (Dan Rosenfeld) writes: >Does anyone know of any interface builders available for Smalltalk >systems? By "interface builder" I mean a program which allows an >application`s interface, or interface elements, to be composed >graphically. > A great looking "Interface Builder" for Smalltalk-80 was demonstrated at the 1990 OOPSLA in Ottawa. It's called Tigre. I understand it is designed to work with Smalltalk-80 Release 4.0 (with color). The people at Tigre can be contacted at: Tigre Object Systems, Inc. 3641 C Soquel Drive Santa Cruz, CA 95062 (408) 476-1854 FAX: (408) 479-4196 The price is a bit steep depending on your budget: $3500 / platform, but it looks like a really nice system. -- | Dan Benson benson@ee.washington.edu | | Dept. of Elec. Engr., FT-10 | | University of Washington (206) 685-7567 | | Seattle, WA 98195 |
objtch@extro.ucc.su.oz.au (Peter Goodall) (12/06/90)
benson@blake.u.washington.edu (Dan Benson) writes: >In article <danr.660381587@melange> danr@autodesk.com (Dan Rosenfeld) writes: >>Does anyone know of any interface builders available for Smalltalk >>systems? By "interface builder" I mean a program which allows an >>application`s interface, or interface elements, to be composed >>graphically. >> >A great looking "Interface Builder" for Smalltalk-80 was demonstrated >at the 1990 OOPSLA in Ottawa. It's called Tigre. I understand it >is designed to work with Smalltalk-80 Release 4.0 (with color). >The people at Tigre can be contacted at: >Tigre Object Systems, Inc. >3641 C Soquel Drive >Santa Cruz, CA 95062 >(408) 476-1854 >FAX: (408) 479-4196 >The price is a bit steep depending on your budget: $3500 / platform, >but it looks like a really nice system. >-- >| Dan Benson benson@ee.washington.edu | >| Dept. of Elec. Engr., FT-10 | >| University of Washington (206) 685-7567 | >| Seattle, WA 98195 | Why is the Smalltalk-80 world obsessed by big prices. I'm sure you would sell 100 times as many for $350.00. Unless of course the product is rough or difficult to use, and requires constant support ---------------------------- Peter Goodall Smalltalk Systems Consultant ObjecTech P/L 162 Burns Bay Rd, LANE COVE , NSW, AUSTRALIA objtch@extro.ucc.su.oz.au
johnson@m.cs.uiuc.edu (12/07/90)
>Why is the Smalltalk-80 world obsessed by big prices. I'm sure >you would sell 100 times as many for $350.00. Unfortunately, there are not very many Smalltalk developers, so people who sell to Smalltalk developers seem to believe that they have to charge a lot because they will have small sales no matter what. They might be right. Perhaps the solution is to get more people using Smalltalk-80, but the problem is that the prices are too high. Sigh!
MUHRTH@tubvm.cs.tu-berlin.de (Thomas Muhr) (12/07/90)
In article <objtch.660468686@extro>, objtch@extro.ucc.su.oz.au (Peter Goodall) says: >Why is the Smalltalk-80 world obsessed by big prices. I'm sure >you would sell 100 times as many for $350.00. Unless of course >the product is rough or difficult to use, and requires constant >support One reason could be that the total number of installations is not considered to be of considerable magnitude: profit = price * installations The negative aspect of this pessimistic marketing strategy is that it works like a self fulfilling prophecy. Other companies have success with the optimistic strategy (Borland, MicroSoft) and have thus established standardsI wonder why IBM has chosen Digitalk as a partner and not the "industry standard for Smalltalk". What interface builders concerns: There is a very promising package called Widgets as an add-on to Smalltalk V/286 which resembles the widget-orientation of PM and Windows. It goes for 149 $ and is a remar- kable example of introducing a new and effective framework into the unnatural (as far as non-simulation-problems are concerned) MVC approach of bare Smalltalk. We will use the system as an intermediary before switching to Smalltalk V/Windows (hurry up, Digitalk!). Widgets provides Windows 3 like look and feel and should be considered for all developments including extensive man-machine-interaction. - Thomas >ObjecTech P/L >162 Burns Bay Rd, >LANE COVE , NSW, AUSTRALIA >objtch@extro.ucc.su.oz.au ------- Thomas Muhr, Technical University of Berlin, BITNET: muhrth@db0tui11 Project ATLAS - Computer Based Tools for Qualitative Research "Computers, like every technology, are a vehicle for the transformation of tradition." (WINOGRAD/FLORES)
nvi@mace.cc.purdue.edu (Charles C. Allen) (12/08/90)
> >Why is the Smalltalk-80 world obsessed by big prices. I'm sure > >you would sell 100 times as many for $350.00. > Perhaps the solution is to get more people using Smalltalk-80, > but the problem is that the prices are too high. For me, the main drawback to Smalltalk is closed nature of the system. It's not possible to produce "double-clickable" applications on the Mac in either V/Mac or ST-80 (does V/PM solve this?). Why should anyone write nifty little programs when he can share them only with others who invest in Smalltalk? It's going on 10 years since the 1981 August Byte, and Smalltalk is *just beginning* to come out of its shell a little bit (V/PM and ParcPlace's runtime). Charles Allen Internet: cca@physics.purdue.edu Department of Physics nvi@mace.cc.purdue.edu Purdue University HEPnet: purdnu::allen, fnal::cca West Lafayette, IN 47907 talknet: 317/494-9776
khaw@parcplace.com (Mike Khaw) (12/08/90)
nvi@mace.cc.purdue.edu (Charles C. Allen) writes: >For me, the main drawback to Smalltalk is closed nature of the system. How do you define "closed"? Smalltalk is certainly less closed than, say, a conventional C language system. You can see the source for all the components of your "library" (i.e., the classes in your image); you can even modify the compiler and debugger, as they are also part of the class library in your image. In earlier versions of Smalltalk-80, when Smalltalk WAS the window system, you could even modify the look and feel of the window system in Smalltalk. How easy is it to modify the look and feel of Windows 3.0, MacOS, OpewLook, Motif, OS2/PM, etc. (not that you're supposed to want to)? Smalltalk-80 also lets you link C functions into the virtual machine, so you can call external code that is callable from C. >It's not possible to produce "double-clickable" applications on the >Mac in either V/Mac or ST-80 (does V/PM solve this?). Why should Smalltalk-80 allows you to make double-clickable applications. Out of the box, the application file has no data fork; image files have only a data fork. So, you can save an image "onto" an application file to get a single file that contains both the virtual image and the virtual machine. For example, in the normal distribution, the "st80" image icon belongs to a folder named "Image", while "Image"'s parent folder contains the virtual machine, named "Smalltalk-80". If you launch the image by double-clicking on the image icon, the default folder is the "Image" folder. When you select "Save" in the running image, in the resulting prompter, if you replace the highlighted default name with "::Smalltalk-80", the image gets saved as the data fork of the application file. When you subsequently double-click the application icon, it doesn't ask for an image file via a StandardFileDialog as it previously would have, but runs the image saved in its data fork. -- Mike Khaw ParcPlace Systems, Inc., 1550 Plymouth St., Mountain View, CA 94043 Domain=khaw@parcplace.com, UUCP=...!{uunet,sun,decwrl}!parcplace!khaw
stenzer@well.sf.ca.us (Steve Enzer) (12/08/90)
danr@autodesk.com (Dan Rosenfeld) writes: >Does anyone know of any interface builders available for Smalltalk >systems? By "interface builder" I mean a program which allows an >application`s interface, or interface elements, to be composed >graphically. >Thanks, >Dan Rosenfeld >[danr@autodesk.com] >-- We at Tigre sell a very complete set of Widget libraries, as well as the Interface Designer to paint them, move them around, resize, change connections, etc. The system is written in Release 4 of Smalltalk and supports full 24 bit color across platforms. Tigre is bundled with the Tigris Object Oriented Database, allowing users of Tigre to easily store and retrieve their objects. The Tigre screens themselves live inside of Tigris databases, allowing a much trimmer image for user applications. Tigre also supports multimedia capabilities, such as sound, and video overlay, though the video-overlay capability is currently limited to the mac, until better boards become available for the SPARC, et al. For more info on Tigre products, please contact Dan Mapes, at: Tigre Object Systems 3641C Soquel Drive Soquel, California 95073 Phone: (408) 476-1854 Fax : (408) 479-4196 Email: veda!tigre@ucscc.ucsc.edu You can also check the following publications for recent write-ups: Digital Review, November 5, 1990 Digital News, November 26, 1990 PC Week, October 29, 1990 EE Times, October 29, 1990 -- Steve Enzer Tigre Object Systems, Inc.
glang@Autodesk.COM (Gary Lang) (12/10/90)
> How easy is it to modify the look and feel of Windows 3.0, MacOS, >OpewLook, Motif, OS2/PM, etc. (not that you're supposed to want to)? And you don't so why should anyone pay $3500 for the priveledge? The ParcPlace people would do well to take a look at all of the successful development environments that have ever been released for the microcomputer world. The really big successes are things like Borland's Turbo languages, dBASE, Think C, and so on. None of these cost over $500.00 on the street and most hove around the $100 to $200 dollar range. For those of you who don't live in the bay area, when John Dvorak saw the press release for ObjectWorks for C++ - another ParcPlace product priced at a couple of thousand bucks, he said the same thing "get real, this is not how microcomputer software companies have made their mark" (not a quote). Adele and company read my lips: microcomputers are not minicomputers. A $5000 compiler on a VAX is worth about $50 on a microcomputer. Isn't this obvious by now?
objtch@extro.ucc.su.oz.au (Peter Goodall) (12/11/90)
glang@Autodesk.COM (Gary Lang) writes: >Adele and company read my lips: microcomputers are not minicomputers. >A $5000 compiler on a VAX is worth about $50 on a microcomputer. >Isn't this obvious by now? Also note that SUN Microsystems is now competing with Apple and the IBM clone hordes for the high performance personal desktop. This market does not easily accept minicomputer prices for development systems or applications. Especially when it already has seen the quality and value of the Borland and Digitalk environments. If SUN wants to become really effective in this market, it should put some pressure on development environment suppliers to revise their marketing strategies. ---------------------------- Peter Goodall Smalltalk Systems Consultant ObjecTech P/L 162 Burns Bay Rd, LANE COVE , NSW, AUSTRALIA objtch@extro.ucc.su.oz.au
tim@abccam.abcl.co.uk (Tim Rowledge) (12/13/90)
I know of several interface builders:- Fabrik; see OOPSLA proceedings of a couple of years ago, InterCons; ditto, Glazier; by Tektronix, and this is the good bit, it is available. Contact Smalltalk Express (081-200-0220, UK) and ask about the Tek Goodies disk. Glazier is a reasonable approach to the problem, but you may not like the style of code it writes for you. Along with it come quite a few other Tek originated goodies. Tim Rowledge
glang@Autodesk.COM (Gary Lang) (12/17/90)
>If SUN wants to become really effective in this market, it should put >some pressure on development environment suppliers to revise their marketing >strategies. Yes, and this is why there is no Improv, WordPerfect, Microphone, etc. on the Suns. But I wouldn't count them out. I'd love to see Smalltalk selling for $300-$600 on the Sun IPC platform for example. Why is this not a good idea? Does PP seriously doubt that they'd sell at least 5 times as many copies as they do now? On the other hand maybe they've already gone over this and just have to price their products this way. This doesn't seem to say much in favor about the expected pervasiveness of ST however. Anyway, if ParcPlace can get their prices to Digitalk's levels it'd be a hard thing to beat. - g
warner@scubed.com (Ken Warner) (12/18/90)
[Somebody said] >>If SUN wants to become really effective in this market, it should put >>some pressure on development environment suppliers to revise their >>marketing strategies. I heard somewhere (might just be a fabrication) that Sun did ask PP to adjust their prices so that the price for the Sun version was not disparate from the prices for other platforms ... and PP did. They made all prices the same, at the Sun's platform price. [Somebody else said] >Anyway, if ParcPlace can get their prices to Digitalk's levels it'd >be a hard thing to beat. Wasn't it already that way? Was anyone beating down their doors? I like Smalltalk alot. I would prefer to program in Smalltalk over any other environment. But Smalltalk is not going to be mainstream. For a programmer, the leap to Smalltalk from conventional procedure oriented languages is too great. Most companies can't afford the time to retrain. C++ will be mainstream because it's a short hop from C. What I see happening is that Objectworks for C++ could be the model for other C++ development environments. If the price is adjusted to a more reasonable level. BTW: What do people think about Objectworks 4.0? I've looked at it on the Mac and am ambivalent toward it. The new interface looks like it was designed by a graphic artist instead of a programmer (is this good?). I like the idea of separate windows but separate windows only clutter up the screen even more. Ken Warner
morse@quark.mpr.ca (Daryl Morse) (12/18/90)
In article <502@scubed.SCUBED.COM> warner@scubed.com (Ken Warner) writes:
[lots of stuff deleted]
<For a programmer, the leap to Smalltalk from conventional procedure
<oriented languages is too great. Most companies can't afford the time
<to retrain. C++ will be mainstream because it's a short hop from C.
<What I see happening is that Objectworks for C++ could be the model
<for other C++ development environments.
Having recently made the leap from "conventional procedure oriented"
languages to Smalltalk, I will confess that it was non-trivial.
Furthermore, I agree that training costs *are* not insignificant.
However, to suggest that a leap to C++ would have been any less costly
is very misleading. If you intend only to write "C" code in C++, as
appears often to be the case, there is little or no overhead. However,
if you intend to write REAL Object-Oriented C++ code (ie. making use
of such features as multiple inheritance, etc), things change very
rapidly. C++ is not the simple, polished language that ST80 is. Many
of its features are either not available, or they do not work
consistently in all implementations (ie. CFront, G++, etc.), or they
are unstable. In comparision to the library that comes with ST80, C++
libraries are almost all a joke. Furthermore, in the effort to provide
C capabilities within C++, which IMHO, did nothing to encourage C++ to
be the clean, easy to understand language that ST80 is, C++ ended up
with a syntax that IMHO, is kludgy, complex, and very difficult to
learn. In short, what I am saying is that because ST80 is a pure OOL,
as opposed to C++, and is relatively stable, as opposed to C++, and
has a useful class library, as opposed to C++, it is a much better
vehicle for learning OO than C++.
[lots of stuff deleted]
<BTW: What do people think about Objectworks 4.0? I've looked at it
<on the Mac and am ambivalent toward it. The new interface looks like
<it was designed by a graphic artist instead of a programmer (is this
<good?). I like the idea of separate windows but separate windows only
<clutter up the screen even more.
Having been a user of 4.0 for some months, I am not ambivalent toward
it. 4.0 is a much improved product over its predecessor. I do not
understand the comment about it being designed by a graphic artist.
The browsers and other user interfaces are all very usable, albeit,
with a few little quirks. Having separate windows is very useful if
you normally do other things while you are running ST80. If you want
to run more than one copy of ST80 at the same time, which we do often,
having separate windows is a necessity.
--
Daryl Morse | Voice : (604) 293-5476
MPR Teltech Ltd. | Fax : (604) 293-5787
8999 Nelson Way, Burnaby, BC | E-Mail: morse@quark.mpr.ca
Canada, V5A 4B5 | quark.mpr.ca!morse@uunet.uu.netPaul.Regenhardt@p0.f500.n5000.z200.METRONET.ORG (Paul Regenhardt) (12/19/90)
I wish ParcPlace would get their act together. Just after Dvorak's article Park Place advertised their ObjectWorks for Windows 3.0 at $595.00. I called, but they told me it did not have color. I told them I would wait. It was a mistake. If you bought that version you can get the color upgrade for only $895.00. However, if you buy the color version (when it becomes available, if ever) it cost $3500.00. I called to confirm it, because I couldn't believe it. I've heard it's a nice product (they have an evaluation copy at $200.00 which does everything, except you can't save the image), but at $3500.00 it will be a while before I find out. So, Is anybody writing a CHB for Steve Byrnes public version of Smalltalk? --- ZMailQ 1.12 (QuickBBS) * Origin: Jaguar's NetWorking Labs, (303)377-2371 HST/v.32 (200:5000/500.0) -- Paul Regenhardt - via MetroNet node 200:5000/301 The Bohemia BBS System, Boulder Colorado (303)449-8946 UUCP: Paul.Regenhardt@p0.f500.n5000.z200.METRONET.ORG or : ...!boulder!bohemia.METRONET.ORG!500.0!Paul.Regenhardt
warner@scubed.com (Ken Warner) (12/20/90)
In article <MORSE.90Dec18115242@quark.mpr.ca> morse@quark.mpr.ca (Daryl Morse) writes: >In article <502@scubed.SCUBED.COM> warner@scubed.com (Ken Warner) writes: >[lots of stuff deleted] ><For a programmer, the leap to Smalltalk from conventional procedure ><oriented languages is too great. [etc] >Having recently made the leap from "conventional procedure oriented" >languages to Smalltalk, I will confess that it was non-trivial. >Furthermore, I agree that training costs *are* not insignificant. >However, to suggest that a leap to C++ would have been any less costly >is very misleading. [stuff about different implementations deleted] For the sake of discussion: Are the differences between language and environment a little blurred here? There are two separate tasks here: Learning the language and learning the environment. This holds for both C++ and Smalltalk. When I became a Smalltalk programmer, the hardest thing to get a gut feeling for was the message passing paradigm. Once I grasped that, the syntax of the language was fairly simple. However, becomming familiar with all the nooks and crannies of the environment still consumes me. >C++ ended up with a syntax that IMHO, is kludgy, complex, and very difficult to >learn. Are you talking about the language or the implementation? Would the Objectworks version of C++ made learning C++ less of an effort? More of an effort? >Having been a user of 4.0 for some months, I am not ambivalent toward >it. 4.0 is a much improved product over its predecessor. How so? >The browsers and other user interfaces are all very usable, albeit, >with a few little quirks. What quirks? >Having separate windows is very useful if >you normally do other things while you are running ST80. If you want >to run more than one copy of ST80 at the same time, which we do often, >having separate windows is a necessity. This is interesting...could you elaborate? Ken Warner
glang@Autodesk.COM (Gary Lang) (12/20/90)
>prices for other platforms ... and PP did. They made all prices the same, at >the Sun's platform price. Hmm. ObjectWorks for the Sun is a few thousand bucks, but for th PC is under a grand. What did I miss here? -- Gary T. Lang (415)332-2344 x2702 Autodesk, Inc. Sausalito, CA. MCI: 370-0730
glang@Autodesk.COM (Gary Lang) (12/20/90)
> The new interface looks like it was designed by a graphic artist > instead of a programmer (is this good?). I like the idea of separate > windows but separate windows only clutter up the screen even more. Comparing OpenLook which was designed by engineers and the Mac/Win3.0/NeXTStep which was designed by Susan Kare - a graphic artist, I'd say that it bodes well for PP, but then I haven't seen OW for the mac... -- Gary T. Lang (415)332-2344 x2702 Autodesk, Inc. Sausalito, CA. MCI: 370-0730
morse@quark.mpr.ca (Daryl Morse) (12/20/90)
In article <503@scubed.SCUBED.COM> warner@scubed.com (Ken Warner) writes: In article <MORSE.90Dec18115242@quark.mpr.ca> morse@quark.mpr.ca (Daryl Morse) writes: >In article <502@scubed.SCUBED.COM> warner@scubed.com (Ken Warner) writes: >[lots of stuff deleted] ><For a programmer, the leap to Smalltalk from conventional procedure ><oriented languages is too great. [etc] >>Having recently made the leap from "conventional procedure oriented" >>languages to Smalltalk, I will confess that it was non-trivial. >>Furthermore, I agree that training costs *are* not insignificant. >>However, to suggest that a leap to C++ would have been any less costly >>is very misleading. >For the sake of discussion: Are the differences between language and >environment a little blurred here? There are two separate tasks here: >Learning the language and learning the environment. This holds for >both C++ and Smalltalk. >When I became a Smalltalk programmer, the hardest thing to get a gut >feeling for was the message passing paradigm. Once I grasped that, >the syntax of the language was fairly simple. However, becomming >familiar with all the nooks and crannies of the environment still >consumes me. I agree, the distinction between the ST80 language and its environment is blurry. The language is deceptively simple. It is small, but the enormity of the environment (ie. classes and browsers) is quite overwhelming. Unfortunately, it is difficult to accomplish much without learning some of both. In retrospect, perhaps the most important thing about ST80 is the fact that it is interpreted. You want to see what a class does, bring up a workspace and try it. Almost no "packaging code" is necessary. Having to go through edit-compile-link-run would not work (well) with ST80. >>C++ ended up with a syntax that IMHO, is kludgy, complex, and very >>difficult to learn. >Are you talking about the language or the implementation? Would the >Objectworks version of C++ made learning C++ less of an effort? >More of an effort? Objectworks C++ is CFront (ie. AT&T C++) if memory serves me correctly. Thus, there is no Objectworks version of C++, per se. Speaking here from the experiences of my co-workers, when dealing with C++, the environment is quite distinct from the language. A good environment helps you browse class libraries (assuming you have some to browse), and learn what they provide, but you are still left with the task of learning the language. A task that is very non-trivial. >>Having been a user of 4.0 for some months, I am not ambivalent toward >>it. 4.0 is a much improved product over its predecessor. >How so? Release 4 is more convenient to use, particularly when you have other things to do, because it doesn't consume your whole screen. An example of this is when you are working on user-defined primitives. You have to work in both C and ST80, and when you are coding the boundary-layer, it is much easier to do both at the same time. The new interfaces are also more conventional and more modern-looking and -feeling. I really didn't care much for the old interface. The SPIM (Smalltalk Portable Imaging Model for graphics and images) is more powerful than what the old product had, and supports color quite well. I will digress for a moment. SPIM is pretty low-level. And contrary to what you may have heard, MVC (model-view-controller) is alive and well in Release 4. I just completed writing a relatively simple visual interface using both SPIM and MVC. Putting it nicely, they practically beg for 3rd-party interface builders and graphics packages because they are so low-level. >>The browsers and other user interfaces are all very usable, albeit, >>with a few little quirks. >What quirks? Little things, like browsing senders and implementors. These features don't work quite as well as they could. A few other things could be improved to make the user interface more intuitive, but they are sort of hard to describe in a short? mail message. >>Having separate windows is very useful if >>you normally do other things while you are running ST80. If you want >>to run more than one copy of ST80 at the same time, which we do often, >>having separate windows is a necessity. >This is interesting...could you elaborate? We are working on distribution, migrating objects between systems. -- Daryl Morse | Voice : (604) 293-5476 MPR Teltech Ltd. | Fax : (604) 293-5787 8999 Nelson Way, Burnaby, BC | E-Mail: morse@quark.mpr.ca Canada, V5A 4B5 | quark.mpr.ca!morse@uunet.uu.net
khaw@parcplace.com (Mike Khaw) (12/21/90)
morse@quark.mpr.ca (Daryl Morse) writes: >important thing about ST80 is the fact that it is interpreted. You It's "dynamically translated", not "interpreted". It has the immediacy and compactness of interpreted code with essentially the full speed of compiled code. -- Mike Khaw ParcPlace Systems, Inc., 1550 Plymouth St., Mountain View, CA 94043 Domain=khaw@parcplace.com, UUCP=...!{uunet,sun,decwrl}!parcplace!khaw
Paul.Regenhardt@p0.f500.n5000.z200.METRONET.ORG (Paul Regenhardt) (12/23/90)
I agree to your statement, "I would rather program in the Smalltalk environment...". I am "so in love" with Smalltalk I am looking into methodologies that would allow me to program in Smalltalk, and then convert to C. I got my company to fund one project already, but it went bust. Not that I'm giving up, my boss certainly sees the advantages to working in Smalltalk. Apparently there are some other people out there with the same idea. Rumor mill has it that Brad Cox (of Objective C fame), recently had a meeting about the very same subject. Objective C has a high start up cost, but if you're doing volume sales the graphics run time is reasonable. --- ZMailQ 1.12 (QuickBBS) * Origin: Jaguar's NetWorking Labs, (303)377-2371 HST/v.32 (200:5000/500.0) -- ============================================================================= Paul Regenhardt - via MetroNet node 200:5000/301 The Bohemia BBS System, Boulder Colorado (303)449-8946 UUCP: Paul.Regenhardt@p0.f500.n5000.z200.METRONET.ORG or : ...!boulder!bohemia.METRONET.ORG!500.0!Paul.Regenhardt =============================================================================
tma@versant.COM (Tim Atkins) (12/26/90)
I will add my two cents on the C++ vs. Smalltalk discussion. C++ is most definitely a "better C", having inheritance, better (though occasionally somewhat finicky) type checking and a greater degree of encapsulation are all big pluses. However, I do not consider it a reasonable language to learn OO programming with. The reasons are much as mentioned in previous articles - language complexity, missing features, missing thorough libraries (although this is beginning to be addressed). To this list I would add that the current quasi-official language design makes it quite difficult to write general purpose libraries. This is mainly a problem of lack of genericity that will be somewhat addressed by the addition of the proposed parameterized types. As it stands today however, the mixture of MI as currently implemented would require any reasonable general purpose class, particularly collection classes, to manipulate a type that was used as a virtual base. But the language design (or rather the current implementation which is quasi-standard) precludes "objects" of this type from being cast (!?) to their real (!?) type. In my view C++ will not be a very strong OO language technically until it includes both parameterized types and a facility for true late binding. When it comes to environment, Smalltalk gets tremendous mileage out of being dynamically typed. That the object structure is extremely regular also makes the production of a good interactive environment much simpler. True, much of this could be done, howbeit with some difficulty, for C++. But their are some important philosophical barriers to such a development. To me one of the most significant is that the ST environment views the world as strictly composed of objects some of which may be classes. The C++ on the other hand views the world as composed of FILES which contain static class declarations (not real objects) and may by used to produce real objects long enough to translate psuedo-messages to C or object code. This is a tremendous difference. An language tangled in the knowledge of file/code interaction can not be used in an environment that treats the world as a cloud of objects without something giving. In ObjectWorks for C++ what gave was the nice interactive environment. There is no (correct me if I missed it) equivalent of the Smalltalk browser, immediate method execution or metadata associated to great benefit with Smalltalk. How can you have a general class browser if you must cling to knowledge of what files implement a class and what files declare it? Also in OW/C++, a program (another rather long-of-tooth concept) is the basic unit of development. There is no concept, as mentioned, of a pool of classes that may be combined to produce many tools. This difference goes so deep as to require actual copies (or at least links) of class files be made for use with every application (must be in separate directory!) that is developed with OW/C++. If this has changed since the early releases I am familiar with then I would appreciate someone letting me know. If it has not changed then I find it simply incredible that anyone would compare OW/C++ to Smalltalk from a programming environment point of view. I do believe whole-heartedly that an interactive programming environment with significant amounts of metadata readily available is essential to efficient OO software development. I also have my gripes with Smalltalk. My most up-to-date ST knowledge is of ParcPlace 4.0. Some of the following seems to be resolved a bit better in Digitalk's PM version. Smalltalk is a very insulated environment - to a fault in my opinion. The existing mechanism for interfacing with code in other languages is quite clumsy and limited. In this day and age a user should not have to code literal magic numbers in to enable calls of functions defined in other languages, yet this is precisely what 4.0 still requires. Among other problems, this makes trying to combine different products that use the so-called User Defined Primitives (last word definitely descriptive) a major and quite needless headache. Inside the user primitive, the official position is that persons trying to interface ST80 code to external functions should know nothing about the real structure of the Smalltalk objects they must deal with! In 4.0 this is somewhat ameliorated by exposing a limited amount of object structure in the form of macros. However, the files state that ParcPlace will not support or in any way aid anyone that uses this infor- mation! This is one of the most incredible failures to understand and support would-be product developer needs I have ever encountered. I agree that 4.0 is a major improvment, particularly in cleaning up the old rat's nest of classes that were not very well abstracted and therefore not at all easy to subclass and combine. However, the standard set of classes is indeed quite low-level with, IMHO, not enough examples or higher-level clasess to make commercial deployment at all straight-forward for even the best of programmers. I too expect this lack to be remedied by third party developers though that gets us into the whole murky realm of class distribution mechanisms which is perhaps the weakest link currently in the OO chain. If you wish to be such a class supplier you have little practical alternative to distribution of your classes as source file-ins. As mentioned above, this will not help you if your classes need access to the outside world. Also there is no good way to distribute classes without source. Personally I feel that source to classes should ALWAYS be available as it is next to impossible to subclass correctly or debug thouroughly without it. However this lack bites hard, particularly among developers who have experience with more conventional languages. Yes, I am aware of the capabilities of BOSS, but it is no longer part of the standard distribution from ParcPlace and therefore cannot be expected to exist at customer sites. The language itself has some growing to do. There are indeed, IMO, places where mulitple inheritance is clearly needed. Also the very regularity of object structure often gets in the way. It is often logically quite reasonable, for instance, to wish to subclass some variableSubClass and add one more named instance variable. This is not allowed in ST80 (nor in Smalltalk/V? ). Such restrictions cause class bloat or, at the least, pervert the logical design of classes to satisfy implementation arcana that a cleaner language should avoid. Also, the focus on a single-user image must evolve toward something perhaps closer to a distributed, multi-user model. This is essential if ST is to become a general programming-in-the-large tool. For OO to reach its full potential all the traditional boundaries of memory, disk, file, machine, process must be overcome as their are all incidentals of implementation that ideally should not clutter up the developer's model of the problem being solved. My conclusion from all this rambling about is that Smalltalk is indeed closer to where I want to go than any other language in general use today. However, it is not the last word and one true light by any means. For the time being, I lean toward viewing smalltalk (extended to be fully distributed) as a fair candidate for dealing with highly evolving systems and, given better external routine interface, as a good tool for binding together software components both of OO and conventional varieties.
tma@versant.COM (Tim Atkins) (12/26/90)
In my opinion, the $10,000 that StepStone charges for graphics runtime makes very little sense. It is doubtful that many persons, other than software system developers or other class authors, would pay the initial $9000 for a development version. This price, in my view, should entitle one to use the Graphics Classes and all other classes included with no further encumberances. The current policy is as wierd as selling a carpenter a hammer but charging a run-time fee on every product built using it. What makes the Graphics Classes a special case? Should I not also stop at the toll-gate whenever I use some method defined on Object?
lerman@stpstn.UUCP (Ken Lerman) (12/28/90)
In article <4112@versant.COM> tma@versant.UUCP (Tim Atkins) writes:
->In my opinion, the $10,000 that StepStone charges for graphics runtime
->makes very little sense. It is doubtful that many persons, other than
->software system developers or other class authors, would pay the initial
->$9000 for a development version. This price, in my view, should entitle
->one to use the Graphics Classes and all other classes included with
->no further encumberances. The current policy is as wierd as selling a
->carpenter a hammer but charging a run-time fee on every product built
->using it. What makes the Graphics Classes a special case? Should I
->not also stop at the toll-gate whenever I use some method defined on
->Object?
The $10,000 fee referred to is for a license to distribute the
ICpak201 runtime to the first 1000 end users. Since this distribution
would be part of a much larger product, it is hard to imagine that
$10/user should be much of an issue.
It is my understanding that the pricing was done this way so that
small companies could pay the additional $10,000 after they have
completed the development of their product rather that pay it all
upfront. (After the first 1000 users, the price is $4.50 per user.)
It's important to realize that software pricing is based on a number
of factors. Rather than the analogy of a hammer, think of a stapler.
Why should you pay extra for the staples? Of course, unlike staples,
extra licenses cost the software vendor nothing extra. But the source
licenses also cost the vendor nothing extra.
Would you rather pay $10000 more for the source license and nothing
for the runtime? Or nothing for the source and more for the runtime?
Talk to your vendor and see what you can negotiate. But remember that
for him to stay in business, he has to make money. And that money has
to come from you, the customer.
------------------------------------------------------------------------
As usual, I speak without the imprimatur of Stepstone. Everything is
negotiable, except my wife and my daughter. But we can talk about
that.
Kentma@osc.COM (Tim Atkins) (01/01/91)
Ken Lehrman writes: >The $10,000 fee referred to is for a license to distribute the >ICpak201 runtime to the first 1000 end users. Since this distribution >would be part of a much larger product, it is hard to imagine that >$10/user should be much of an issue. > >It is my understanding that the pricing was done this way so that >small companies could pay the additional $10,000 after they have >completed the development of their product rather that pay it all >upfront. (After the first 1000 users, the price is $4.50 per user.) My point was that I do not see why it is reasonable that any runtime fee be charged at all on this or any other library. The developer has paid for the use of these classes in building the product. Why should the user be charged for anything but the finished product and only that? Part of my position stems from a belief that such pricing policies could act as a significant obstacle to the OO "software IC" revolution. I don't have to pay a runtime fee for use of an Intel chip. If all vendors carry out similar policies then there can be a significant tendency on the part of particularly the less well-heeled and more innovative startups to reinvent the wheel rather than have part of their pricing and perhaps other policies regarding the distribution of their product dictated by potentially many vendors. Ten bucks is, as you say, not a lot of money but multiply it by 10 or more vendors and you start getting into significant cost that can not but help raising the overall price of software higher than it should and could be using this wonderful technology. I also disagree that it is less painful to pay this $10000 or whatever just before customer ship. At this time many companies will be struggling along with their first 10-100 sales NOT 1000. That raises the perceived per-user cost at a rather critical point in the company's life. I would much rather pay the vendor off early in the game instead of being nickel and dimed to death in perpetuity. - Tim
glang@Autodesk.COM (Gary Lang) (01/06/91)
$10,000 for source code that does what ICpak201 does is hardly out of line with industry pricing. - g -- Gary T. Lang (415)332-2344 x2702 Autodesk, Inc. Sausalito, CA. MCI: 370-0730
glang@Autodesk.COM (Gary Lang) (01/06/91)
>Why should the user be charged for anything but the finished product >and only that? Because it's software that's why. It is copied. It amounts to a royalty based on sales. If you write software and sell it, presumably, you want to receive money for your efforts even if you sell more than 100 copies do you not? StepStone has written a large percent of your product - about 40% in most cases for really deep applications. Why should their returns stop at some arbitrary figure and all the money go to you? THEY WROTE THE CODE... not you. The subject of runtime comes up over and over again but it boils down to this... If you write development tools and libraries for a living, if you can make sufficient money from the sales of the tools itself to continue developing it, you're probably not going to charge runtime fees becuase they do in fact stifle sales and drive you towards competitors. But if there are no competitors (how many other GUI libraries are there for OC) and if you can't make enough money to survive just selling your compilers (which I would expect is the case for StepStone - OC is wonderful (I program exclusively in it) but not a standard yet - then you have to look at pricing for other products in your company. This would include runtime fees for libraries (especially if you sell source code with your library), seminar fees, and so on. Any way you can charge for your expertise to stay alive is kossher in my book. - g -- Gary T. Lang (415)332-2344 x2702 Autodesk, Inc. Sausalito, CA. MCI: 370-0730