home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #3 / NN_1993_3.iso / spool / comp / lang / forth / 4030 < prev    next >
Encoding:
Internet Message Format  |  1993-01-28  |  6.8 KB
  1. Path: sparky!uunet!ukma!bogus.sura.net!howland.reston.ans.net!spool.mu.edu!olivea!charnel!fish
  2. From: fish@ecst.csuchico.edu (Kevin Haddock)
  3. Newsgroups: comp.lang.forth
  4. Subject: Re: Forth and Adaptation
  5. Message-ID: <1k9hjbINN29a@charnel.ecst.csuchico.edu>
  6. Date: 28 Jan 93 21:01:31 GMT
  7. References: <28370@sybase.sybase.com>
  8. Organization: California State University, Chico
  9. Lines: 125
  10. NNTP-Posting-Host: cscihp.ecst.csuchico.edu
  11.  
  12. In article <28370@sybase.sybase.com> hamish@sybase.com (Just Another Deckchair on the Titanic) writes:
  13. >[my stuff deleted]
  14. >
  15. >So why *hasn't* Forth adapted? Why *don't* we see armies of Forth
  16. >programmers out here in the Real World (tm)?
  17.  
  18. Well, as if I didn't already answer that question with my previous post
  19. (which you quoted) how about these 3 letters:  A.T.T.?  Is that
  20. a good enough reason?
  21.  
  22. > Why doesn't a company like
  23. >(e.g.) Sybase use Forth in applications that would seem to be ideal for
  24. >Forth?
  25.  
  26. Is Sun a real enough company for you? What about Federal Express?
  27. How many others are using Forth and not fessing up to it?  I've
  28. heard Apple has used it for some of thier internal projects (maybe
  29. it's hiding in some of thier roms like Sun?)  
  30.  
  31. >What makes something a "fundamental 'real-world' application"?
  32. >And why are so many of them being written in something like Smalltalk
  33. >(the Forth for the nineties...) rather than Forth?
  34. Smalltalk?!?  How about the multi-megabyte overhead of Smalltalk?
  35. How about it's inefficiency?  I'll agree that with specialized hardware
  36. Smalltalk might be an attractive option for low production applications
  37. and/or exploratory (prototype) work.  I think you are talking apples
  38. and oranges here.  With an OO and GUI layer Forth could do what
  39. Smalltalk can do (although you wouldn't necessarily be forced to
  40. use it).  Can you say the opposite is true?  Forth is a FULL BANDWIDTH
  41. language.  You can run while you compile, you can extend it into
  42. any other language (even a user level lexicon) easily.  You can
  43. assemble, inline code, interpret, macro, etc.... What more is there
  44. to say?
  45.  
  46. What makes something a fundamental real-world application in my book
  47. is something that has to get the job done in the real-world with
  48. a minimum amount of monkey motion, both on the computer's and the
  49. programmer's part.  This means not having many megabytes of useless
  50. overhead and wasted clock cycles.  In most applications it is
  51. cheaper just to throw a lot of hardware and 'tools' at the
  52. problem.  But what happens when you want to replicate that application
  53. many times over, or when that application pushes the envelope of what
  54. hard/software is able to do?  It is then that the everything and the
  55. kitchen sink approach falls apart.  The only snag is that less hardware
  56. is cheaper and more reliable (not as much to break down).  Less software
  57. is easier to support and allows simpler, more reliable programs.
  58. >
  59. >There's more to adaptation than just having a nifty *language*. It's
  60. >not language adaptability that's all important - rather, it's the
  61. >adaptability of things (applications, modules, etc) built in that
  62. >language that's important, and the adaptability of the programming
  63. >tools and environment.
  64.  
  65. I disagree wholeheartedly.  I just finished a stint with a language/
  66. environment that 'integrated' everything you needed.  The whole
  67. time I was wishing I could use a minimalist Forth.  Believe me,
  68. the language's adaptability is ALL IMPORTANT!  That is the WHOLE
  69. FORTH CONCEPT.  A small set of really tight tools that fit
  70. together easily rather than a bunch of loose tools stuck together
  71. with chewing gum and bailing wire.  This project was
  72. a nightmare because of all the 'vendors' whose binary layers did
  73. nothing but get in the way.  They did more work on neophyte user
  74. interface and protecting thier asses than they did on helping me
  75. get my job done.  A good vendor that focuses on providing a tight
  76. system with a lot of attention on performance and iterative
  77. loop and one who provides SOURCE CODE is on the programmers side.
  78. These people are providing value for value.  They give you what
  79. it takes to deliver to the customer.  Those who don't provide
  80. the above are just exploiting the programmer by fooling him that
  81. he may actually be able to do the job which is usually not the case.
  82.  
  83. >
  84. >Even more important is the ability to let the vendors do as much of
  85. >your work as possible - why reinvent the wheel? If a system supplies a
  86. >set of networking and (say) windowing functions as a C library or C++
  87. >or Smalltalk class hierarchy, you should just plug into these for the
  88. >services (and generally can in any of the languages I work with).
  89.  
  90. I don't disagree with letting the vendors do most of the work.  I just
  91. question thier ability to be able to debug every line of code that
  92. I might want to use.  I appreciate thier contribution unless it turns
  93. out to be a trojan horse (which is usually the case w/o source).
  94.  
  95. > 
  96. >Similarly, interoperability is a huge issue - if I can't work in all
  97. >three of the languages together on the same (large) application or
  98. >suite of applications, then I'm screwed.
  99.  
  100. I still think performance is still the biggest issue.  If I have
  101. enough performance I can write simpler programs and I don't need
  102. so much interoperability.  I can use direct files instead of b+trees.
  103. I can do brute force lookups instead of 'linear hashes', etc...
  104. Performance is the art to which function can aspire.  Performance,
  105. in the run-time, compile-time, and iterative loop is what counts.
  106. Special purpose simple tools provide that.  General purpose
  107. complex tools do not.
  108. >
  109. >Similarly, if I can't easily use the system-supplied tools on my source
  110. >code, then it's not even worth considering the language. The recent
  111. >screens vs. files argument was classic - if a Forth source can't be
  112. >made to look exactly like a normal text file to my tools (grep, SCCS,
  113. >RCS, Envy, etc. etc. ad nauseam), then it's lierally worthless.
  114. Unix was invented to provide the adequate text processing for languages
  115. with complex syntax and which did not compress well.  C provides some
  116. level of compression (cpp, functions, terse operators, etc...) but not
  117. to the level that Forth does.  I think that what I was trying to say
  118. was that this 'compression' negates the need for most of the tools
  119. you mentioned.  You are welcome to your opinion and I'd hope I'm
  120. welcome to mine.  I personally try to make my code turn out looking like
  121. state tables and charts so maintenance is not a real problem.
  122. >
  123. >*Those* are the sort of things that are important in this little
  124. >corner of the Real World (tm), where, frankly, even though I was once
  125. >a Forth evangelist, I wouldn't even consider it for serious work
  126. >now....
  127. So now you just come around to torpedo the rest of us?  Sounds like
  128. you couldn't hack it to me.
  129.  
  130. -Kevin
  131. fish@cscihp.ecst.csuchico.edu
  132.  
  133. -------
  134. There are no complex problems; only complex solutions!
  135. -------
  136. Bureaucracy:  The process of turning energy into solid waste.
  137.