Path: utzoo!mnetor!uunet!husc6!tut.cis.ohio-state.edu!rutgers!super.upenn.edu!linc.cis.upenn.edu!mayerk From: mayerk@linc.cis.upenn.edu (Kenneth Mayer) Newsgroups: comp.sys.mac.programmer Subject: Re: Prototyper vs. Doing it Yourself Message-ID: <3715@super.upenn.edu> Date: 20 Mar 88 16:22:31 GMT References: Sender: news@super.upenn.edu Reply-To: mayerk@linc.cis.upenn.edu.UUCP (Kenneth Mayer) Organization: University of Pennsylvania Lines: 66 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?"