home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #1 / NN_1993_1.iso / spool / comp / lang / misc / 4096 < prev    next >
Encoding:
Internet Message Format  |  1993-01-08  |  4.0 KB
  1. Path: sparky!uunet!noc.near.net!nic.umass.edu!m2c!jjmhome!smds!rh
  2. From: rh@smds.com (Richard Harter)
  3. Newsgroups: comp.lang.misc
  4. Subject: Re: Assessing a language
  5. Message-ID: <1993Jan8.065819.14682@smds.com>
  6. Date: 8 Jan 93 06:58:19 GMT
  7. References: <nharvey.726365226@probitas>
  8. Reply-To: rh@ishmael.UUCP (Richard Harter)
  9. Organization: Software Maintenance & Development Systems, Inc.
  10. Lines: 105
  11.  
  12. In article <nharvey.726365226@probitas> nharvey@probitas.cs.utas.edu.au (Nicole Harvey) writes:
  13.  
  14. >hi,
  15. >   I posted the following article to another newsgroup, and I was told this had
  16. >been already been discussed in this newsgroup. Did anyone save the responses?
  17. >Is there a FAQ for this newsgroup?
  18.  
  19. >   I am involved in assessing a language. Does anyone know of a standard
  20. >set of problems that I could use to judge the languages compabilities?
  21. >   Can anyone think of a problem that represents a real need in a language?
  22. >For example, we have tested it for the eight queens problem to show that 
  23. >it can do state space searches. We have also made sure it can generate the 
  24. >Fibonacci numbers. Can you think of any other well known problems?
  25. >   What things do you expect to be able to write relatively simply using any
  26. >language? I would like to hear from people working in all areas. 
  27.  
  28. This is a good question.  One standard way to tackle language assessment
  29. is to have a check list of features, e.g.
  30.  
  31. ->    Does it have recursion?
  32. ->    Garbage collection?
  33. ->    Strong typing/Weak typing/No typing
  34. ->    Arithmetic
  35. ->        Machine equivalents
  36. ->        Big nums?
  37. ->        Other
  38. ->    What database access facilities?
  39. ->    User defined types?
  40. ->    Objects?
  41. ->    What intrinsic data structures?
  42. ->    Lazy evaluation?
  43. ->    Application specific features?
  44. ->    I/O
  45. ->        Language intrinsic/Libraries
  46. ->        Ports/handles/file names/file numbers
  47. ->    Access to OS
  48. ->    Level and type of modularity
  49. ->    Syntax structure
  50. ->        Algebraic
  51. ->        Lispish
  52. ->        Stack language
  53. ->        Muddled
  54. ->    Consistency of language syntax?
  55. ->    etc.
  56.  
  57. One trouble with a features check list (besides the inevitable
  58. religious wars) is that it doesn't tell you much about how
  59. convenient or inconvenient the language is to use and what
  60. applications it is really good for.  The merit of a good problem set
  61. is that it puts a language to the test.  The problem set should cover
  62. a wide variety of applications, and yet each problem should be fairly
  63. simple.  Here are some problems for different areas:
  64.  
  65. 1.    General language strength
  66.  
  67. 1.1    Write a program that, when run, prints itself.
  68. 1.2    Write an interpreter for the language in the language
  69. 1.3    Write a symbolic debugger for the language
  70.  
  71. 2.    Arithmetic/mathematical
  72.  
  73. 2.1    Write an FFT library routine
  74. 2.2    Write a matrix inversion routine
  75. 2.3    Write a random number generator
  76. 2.4    Compute pi to one thousand digits
  77. 2.5    Write a Runge-Kutta routine and a Newton/Raphson
  78.     routine that work together as co-routines.
  79.  
  80. 3.    Tree search
  81.  
  82. 3.1    Solve the eight queens problem
  83. 3.2    Write an equivalent of the UNIX find utility
  84.  
  85. 4.    Data record processing
  86.  
  87. 4.1    Read a file of formatted records and print totals for
  88.     specified fields.
  89. 4.2    Read a file of formatted records which has names in one
  90.     field and data in another.  Print totals and name for
  91.     each distinct name.
  92. 4.3    Do 4.1 and 4.2 for various formatting conventions.
  93.  
  94. 5.    String processing
  95.  
  96. 5.1    Read a file created with a text editor such as vi which has
  97.     line feeds after each line.  Prepare this file for input to
  98.     a word processor, i.e. remove line feeds within a paragraph.
  99.  
  100. 5.2    Process a file of text and capitalize the beginning character
  101.     in each sentence.
  102.  
  103. 5.3    Find all words in a file of text that are present in more than
  104.     one case format, e.g. Polish and polish.
  105.  
  106. 6.    Database communication
  107.  
  108. 6.1    Do a query to a database with an SQL interface.
  109.  
  110. This is just a start on a list.  I would be mightily interested in
  111. seeing people improve the list.
  112. -- 
  113. Richard Harter: SMDS Inc.  Net address: rh@smds.com Phone: 508-369-7398 
  114. US Mail: SMDS Inc., PO Box 555, Concord MA 01742.    Fax: 508-369-8272
  115. In the fields of Hell where the grass grows high
  116. Are the graves of dreams allowed to die.
  117.