🚀 go-pugleaf

In article <6835@beta.UUCP> hwe@beta.UUCP (Skip Egdorf) writes:
>In article <9819@duke.cs.duke.edu>, jds@duke.cs.duke.edu (Joseph D. Sloan) writes:
>> 	It's common practice in comparative programming languages 
>> courses to assign the same problem in several different languages to 
>> compare and contrast different features of those languages.
   ...
>> 
>> 	Would folks that have such problems or collections of such
>> problems be willing to share?   Please describe 1) the problem, 
>> 2) proposed languages, and 3) what langage features are being contrasted.
 
>> 				Many thanks,
>> 				jds@duke

>This might provoke some interesting discussion!

>...I would recomend the problem of the self reproducing program.
>This problem is really a joy to play with in the ART side of the house.

>This problem seems to impress the young mind with a strong impression
>of which languages are true power tools for solving problems, and which
>are "more in the problem set than the solution set."

  I'm not entirely sure what this problem shows.  As  a  spare
  time,  have-some-fun, rec.puzzles kind of mind-bending brain
  teaser,  it's  great.   But  it's  really  all  about   some
  coincidental   happenstance   concerning   the   essentially
  arbitrary syntax of a language.  (OK,  before  I  get  flame
  broiled by the language designers out there: the syntax of a
  language is certainly not arbitrary. But this  problem  does
  not  address  any of the fundamental aspects of a language's
  syntax.) I guess I just don't see how this  speaks  of  what
  the  language  buys  you and how you might do things with it
  later on (except in Obfuscated C Contests 8-).

>...it is a very good problem for letting the students discover the fact
>that some languages try to get in your way more than others.

  I don't think it does show much about the power or  ease  of
  use  of  the  language.   I  think more appropriate problems
  might involve aspects that play on  the  strong  suit  of  a
  particular  language.  (So called "rigged contests".) Things
  like implementing record structures and  dynamic  memory  in
  Fortran and then in Pascal (or C). This will demonstrate how
  useful a language's data structuring facilities are.

  How about giving  a  simple  assignment  (like  implementing
  stacks  operations  with  arrays) in, say, Modula-2 and then
  giving a followup assignment to change the implementation to
  use  linked  lists?   The  second assignment, if done right,
  ought to be absolutely trivial -- a matter of changing 3  or
  4  functions and a type definition.  This ought to point out
  how a language might encourage the benefits of modularity.

  Or if we want to talk about how the  syntax  of  a  language
  influences  it's "power", how about something that calls for
  a program to build code on the fly,  like  the  managing  of
  rules  for  a  mini expert system? LISP's uniformity of code
  and data  as  well  as  PROLOG's  code<-->structure  mapping
  functions  would be clear wins here while it would take some
  more thought in other languages.

  I think a good example of a kind of problem *NOT* to  assign
  is  the  standard classic of: ``OK we're going to learn LISP
  today;  LISP  uses  recursion,  here  is  how  you  write  a
  factorial  program (or Towers of Hanoi or quicksort)'' As an
  introductory lesson to recursion this might not be bad,  but
  the  job  of  teaching  recursion  is only half done when it
  teaches HOW. It should also mention WHEN  to  use  recursion
  (and  when  not  to).   An  important point to get across to
  students is  that  just  because  something  *can*  be  done
  recursively,   doesn't   necessarily   mean   ought  to  be.
  Especially if the non-recursive version is as easy to  write
  and  as  clear  to  read,  and  more  efficient.  (The above
  argument  based  on  current  commonly  available   compiler
  technology.  Your mileage may vary.)

  These, I think, highlight  some  interesting  properties  of
  languages. But I'm sure others have better examples.

>				Skip Egdorf
>				hwe@lanl.gov


=John Costanzo
__________
ARPA:    costanzo@cs.rochester.edu
UUCP:    ..!{allegra,decvax,seismo}!rochester!costanzo 
USnail:  CS Dept., University of Rochester, Rochester NY 14627
Phone:   (716)275-7747                        Spoken: Hey You!
-- 
ARPA:    costanzo@cs.rochester.edu
UUCP:    ..!{allegra,decvax,seismo}!rochester!costanzo 
USnail:  CS Dept., University of Rochester, Rochester NY 14627
Phone:   (716)275-7747                        Spoken: Hey You!