Re: [Haskell-beginners] Doubts about functional programming paradigm

Though this post was prompted by beginners@haskell.org, it seemed pertinent enough for cross-posting to haskell-prime.
I just wanted to make a point that learning haskell is *much* harder than learning most other programming languages
I would not put it that way. One gets so much farther in capability almost instantly with a functional language. I know. At the dawn of functional programming, John McCarthy could teach in one hour everything from cons up to symbol manipulation that would have been a month's project in Fortran. (My account of that hour is at http://www.paulgraham.com/mcilroy.html.) What's hard about Haskell is that its landscape extends into terrains not imagined elsewhere. As long as you stay in the flat Floridian landscape of Fortran et al, you don't need to explore the Himalayas of Haskell. But of course the very exhilaration and inspiration of the high peaks draws one into the "*much* harder" training necessary to surmount them.
the learning aids that are available are not yet cohesive enough to present a clear path ahead for the average programmer.
I agree with this. Alas, there does not exist a definition of the Haskell one reads about on the haskell-cafe mailing list. I treasure my hardcover Haskell 98 report--so rare you can't even find it in the used-book marketplace. Haskell 2010 was obsolete as soon as it was promulgated. Contemporary Haskell as practiced by cognoscenti flaps in a gale of language pragmas. There is no authoritative source about these pragmas. They are listed and described in the GHC User Guide, but that source all too often defines solely by example, not even bolstered by a formal syntax specification. I earnestly hope the newly revived Haskell-prime committee can rectify this state of affairs, and that GHC will provide a compliant implementation. Doug McIlroy

Mr. McIlroy, FWIW I would love to read more about that McCarthy talk. It sounds like an amazing experience.
There is no authoritative source about these pragmas. They are listed and described in the GHC User Guide, but that source all too often defines solely by example, not even bolstered by a formal syntax specification.
I think it would very helpful simply to better (and more rigorously) document the syntax and semantics of the available extensions. There is currently a call to action to update GHC's Haddock documentation in preparation for the 8.0 release [1]. Perhaps some effort can also be directed towards the documentation of the LANGUAGE pragmas. There is still a problem, though: For completeness, one must consider the interactions of the various subsets of these pragmas, some of which are already known to be unsound. What's worse, the number of extant pragmas already makes an enumeration of these subsets impractical, since there are some 10^31 of them even ignoring the "NoX" pragmas. The only long-term solution then seems to be to codify a new Haskell standard that incorporates some known-good subset of these pragmas that the community seems to agree on, which I suppose is part of the task that the Haskell Prime committee has before them. I do not envy them. [1]: https://mail.haskell.org/pipermail/ghc-devs/2015-December/010681.html

I'm firmly with Derek.. we should teach people things like maps, folds and
generic recursion instead of subjecting them to stuff like Java or C++. I'm
not starting a war here, just stating that after 30+ years in software,
mentoring and helping people learn... that, like teaching your kid to read
or play guitar... the magic just happens. They learn and you don't know how
they learned but they take it in and build on it.
By not clouding impressionable learning minds with the gory details for for
loops and such like but instead immediately beginning their programming
lives with maps folds and recursion I think we would be raising the level
of goodness... then maybe Haskell would be taught in schools!
I taught myself prolog a year or three back...thanks to my FP skills,
concepts like recursion were a done deal and backtracking was not that hard
to take on board. Maybe we should teach Prolog as the first language people
ever learn!
Regarding language pragmas. Yes!!! A complete hitch-hikers guide with
information examples would be good. I have often tried to work with code I
find only realise that the author had used the "automatically munge strings
to be the right type" option and not mentioned it.
Whatever. Haskell started in '98, it's 2016 now... it's going to last!
:)
Sean
On 15 December 2015 at 20:13, Rein Henrichs
Mr. McIlroy,
FWIW I would love to read more about that McCarthy talk. It sounds like an amazing experience.
There is no authoritative source about these pragmas. They are listed and described in the GHC User Guide, but that source all too often defines solely by example, not even bolstered by a formal syntax specification.
I think it would very helpful simply to better (and more rigorously) document the syntax and semantics of the available extensions. There is currently a call to action to update GHC's Haddock documentation in preparation for the 8.0 release [1]. Perhaps some effort can also be directed towards the documentation of the LANGUAGE pragmas.
There is still a problem, though: For completeness, one must consider the interactions of the various subsets of these pragmas, some of which are already known to be unsound. What's worse, the number of extant pragmas already makes an enumeration of these subsets impractical, since there are some 10^31 of them even ignoring the "NoX" pragmas.
The only long-term solution then seems to be to codify a new Haskell standard that incorporates some known-good subset of these pragmas that the community seems to agree on, which I suppose is part of the task that the Haskell Prime committee has before them. I do not envy them.
[1]: https://mail.haskell.org/pipermail/ghc-devs/2015-December/010681.html _______________________________________________ Beginners mailing list Beginners@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners

