paul@cs.uq.oz.au (Paul Bailes (P.A.)) (03/22/91)
HELP! I am trying to raise the profile of FP in our undergraduate degree in
computing. Having failed to persuade my colleagues that we should move beyond
Pascal(!), I'm trying to get our intermediate-level (2nd year) Functional and
Logic Programming subject made a prerequisite for our advanced-level (3rd year)
Software Engineering project, the grounds being that FP (and LP) are good for
Rapid Prototyping.
PLEASE can anyone supply me with examples/references to
(1) significant examples of use of FP for RP, either academically or
industrially
(2) examples of FP-written RPs that do ``nice'' IO (in order to satisfy
people who think UI prototyping is necessary as well as functional
prototyping.
I've got a number of (1) but very few of (2) - Colin Runciman once showed
me a speadsheet (written in Glide, I recall) but that's about it.
I suggest that replies be posted to the net as
(a) the material should be generally useful
(b) I've got no time (sorry) to collate responses direct to me for summarisation
on the net.
Thanks in advance,
Paul Bailes
(paul@cs.uq.oz.au)paul@cs.uq.oz.au (Paul Bailes (P.A.)) (03/22/91)
In <348@uqcspe.cs.uq.oz.au> paul@cs.uq.oz.au (Paul Bailes (myself)!) writes: >HELP! I am trying to raise the profile of FP in our undergraduate degree in >computing. Having failed to persuade my colleagues that we should move beyond >Pascal(!), I'm trying to get our intermediate-level (2nd year) Functional and >... OOPS! I failed to mention that ``beyond Pascal'' applied to 1st year teaching. Actually, we get around to Modula-2 and C in second year. Apologies to any of my colleagues reading this. Paul Bailes (paul@cs.uq.oz.au)
cl@lgc.com (Cameron Laird) (03/22/91)
In article <348@uqcspe.cs.uq.oz.au> paul@cs.uq.oz.au writes: >HELP! I am trying to raise the profile of FP in our undergraduate degree in . . . >PLEASE can anyone supply me with examples/references to . . . >(2) examples of FP-written RPs that do ``nice'' IO (in order to satisfy > people who think UI prototyping is necessary as well as functional > prototyping. . . . [RP--rapid prototyping; UI--user interface] This relates to a question I've been thinking of posting for the last week. I'll introduce it with a bit of background. I'm very naive about FP; all I know is what I read, 'cause I haven't yet gone to the trouble of setting myself up with an FP environment. I'm a mathematician, and FP sure looks right to me, but I know I have a lot more to learn. My daily work for the last few years has involved a lot of UI considerations. In 1991, I've been Xprogramming. As- sume with me that X is a commercial success, but that event-driven paradigms are a hurdle for many coders and engineers. How do mature FP thinkers react to this? I'm not primarily looking for a textbook reference, although any advice will get my attention. What I want are some down-to-earth words, perhaps on this model: "Sure, the usual model for UI is a dialogue--the user does something, the computer does something, the user does something else, and so on. All this temporal sequencing seems antithetical to FP principles, and of course the usual ways of imple- menting the state of the dialogue make a funny joke in FP circles; however, the way we see it is {FILL-IN-THIS-BLANK}." A postscript: if someone knows what FP environment is free, easy-to-install on a PC or SPARCstation, and good practice for autodidacts, I'm ready to listen. -- Cameron Laird USA 713-579-4613 cl@lgc.com USA 713-996-8546
sean@castle.ed.ac.uk (S Matthews) (03/24/91)
paul@cs.uq.oz.au (Paul Bailes (P.A.)) writes: >... made a prerequisite for our advanced-level (3rd year) >Software Engineering project, the grounds being that FP (and LP) are good for >Rapid Prototyping. >PLEASE can anyone supply me with examples/references to This is interesting. Why do you think that functional programming is good for this sort of thing if you cannot quote evidence from which you have concluded that it is good for this sort of thing (apart from faith---halleluja praise the Lord (Alonzo Church in this case I suppose)). I do not blame your colleagues for being unconvinced. Deciding arbitararily that something is the case, and then looking for evidence to support that proposition is not exactly good methodology. Sean P.S. This is not a criticism of functional programming, just a criticism of a suspect belief system.
rbe@yrloc.ipsa.reuter.COM (Robert Bernecky) (03/26/91)
In article <368@uqcspe.cs.uq.oz.au> paul@cs.uq.oz.au writes: >In <348@uqcspe.cs.uq.oz.au> paul@cs.uq.oz.au (Paul Bailes (myself)!) writes: > >>HELP! I am trying to raise the profile of FP in our undergraduate degree in >>computing. Having failed to persuade my colleagues that we should move beyond Well, at the risk of having tactical nukes directed this way from the Real FP types... I realize that university types involved in language design etc don't have much truck with mundane issues such as Real Life Applications. However, if you look at the ACM SIGAPL proceedings, you'll see a number of articles on such topics as: a. Functional Programming in APL. AI, Games, etc. here. b. APL for Prototyping(APL86 in particular). Hitachi used APL for prototyping a new PL/I compiler, and claims that it shortened development time by 1/3! (If you have ever written a PL/I compiler or even used PL/I, you'll realize how huge a savings this is). c. J: A new dialect of APL, which uses the ASCII character set, and which we hope has discarded a number of design errors we made in APL. J is MUCH more functional than APL ( You can merge two arrays to make a third -- no need for indexed assignment). Recent work by Roger Hui and yrs trly involve Function Arrays, called Gerunds, which make functions first class objects in the language. See earlier work by me in APL84 (SIGAPL Quote Quad vol 14, no 4). Bob
S.Clayman@cs.ucl.ac.uk (03/26/91)
Cameron Laird writes: >> >> I'm not primarily looking for a textbook reference, although >> any advice will get my attention. What I want are some >> down-to-earth words, perhaps on this model: "Sure, the >> usual model for UI is a dialogue--the user does something, >> the computer does something, the user does something else, >> and so on. All this temporal sequencing seems antithetical >> to FP principles, and of course the usual ways of imple- >> menting the state of the dialogue make a funny joke in FP >> circles; however, the way we see it is {FILL-IN-THIS-BLANK}." >> Have a look at %A A. Dwelly %T Functions and Dynamic User Interfaces %R Proc. FPCA 89 %I ACM %P 371-381 %D 1989 >> A postscript: if someone knows what FP environment is free, >> easy-to-install on a PC or SPARCstation, and good practice >> for autodidacts, I'm ready to listen. We use Miranda here. It's not free but we've found it gives good all round behaviour. It has it's quirks but..... stuart
paul@cs.uq.oz.au (Paul Bailes (P.A.)) (03/26/91)
In <9309@castle.ed.ac.uk> sean@castle.ed.ac.uk (S Matthews) writes: >paul@cs.uq.oz.au (Paul Bailes (P.A.)) writes: >>... made a prerequisite for our advanced-level (3rd year) >>Software Engineering project, the grounds being that FP (and LP) are good for >>Rapid Prototyping. >>PLEASE can anyone supply me with examples/references to >This is interesting. Why do you think that functional programming is >good for this sort of thing if you cannot quote evidence from which you >have concluded that it is good for this sort of thing (apart from >faith---halleluja praise the Lord (Alonzo Church in this case I >suppose)). AMAZING! It sounds as if you are saying that the only legitimate grounds for advocating some technique etc. are its prior (satisfactory) uses. How then may someone advocate something innovative? I'm sorry if I have misunderstood you, but your posting is open to this sort of interpretation. >I do not blame your colleagues for being unconvinced. Deciding >arbitararily that something is the case, and then looking for evidence >to support that proposition is not exactly good methodology. Who's decided something arbitrarily? There are criteria other than experience for assessing the merits of a technique (but then, what you said above leaves open the possibility that you disagree). >Sean >P.S. This is not a criticism of functional programming, just a >criticism of a suspect belief system. To what ``belief system'' do you refer? Paul Bailes
dlester@cs.man.ac.uk (David Lester) (03/27/91)
In article <417@uqcspe.cs.uq.oz.au> paul@cs.uq.oz.au writes: > [Does anybody know of RP using FP in Industry?] It has been some while since I worked in industry, but when I was there I was responsible -- with Geoff Burn -- for a distributed implementation of a functional programming language. We chose to formally specify our extension to the G-machine. I claim that without making this executable, it is impossible to validate the design in any reasonable time period. For the record the specification extended over 50 pages [1,3]. I have previously proved correct a small sequential implementation of a functional language. The specification was two pages, the proof was 60 pages and took 12 -- 18 months (see reference [2]). To give you some idea of what would be involved in a formal proof, I jot down some of the points that would need to be considered. (1) Abstract Interpretation: when it was permissable to rearrange the evaluation of sub-expressions. (2) Garbage Collection: Is it correct? How does it mesh with the machine? (3) Evaluation order: The G-machine sometimes performs eager evaluation. e.g. (x:xs) is built directly. This makes it more difficult to prove properties about. This leads to Lester's Hypothesis: "In most industrial applications, a fully formal approach is not cost effective." And as a Corollary: "Executable specifications provide a reasonable compromise between formality and cost." I look forward to the day when this is not the case. David Lester. (Did I really send this from the current home of VDM?) [1] @inproceedings{BURN88b, author = "G.L. Burn", title = "A Shared Memory Parallel {G}-Machine Based on the Evaluation Transformer Model of Computation", booktitle = "Proceedings of the Workshop on the Implementation of Lazy Functional Languages", address = {Aspen\"{a}s, G\"{o}teborg, Sweden}, year = 1988, month = "5--8 September" } [2] @phdthesis{LESTER88a, author = "Lester, D.R.", title = "Combinator Graph Reduction: A Congruence and its Applications", school = "Oxford University", type = "DPhil thesis", year = 1988, note = "{\it Also} published as Technical Monograph PRG-73", } [3] @inproceedings{LESTER89c, author = "Lester, D.R. and Burn, G.L.", title = "An Executable Specification of the {HDG}-{M}achine", booktitle = "Workshop on Massive Parallelism: Hardware, Programming and Applications", address = "Amalfi, Italy", month = "9--15 October", year = 1989 }
sean@castle.ed.ac.uk (S Matthews) (03/27/91)
paul@cs.uq.oz.au (Paul Bailes (P.A.)) writes: >In <9309@castle.ed.ac.uk> sean@castle.ed.ac.uk (S Matthews) writes: >>paul@cs.uq.oz.au (Paul Bailes (P.A.)) writes: >>This is interesting. Why do you think that functional programming is >>good for this sort of thing if you cannot quote evidence from which you >>have concluded that it is good for this sort of thing (apart from >>faith---halleluja praise the Lord (Alonzo Church in this case I >>suppose)). >AMAZING! It sounds as if you are saying that the only legitimate >grounds for advocating some technique etc. are its prior (satisfactory) >uses. How then may someone advocate something innovative? I'm One might say: `Perhaps functional programming languages are a good tool for prototyping software, certainly my personal experience on small programs suggests that they *might* be. I will run some experiments to see if my intuition is good and this is really true.' Or one might say: `I have seen described/worked on several projects where functional programming languages were used more effectively than other approaches that I have seen/used for developing prototypes of software'. But one would not say: `I was told by someone once that functional programming languages are good for rapid prototyping. Let's rearrange the syllabus of the computer science course on this basis.' A suspect belief system is a belief system where things are believed without good reason to think that they are true. It is, of course, possible for a suspect belief system to believe things that are true, but then the first test of a good belief system is that it does not believe anything false, rather than what it believes that is true. Sean
paul@cs.uq.oz.au (Paul Bailes (P.A.)) (03/30/91)
In <9343@castle.ed.ac.uk> sean@castle.ed.ac.uk (S Matthews) writes: >.............. >One might say: >`Perhaps functional programming languages are a good tool for >prototyping software, certainly my personal experience on small programs >suggests that they *might* be. I will run some experiments to see if my >intuition is good and this is really true.' >Or one might say: >`I have seen described/worked on several projects where functional >programming languages were used more effectively than other approaches >that I have seen/used for developing prototypes of software'. >But one would not say: >`I was told by someone once that functional programming languages are >good for rapid prototyping. Let's rearrange the syllabus of the computer >science course on this basis.' Very good, and all true. What's not true is the possible implication that the final, ``would not say'' position is a position that I hold. What makes you think I do, if at all? Who would be so unprofessional? Paul Bailes (PS apologies to other readers for all this, but S Matthews' public comments require a public response. Thanks to all those who have answered my RFI - please keep them coming. PB)