home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #3 / NN_1993_3.iso / spool / comp / lang / lisp / mcl / 2075 < prev    next >
Encoding:
Internet Message Format  |  1993-01-21  |  5.0 KB
  1. Path: sparky!uunet!olivea!apple!cambridge.apple.com!UK0392@AppleLink.Apple.COM
  2. From: UK0392@AppleLink.Apple.COM (EHN & DIJ Oakley,GB,IDV)
  3. Newsgroups: comp.lang.lisp.mcl
  4. Subject: Re2: Mother ship App.(flame)
  5. Message-ID: <727651337.0183162@AppleLink.Apple.COM>
  6. Date: 21 Jan 93 20:58:00 GMT
  7. Sender: owner-info-mcl@cambridge.apple.com
  8. Lines: 78
  9. Approved: comp.lang.lisp.mcl@Cambridge.Apple.C0M
  10.  
  11. Whoa!  Not only a flame, but going against all my experience and feelings!
  12. Come now, John:
  13.  
  14. >I don't know if anyone really wanted an 'applications environment' when they
  15. >bought MCL.
  16. If you mean an extensible development environment, which can amount to the same
  17. thing, I think that you underestimate the number of those who would like it.
  18.  
  19. >MCL does infact make stand alone applications,  even though they're too big
  20. >to be of any use to anyone
  21. Well, we have one MCL app which is being used in beta, one which has 'shipped'
  22. (vertical market), and another under development now which is due to go into
  23. late beta by the end of February 93, and four more in design.  I am sure that
  24. there are others out there...
  25.  
  26. >The fact is,  MCL makes B I G CLUMSY and BUGGY applications
  27. As others have pointed out, this is categorically untrue.  Admittedly, I have
  28. only used THINK C, TML Pascal, MPW Pascal, MPW C, MPW C++, with and without
  29. MacApp from 1.1.1 to 3.0, Prograph, ProIcon, and MacProlog, as Mac development
  30. systems, but MCL 2.0 produces by far the least buggy applications (I cannot
  31. recall a 'crash' in the conventional sense, and CL errors are almost unheard
  32. of) of them all.  Add to that the fact that I am a rank novice Lisp programmer,
  33. so I can lay claim to giving it a good run for its money!  [an aside:  I would
  34. probably rank MacProlog a good second, although I have not yet used it enough
  35. to be certain].  I keep a summary of all info-mcl messages of potential future
  36. value, including bugs; you may be interested to hear that bugs are very few and
  37. far between, and almost invariably fairly obscure.  Compare this with the other
  38. development systems of which I have experience - listen in to one of the MacApp
  39. group mailing lists for example - and MCL is virtually bug-free now.  As
  40. regards 'clumsy', I am not sure what this is supposed to mean in this context;
  41. however, the vertical market app is a real-time radar screen simulator which
  42. performs immaculately, and the word 'clumsy' is definitely not one I would have
  43. associated with it.
  44.  
  45. >it's also very clear that nothing is being done about the B I G and CLUMSY
  46. >'feature'
  47. I thought that much of this thread had emerged from the discussion arising from
  48. three possible ways to smaller apps, suggested by one of the MCL development
  49. team?  Again, as others have pointed out, look at any other proper Common Lisp,
  50. and you will see something an order of magnitude bigger.  No, considering
  51. making regular standalone apps with MCL is tribute to the effort that has gone
  52. into keeping it lean (and mean).
  53.  
  54. >here's an exerpt from an article published by Andrew Shalit in the APDAlog of
  55. >Spring 1989...
  56. >...Nowadays the smallest program I can make is twice the size of the smallest
  57. >program that could be made 4 years ago
  58. You might also have noticed that almost every other Mac application over this
  59. period has grown somewhat larger in size - Excel, Word, etc.  This may just
  60. have a little to do with the fact that there is a lot more to the System
  61. software, which has also grown in size.  And strangely enough, back in 89, I
  62. only had 8 meg RAM, whilst now I have 36 megs (largely to accommodate
  63. MPW/MacApp).  I think this may just be an industry trend :-)  What you *should*
  64. of course do is to compare the functionality and popularity between MACL of 89
  65. and MCL of today - I for one would never have seriously contemplated using MACL
  66. of 89 for the things which I currently use MCL for daily.
  67.  
  68. >This is ridiculous,  it's quite evident that size has not been a priority,
  69. >and it never was a priority
  70. I do not believe that size is not and has not been a priority.  However,
  71. complete compliance with a language standard which is of Byzantine size and
  72. complexity (and long may it be so!), complete support for the enormity of the
  73. Mac System without having to write loads of foreign functions, and in fact
  74. being one of the finest Common Lisp implementations and one of the finest Mac
  75. development environments, are also important considerations.  Fail in any of
  76. those, and size of apps is immaterial.  I agree with the word 'ridiculous',
  77. only I would turn it back on you and suggest that it is ridiculous to flame in
  78. such an uninformed manner one of Apple's finest products, and one of the Mac's
  79. most mature and productive development environments.  What is more, it is also
  80. their best supported product, as we in info-mcl benefit from the same standard
  81. of technical support normally only provided under expensive and select
  82. programmes like the Apple Partner scheme.  We should come to praise MCL, not
  83. blindly bury axes into it:  if you want to offer constructive criticism, then
  84. surely a reasoned response to the three options for reduction in size would be
  85. a wiser move?
  86.  
  87. Howard.
  88.  
  89.