I really do think that pointing students to an unmaintained language implementation (regardless of the pedagogical reasons) has negative consequences for the functional programming community as a whole.
If it works, maintenance doesn't matter. So, I assume the real concern is that Hugs isn't evolving. To put it in the worst light, this may be read as a complaint that Hugs doesn't keep up with some party line. I would hate to think that the "community as a whole" is that conformist. The disdain for "pedagogical reasons" brushes aside an implicit wakeup call to the community. Hugs is attractive because it is well described and bounded, whereas Haskell realized in GHC lacks a coherent description and presents a myriad of often inscrutable faces. To the extent that the community is defined by such an artifact, it has turned away from educators, not vice versa. Learning how to wrangle a marvelous, but cantankerous, beast should not be confounded with initiation to the insights of functional programming. Doug McIlroy
On Thu, Apr 14, 2016 at 9:35 PM, Doug McIlroy
The disdain for "pedagogical reasons" brushes aside an implicit wakeup call to the community.
I use GHC 7.10 to teach Haskell for pedagogical reasons. There is no consensus on the pedagogical virtue of the most recent changes to the compiler and base libraries, but a good portion of us happen to prefer and achieve apparently good results teaching post-AMP, post-FTP Haskell with various GHC extensions.
Hugs is attractive because it is well described and bounded, whereas Haskell realized in GHC lacks a coherent description and presents a myriad of often inscrutable faces.
Haskell 98 has many qualities that can be understood as shortcomings resulting from historical accidents, and the current realization of Haskell in GHC fixes several of those. Yet more arguable infelicities are solved by teaching to a certain set of language extensions, some even quite recent. Avoiding these problems has pedagogical benefits. Although precise, coherent descriptions are available for Haskell 98 and Haskell 2010 for reference in the Reports, the documentation shipped by GHC for many language extensions is often reasonably close in precision and coherence, as far as many students are concerned — and, more importantly, the learning process for a student rarely involves consuming a precise, coherent definition, and often involves a greater degree of experimentation and consumption of explanations aimed to teach, not to serve as reference for language implementors. I do not aim to suggest that standards are not useful —they surely are—, but standards are of limited use to many students.
Learning how to wrangle a marvelous, but cantankerous, beast should not be confounded with initiation to the insights of functional programming.
In any case, an initiation to the insights of functional programming surely must not begin with a general-purpose programming language adequate for industrial application, but rather with a discussion of the nature of functional programming supported by a review of the theory upon which it is founded: at the very least, the lambda calculus, preferably along with some basic ideas from type theory. Programming in a number of concrete languages is helpful for this: some modern descendent of LISP, perhaps some proof assistant over a functional language, and indeed, some Haskell. If these students are to become industrial practitioners, it serves them well to teach GHC Haskell to illustrate one facet of the complex industrial side of functional programming. This, indeed, is not quite adequate for the most basic bits of an initiation — and that is fine.
On 15/04/16 4:16 pm, Manuel Gómez wrote:
Although precise, coherent descriptions are available for Haskell 98 and Haskell 2010 for reference in the Reports, the documentation shipped by GHC for many language extensions is often reasonably close in precision and coherence, as far as many students are concerned — and, more importantly, the learning process for a student rarely involves consuming a precise, coherent definition, and often involves a greater degree of experimentation and consumption of explanations aimed to teach, not to serve as reference for language implementors.
I do not aim to suggest that standards are not useful —they surely are—, but standards are of limited use to many students.
I'm reminded of a Prolog textbook that was written with much thought and care, diligently adhering scrupulously to the then-current draft of the ISO Prolog standard, and tested in a Prolog implementation written to conform to it. The book ended up being useless because the standard changed to be somewhat less of a complete break from the past, so eventually there were *no* Prolog systems compatible with the book. Students themselves mostly do not know or care what the standard is. What they *are* affected by is whether their teaching materials agree with the implementation they are using.
Very well put! -----Original Message----- From: Haskell-Cafe [mailto:haskell-cafe-bounces@haskell.org] On Behalf Of Doug McIlroy Sent: 15 April 2016 03:05 To: haskell-cafe@haskell.org Subject: Re: [Haskell-cafe] Hugs
I really do think that pointing students to an unmaintained language implementation (regardless of the pedagogical reasons) has negative consequences for the functional programming community as a whole.
If it works, maintenance doesn't matter. So, I assume the real concern is that Hugs isn't evolving. To put it in the worst light, this may be read as a complaint that Hugs doesn't keep up with some party line. I would hate to think that the "community as a whole" is that conformist. The disdain for "pedagogical reasons" brushes aside an implicit wakeup call to the community. Hugs is attractive because it is well described and bounded, whereas Haskell realized in GHC lacks a coherent description and presents a myriad of often inscrutable faces. To the extent that the community is defined by such an artifact, it has turned away from educators, not vice versa. Learning how to wrangle a marvelous, but cantankerous, beast should not be confounded with initiation to the insights of functional programming. Doug McIlroy _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe This email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please delete all copies and notify the sender immediately. You may wish to refer to the incorporation details of Standard Chartered PLC, Standard Chartered Bank and their subsidiaries at http://www.standardchartered.com/en/incorporation-details.html Insofar as this communication contains any market commentary, the market commentary has been prepared by sales and/or trading desk of Standard Chartered Bank or its affiliate. It is not and does not constitute research material, independent research, recommendation or financial advice. Any market commentary is for information purpose only and shall not be relied for any other purpose, and is subject to the relevant disclaimers available at http://wholesalebanking.standardchartered.com/en/utility/Pages/d-mkt.aspx Insofar as this e-mail contains the term sheet for a proposed transaction, by responding affirmatively to this e-mail, you agree that you have understood the terms and conditions in the attached term sheet and evaluated the merits and risks of the transaction. We may at times also request you to sign on the term sheet to acknowledge in respect of the same. Please visit http://wholesalebanking.standardchartered.com/en/capabilities/financialmarke... for important information with respect to derivative products.
participants (4)
-
Augustsson, Lennart -
Doug McIlroy -
Manuel Gómez -
Richard A. O'Keefe