On Wed, Dec 16, 2015 at 1:43 AM, Rein Henrichs
Mr. McIlroy,
FWIW I would love to read more about that McCarthy talk. It sounds like an amazing experience.
No I was not there (in more than one sense!) when that talk happened About the power of scheme being under-appreciated (even by the authors of SICP!) http://blog.languager.org/2013/08/applying-si-on-sicp.html

Lacking intentional syntax for function application is much more profound
than I would have expected.
Cheers,
Darren
On Dec 20, 2015 08:39, "Rustom Mody"
On Wed, Dec 16, 2015 at 1:43 AM, Rein Henrichs
wrote: Mr. McIlroy,
FWIW I would love to read more about that McCarthy talk. It sounds like an amazing experience.
No I was not there (in more than one sense!) when that talk happened
About the power of scheme being under-appreciated (even by the authors of SICP!)
http://blog.languager.org/2013/08/applying-si-on-sicp.html
_______________________________________________ Beginners mailing list Beginners@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners

On Mon, Dec 21, 2015 at 4:57 AM, Darren Grant
On Dec 20, 2015 08:39, "Rustom Mody"
wrote: On Wed, Dec 16, 2015 at 1:43 AM, Rein Henrichs
wrote: Mr. McIlroy,
FWIW I would love to read more about that McCarthy talk. It sounds like an amazing experience.
No I was not there (in more than one sense!) when that talk happened
About the power of scheme being under-appreciated (even by the authors of SICP!)
http://blog.languager.org/2013/08/applying-si-on-sicp.html
Lacking intentional syntax for function application is much more profound
than I would have expected.
Not sure what you mean: Scheme does not have intentional syntax for function application. Neither does Haskell. Both have a reified (or first-classed) function for function-application. Scheme pronounces it 'apply'. Haskell pronounces it '$' This is close but not quite the same as an explicit application syntax: Close because if we have foo x = 2*x we can write Prelude> foo $ (2+5) 14 or Prelude> foo (2+5) 14 Not quite the same because the definition of foo cannot be 'explicitized' to foo$x = 2*x

Much better said. :)
Put my foot in my mouth. I was vaguely accusative where I intended to
allude to comprehension.
There are certain basic connections that had not really ever gelled prior
to reading some of your posts. For example, that function application
itself is obviously a fixed point had me slapping my forehead.
Much taken for granted in my day to day work.
Cheers,
Darren
On Dec 22, 2015 4:49 AM, "Rustom Mody"
On Mon, Dec 21, 2015 at 4:57 AM, Darren Grant
wrote: On Dec 20, 2015 08:39, "Rustom Mody"
wrote: On Wed, Dec 16, 2015 at 1:43 AM, Rein Henrichs
wrote: Mr. McIlroy,
FWIW I would love to read more about that McCarthy talk. It sounds like an amazing experience.
No I was not there (in more than one sense!) when that talk happened
About the power of scheme being under-appreciated (even by the authors of SICP!)
http://blog.languager.org/2013/08/applying-si-on-sicp.html
Lacking intentional syntax for function application is much more
profound than I would have expected.
Not sure what you mean: Scheme does not have intentional syntax for function application. Neither does Haskell. Both have a reified (or first-classed) function for function-application. Scheme pronounces it 'apply'. Haskell pronounces it '$'
This is close but not quite the same as an explicit application syntax:
Close because if we have foo x = 2*x
we can write
Prelude> foo $ (2+5) 14
or
Prelude> foo (2+5) 14
Not quite the same because the definition of foo cannot be 'explicitized' to
foo$x = 2*x
_______________________________________________ Beginners mailing list Beginners@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners
participants (5)
-
Darren Grant
-
Doug McIlroy
-
emacstheviking
-
Rein Henrichs
-
Rustom Mody