rs4u+@andrew.cmu.edu (Richard Siegel) (03/14/88)
I've been reading the discussion of Prototyper on this board, and
despite the rather crass :-) plugging I've seen, it does sound intriguing.
However, I resist using tools such as MacApp, or Programmer's Extender,
or MacExpress, or Prototyper, simply on the grounds that I'd rather do it
myself. If I do it myself, I've gained an insight into how things work; I've
gotten my hands dirty, and I know exactly where the bugs lie (if there are
any). The learning is sometimes more valuable than getting the job done. My
plotting program's been in continuous development for over a year (since the
last time I released it as shareware) and it bears no resemblance to its
previous incarnation; the interface is more standard, more intuitive, and
faster than previous versions. And I know a lot more about programming in
general, and about hacking the user interface toolbox, in particular.
I guess the point is that I've done application development since
before the first toolkits came out, and I've written all of my interfaces by
hand. And enjoyed every minute of it. And I see no reason to throw out all of
my work at this point.
Aside from the philosophical differences, the practical application is
that since I've done the interface already, it's a simple job to build up a set
of libraries, or even an application shell. Also, I can keep my code current
with the system by adding MultiFinder support, color capability, and so forth,
instead of relying upon someone else to do it for me.
When I get Lightspeed Pascal with object support, I'm going to use it
to make my application smaller and more elegant, not just to run MacApp.
So call me crazy.
--Rich
===================================================================
Rich Siegel
Confused Undergrad, Carnegie-Mellon University
The opinions stated here do not represent the policies
of Carnegie-Mellon University.
Arpa: rich.siegel@andrew.cmu.edu
UUCP: {decvax,ucbvax,sun}!andrew.cmu.edu!rich.siegel
==================================================================lsr@Apple.COM (Larry Rosenstein) (03/15/88)
In article <AWCzzgy00V48UYU0bT@andrew.cmu.edu> rs4u+@andrew.cmu.edu (Richard Siegel) writes: > > However, I resist using tools such as MacApp, or Programmer's >Extender, or MacExpress, or Prototyper, simply on the grounds that I'd >rather do it myself. If I do it myself, I've gained an insight into how >things work; I've gotten my hands dirty, and I know exactly where the bugs This is a very good point. My experience with MacApp has been that some people do like to know what is going on inside of MacApp. These people tend to have a harder time using MacApp because MacApp is a fairly large program written in a certain style. (It does take a while to fully understand what goes on inside of MacApp, plus the dynamic binding of method calls makes it even more difficult.) People who will accept the "MacApp approach", and will try using MacApp before finding out how it works seem to have an easier time learning it. >lie (if there are any). The learning is sometimes more valuable than >getting the job done. My plotting program's been in continuous development >for over a year (since the last time I released it as shareware) and it >bears no resemblance to its previous incarnation; the interface is more >standard, more intuitive, and faster than previous versions. And I know a >lot more about programming in general, and about hacking the user interface >toolbox, in particular. The philosophy of MacApp is that programmers shouldn't have to know about the details of the Toolbox, in order to produce an application. They also should not have to reinvent the code for the standard user interface each time. On the other hand, if learning about the workings of the Toolbox is what you want to do, then MacApp is not going to help you do it. -- Larry Rosenstein, Object Specialist Apple Computer, Inc. 20525 Mariani Ave, MS 32E Cupertino, CA 95014 AppleLink:Rosenstein1 domain:lsr@Apple.COM UUCP:{sun,voder,nsc,decwrl}!apple!lsr
rmh@Apple.COM (Rick Holzgrafe) (03/16/88)
In article <AWCzzgy00V48UYU0bT@andrew.cmu.edu> rs4u+@andrew.cmu.edu (Richard Siegel) writes: > > However, I resist using tools such as MacApp, or Programmer's Extender, >or MacExpress, or Prototyper, simply on the grounds that I'd rather do it >myself. If I do it myself, I've gained an insight into how things work; I've >gotten my hands dirty, and I know exactly where the bugs lie (if there are >any). The learning is sometimes more valuable than getting the job done. My > >=================================================================== >Rich Siegel >Confused Undergrad, Carnegie-Mellon University > >The opinions stated here do not represent the policies >of Carnegie-Mellon University. > >Arpa: rich.siegel@andrew.cmu.edu >UUCP: {decvax,ucbvax,sun}!andrew.cmu.edu!rich.siegel >================================================================== All valid points, Rich. And I'll admit before I start shooting off my mouth, that I haven't yet done any programming in an object-oriented environment (I work in C -- "RSN", they tell me :-). But as an ex-Un*x hack, I have programmed with such luxuries as YACC, which creates parsers from simple descriptions of a grammar, and LEX, which creates scanners from (fairly) simple descriptions of a lexicon. The purpose of these gadgets, ultimately, is the same as the purpose of a compiler vs. an assembler. Writing in assembler, you know EXACTLY what the machine is doing: nothing is hidden: and your code is smaller and runs faster. So why program in a high-level language? The answer is, that in a production environment the learning is rarely more important than getting the job done in a timely fashion. In school, you should learn (I did notice your mailing address :-). In production, you generally should have already learned: you can then decide whether the job is better done by hand or by a power tool. (Once in a while, I usually do take time to learn something new. I don't mean to imply that I am or anyone is a total know-it-all or ever can be!) Brad J. Cox, in his book "Object-Oriented Programming: An Evolutionary Approach" makes the point that for twenty years, the productive capability of hardware engineers has doubled every year, because each year they can grab an ever-more-sophisticated pre-made component off the shelf, instead of re-designing that particular wheel themselves. In the same two decades, while the hardware designer's effectiveness has been increasing exponentially, the software designer's has been increasing only arithmetically (Cox's estimates), largely because we software types can rarely re-use someone else's work. The odd "sort" routine from a sub-routine library, and that's about it. Pretty low-level stuff, while the hardware folks can now grab an entire CPU for around $30. The moral: Power tools are effective: they don't come without price, but the right (!) power tools can be a tremendous productivity aid. So how massive a flame war have I started? (-: *cringe* :-) ========================================================================== Rick Holzgrafe | {sun,voder,nsc,mtxinu,dual}!apple!rmh Communications Software Engineer | AppleLink HOLZGRAFE1 rmh@apple.com Apple Computer, Inc. | "All opinions expressed are mine, and 20525 Mariani Ave. MS: 27-Y | do not necessarily represent those of Cupertino, CA 95014 | my employer, Apple Computer Inc."
gillies@uiucdcsp.cs.uiuc.edu (03/17/88)
I think you can learn a lot from a prototyping tool. You can design
an elaborate user interface, and then look at the code it generates.
One of the best ways to learn is by seeing and imitating. So
watch how the prototyper generates code for an application, and learn
to imitate it.
Don Gillies {ihnp4!uiucdcs!gillies} U of Illinois
{gillies@p.cs.uiuc.edu}mayerk@linc.cis.upenn.edu (Kenneth Mayer) (03/21/88)
When last we saw our hero, rs4u+@andrew.cmu.edu (Richard Siegel) ... > ... ... ... > However, I resist using tools such as MacApp, or Programmer's Extender, >or MacExpress, or Prototyper, simply on the grounds that I'd rather do it >myself. If I do it myself, I've gained an insight into how things work; I've >gotten my hands dirty, and I know exactly where the bugs lie (if there are >any). The learning is sometimes more valuable than getting the job done. Granted. Most people however don't have the luxury of making the same mistakes over and over again until they learn how to do it right. Tools that I've used, such as MacApp and Prototyper are in the one case, a pre- made library of a standard interface that my shop can use across all applications that we build. We use a lot of student programmers who've barely started their programming careers, much less Macintosh programming. In the second case, Prototyper, I will be the first to admit that I don't like the code that is generated. In a word, it sucks buffalo chips. I don't think that it was ever meant to be a replacement for writing good, clean Macintosh supporting code. Instead, it is a starting point for how the program control should flow, where mouse and menu events have to go, and it creates resources like windows, icons, and menus better than any other package I've used. I've found that Prototyper is most useful for interactive interface design with a content expert. I can change formats, dialogs, and windows quickly, then show the client the result. That makes my job a lot easier. MacApp is not going to replace all pascal programmers for some time to come. My group has discovered several minor (and some not so minor) bugs in MacApp. MacApp, in addition, makes it very difficult to do things that you may want to do, but was never in the original design. For example: it is impossible to center dialog boxes dynamicly. That is, if you place a dialog window in the center of MacPlus screen in your resource description file, it will be in the upper left quadrant of a MacII display. Not pretty, and NOT in accordance with Apple standards. And there is no workaround that we have found. What MacApp provides is a way to write object oriented code. Which, if done correctly (and I stress this highly), gives you code that you can literally cut and paste into other applications. Object orientedness allows you to create child class objects with extensions you need, without modifying the base code source. > > I guess the point is that I've done application development since >before the first toolkits came out, and I've written all of my interfaces by >hand. And enjoyed every minute of it. And I see no reason to throw out all of >my work at this point. You are one of the lucky ones to developed and maintained a workable library over the years. My shop has been in business since 1984, and yet, when I started last November, there was no source code in our library that drove the standard event loop. Everyone is expected to write one for him or herself. > > When I get Lightspeed Pascal with object support, I'm going to use it >to make my application smaller and more elegant, not just to run MacApp. > You may discover that the source code specific to your applicatio is smaller, but that the overall source and object code is much larger. Object oriented Pascal in MPW tends to be huge (a minimum of 100K). ----- ===== ----- ===== ----- ===== ----- Kenneth Mayer | Teacher: "Two plus two equals..." mayerk@eniac.seas.upenn.edu | Student: "Four, but what's a two?"