home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / comp / lang / tcl / 1217 < prev    next >
Encoding:
Text File  |  1992-08-18  |  3.0 KB  |  68 lines
  1. Newsgroups: comp.lang.tcl
  2. Path: sparky!uunet!eco.twg.com!twg.com!news
  3. From: "David Herron" <david@twg.com>
  4. Subject: Object orientedness & The Customer (tm)
  5. Message-ID: <1992Aug18.170731.12063@twg.com>
  6. Sensitivity: Personal
  7. Encoding:  48 TEXT , 4 TEXT 
  8. Sender: news@twg.com (USENET News System)
  9. Conversion: Prohibited
  10. Organization: The Wollongong Group, Inc., Palo Alto, CA
  11. Conversion-With-Loss: Prohibited
  12. Date: Tue, 18 Aug 1992 17:10:23 GMT
  13. Lines: 53
  14.  
  15. The recent discussion about the limitations of TCL have been interesting.
  16. I've got to agree with most of the points.  From an engineering perspective
  17. that is.
  18.  
  19. However my point of view is not one which looks on this as a research
  20. proposition.  Instead the concern is to make applications where the
  21. customer is not limited by the vision of the people selling the
  22. software.  Or, as Sean said yesterday, to raise the least common
  23. denominator of software.
  24.  
  25. But whatever I do with it must be usable by some version of the
  26. stereotypical End User.  After all, we survive here on what we sell,
  27. not on how many papers we write ;-).
  28.  
  29. As an engineer the comments about how an `object' paradigm to programming
  30. helps to control complexity are right on the mark.  It puts into focus
  31. some of the problems I've had with my own TCL applications.  So far I've
  32. been solving these with careful modularization of data & procedures,
  33. but there's only so far that can go.
  34.  
  35. ..BUT...
  36.  
  37. If one is trying to sell an application with an embedded configuration/extension
  38. language built in, you have to expect The Customer to play with it.  Not
  39. all will, but some will.  And the more who do play with it (to an extent)
  40. the better.  Having an embedded extension language does not limit my responsibility
  41. for creating a good application, but regardless of how good a job an engineering
  42. team does it cannot predict all the things the customer will want to do with
  43. the software they build.  So it is a win/win situation to write the front end
  44. using an interpreted language and let the end user be able to see and play
  45. with the front end if s/he wishes.
  46.  
  47. For this to be of any aid to The Customer they must be able to understand
  48. whatever language we choose to use.  Throwing an Object and Class paradigm
  49. into the language seems to raise the amount s/he must learn before being
  50. able to play with the applications front end.  But that's just `intuition'
  51. and some user-factors research might prove me wrong.  Especially if it was
  52. presented well with something to make the class structure obvious.
  53.  
  54. I'm open to persuasion here ...
  55.  
  56.  
  57. BTW, I have to agree with most of Sean's comments.  TCL/TK has been a breeze
  58. to work with and I am 100% sold on interactively and iteratively building
  59. the front end to applications.  Now to sell the rest of my group ;-).  Or
  60. maybe find a job somewhere that a new project is starting and they appreciate
  61. the value of the things I've touched on up there ... ;-)
  62.  
  63.  
  64. <- David Herron <david@twg.com> (work) <david@davids.mmdf.com> (home)
  65. <-
  66. <- "Just because I recreate the middle ages on weekends doesn't mean I have to
  67. <- at work." -- me
  68.