rs4u#@ANDREW.CMU.EDU (Richard Siegel) (12/06/86)
[Line-Eater? What Line-Eater? *Chomp* 8-) ] Organization: Carnegie-Mellon University, Pittsburgh, Pa. Position: Confused Undergraduate I'll remain neutral on the subject of posting the MacApp sources, but let me ask: what is MacApp written in? Object Pascal? Lisa Pascal? If it were written in LisaPascal (which I seriously doubt), it would be useful to those of us who can't afford an implementation of Object Pascal (read that MPW). Ergo, it's written in Object Pascal. Besides, I would wager it's a huge amount of code to post. Can you say "A megabyte of source code?" I bet you can! Personally, I'd like to see more implementations of Object Pascal (Like in a future version of Lightspeed Pascal), and a leaner MacApp library -- one that DOESN'T need a meg and hard drive! Is a stripped MacApp possible? Or a MacApp consisting of modules? What frosts me is that I am a college student, a programmer of some experience, and a Macintosh developer of some experience, but I don't have the resources (hardware = $$$$ x 10**3), so all these tools that Apple are putting out -- and they are high-quality, too; in spite of its slowness and size, MPW/MacApp is REALLY powerful -- are out of my reach! I have only what I can afford: a 512K Macintosh with an external drive, both 400K drives, old Roms, and so forth. I can't afford an upgrade, I can't afford another disk drive (I borrowed an 800K drive from a friend). I need a hard disk and a megabyte to run MacApp and/or MPW (I heard that all MPW needs is 512K and two 800K drives, and I don't believe it because I saw it choke on a 512Kenhanced), and I'm stuck. I'm sorry to have gone off on such a wild flaming tangent, but I seriously think that more attention needs to be paid to the "kitchen-table" developer (or college student developer, if you wish) than is being paid right now. --Rich These opinions are mine only, and they're like champagne: fermented for a long time. Richard M. Siegel Arpanet: rs4u@andrew.cmu.edu (the only way to get to me!) Disclaimer --> Disclaimers are bogus. (And as I finish this letter, my friend Joe Keane comes up to me and reads the letter and says: "Rich, you know, the guys at Apple are going to read your post, and say 'We're sorry you feel this way', and send you a megabyte of memory just to shut you up.")
lsr@apple.UUCP (Larry Rosenstein) (12/08/86)
>let me ask: what is MacApp written in? Object Pascal? Lisa Pascal? If it were >written in LisaPascal (which I seriously doubt), it would be useful to those >of us who can't afford an implementation of Object Pascal (read that MPW). >Ergo, it's written in Object Pascal. Besides, I would wager it's a huge >amount of code to post. Can you say "A megabyte of source code?" I bet you >can! > MacApp started out in the Lisa Workshop version of Object Pascal, and was ported to MPW Pascal. (The standard MPW Pascal compiler supports Object Pascal.) The MacApp sources are about a megabyte, and the sample programs take up another megabyte. When you buy MacApp you get 4 diskettes and several hundred pages of documentation. If you just want to look at the sources, APDA sells a printed listing. > Personally, I'd like to see more implementations of Object Pascal >(Like in a future version of Lightspeed Pascal), and a leaner MacApp library >-- one that DOESN'T need a meg and hard drive! Is a stripped MacApp possible? >Or a MacApp consisting of modules? > The simple fact is that MacApp implements a lot of features. We had very high standards for MacApp in terms of its adherence to the user interface guidelines, its error handling, and its reliability. In addition, MacApp was designed to be very general, so that it could be used in a variety of applications. It would certainly be possible to implement a MacApp-like framework that had only the most basic features in it. Such a framework would be more suitable for small utility applications or for learning Macintosh programming. Once you start implementing the rest of the MacApp features, I think you would end up with the same amount of code as in MacApp. One problem with dividing MacApp into separate units is that the principal MacApp object types all refer to one another. Right now the MPW Pascal compiler requires that they be defined in the same unit. (The compiler does not permit mutually recursive USES statements.) If that restriction was relaxed, then we could split the MacApp unit into several pieces. > What frosts me is that I am a college student, a programmer of some >experience, and a Macintosh developer of some experience, but I don't have >the resources (hardware = $$$$ x 10**3), so all these tools that Apple are >putting out -- and they are high-quality, too; in spite of its slowness and >size, MPW/MacApp is REALLY powerful -- are out of my reach! This is unfortunately true. MPW and MacApp are not intended for everyone. They are simply other alternatives for Macintosh programmers. I think that other third party products address the needs of the "kitchen-table" developers very well, while MPW and MacApp address the needs of professional developers. We would like to make MacApp available in other development systems, and have been working with third parties to make this happen. -- Larry Rosenstein Object Specialist Apple Computer AppleLink: Rosenstein1 UUCP: {sun, voder, nsc, mtxinu, dual}!apple!lsr CSNET: lsr@Apple.CSNET
dtw@f.gp.cs.cmu.edu.UUCP (12/10/86)
| MPW and MacApp are not intended for everyone. They are simply other | alternatives for Macintosh programmers. I think that other third party | products address the needs of the "kitchen-table" developers very well, | while MPW and MacApp address the needs of professional developers. | | We would like to make MacApp available in other development systems, and | have been working with third parties to make this happen. I don't understand why "professional" developers need MPW and MacApp and "kitchen-table" developers don't. No third party products provide the high level of support for the Mac user interface as does MacApp. If the "professional" needs this level of support, then why doesn't the "kitchen- table" developer? Is it that the "kitchen-table" developers are smarter, better programmers? Or is it that Apple just doesn't care about them, because they are less likely to directly help Apple sell Macs?
vito@trwspf.UUCP (12/10/86)
In article <364@apple.UUCP> lsr@apple.UUCP (Larry Rosenstein) writes: >We would like to make MacApp available in other development systems, and >have been working with third parties to make this happen. > When will this happen and with which languages. Personally, I would like to see better access to the toolbox from Smalltalk. In fact, I would like to prototype applications in Smalltalk and (when finished with what I've got), convert the Smalltalk code into a language (Object Pascal or Object Assembler) and get real performance!!! -- Herb Barad - TRW Data Systems Lab ARPA: barad@brand.usc.edu or vito%trwspf.uucp@brand.usc.edu USENET: ...!{brand|trwrb}!trwspf!vito
rs4u#@ANDREW.CMU.EDU.UUCP (12/10/86)
This is in response to Duane Williams' (dtw@f.gp.cs.cmu.edu) article of Dec. 9: I agree veery strongly -- it is the smaller, third-party developer or hobbyist or college student that needs the most support. While there are some fine development systems out there (to wit, Lightspeed C and Lightspeed Pascal) and the situation is much better for kitchen-table developers than it used to be, the fact is that it's the professionals wwith money to spend and marketable results to offer (or promise) that end up getting the lion's share of support. For example: to be a Registered Developer and receive direct phone and e-mail tech support from Apple costs $595 a year. I personally cannot afford that. I'm a Certified Developer, which costs nothing. I have received monthly mailings from Apple, lately containing Technotes, but thsoe are available just about anywhere. (They are freely distributed, yes?) Otherwise, the advantages are nil. "Or is it that Apple just doesn't care about them, because they are less likely to directly help Apple sell Macs?" I would suspect it's the latter. While Apple certainly could help more, the attitude seems prevalent among large companies: "We want to sell computers/toasters/baseball bats, so let's give all our support to the professional developer/toaster engineer/baseball bat handle-wrapper, rather to the little
wetter@tybalt.caltech.edu.UUCP (12/11/86)
In article <20@f.gp.cs.cmu.edu> you write: > >| MPW and MacApp are not intended for everyone. They are simply other >| alternatives for Macintosh programmers. I think that other third party >| products address the needs of the "kitchen-table" developers very well, >| while MPW and MacApp address the needs of professional developers. >| >| We would like to make MacApp available in other development systems, and >| have been working with third parties to make this happen. > >I don't understand why "professional" developers need MPW and MacApp and >"kitchen-table" developers don't. No third party products provide the high >level of support for the Mac user interface as does MacApp. If the >"professional" needs this level of support, then why doesn't the "kitchen- >table" developer? Is it that the "kitchen-table" developers are smarter, >better programmers? Or is it that Apple just doesn't care about them, >because they are less likely to directly help Apple sell Macs? From the acticle you quoted "We have been working with third parties to make this happen". In the article where he talks about the needs of kitchen vs provessional devlopers he is refering to MPW more then MacAPP. MPW is not intended for the average user turned programmer it is intended for someone familar with the traditional command line development enivirionment (and god forbid likes it, bleh!). MPW in not easy to use but it is incredibly powerful. Not all of the power of MPW is needed for MacAPP, only an object pascal compiler. Thus apple is trying to get third party compilers to suppor object pascal. Then the "kitchen table" developer can use MacAPP without having to resort to the more complete envirionment of MPW. As for the rest of your comments about whether Apple cares about the "kitchen table" developers, well I'll take them for what they are worth.... Pierce Wetter Reclaimer, spare that tree! Take not a single bit! It used to point to me, Now I'm protecting it. It was the reader's CONS That made it, paired by dot; Now, GC, for the nonce, Thou shalt reclaim it not. -------------------------------------------- wetter@tybalt.caltech.edu --------------------------------------------
lsr@apple.UUCP (Larry Rosenstein) (12/12/86)
In article <125@trwspf.UUCP> vito@trwspf.UUCP (Herb Barad) writes: > >When will this happen and with which languages. Personally, I would like >to see better access to the toolbox from Smalltalk. In fact, I would like >to prototype applications in Smalltalk and (when finished with what I've >got), convert the Smalltalk code into a language (Object Pascal or >Object Assembler) and get real performance!!! > In general, there are 2 ways to be compatible with MacApp. First is to adopt the MPW object module format and the Object Pascal method call runtime scheme (which was described in the December MacTutor, by the way). If you do this, then you can use a pre-compiled version of MacApp and only have to convert the MacApp interfaces into your language. Second is to translate MacApp into your lanaguage. This is a relatively big job, because MacApp is about 20,000 lines of code. If any language developer is interesting in supporting MacApp s/he can write to the MacApp product manager: Harvey Alcabes Apple Computer 20525 Mariani M/S 27-S Cupertino, CA 95014 It interesting tha Smalltalk was mentioned, because there is an ongoing research project at Apple investigating putting MacApp in Smalltalk. This was demonstrated at OOPSLA last October, but is not currently available. (It is based on a very old version of MacApp and is somewhat fragile.) The Smalltalk runtime is very different from that of Object Pascal, so the Smalltalk people wrote a translator (in Smalltalk). The translator did not do a 100% job, so they then hand edited the result. They are able to run some of the simple sample programs and switch back and forth from the Macintosh world to the Smalltalk world. (They implement 2 different screens.) While the MacApp program is running, you have the usual Macintosh user interface (desk accessories, pull-down menus, etc.). As you might imagine, there are a lot of issues that still need to be resolved, which is why it is a research project. For example, there is no Smalltalk to Pascal translator. Second, there are Pascal constructs that Smalltalk doesn't support such as VAR parameters. Third, some Toolbox calls require a procedure pointer as a parameter, which is difficult to do in Smalltalk. Finally, there are issues involved with memory management because the Smalltalk heap is separate from the Macintosh heap. -- Larry Rosenstein Object Specialist Apple Computer AppleLink: Rosenstein1 UUCP: {sun, voder, nsc, mtxinu, dual}!apple!lsr CSNET: lsr@Apple.CSNET
dgold@apple.UUCP (David Goldsmith) (12/12/86)
In article <MS.V3.18.rs4u.80020c06.blythedale.ibm032.129.1@andrew.cmu.edu> rs4u#@ANDREW.CMU.EDU (Richard Siegel) writes: >... For example: to be a Registered Developer and receive direct >phone and e-mail tech support from Apple costs $595 a year. I personally >cannot afford that. I'm a Certified Developer, which costs nothing. I have >received monthly mailings from Apple, lately containing Technotes, but thsoe >are available just about anywhere. (They are freely distributed, yes?) >Otherwise, the advantages are nil. Certified developers (and it does indeed cost nothing to become one) are also entitled to technical support via e-mail (MCI). Certified developers also get discounts on Apple equipment. Only Registered Developers get telephone technical support. -- David Goldsmith Apple Computer, Inc. MacApp Group AppleLink: GOLDSMITH1 UUCP: {nsc,dual,sun,voder,ucbvax!mtxinu}!apple!dgold CSNET: dgold@apple.CSNET, dgold%apple@CSNET-RELAY
lsr@apple.UUCP (Larry Rosenstein) (12/12/86)
In article <20@f.gp.cs.cmu.edu> dtw@f.gp.cs.cmu.edu (Duane Williams) writes: > >I don't understand why "professional" developers need MPW and MacApp and >"kitchen-table" developers don't. No third party products provide the high >level of support for the Mac user interface as does MacApp. If the >"professional" needs this level of support, then why doesn't the "kitchen- >table" developer? Is it that the "kitchen-table" developers are smarter, >better programmers? Or is it that Apple just doesn't care about them, >because they are less likely to directly help Apple sell Macs? "Kitchen-table" or "weekend" developers need as much help (if not more) in producing their applications. In general, they don't have the time to spend learning about the details of Inside Macintosh. MacApp tries to solve this problem. It is equally true that Apple is in the business of selling machines, and that the vast majority of users care about the commerical software that is available. Therefore, Apple devotes most of its limited resources towards commerical developers, because they are the most likely to ship products. Apple does care about "kitchen-table" developers. We helped APDA get off the ground, for example. As David Goldsmith mentioned, there is no fee to become a Certified Developer, which provides for discounts on equipment and E-Mail Technical Support. (You do have to convince the Developer Relations people that you are serious about shipping a product.) MPW was targeted towards "professional" developers because there seemed to be a lack of third party products in that market. I am not very familiar with all the development systems on the Macintosh, but I don't think any of them offer the expandability of MPW. Also, MPW supports multi-language development. The goal of making MPW run on a minimal hardware configuration was not a high priority. MPW was tested, however, on a 512Ke with 2 800K drives, but compiling large programs simply requires more memory. The main goal of MacApp was to produce a framework that could be used for commerical applications. Once again, there are already similar products that are designed to make development easier. From third parties there is MacExpress (not to be confused with DiskExpress from the same company), and the Pascal/C Extenders. In the public domain/shareware category are TransSkel (and related things). As was mentioned above, none of these systems (as far as I know) address as broad a range of features as does MacApp. Some of these features (e.g., memory management, error handling, printing) are very important and very difficult to do. Adding all these features increased the size of MacApp. Off hand, I can't think of many features that could be eliminated from MacApp in order to reduce its size. We could eliminate support for the clipboard, for example, but that means either you would have to implement this all yourself or leave it out of the program altogether. It might be true that the MPW Pascal compiler makes inefficient use of memory, and that a different compiler would be able to compile MacApp programs in 512K of memory. As far as a hard disk goes, I don't think you can implement a very large application on a machine with 2 800K drives. Even if you don't have the hardware to run MPW and MacApp, you can get a printed MacApp listing from APDA and get some benefit out of studying the source code. I will gladly describe any of the techniques used in MacApp, so that other people can incorporate them into their applications. -- Larry Rosenstein Object Specialist Apple Computer AppleLink: Rosenstein1 UUCP: {sun, voder, nsc, mtxinu, dual}!apple!lsr CSNET: lsr@Apple.CSNET
joel@gould9.UUCP (Joel West) (12/12/86)
For anyone interested in MacApp, I strongly recommend the December
issue of MacTutor.
Larry Rosenstein's example is more understandable and useful than
the ones supplied with the source or printed by Schmucker. He also
briefly summarizes the philosophy if you haven't seen it already.
Ken Doyle's article talks about the MacApp/MPW Object Pascal implementation
in a way that appears nowhere else. One developer I know that was previously
anti-MacApp is now leaning towards Object Pascal (if not MacApp) for
future development. Apple and the MacApp group have done a lot to
make sure that the performance penalties are minimal.
--
Joel West MCI Mail: 282-8879
Western Software Technology, POB 2733, Vista, CA 92083
{cbosgd, ihnp4, pyramid, sdcsvax, ucla-cs} !gould9!joel
joel%gould9.uucp@NOSC.ARPAmikec@tekred.UUCP (Mike Combs) (12/13/86)
In article <374@apple.UUCP> dgold@apple.UUCP (David Goldsmith) writes: >In article <MS.V3.18.rs4u.80020c06.blythedale.ibm032.129.1@andrew.cmu.edu> rs4u#@ANDREW.CMU.EDU (Richard Siegel) writes: >>cannot afford that. I'm a Certified Developer, which costs nothing. I have >>received monthly mailings from Apple, lately containing Technotes, but thsoe >>are available just about anywhere. (They are freely distributed, yes?) >>Otherwise, the advantages are nil. > >Certified developers (and it does indeed cost nothing to become one) are also >entitled to technical support via e-mail (MCI). Certified developers also >get discounts on Apple equipment. Only Registered Developers get telephone >technical support. >-- >David Goldsmith >Apple Computer, Inc. I've found Apple's technical support through MCI to be very useful, indirectly, and directly. Indirectly, because writing down the problem to send to Apple forces you to concretely identify it. More than once, the process of describing the problem has led to it's solution before I e-mailed off the question. Directly, because Apple replies in a day or so. Their MCI support is much better than many outfit's telephone support. You don't have to explain the problem to five people before you reach the right one. You don't have to call them back when they forget to call you back. And you don't wait on the tech-line hold for 1/2 an hour. ..mac <- These were my initials before Apple borrowed them. But I don't mind. But perhaps you should copyright your initials before it's too late. :-) -- ----- Mike A. Combs -------------------------------------------------- ^--the "A" is for: "Accidently erased the files" GEnie: mike.combs MCI: m.combs tektronix!tekgen!tekred!mikec