Article View: comp.lang.lisp.mcl
Article #644Re2: Mother ship App.(flame)
From: EHN & DIJ Oakley,GB,IDV
Date: Thu, 21 Jan 1993 20:58
Date: Thu, 21 Jan 1993 20:58
78 lines
5211 bytes
5211 bytes
Whoa! Not only a flame, but going against all my experience and feelings! Come now, John: >I don't know if anyone really wanted an 'applications environment' when they >bought MCL. If you mean an extensible development environment, which can amount to the same thing, I think that you underestimate the number of those who would like it. >MCL does infact make stand alone applications, even though they're too big >to be of any use to anyone Well, we have one MCL app which is being used in beta, one which has 'shipped' (vertical market), and another under development now which is due to go into late beta by the end of February 93, and four more in design. I am sure that there are others out there... >The fact is, MCL makes B I G CLUMSY and BUGGY applications As others have pointed out, this is categorically untrue. Admittedly, I have only used THINK C, TML Pascal, MPW Pascal, MPW C, MPW C++, with and without MacApp from 1.1.1 to 3.0, Prograph, ProIcon, and MacProlog, as Mac development systems, but MCL 2.0 produces by far the least buggy applications (I cannot recall a 'crash' in the conventional sense, and CL errors are almost unheard of) of them all. Add to that the fact that I am a rank novice Lisp programmer, so I can lay claim to giving it a good run for its money! [an aside: I would probably rank MacProlog a good second, although I have not yet used it enough to be certain]. I keep a summary of all info-mcl messages of potential future value, including bugs; you may be interested to hear that bugs are very few and far between, and almost invariably fairly obscure. Compare this with the other development systems of which I have experience - listen in to one of the MacApp group mailing lists for example - and MCL is virtually bug-free now. As regards 'clumsy', I am not sure what this is supposed to mean in this context; however, the vertical market app is a real-time radar screen simulator which performs immaculately, and the word 'clumsy' is definitely not one I would have associated with it. >it's also very clear that nothing is being done about the B I G and CLUMSY >'feature' I thought that much of this thread had emerged from the discussion arising from three possible ways to smaller apps, suggested by one of the MCL development team? Again, as others have pointed out, look at any other proper Common Lisp, and you will see something an order of magnitude bigger. No, considering making regular standalone apps with MCL is tribute to the effort that has gone into keeping it lean (and mean). >here's an exerpt from an article published by Andrew Shalit in the APDAlog of >Spring 1989... >...Nowadays the smallest program I can make is twice the size of the smallest >program that could be made 4 years ago You might also have noticed that almost every other Mac application over this period has grown somewhat larger in size - Excel, Word, etc. This may just have a little to do with the fact that there is a lot more to the System software, which has also grown in size. And strangely enough, back in 89, I only had 8 meg RAM, whilst now I have 36 megs (largely to accommodate MPW/MacApp). I think this may just be an industry trend :-) What you *should* of course do is to compare the functionality and popularity between MACL of 89 and MCL of today - I for one would never have seriously contemplated using MACL of 89 for the things which I currently use MCL for daily. >This is ridiculous, it's quite evident that size has not been a priority, >and it never was a priority I do not believe that size is not and has not been a priority. However, complete compliance with a language standard which is of Byzantine size and complexity (and long may it be so!), complete support for the enormity of the Mac System without having to write loads of foreign functions, and in fact being one of the finest Common Lisp implementations and one of the finest Mac development environments, are also important considerations. Fail in any of those, and size of apps is immaterial. I agree with the word 'ridiculous', only I would turn it back on you and suggest that it is ridiculous to flame in such an uninformed manner one of Apple's finest products, and one of the Mac's most mature and productive development environments. What is more, it is also their best supported product, as we in info-mcl benefit from the same standard of technical support normally only provided under expensive and select programmes like the Apple Partner scheme. We should come to praise MCL, not blindly bury axes into it: if you want to offer constructive criticism, then surely a reasoned response to the three options for reduction in size would be a wiser move? Howard.
Technical Details
Message-ID:
<727651337.0183162@AppleLink.Apple.COM>Path:
arc1-ca.pugleaf.net!sparky!uunet!olivea!apple!cambridge.apple.com!UK0392@AppleLink.Apple.COMShow Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!sparky!uunet!olivea!apple!cambridge.apple.com!UK0392@AppleLink.Apple.COM From: UK0392@AppleLink.Apple.COM (EHN & DIJ Oakley,GB,IDV) Newsgroups: comp.lang.lisp.mcl Subject: Re2: Mother ship App.(flame) Message-ID: <727651337.0183162@AppleLink.Apple.COM> Date: 21 Jan 93 20:58:00 GMT Sender: owner-info-mcl@cambridge.apple.com Lines: 78 Approved: comp.lang.lisp.mcl@Cambridge.Apple.C0M