home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / sys / amiga / programmer / 7053 < prev    next >
Encoding:
Text File  |  1996-08-05  |  4.6 KB  |  108 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: Re: E
  5. Message-ID: <DpJo8z.HrM@cix.compulink.co.uk>
  6. Organization: Compulink Information eXchange
  7. References: <19960407.E196AD0.2D7E@hydra.zrz.tu-berlin.de>
  8. Date: Mon, 8 Apr 1996 13:02:58 GMT
  9. X-News-Software: Ameol32
  10.  
  11. > You may be right there..i'd like more additional, fancy features 
  12. > also..this
  13. > begins with support for different CPUs, optimizing, FPU-support and this
  14. > and that and what do i know else...but this does not mean the language
  15. > is BAD now because some feature is missing....
  16.  
  17. I agree, but support for different CPU's and FPU's is *vital* for a large 
  18. commercial project like Photogenics (and my original argument was that E 
  19. was not suitable for /commercial/ software, and as we're the only people 
  20. who seem to have tried using it for that, I guess I may be right). E is a 
  21. fine language for people to experiment with, to learn the basics of 
  22. programming with (if they're scared of C) and for writing small 
  23. utilities, etc. But it won't replace C (and I don't think Wouter ever 
  24. intended that anyway), and if you're an experienced E programmer I'd 
  25. suggest you take another look at C. Yes, the compiler is slower, but the 
  26. end result code will, in many cases, be better. And as it's only you who 
  27. compiles your code, and people will be running the end result (possibly) 
  28. millions of times, it's better to have one person (the programmer) 
  29. inconvenienced and have the majority (the users) save time in the long 
  30. run with more optimal code.
  31.  
  32. > I think you/we should
  33. > differ between the language as such (which is great work by wouter, it
  34. > makes sense and it's concept is great...) and how the compiler then 
  35. > works...
  36.  
  37. I don't think the actual E language is that wonderful (the expression 
  38. parsing is poor, the lack of strong typecasting can cause no end of 
  39. problems, etc, etc), but I do think that Wouter has done a good job with 
  40. the compiler implementation - full credit for writing a new language and 
  41. building a whole compiler to go with it, it's not easy doing all that on 
  42. your own. I don't like the language very much myself, but that doesn't 
  43. mean I don't respect the amount of work and effort Wouter's put into the 
  44. project.
  45.  
  46.  
  47.  
  48. > What ya mean ? "The compiler"...or "The language" ?! I must admit 
  49. > besides
  50. > of (forced) compiling of some C-sources i have never (thank god) done 
  51. > much
  52. > programming in C....that's because i do not like this much steps of 
  53. > linking,
  54.  
  55. With SAS c, you edit mycode.c and type
  56.  
  57. sc link mycode.c
  58.  
  59. That generates a complete executable for you, one easy step. (and why 
  60. Lattice couldn't have done that years ago I'll never know :-)
  61.  
  62. But there are times you need the power of the linker, especially for 
  63. larger projects. 
  64.  
  65. SAS c is a better compiler than EC. Regardless of my reservations about 
  66. the language itself, EC doesn't produce as good code, for a reasonably 
  67. written piece of E/C. This is no bad reflection on Wouter - it's simply 
  68. that SAS has been developed over many years by many people - EC has been 
  69. developed over less years by one person. 
  70.  
  71. > assembling and general work most C-compilers need for doin' the same 
  72. > what
  73. > is just a keypress in my CygnusED ;) The EC is f***g fast..the 
  74.  
  75. EC is f***ing fast, but it's not my prime concern when writing code. 
  76. Unless i learn how to type 6000 times faster, writing the code will 
  77. always be the slowest part of my programming day. E makes it MORE 
  78. dificult for me by slowing down this process (I don't like being forced 
  79. to use uppercase for this, lower case for that, etc.) - I admit this is 
  80. because I'm used to C and won't be the case if you're used to E to begin 
  81. with. 
  82.  
  83. But speed isn't everything. I'd much rather use a slow compiler with 
  84. better output any day... I guess if you're still using a 68000 computer 
  85. (a500 etc) then SAS may be unbearably slow, but most of us are using 
  86. reasonably fast Amigas by now I'd guess...
  87.  
  88. > Some nice C-example:
  89. > 
  90. >       for(s;e;u) {
  91. >        t;
  92. >       };
  93. > 
  94. > Look at the brackets/syntax and when expressions here get
  95. > executed how often....and explain me the logic behind that ;)
  96.  
  97. C isn't the best language in the world (C++ even more so), but they're 
  98. standard. Any computer language has certain oddities that need getting 
  99. used to (if it doesn't it's invariably a very inflexible language). E has 
  100. oddities, such as the expression parsing, the upper/lower case letter 
  101. requirement of library functions - so KPrintF in E becomes KprintF, 
  102. etc...)
  103.  
  104. But once you've learnt C, you won't need to bother learning a new 
  105. language for a long time, so it's worth the effort :-)
  106.  
  107. Jolyon
  108.