"O LANGUAGE DESIGNER, REMEMBER THE POOR USER""
This is interesting (and from 1990): http://groups.google.co.uk/group/comp.lang.functional/msg/655bb7bbd0fd8586 (Not sure if this is well-known. It seems like it either is, or it should be. Either way, I just stumbled across it.)
Here are some choice-quotes that are one of {insightful, controversial,
arguable}:
Starting with my favorite quote ;):
"The ability to operate on the program as data is basic to the provision of
many desirable utilities, e.g. the Boyer-Moore theorem prover, and the
program
transformation work that was based on Hope, not to mention a compiler.
It seems unfortunate that recent functional languages are heteroousian in
the
sense that they are defined in the usual computer scientist's way of
specifying
a syntax, and not specifying a representation of a program as a
data-structure. This is a manifestation of the besetting vice of computer
scientists - they will insist in locking up goodies in a black box..."
On Lisp:
"There is a danger that this perspective will adversely affect the design of
a
language from the user's point of view. The most extreme case is that of
LISP,
which may be seen as a very flawed implementation of the Lambda Calculus,
which preserves the notation rather closely."
On Haskell syntax:
"However, if the use of upper case is not permitted for
ordinary variables a conflict arises between the language conventions and
the
conventions of mathematics,...."
"Haskell is also in conflict with established programming conventions in
that
it it uses double colon to denote membership of a type (e.g. x::Int) rather
than the single colon that those millions of existing programmers will be
familiar with,.."
On Haskell arrays:
"The Haskell array operation is a related construct, from which a instances
of
the application of the POP-11 newarray could be implemented - it does
however
suffer from one practical draw-back, namely it takes an association list as
argument, which makes it inefficient as a means of memoising a function,
unless a very smart compiler is used."
On purity:
"I want a language that is not purely functional because functional
languages do not reflect the basic structure of computers. If you want to
write a matrix inversion algorithm it will be hard to do it efficiently
without assignment."
Matt
On Thu, Apr 16, 2009 at 7:04 PM, Matt Morrow
This is interesting (and from 1990):
http://groups.google.co.uk/group/comp.lang.functional/msg/655bb7bbd0fd8586
(Not sure if this is well-known. It seems like it either is, or it should be. Either way, I just stumbled across it.)
On Thu, 16 Apr 2009 19:04:43 -0500, Matt Morrow
This is interesting (and from 1990):
http://groups.google.co.uk/group/comp.lang.functional/msg/655bb7bbd0fd8586
(Not sure if this is well-known. It seems like it either is, or it should be. Either way, I just stumbled across it.)
Regarding the following quoted portion:
USERS OF FUNCTIONAL LANGUAGES WILL HAVE SOME STRONG PRECONCEPTIONS ABOUT HOW COMPUTATIONS ARE EXPRESSED.
... Since, if a functional language is to be successful, the great body of its users can be expected to be drawn from the millions who have some expierience of Ada, C or Pascal, the conventions pertaining in those languages should have weight in the forms chosen for any functional language where they do not conflict with the essential attributes of the functional language.
Sorry, but I do not agree with this view. Essentially, this means that new functional languages should in some way syntactically resemble Ada, C or Pascal. However, many newcomers to such functional languages as Haskell come from other languages (I myself come from Scheme and T), and requiring Haskell to resemble Ada, C or Pascal would risk alienating such other users. Besides, regarding the premise of "if a functional language is to be succesful," why is it so important that "a functional language ... be successful" in the first place? Both Simon Peyton Jones and Alan Perlis have disagreed on this issue. According to [2] (see http://research.microsoft.com/en-us/um/people/simonpj/papers/history-of-hask...) (see page 10), there are definite reasons for striving to "avoid success at all costs," as follows:
The fact that Haskell has, thus far, managed the tension between these two strands of development [as a mature language, and as a laboratory in which to explore advanced language design ideas] is perhaps due to an accidental virtue: Haskell has not become too successful. The trouble with runaway success, such as that of Java, is that you get too many users, and the language becomes bogged down in standards, user groups, and legacy issues. In contrast, the Haskell community is small enough, and agile enough, that it usually not only absorbs language changes but positively welcomes them: it’s like throwing red meat to hyenas.
Furthermore, to quote [1] below (see the dedication of SICP at http://mitpress.mit.edu/sicp/full-text/book/book-Z-H-3.html), isn't our role supposed to be to "keep fun in computing?"
``I think that it's extraordinarily important that we in computer science keep fun in computing. When it started out, it was an awful lot of fun. Of course, the paying customers got shafted every now and then, and after a while we began to take their complaints seriously. We began to feel as if we really were responsible for the successful, error-free perfect use of these machines. I don't think we are. I think we're responsible for stretching them, setting them off in new directions, and keeping fun in the house. I hope the field of computer science never loses its sense of fun. Above all, I hope we don't become missionaries. Don't feel as if you're Bible salesmen. The world has too many of those already. What you know about computing other people will learn. Don't feel as if the key to successful computing is only in your hands. What's in your hands, I think and hope, is intelligence: the ability to see the machine as more than when you were first led up to it, that you can make it more.''
Alan J. Perlis (April 1, 1922-February 7, 1990)
I had always thought that part of the advantage of Haskell was the ability of being agile enough to experiment. Robbing Haskell of that advantage would seem to kick the fun out of the house. -- Benjamin L. Russell References [1] Abelson, Harold and Sussman, Gerald Jay with Sussman, Julie. _Structure and Interpretation of Computer Programs, Second Edition._ Cambridge, MA: The MIT Press and New York: McGraw-Hill, 1996. http://mitpress.mit.edu/sicp/full-text/book/book-Z-H-3.html [2] Hudak, Paul, Hughes, John, Peyton Jones, Simon, and Wadler, Philip. "A History of Haskell: Being Lazy With Class." San Diego, California: _The Third ACM SIGPLAN History of Programming Languages Conference (HOPL-III)_ (2007): 12-1 - 12-55, 2007. http://research.microsoft.com/en-us/um/people/simonpj/papers/history-of-hask... -- Benjamin L. Russell / DekuDekuplex at Yahoo dot com http://dekudekuplex.wordpress.com/ Translator/Interpreter / Mobile: +011 81 80-3603-6725 "Furuike ya, kawazu tobikomu mizu no oto." -- Matsuo Basho^
participants (2)
-
Benjamin L.Russell -
Matt Morrow