noren@dinl.uucp (Charles Noren) (06/15/90)
About a week ago I posted a response to a query about
Object Oriented graphics tools. I had some questions about
the vendor and my e-mail responses to each of the equirer's
has bounced, so I'm posting this article.
We have been evaluating for over a week now the Objective-C
compiler and support tools, which include a browser, the
standard foundation class library (ICpak101) and their
graphics class library (ICpak201). Objective-C is made by:
The Stepstone Corporation
75 Glen Road,
Sandy Hook, CT 06482
(203) 426-1875
We are working on a Sun 3/470 with a color monitor using
SunOS 4.0.3. We have also tried it out on a Sun 3/260,
and a Sun 3/50 with only 4MB RAM and a monochrome monitor.
The tools work fine on all machines tested including our
dog 3/50 (the graphics package makes some nice assumptions
about patterns in place of colors on a monochrome screen).
In fact, on the 3/50 the graphics windowing package seemed more
responsive than the SunView windowing environment underneath
it.
Some specific comments about the Objective-C environment:
o Objective-C, the language.
For a C programmer, I've found this language to be very
easy to learn. The documentation, which includes a
tutorial and examples, is a pleasure to read. The OO
extensions are very simple to understand and I was able
to write my first Objective-C program within an hour
of first reading the manual. The OO extensions are
Smalltalk-like, including the late binding mechanisms
of the objects. This Smalltalk-like paradigm is very
powerful and easy to learn and is one of Objective-C
strengths over C++. The langauge does have a couple
of worts. One is that the current version does not
support class variables. I am told that this will
be added possibly in the next version of the compiler.
The other item missing is that Objective-C, like
Smalltalk, does not have multiple-inheritence. For
me this is no problem, although I know there is *strong*
opinions on both sides of this issue.
o The Browser.
The Objective-C browser is WONDERFUL! It comes up in
the look and feel of the Objective-C graphics package
(ICpak201). It is currently a read-only browser, but
a read/write browser is due to come out soon. I'm not
bothered right now by a read-only browser because I run
with SunView along with the browser and can always quickly
pop open a window when I need to do edits. I've never
worked with a browser before, but the very day I installed
it I found I could not live without it. One of the
difficulties of an OO environment is that the code
implementing a class (along with the documentation of the
class) is very narrow, showing only the definitions and
redefinitions inside that class. A browser opens up the
entire inherited world of an object and quickly shows all
sorts of information, including the source code of the
particular method of interest.
o ICpak101, the foundation class library.
This class library provides many classes that are very
useful in program development. Classes include: arrays,
collections (ordered collections, stack, set, dictionary),
"balanced node" for the support of binary trees, points and
rectangles that support primative graphics.
o ICpak201, the window class library.
This class provides window management. It runs on top of
X-Windows (X11R3) and some of the native windowing
environments on many of the host systems it runs on
(including SunTools). The class library nicely supports:
windows (including scrollable and resizable windows),
a variety of menus, buttons, notifiers, prompters, icons,
color maps, and more. The sample code provided includes
a useable icon editor, menu-prototyper, and color edit
facilities that can be easily built into applications.
The class definitions are organized well, but I find that
the browser is needed to really get a good feel of how
the class library is put together.
o The 2-D graphics library.
I don't have a copy of this, but this is in beta test at
this moment. I can't wait to try this out.
o Documentation.
The documentation set that comes with this is one of the
best document sets I've seen. It is complete, accurate
(I did find one minor pice of information missing in one
spot), and a pleasure to read. The binders are about
11 inches by 9 inches, which I found a convenient size.
o Installation.
This was a breeze! For the compiler, ICpak101, and ICpak201
you merely tar off from a tape and run. For the browser,
you tar off, edit a file, and then build the browser symbol
tables for all the installed class libraries. This was one
of the easiest installs of a software package I've ever done.
o Technical support.
Stepstone provides strong, friendly, responsive support,
showing no evidence of impatience for a beginner in the
language that I am. I have talked with them about things
such as my favorite compiler flags on the Sun C compiler
and they have been very helpful in showing how I can perform
the same functionality with their product.
o Database support.
Currently there is no support to an Object-Oriented
Database, other what you can normally interface with in the
C language. However, there is a rumor that they are
working with Servio Logic (makers of Gemstone OODBMS) to
provide an OO interface with their databse.
All-in-all, Objective-C is a very nice language and one that
should be considered in evaluating OO langauges.
(Note: while cross-posted in both comp.object and comp.lang.c++,
followups are directed to comp.object).
--
Chuck Noren
NET: ncar!dinl!noren
US-MAIL: Martin Marietta I&CS, MS XL8058, P.O. Box 1260,
Denver, CO 80201-1260
Phone: (303) 971-7930lgm@cbnewsc.att.com (lawrence.g.mayka) (06/27/90)
In article <55443@microsoft.UUCP> jimad@microsoft.UUCP (Jim ADCOCK) writes: >low level programming tasks. Ideally, one would have a language that would >seamlessly handle the full range of programming tasks -- one would never have >to break into assembler. No standard language quite handles that. Languages >that cannot do a good job of programming in the small require that the >low level "chip" libraries be written in a different language, and provided >as part of a compiler's implementation. In practice, all compilers have a It depends what you mean by a "different" language. Lisp on a Symbolics workstation can indeed "seamlessly handle the full range of programming tasks," from DEFINE-PROGRAM-FRAMEWORK in the Dynamic Windows package all the way down to %POINTER-DIFFERENCE in the System package. Certainly not all of this is defined in standard Common Lisp, of course: The highest-level constructs have not yet been standardized throughout the industry; the lowest-level constructs violate trusted Common Lisp abstractions and their very standardization might encourage their use beyond what is absolutely necessary. Nevertheless, all constructs great and small follow the usual syntactic patterns of the Lisp language - functions, macros, and special forms - and "are" Lisp to the same extent that the extra library functions a particular C implementation might include "are" C. In another sense, of course, your statement is somewhat naive, in that no one uses a single language for all aspects of computation, all the way down to microcoding, chip cell placement, gate connection, etc. (Though the Symbolics microprocessor designers may have come close if their microcoding language and chip cell placement language were Lisp-like!) Lawrence G. Mayka AT&T Bell Laboratories lgm@iexist.att.com Standard disclaimer.
andyk@stpstn.UUCP (Andy Klapper) (06/27/90)
In article <55443@microsoft.UUCP> jimad@microsoft.UUCP (Jim ADCOCK) writes: > ... A number of things on what he feels Brad Cox is saying when he talks > about different levels of integration. I think you missed the point. It's not so much what kinds of libraries come with a language but the relative level of abstraction that the binding technology allows you the use. An example of simular 'programming' languages with two different binding levels and two different focuses of use may prove useful. The C language and the Unix C-shell language provide two different levels of binding. The C language provides a much lower, tighter, and faster binding level than a Unix C-shell language. In Brad's terminology the C language is chip level and the C-shell language is board level. Why board level ? The pipe and filter mechanism of Unix allows the user to slap a bunch of standard shells together to get a new shell tool where the thread of execution can be different for each shell. Is this useful ? Sure, I've seen people put together a few shells together on the command line and be done with. The process would have taken at least half a day to write in C. (which is not a lot of time for a C program of even simple complexity) Is it slow ? As sin. (or at least can be depending on the task). Is it simpler than C, you bet ! Is it better ? That depends on what you want to do. The biggest advantage is that it takes less time to train somebody to use C-shells than it is to use C (especially if you add in all the tools that the average C user uses (compiler, linker, editor, debugger, profiler ...) This example falls apart in that C-shells are not as easy to use as they could be. If somebody put a nice UI around them that would allow the user to place a bunch of shells on the screen and draw lines between them to show the data flow from grep to sort to filter ... then you have something closer to National Instruments(?) Lab View program that lets the user be the programmer. And that is the goal of the Software Industrial Revolution. Once the user becomes the programmer there will be many more programmers. Granted less skilled ones. (Take a look at the number of people 'programming' their spread sheets and you will see a hint of what the future may hold). Smalltalk, Objective-C and Eiffle offer a binding level somewhere between C and a C-shell. C++ offers a binding level somewhere between C and Objective-C. If I go any farther with this I will enter into a language war. Since language wars are counter productive I'd like to avoid that. Use the right tool for the right task. APL maybe the best at complex mathematical manipulation of data but I wouldn't want to use it to write a graphical user interface for a military command and control system. As a correllary to 'use the right tool', let me state that any tool can be used incorrectly, or bad code can be written in any language. One thing that I would like to know is why you feel that simple languages friendly to the neophyte programmer cannot be used in the large commercial projects ? I always thought simple & elegant was better than complex and and confused. When my code gets big and complex I don't want to be fighting with the structures and syntax that a language forces on me. On the other hand I don't want to have to fight with a language to let me do something that I need to do. (I admit it, I want everything !) -- The Stepstone Corporation Andy Klapper 75 Glen Rd. andyk@stepstone.com Sandy Hook, CT 06482 uunet!stpstn!andyk (203) 426-1875 fax (203)270-0106
jmaloney@cs.washington.edu (John Maloney) (06/28/90)
In reply to Brad Cox's statement:
> what about a C-based varient of Smalltalk Blocks?
I think that blocks (or "closures", to be technical) are an extremely
valuable language mechanism. They allow all sorts of customized control
structures to be synthesized without extending the language semantics at all.
For example, the Smalltalk-80 *language* has no control flow mechanisms
other than blocks. Everything else -- if-then-else, loops, iteration over
collections -- is implemented using blocks.
While we're wishing: I think that end-user customization is going to be
increasingly desirable, especially in user interfaces. That is, end-users
will increasingly write little mini-programs to tailor applications to their
precise needs. What language should they use to do this? Why not Smalltalk,
Objective-C, or Lisp -- i.e. the language of the base application? This obviates
the need for a custom language and its interpreter. In Smalltalk, it is quite
easy to compile a string typed by the user into a custom code fragment that
can be executed by the application at appropriate times. For example, the
user might customize the behavior of a button or add a new item to a menu.
What I'm suggesting is that programs like HyperCard would not need to
supply a "HyperTalk" language if they could use C++ or Objective-C as the
customization languague. Smalltalk and Lisp already allow this. It is harder
to achieve in the C-based OOP dialects because:
a) the compiler is not usually part of the run-time system, and
b) symbol table information needed for variable bindings is often
removed during compilation.
I would thus like to add "dynamic compilation and binding" to the wish-list.
-- Johncox@stpstn.UUCP (Brad Cox) (06/28/90)
In article <5281@stpstn.UUCP> andyk@stpstn.UUCP (Andy Klapper) writes: >In article <55443@microsoft.UUCP> jimad@microsoft.UUCP (Jim ADCOCK) writes: > >> ... A number of things on what he feels Brad Cox is saying when he talks >> about different levels of integration. > >I think you missed the point. My point is really just common sense, but does involve a paradigm shift to understand it. What's a paradigm shift? It is what Copernicus did when he moved the center of the universe from the earth to the sun. The silver bullet for the astronomy/calendar crisis of that era was not a technology. It was a paradigm shift, which moved mankind from the center of the universe out towards the periphery. The silver bullet for the software crisis is a paradigm shift that moves the center of the software universe from *processes* to *products*, from *producers* to *consumers*, from *languages* to *components*; from us as programmers to our customers. Gasp, yes! That's actually what I said. Moving us programmers out of God's eye at the center of the universe to out there at the periphery, revolving around our customers interests, not our own. The terrifying thing to me is that I'm afraid that we're going to find this so troubling, that we'll overlook that this is actually why the Japanese are managing to build software right now, using extremely 'poor' software development technologies by our standards, and are routinely beating us on quality and time-to-market by factors of *one to two orders of magnitude*. To see what I mean, notice the number of standards bodies screwing around with standard processes (Ada, C++, 2167, Cleanroom), and the absence of standards bodies defining standard *products* of these processes; i.e. a standard Stack, Queue, Customer, Kahlman filter object, etc. Notice the lack of a marketplace for such objects, comparable to the plumbing supply marketplace. And notice the lack of a commonly understood vocabulary for discussing and understanding different software architectural levels, comparable to the understandings that underlie tangible products. With a bolt, for example, we immediately understand that it will be used as a binding mechanism for something larger, like a tractor. And we immediately understand that the bolt is composed of something smaller, probably built by somebody else, such as a steel rod, which is in turn built by somebody else, a steel refinery, which is a customer for steel ore provided by somebody else. The bolt is produced by, and is consumed within, a marketplace; a vehicle for distributing complexity over time and space, which has no robust counterpart in software, where everything tends to be built from first principles 'for efficiency'. None of this is hard to understand, other than to accept that the common sense mechanisms that apply in the tangible domain of everyday experience can, *should*, and *must* be allowed to apply in the abstract/concrete swamp of software development. Better standard *processes* will never eliminate the software crisis. But standard *products* might. This is precisely the difference between Objective-C and C++. Objective-C is a name for an environment of standard products, called Software ICs. C++ is the name for yet another of a long line of standard *processes*, which will have the same impact on the software crisis as its predecessors; which is none at all. -- Brad Cox; cox@stepstone.com; CI$ 71230,647; 203 426 1875 The Stepstone Corporation; 75 Glen Road; Sandy Hook CT 06482
jimad@microsoft.UUCP (Jim ADCOCK) (06/28/90)
In article <5281@stpstn.UUCP> andyk@stpstn.UUCP (Andy Klapper) writes: >One thing that I would like to know is why you feel that simple languages >friendly to the neophyte programmer cannot be used in the large commercial >projects ? I always thought simple & elegant was better than complex and >and confused. When my code gets big and complex I don't want to be fighting >with the structures and syntax that a language forces on me. On the other >hand I don't want to have to fight with a language to let me do something >that I need to do. (I admit it, I want everything !) Well, perhaps you can suggest a simple language friendly to the neophtye programmer that can be used for large commercial projects? In my experience, they don't work. You need rigor built into the language for large projects, for small single-writer projects that rigor is just a pain. Ideally, one wants a language that is simple as possible while still covering the vast majority of the tasks at hand, but no simpler. It is a royal pain trying to "fake it" in a language that doesn't have quite the features one needs -- which is reality. Quick, single programmer projects can be legitimately written in "write-only" scripting languages. Clearly that is unacceptable in large projects.
cox@stpstn.UUCP (Brad Cox) (06/30/90)
In article <12396@june.cs.washington.edu> jmaloney@cs.washington.edu (John Maloney) writes: >I would thus like to add "dynamic compilation and binding" to the wish-list. You're asking for an Objective-C *interpreter*. Such a facility, which supported dynamic compilation (of source files) and dynamic linking (of compiled binary files: isn't this what you mean by binding? The compiler and the interpreter have always supported dyanmic *binding*, but the compiler relies on a separate linker utility for linking) already exists for Objective-C releases through 3.0. The interpreter has not yet been upgraded to version 4.0. -- Brad Cox; cox@stepstone.com; CI$ 71230,647; 203 426 1875 The Stepstone Corporation; 75 Glen Road; Sandy Hook CT 06482
jimad@microsoft.UUCP (Jim ADCOCK) (07/03/90)
In article <5286@stpstn.UUCP> cox@stpstn.UUCP (Brad Cox) writes: >Better standard *processes* will never eliminate the software crisis. But >standard *products* might. This is precisely the difference between >Objective-C and C++. Objective-C is a name for an environment of standard >products, called Software ICs. C++ is the name for yet another of a long >line of standard *processes*, which will have the same impact on the >software crisis as its predecessors; which is none at all. Well, for what its worth, my several years experience with ObjC, and with C++, is the exact opposite of Brad's claims. All of which means, I suppose, is, as always, caveat emptor.
kim@spock (Kim Letkeman) (07/03/90)
In article <5286@stpstn.UUCP>, cox@stpstn.UUCP (Brad Cox) writes: | | Better standard *processes* will never eliminate the software | crisis. But standard *products* might. This is precisely the | difference between Objective-C and C++. Objective-C is a name for an | environment of standard products, called Software ICs. C++ is the | name for yet another of a long line of standard *processes*, which | will have the same impact on the software crisis as its | predecessors; which is none at all. I was with you right until this last paragraph. If I understand your paradigm shift correctly, you are asking software people to look at the forest rather than concentrating on the trees. Consider larger blocks of functionality (e.g. Objective C with its software IC's) rather than a low level tool to build software (e.g. a C++ compiler.) I agree that if everyone accepted Objective C and Stepstone's class libraries as the standard for reusable software then great strides toward alleviating the software crisis would be made. The combination of OOP's reusable paradigm coupled with a standard set of classes that *everyone* used would be unbeatable. But in reality, the same effect would be gained if *any* OOP language and library of classes were chosen as standard (assuming the language supports OOP to a high degree.) This is where I differ with your (implied) criticism of C++. C++ will be (is?) just as good when a fully featured, high quality and highly integrated set of library classes become available and widely used. I do agree with the essence of your posting however. I hope that the paradigm shift does happen as it is probably our best hope to eventually see eye to eye in the software world. I think the biggest problem with software (reusable or otherwise) is that it is wetware. It exists in infinite variation in our minds. No one likes to be constrained to a single solution to a problem, and very few people see things in the same way. I hope we can find a way to get more acceptance of the common denominator, but we have to get people to remove the thought of "lowest common denominator" from their minds first. Kim -- Kim Letkeman mitel!spock!kim@uunet.uu.net
pkr@media01.UUCP (Peter Kriens) (07/05/90)
In article about a review of Objective-C I read the following statement: | I agree that if everyone accepted Objective C and Stepstone's class | libraries as the standard for reusable software then great strides | toward alleviating the software crisis would be made. The combination | of OOP's reusable paradigm coupled with a standard set of classes that | *everyone* used would be unbeatable. | | But in reality, the same effect would be gained if *any* OOP language | and library of classes were chosen as standard (assuming the language | supports OOP to a high degree.) This is where I differ with your | (implied) criticism of C++. C++ will be (is?) just as good when a | fully featured, high quality and highly integrated set of library | classes become available and widely used. I absolutely do not agree that a "standard" class library for C++ would allow the ideal IC/board level approach. The C++ language is much more targeted at making many "stand-alone" objects. Most C++ class libraries define their own hierarchy which means that it is almost impossible to come to 1 class tree for all third party software. This means that the "connectivity" of the software IC's in C++ will always be much harder to implement in comparising to Objective C, Smalltalk or CO2, which are all languages that build their classes from one root. This single root allows for a common behavior that is used by the general classes like collections. In C++ you have it is too natural to build low level objects that each have their own root behaviour. If we go back to the IC/board level metaphor, in C++ you will be using ECL, TTL, DDL (remember?) MOS and few hundred other standards, which means converters etc. In the languages which use one root and use dynamic binding you can specify a common behaviour which means that you only use one interface specification. So, though in theory it would probably be possible to standardize on one class library in C++. But the number of options and possible incompatibilities would be so overwhelming that we would need a standard committee to figure out what works how. And we all know how long it takes to get all C compilers to work alike using ANSI. I am a strong believer in the IC idea. Not that I believe that the complexity of a hardware even comes close to software. The number of dimensions in hardware is much smaller. In hardware you repeat the same building blocks to build a bigger system. In software every component is unique. But by encapsulation and using a generic software interface I have seen that it is possible to build systems faster. And I think that languages like Smalltalk, Objective C and CO2 are much more productive in this area then C++. Peter Kriens
lgm@cbnewsc.att.com (lawrence.g.mayka) (07/05/90)
In article <3814@kim> kim@spock (Kim Letkeman) writes: >But in reality, the same effect would be gained if *any* OOP language >and library of classes were chosen as standard (assuming the language >supports OOP to a high degree.) This is where I differ with your >(implied) criticism of C++. C++ will be (is?) just as good when a >fully featured, high quality and highly integrated set of library >classes become available and widely used. I think this glosses over some very significant differences in language design goals and ambient culture/environment which affect the feasibility, utility, and practicality of such libraries. >very few people see things in the same way. I hope we can find a way >to get more acceptance of the common denominator, but we have to get >people to remove the thought of "lowest common denominator" from their >minds first. Indeed, one of the great dangers of standardization is the tendency to gravitate toward the "lowest common denominator" (what the laziest vendor is willing to implement, what the most primitive development environment can support, what the most obsolete hardware can run, what the most stubborn programmer is willing to use, what the dustiest decks are compatible with, etc.). The other extreme, of course, is to agree to a standard that has not been shown to be feasible, useful, and practical. Lawrence G. Mayka AT&T Bell Laboratories lgm@iexist.att.com Standard disclaimer.
cox@stpstn.UUCP (Brad Cox) (07/07/90)
In article <1278@media01.UUCP> pkr@media01.UUCP (Peter Kriens) writes:
:In article about a review of Objective-C I read the following
:statement:
:
:I absolutely do not agree that a "standard" class library
:for C++ would allow the ideal IC/board level approach.
Wonderfully said! But I would like to steer this conversation away
from a confrontational approach between the two philosophies that
tend to polarize such debates, and point out that mature domains
seldom indulge in panacea A versus panacea B debates.
The whole point of my gate/block level integration (C++) versus
chip-level integration (Objective-C) versus card-level integration
(Fabrik, Metaphor, LabView) terminology was to emphasize that *all*
of them have a role to play for different constituencies of any
robust software components marketplace.
Just try to imagine where the hardware industry would be today if
they'd "standardized" on silicon fabrication technologies for *all*
levels of their marketplace, without ever deploying chip and card
level technologies.
:I am a strong believer in the IC idea. Not that I believe that the
:complexity of a hardware even comes close to software. The
:number of dimensions in hardware is much smaller. In hardware you repeat
:the same building blocks to build a bigger system. In software every
:component is unique. But by encapsulation and using a generic software
:interface I have seen that it is possible to build systems faster. And
:I think that languages like Smalltalk, Objective C and CO2 are
:much more productive in this area then C++.
But I absolutely do not agree that software's complexity has to be
greater than that of hardware. Admittedly, it certainly is today,
but isn't that precisely because we still invent and implement
everything from first principles, rather than by relying on and
supporting a marketplace in interchangeable software components.
Just imagine how complex hardware engineering would be if each
designer mined raw silicon and proceeded from there.
--
Brad Cox; cox@stepstone.com; CI$ 71230,647; 203 426 1875
The Stepstone Corporation; 75 Glen Road; Sandy Hook CT 06482db@lfcs.ed.ac.uk (Dave Berry) (07/13/90)
In article <55517@microsoft.UUCP> jimad@microsoft.UUCP (Jim ADCOCK) writes: >Well, perhaps you can suggest a simple language friendly to the neophtye >programmer that can be used for large commercial projects? You can find some useful ideas in Standard ML. This is taught as a first language by several colleges, and is also being used for large commercial projects. The reason it works is that it's expression based, so integers, functions and modules can all be typed straight to the system (usually an incremental compiler). Neophytes can write simple programs without having to write module interfaces and the like. Also, the core language (i.e. the non-module part) uses type inference, so people don't even have to specify the types of their variables. Mistakes occasionally cause confusing error messages, at least with existing implementations, but in many ways type inference is a win. I'm not claimning that Standard ML will meet your every need. But some of its features do seem to support the distinction between large and small projects. If you're interested in that, I'd recommend taking a look. Dave Berry, LFCS, Edinburgh Uni. db%lfcs.ed.ac.uk@nsfnet-relay.ac.uk "ML don't stand for nothing! ML *is* ML" -- Spike Lee.
nick@lfcs.ed.ac.uk (Nick Rothwell) (07/16/90)
In article <5156@castle.ed.ac.uk>, db@lfcs (Dave Berry) writes: >In article <55517@microsoft.UUCP> jimad@microsoft.UUCP (Jim ADCOCK) writes: >>Well, perhaps you can suggest a simple language friendly to the neophtye >>programmer that can be used for large commercial projects? > >You can find some useful ideas in Standard ML. This is taught as a first >language by several colleges, and is also being used for large commercial >projects. > >The reason it works is that it's expression based, so integers, functions >and modules can all be typed straight to the system (usually an incremental >compiler). Neophytes can write simple programs without having to write >module interfaces and the like. Also, being almost purely functional, there is little need to reason about state in the various modular components. Hence, the type inference system serves as an informal verification, if you like, of the system - if it typechecks, then the chances are it'll work. This is an interesting difference from OO languages where local state is quite an important concept. > Dave Berry, LFCS, Edinburgh Uni. Nick. -- Nick Rothwell, Laboratory for Foundations of Computer Science, Edinburgh. nick@lfcs.ed.ac.uk <Atlantic Ocean>!mcsun!ukc!lfcs!nick ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ Ich weiss jetzt was kein Engel weiss