Bringing Euterpea up to date

[madjestic]

Hey Donya,

Is there a chance this repo could be brought up to date? There's a bunch of forks that have fixes for the cabal for example so that it supports the recent ghc/cabal versions. For instance here.

Cheers!

[free-variation]

The basic issue here is the first-time user experience.

I just received the hardback edition of the book -- which, having read the first couple of chapters, seems like an absolute classic in programming, up there with SICP and The Little Schemer.

So my question is, why not enable others to help out here, so that the average student may benefit from this great text by following along with a working system?

[donya]

Hey Donya,

Is there a chance this repo could be brought up to date? There's a bunch of forks that have fixes for the cabal for example so that it supports the recent ghc/cabal versions. For instance here.

Cheers!

I am not averse to updating it, but it's also obvious that the current round of people posting here are not familiar with the history of this library. With the site still down I can't simply point to things there to explain certain things, so I will make a small monologue here.

The first issue is that I need hard proof of significant backwards compatibility for any suggested changes; that means seeing install traces followed by testing features of the library in GHCi AND testing the HSoM library and MUIs along with it. It's a time consuming process*. If you think I'm being paranoid, it is the only way I have avoided the utter mountains of times Euterpea got busted in its earlier days from not being that careful when making changes. Basically I am not willing to just make any changes purely on optimism and wait for potentially even more complaints to pile up.

The next issue is what versions of things people actually use. To estimate user base I have to go based on who contacts me between here and private email about things related to the library. The skew is towards somewhat older things; people using the most recent versions of stuff are a minority. Using things several years out of date is common. I literally still have the odd person asking me how to set up on Windows XP just to put things in perspective. I am willing to support newer versions of things, but not at the expense of at least the middle ground of the versioning ranges I see people asking about.

And finally, with Haskell having turned into a complete wild west messthat it is these days with no more yearly release pattern to develop around...I predict it will break again in short order and then this will start all over again. That's basically why I gave up trying to keep things smooth across newer versions ASAP and switched to only addressing things every 1-2 years. I'd fix it, then something somewhere would get a new version just a few weeks later the new emails would pile in and I'd just have to tell people to use older versions of things anyway. This was far less of a problem for me when Haskell Platform was a thing (and I can't reasonably turn to Stack to solve the stability issues for a few different reasons, the most recent of which is that it apparently doesn't play nice with rural internet connections like mine).

* A broader comment not necessarily aimed at any single person: regarding time, there is a persistent misconception in the functional programming community that I somehow get compensated for efforts related to Euterpea. I do not. I have received $0 from the textbook and have had no funding for anything Euterpea-related for years. Please keep that in mind when voicing any complaints about how Euterpea is managed.

[madjestic]

Thank you, Donya, for caring to give a thorough explanation. The ephemeral nature of IT in principle can be quite a chore, is it even worth chasing the rabbit?

From my understanding the main point is that keeping things up to date may break backwards-compatibility and introduce new bugs. This should not be an issue for a version bump though, right? The user-base may still opt for not using the latest version. The new bugs may and will pop up, however that will not effect the older version, the dev.community, hopefully (and judging by the activity in this repo, demonstrably so) will engage and share the burden of bug-fixing, communicating with the upstream, etc. in relation to the new release.

How do you feel about delegating work related to bug-fixing the new releases to the community?

[free-variation]

Thank you @donya for detailing your position. And of course you're right -- one doesn't want to break backwards compatibility.

There are ways of gaining confidence in a proposed change, however, that don't necessarily rely on extensive manual testing. In other open-source settings (and professionally) I routinely use automated tests, triggered by code updates, that run (hopefully) complete regressions. Such an apparatus could be set up here, and given the value of the book and this library, it seems to me you would be able to attract volunteers to help with the setup and with writing tests. I, for one, would love to help.

[donya]

From my understanding the main point is that keeping things up to date may break backwards-compatibility and introduce new bugs. This should not be an issue for a version bump though, right?

I wish it were the case that version bumps were trustworthy but often they are not. Typically I would trust a 0.0.x type bump but not larger ones. Being very permissive of version numbers caused me lots of headaches in years past.

How do you feel about delegating work related to bug-fixing the new releases to the community?

The library is open-source but I will not be making it open-contribution. If a problem is outstanding and someone in the community comes to me and explains the fix in sufficient detail and/or has done enough testing to convince me, then I take their advice and make the change myself (and usually double check some of the testing). My no-PR policy is not just me being a control freak; it's in response to some things that happened 7 years ago that I do not discuss publicly.

There are ways of gaining confidence in a proposed change, however, that don't necessarily rely on extensive manual testing. In other open-source settings (and professionally) I routinely use automated tests, triggered by code updates, that run (hopefully) complete regressions.

I have been involved with this library since 2008 when it was still Haskore. A colleague of mine attempted to maintain such a test system. It was junked later because it didn't and couldn't span the real-time interactive aspects of things which also happen to be some of the most frequently broken components.

At this point, my posting here is at the expense of fixing the site.

[julmb]

• A broader comment not necessarily aimed at any single person: regarding time, there is a persistent misconception in the functional programming community that I somehow get compensated for efforts related to Euterpea. I do not. I have received $0 from the textbook and have had no funding for anything Euterpea-related for years. Please keep that in mind when voicing any complaints about how Euterpea is managed.

I am sorry if this is off-topic, but I am genuinely curious. This is not a cheap book. It costs $40 on Amazon and $60 on Cambridge Press. If you are not receiving any of that, who is? Is the publisher taking everything? If so, that sounds outrageous.

[donya]

I am sorry if this is off-topic, but I am genuinely curious. This is not a cheap book. It costs $40 on Amazon and $60 on Cambridge Press. If you are not receiving any of that, who is? Is the publisher taking everything? If so, that sounds outrageous.

Indeed off topic, but I will be transparent on this because it the textbook is related to the repos.

I believe any royalties are going to Paul Hudak's estate. That's truly the extent of my knowledge on anything to do with money and that book. I have no idea whether the book even sold enough to result in any royalties. I have no control over the prices and essentially no information about what went on with the book post-publication. I haven't pushed any of those issues and dont' intend to, since it has nothing to do really with why I went through the process of finishing the book.