home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / sys / amiga / programmer / 7147 < prev    next >
Encoding:
Text File  |  1996-08-05  |  4.2 KB  |  105 lines
  1. Newsgroups: comp.sys.amiga.programmer
  2. Path: cix.compulink.co.uk!usenet
  3. From: jralph@cix.compulink.co.uk ("Jolyon Ralph")
  4. Subject: More on E
  5. Message-ID: <DpnDMr.DrG@cix.compulink.co.uk>
  6. Organization: Compulink Information eXchange
  7. References: <u>
  8. Date: Wed, 10 Apr 1996 13:04:03 GMT
  9. X-News-Software: Ameol32
  10.  
  11. Wouter wrote:
  12.  
  13. > Aha. Now tell me then, do things that are personal preference on your 
  14. > part
  15. > make something unfit for general serious use by anyone, regardless?
  16.  
  17. It's a (possibly unfortunate) fact that almost all Amiga OS developer 
  18. documentation and example code has always been written in C or for C 
  19. programmers.
  20.  
  21. Anyone learning E (or any other language for that matter) will have to 
  22. learn enough C anyway in order to learn how to use the OS, to use 
  23. examples from books, read PD code, etc.
  24.  
  25. And if you're reading someone's C code, whoever you are and hoever much 
  26. experience in C you've had, you're bound to get confused between 
  27. differences (such as expression parsing) between C and E. Some of these 
  28. may be subtle enough not to be noticed immediately resulting in obscure 
  29. and dificult to track down bugs.
  30.  
  31. Unless you intend to rewrite the entire RKM's from an E perspective, you 
  32. must admit that this will cause people some problems :-)
  33.  
  34. > Well, my apologies for passing the "flame mode" treshold so soon.  But 
  35. > your
  36.  
  37. Well, I did kind of start it :-)
  38.  
  39. > Yeah right. Like I haven't done that a thousand times already.
  40.  
  41. Well, I'm not on the E mail list, I've read the sections in E.guide, but 
  42. some other things would be nice to know. When will E give in-line 680x0 
  43. assembler? When will it do better 680x0/6888x compilation?
  44.  
  45. When can I compile a module with DEBUG info without having NOP's all over 
  46. the place? (reason - I tend to compile once with debug and then SLINK 
  47. from  xxx.debug to xxx STRIPDEBUG to remove the debug data rather than 
  48. compiling twice with and without debug. Obviously, I do have to compile 
  49. twice now with E)
  50.  
  51. > You are maintaining a large E project without utilizing E's module
  52. > system, which is not the way it was meant to be used. Not surprisingly
  53. > smaller problems start to weight heavier, and have little to do with
  54. > real large scale programming features.
  55.  
  56. The majority of Photogenics E code was written before the module system 
  57. was available to us :-) We've never got round to splitting it up much (it 
  58. is in 3 modules now)
  59.  
  60.  
  61. > The one-error thing is indeed one of the bigger design errors in EC,
  62. > and like some other features too much targeted at myself as a user
  63. > (I only get errors from EC each tenth run or so).
  64.  
  65. That is my most particular 'hate' with E, decent error reports would be 
  66. most handy (and if the syntax in a multiline statement is wrong, it would 
  67. be really nice if the actual line with the error could be shown, not the 
  68. start of the multiline statement - we have some *huge* multiline 
  69. statements - such as our CreateMenu :-)
  70.  
  71. > That's because of your fixed C perspective. remember? I bet you'd be
  72. > bald by the time you tried several other languages ;)
  73.  
  74. I've written code in many languages, Pascal, C, C++, Prolog, many 
  75. BASIC's, 680x0, Z80 and, of course, E. I don't really think any language 
  76. is 'best', I can think of bad points about every single one. That doesn't 
  77. mean I want to go out and write something better though, I'm quite happy 
  78. sticking with the one that's 'least worse', and at the moment for my work 
  79. on the Amiga that's C, and on the PC, C++.
  80.  
  81. > Geesh. I beg to differ. I think it's quite a bit easier, thanks to its
  82. > logical structure (it's there, look real hard! :).
  83.  
  84. That's your perogative :-) 
  85.  
  86. > It can be done of course, but it involves hairy things like dragging an 
  87. > E
  88. > environment around.  If you insist on rewriting the main program in C 
  89. > and feel
  90. > like keeping some E code around, might I advice you look into EC's 
  91. > .library
  92. > linker?
  93.  
  94. Yes, I think that may be the best way to do it, I'll check out the EC 
  95. .library linker.
  96.  
  97. I understand the problems with EC using a different module format, and 
  98. yes, garbage collection would be a problem. But it could have been 
  99. designed originally to work with standard object files, and workarounds 
  100. could have been put in for garbage collection anyway. From the way you 
  101. describe how it works it may be too late now to engineer .o support in, 
  102. which is a pity.
  103.  
  104. Jolyon
  105.