"I don't remember learning being as difficult as the claims on this thread. (Memory can deceive, I guess.)" Yes, it can. What really matters for that question is quantification. How hard was it for other people a decade ago? How hard is it now? What kinds of people were learning a decade ago? What kinds of people are learning now? Without measures, you're just offering anecdotal evidence. You say that Haskell is having problems because it wasn't true to the faith of "Avoid success at all costs". I always thought that was supposed to be a wryly paradoxical statement of strategy, not an "objective"; it was an impishly witty design-methodology heuristic, not a hymn. Perhaps I'm misreading the community spirit at Haskell Foundation, but it seems the tune shifted a while back. You feel that the wrong kinds of people are learning Haskell now, that it's "adopting" too many problem children. Thank you for your generous offer to help me dig myself out of the hole you said I dug for myself, though I can't understand why. After all, you've made it clear that you think I'm a problem child. How else to explain why you distorted what I've said elsewhere, in your summary of my positions, when you could have just linked to my actual words, in archives, and let them speak for themselves? "This juvenile delinquent has got Haskell all wrong -- stop him before he vandalizes again!" But I suppose it's just in your humanitarian nature to help even us juvenile delinquents. Still, are you sure you don't have things upside down? I'm afraid I can't offer much to you, from the way I feel the direction of gravity.

From where I am, I think the only thing I can send downward to you is a shovel full of dirt.

Is GHC part of the problem? I'm pretty sure of that. Are lots of people getting Haskell wrong? That's symptomatic, at least. Has Haskell gotten too big. I wouldn't be surprised. Should more mathematical approaches be emphasized? I'm not against it, as long as there's emphasis where it's due -- for some Haskellers coming up, it may be better to bring in the math later, when they are already feeling certain patterns in coding but don't quite know how they can be concisely and rigorously expressed, and applied. But over and above all that, you can't learn Haskell by sitting with a reference manual, and trying things out in GHCI. Nor can you learn it very easily by studying relatively mature code. And if "avoiding success" means a book is giving examples that don't work anymore, that's more frustration for readers who are already feeling the steepness of the learning curve. People who want to learn need better things to read. What's "better"? It'll vary according to the reader. I'm a reader who doesn't need another sermon about, say, the virtues of static types -- I converted to that religion long ago. I'm a reader who keeps the machine level in mind, because I've been on projects where a new release of a product that used to be fast enough is suddenly extremely slow on startup initialization -- e.g., someone rewrote an SQL query in the ORM to be "more elegant" but unfortunately also as if disk-head seeks, platter rotations, and block reads were as virtually instantaneous as, say, a line fetch from L3 cache. The problem isn't overpopulation, it isn't like all those Irish that Reverend Malthus thought should starve to death because, well, they'll just breed out of control otherwise. It's the problem of professionalization, which software has always had. Entry is cheap and easy. Hardly a month goes by that we don't hear of some (supposed) miracle of modern software science from some senior in high school who started a software company. Turnover is high. This means a lot of internal treadmills to retain knowledge of how the code works. Lots of people burn out in ten years -- a ten years that, in other engineering professions, is the point at which you're considered fully seasoned, ready to hit your stride. Why the continuing immaturity? Software hasn't killed a lot of people (yet, he says, scanning the sky nervously for drones.) As long as most software was mostly in corporate information systems, the casualties tended to be only corporate-political. If you were such a casualty, it was a bit like being a player in an MMPORG. You could get "reincarnated" in another division, or another corporation, no matter how ignominious your failure. Not much karmic justice either. Even if you perpetrated fraud, which most financial firms prefer to cover up than prosecute, sending you on, because it would be bad PR to send your case to trial and have customers discover that the firm is not as good about internal security threats as it claims. To some extent, it's the very softness of software that has kept the field so immature. Mistakes are made, but unlike a shifty bridge or a shaky plane, they can be corrected cheaply and (for now) safely -- or at least, any new bugs that your patch introduced are subtler, less frequently manifested, easier to blame on someone else. Or maybe you jumped to another company by the time your code became a problem. Never have to grow up, not me! But one sign of maturity in an engineering profession is that it stops being a priesthood/guild and starts being a public responsibility. And that starts with clear communication, within and beyond the profession. Better tools are nice, of course. But if they are effectively impenetrable to those outside the guild, you're not really solving the problem. A firmer grounding in theory is also very important. But if it's hermetic incantations and thumping of mathematical bibles, that's also not good, clear communication, within and beyond the profession. Haskell has survived what is, for programming languages, a truly staggering infant mortality rate. But what stage of life is it in, now? Who are the models of maturity, for use of Haskell professionally? How can they be elevated to influence, both within and beyond Haskell programmer subculture? Bishops and guild masters were ultimately answerable to feudal lords, and modern institutions that fund software development are significantly feudal, both internally and in their interactions with other institutions. Professionalism confers an advantage: You can speak with the authority of backing from your own institution, its own ethics and values, its own standards -- as long as that profession has proven that it's motivated from a sense of public responsibility. But your profession has to speak clearly, as clearly as possible, on all levels, to maintain itself as an institution, to remain influential -- i.e., from a stance of being IN these feudal mini-worlds but not OF them. This is because, in a way, apart from the brains of its members, clear communication is the only real asset a professional institution has. And that's where better writing comes in. Regards, Michael Turner Executive Director Project Persephone 1-25-33 Takadanobaba Shinjuku-ku Tokyo 169-0075 Mobile: +81 (90) 5203-8682 turner@projectpersephone.org Understand - http://www.projectpersephone.org/ Join - http://www.facebook.com/groups/ProjectPersephone/ Donate - http://www.patreon.com/ProjectPersephone Volunteer - https://github.com/ProjectPersephone "Love does not consist in gazing at each other, but in looking outward together in the same direction." -- Antoine de Saint-Exupéry On Sat, Sep 18, 2021 at 12:40 PM <haskell-cafe-request@haskell.org> wrote:

