Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!seismo!rochester!costanzo From: costanzo@rochester.arpa (John N. Costanzo) Newsgroups: comp.lang.misc Subject: Re: Problems needed! Message-ID: <395@sol.ARPA> Date: Fri, 26-Jun-87 11:21:10 EDT Article-I.D.: sol.395 Posted: Fri Jun 26 11:21:10 1987 Date-Received: Sat, 27-Jun-87 09:24:21 EDT References: <9819@duke.cs.duke.edu> <6835@beta.UUCP> Reply-To: costanzo@rochester.UUCP (John N. Costanzo) Organization: U of Rochester, CS Dept, Rochester, NY Lines: 95 Summary: No problem. 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!