home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #3 / NN_1993_3.iso / spool / comp / lang / forth / 3999 < prev    next >
Encoding:
Internet Message Format  |  1993-01-26  |  2.8 KB
  1. Path: sparky!uunet!spool.mu.edu!agate!ucbvax!mtxinu!sybase!hamish
  2. From: hamish@sybase.com (Just Another Deckchair on the Titanic)
  3. Newsgroups: comp.lang.forth
  4. Subject: Forth and Adaptation
  5. Message-ID: <28370@sybase.sybase.com>
  6. Date: 21 Jan 93 18:17:20 GMT
  7. Sender: news@Sybase.COM
  8. Organization: Sybase Inc, Emeryville CA USA
  9. Lines: 47
  10.  
  11. In article <1j9rt7INNafb@charnel.ecst.csuchico.edu> fish@ecst.csuchico.edu (Kevin Haddock) writes:
  12.  
  13. >Adapting is what Forth is all about.  Forth is the most adaptable
  14. >language that I know of.  The fact that there is an ARMY of C programmers
  15. >working constantly on adapting a less flexible language to new arenas
  16. >while there are relativly few Forth programmers that are not completely
  17. >tied up with more fundamental 'real-world' applications does not make
  18. >Forth any less adaptable.
  19.  
  20. So why *hasn't* Forth adapted? Why *don't* we see armies of Forth
  21. programmers out here in the Real World (tm)? Why doesn't a company like
  22. (e.g.) Sybase use Forth in applications that would seem to be ideal for
  23. Forth? What makes something a "fundamental 'real-world' application"?
  24. And why are so many of them being written in something like Smalltalk
  25. (the Forth for the nineties...) rather than Forth?
  26.  
  27. There's more to adaptation than just having a nifty *language*. It's
  28. not language adaptability that's all important - rather, it's the
  29. adaptability of things (applications, modules, etc) built in that
  30. language that's important, and the adaptability of the programming
  31. tools and environment.
  32.  
  33. Even more important is the ability to let the vendors do as much of
  34. your work as possible - why reinvent the wheel? If a system supplies a
  35. set of networking and (say) windowing functions as a C library or C++
  36. or Smalltalk class hierarchy, you should just plug into these for the
  37. services (and generally can in any of the languages I work with).
  38.  
  39. Similarly, interoperability is a huge issue - if I can't work in all
  40. three of the languages together on the same (large) application or
  41. suite of applications, then I'm screwed.
  42.  
  43. Similarly, if I can't easily use the system-supplied tools on my source
  44. code, then it's not even worth considering the language. The recent
  45. screens vs. files argument was classic - if a Forth source can't be
  46. made to look exactly like a normal text file to my tools (grep, SCCS,
  47. RCS, Envy, etc. etc. ad nauseam), then it's lierally worthless.
  48.  
  49. *Those* are the sort of things that are important in this little
  50. corner of the Real World (tm), where, frankly, even though I was once
  51. a Forth evangelist, I wouldn't even consider it for serious work
  52. now....
  53.  
  54.     Hamish (Long Time Lurker)
  55. ---------------------------------------------------------------------------
  56. Hamish Reid       Sybase Inc, 6475 Christie Ave, Emeryville CA 94608 USA
  57. +1 510 596-3917   hamish@netcom.com  hamish@sybase.com  uunet!sybase!hamish
  58.