Send Haskell-Cafe mailing list submissions to haskell-cafe@haskell.org

To subscribe or unsubscribe via the World Wide Web, visit http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe or, via email, send a message with subject or body 'help' to haskell-cafe-request@haskell.org

You can reach the person managing the list at haskell-cafe-owner@haskell.org

When replying, please edit your Subject line so it is more specific than "Re: Contents of Haskell-Cafe digest..."

Today's Topics:

1. Re: Numerics (was: Re: Trouble with asinh) (Jerzy Karczmarczuk) 2. On finding the right exposition... (Viktor Dukhovni) 3. Re: On finding the right exposition... (Tom Ellis) 4. Re: On finding the right exposition... (Monads) (Joachim Durchholz) 5. Re: On finding the right exposition... (Viktor Dukhovni) 6. Re: On finding the right exposition... (Monads) (Brandon Allbery) 7. Re: On finding the right exposition... (Monads) (Viktor Dukhovni) 8. Re: On finding the right exposition... (David Feuer) 9. Re: On finding the right exposition... (Tom Ellis) 10. Re: Numerics (was: Re: Trouble with asinh) (Barak A. Pearlmutter) 11. Re: On finding the right exposition... (Chris Smith) 12. Re: On finding the right exposition... (Albert Y. C. Lai) 13. Re: Haskell reference documentation, laws first or laws last? (Keith) 14. Re: Haskell's "historical futurism" needs better writing, not better tools (Douglas McIlroy) 15. Better writing about Haskell through multi-metaphor learning (Michael Turner) 16. Re: Haskell-Cafe Digest, Vol 217, Issue 16 (Anthony Clayden)

----------------------------------------------------------------------

Message: 1 Date: Fri, 17 Sep 2021 20:31:24 +0200 From: Jerzy Karczmarczuk <jerzy.karczmarczuk@unicaen.fr> To: haskell-cafe@haskell.org Subject: Re: [Haskell-cafe] Numerics (was: Re: Trouble with asinh) Message-ID: <32be9982-6be3-c136-c0b4-7622f3d88404@unicaen.fr> Content-Type: text/plain; charset="utf-8"; Format="flowed"

Le 17/09/2021 à 19:16, Carter Schonwald a écrit :

...

Hey Barak, is Common Lisp the only extant language to take those issues seriously or are there other examples or better ones?

// tan / atan troubles cited by Barak.

Common Lisp??

But even the ugly Python reacts better to such examples:

...

...

...

rr, ii = 1.0e-20+0j, 1.0e-20j

*>>> from numpy import * *

*>>> tan(rr),arctan(rr) ((1e-20+0j), (1e-20+0j))

...

...

...

tan(ii),arctan(ii) (1e-20j, 1e-20j)*

*==*

This works also with cmath (with arctan as atan). **

Jerzy Karczmarczuk

-- L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel antivirus Avast. https://www.avast.com/antivirus