home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #19 / NN_1992_19.iso / spool / comp / lang / modula2 / 1085 < prev    next >
Encoding:
Text File  |  1992-08-29  |  2.3 KB  |  48 lines
  1. Newsgroups: comp.lang.modula2
  2. Path: sparky!uunet!munnari.oz.au!metro!seagoon.newcastle.edu.au!wombat.newcastle.edu.au!eepjm
  3. From: eepjm@wombat.newcastle.edu.au (Peter Moylan)
  4. Subject: Re: Is Modula-2 dead? 
  5. Message-ID: <1992Aug28.100804.1@wombat.newcastle.edu.au>
  6. Lines: 36
  7. Sender: news@seagoon.newcastle.edu.au
  8. Organization: University of Newcastle, AUSTRALIA
  9. References: <1992Aug20.134358.25702@informatik.uni-bremen.de> <714374380snx@black.demon.co.uk> <munk.714828002@prles6b>
  10. Date: Fri, 28 Aug 1992 00:08:04 GMT
  11.  
  12. In article <munk.714828002@prles6b>, munk@prl.philips.nl (Harm Munk) writes:
  13. > 
  14. > If people think that real programs should be written in C or C++, then let's
  15. > stop developing native Modula 2 compilers. Instead, we should have compilers
  16. > that compile to C or C++. If we do that, we use C (and C++ ?) for the purpose
  17. > that it was developed for: glorified assembly ;-).
  18. > 
  19. > And if asked in which language our products are written, we can say that the
  20. > code is in C or C++.
  21.  
  22. I was forced into a similar situation many years ago.  I used a 
  23. high-level language when developing an application for an organisation
  24. which was used to using assembly language.  The auditors complained.
  25. So I took my object code, ran it through a disassembler, and delivered
  26. the assembly language output.  The auditors were then happy.  Not a
  27. peep over the fact that my final code had no comments, no labels,
  28. no variable names.  I had hoped to make the point that their
  29. requirements were stupid, but they missed the point.
  30.  
  31. I don't have to like it, though.  These days, I make sure I point out
  32. to all and sundry exactly *why* C/C++ programming is unsafe, and
  33. why it is uneconomical in terms of development time (particularly
  34. debugging time).  It's an uphill battle, but that's no reason for
  35. giving up the battle.
  36.  
  37. Try working on the project managers and the accountants.  If you
  38. can give them hard proof that they're saving time and money by
  39. specifying M2 (or, indeed, any high-level language) rather than C++,
  40. half the battle is won.  One way to do this is to try to introduce
  41. an environment which permits mixed-language programming (this is one
  42. reason why I recently converted to TopSpeed), and then come up with
  43. some hard figures - by using detailed logs and timesheets - which
  44. show that you're more productive than the rest of the team.
  45.  
  46. -- 
  47. Peter Moylan                      eepjm@wombat.newcastle.edu.au
  48.