Newsgroups: comp.lang.lisp,comp.lang.scheme
Path: cantaloupe.srv.cs.cmu.edu!das-news2.harvard.edu!oitnews.harvard.edu!purdue!haven.umd.edu!hecate.umd.edu!bloom-beacon.mit.edu!gatech!news.mathworks.com!rill.news.pipex.net!pipex!btnet!btnet-feed2!bhars12c.bnr.co.uk!bcarh8ac.bnr.ca!bcarh189.bnr.ca!nott!kwon!watserv3.uwaterloo.ca!undergrad.math.uwaterloo.ca!not-for-mail
From: papresco@csclub.uwaterloo.ca (Paul Prescod)
Subject: Re: Theory #51 (superior(?) programming languages)
Sender: news@undergrad.math.uwaterloo.ca (news spool owner)
Message-ID: <E5KuJF.A46@undergrad.math.uwaterloo.ca>
Date: Fri, 14 Feb 1997 05:14:03 GMT
X-Newsposter: Pnews 4.0-test50 (13 Dec 96)
References: <3059948144828413@naggum.no> <MPG.d6ba01d9475e4249896a8@news.demon.co.uk> <E5I4EM.1Ex@undergrad.math.uwaterloo.ca> <MPG.d6c5c16f989a7f59896aa@news.demon.co.uk>
Nntp-Posting-Host: calum.csclub.uwaterloo.ca
Organization: University of Waterloo Computer Science Club
Lines: 62
Xref: glinda.oz.cs.cmu.edu comp.lang.lisp:25397 comp.lang.scheme:18628

I think we agree that Lisp will not be mainstream anytime soon, and
perhaps never. I think that we agree that the top teir of programmers
could be better marketed to, although more money is only part of the
problem.

Note that Java has something like closures, so we are at least making
progress. Lisp-ish ideas are becoming mainstream. Guy Steele might
have something to do with that. Perhaps Algol style programming
languages will progress towards Lisp semantics just as the Windows
kernel migrates towards Unix, and functional programming language syntax
will migrate towards that of algol-style languages, just as Unix gets
more and more GUI (slowly!).

>Have you seen Haskell and frameworks like Fudgets and Haggis? I can't 
>comment on Lisp-based frameworks, as I'm only vaguely familiar with 
>one of them. I'd prefer any of 'em to the framworks I've seen and used 
>in C++. I'd prefer the MVC classes in Smalltalk-80 to anything in 
>Java. I don't know CLIM, unfortunately.

I don't doubt that the Smalltalk-80 frameworks are more mature, but I think
that Java is as capable a language of wrapping the GUI objects in 
language constructs as Smalltalk is. I don't think that doing the same
things in functional languages is as "intutive" (loaded word!), but there
may be benefit to doing it that way anyhow. Please describe what you 
see the benefits of functional GUI programming to be. In my mind, once
you are mostly manipulating state (screen objects, database connections,
TCP/IP connections), you might as well move to a language that is designed
to model object states, rather than one that is designed to model functions.

On the other hand, if you are going to argue that you should use Lisp or
Haskell imperatively, then I'll ask: then what benefit do they offer over
Algol style languages? Why not use a language that was designed to be
imperative? I've only preused a Haskell introduction, but my reading
suggested that they jumped through some major hoops to surpress imperative
programming. I have seen it described as "purely functional", monadic I/O
notwithstanding.

I'm looking at the Fugets info, and it sounds like the *added* an object
construct to the language: "Fudget programming is like Object Oriented
Programming in that state information is encapsulated and hidden from
arbitrary use/misuse. The components that corresponds to objects are
called fudgets. State information can be accessed/changed only by sending
messages to the fudget maintaining it."

I also note that many of the benefits ascribed to functional programming
languages in that document also hold for Java: "Higher order functions 
and parametric polymorphism." (and a Java 2.0 with generics would be
even more competitive here) "Automatic memory management", "Type safety".
The two it fails on are "Brief notation" and "Lazy evaluation". Fair 
enough, but not really earthshaking stuff for GUI programming. In ML, the
brief notation seems to be "bought" through a very complex type system
that must be restricted so that the type inferencer can cope. Lazy 
evaluation can be simulated in any language, especially any language with
closures.

Functional programmers may want to look at the proposed "Inner Class"
documentation to see how it compares to closures. 

http://www.javasoft.com/products/JDK/1.1/docs/guide/innerclasses/html/innerclasses.doc.html

 Paul Prescod

