Path: utzoo!attcan!uunet!hsi!stpstn!andyk From: andyk@stpstn.UUCP (Andy Klapper) Newsgroups: comp.object Subject: Re: Objective-C review Message-ID: <5281@stpstn.UUCP> Date: 27 Jun 90 13:34:54 GMT References: <1638@dinl.mmc.UUCP> <1690@kunivv1.sci.kun.nl> <5239@stpstn.UUCP> <55443@microsoft.UUCP> Reply-To: andyk@stpstn.UUCP (Andy Klapper) Organization: The Stepstone Corporation, Sandy Hook, CT 06482 Lines: 60 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