Thanks Emily, yes let me say straight away John has been entirely respectful and patient in his responses. There are other comments though.
(To go back to your earlier remark:)
In particular, ‘gatekeeping’ is a matter of perceptions. Those long-experienced and ‘inside’ Haskell might not perceive the Haskell community in the same way as newbies who drop in for a ‘taster’ but leave fairly quickly.
Anyhoo, my comment has been disappeared, so I’ll stop.
That would be amazing!
I just hope we can get more of the community rallied around fixing up some of the smaller issues.
Totally agreed.
Here is an early non-strict language implementation:
https://github.com/haskell-implementations/hbc/tree/master
It implemented a simple form of records/named fields:
…are there any volunteers for making this work in Haskell?
No I don’t. In particular I don’t want to threaten type safety, and I’m well aware I’m not expert enough to tell if a proposal might do that, so I defer to those guarding overall integrity of the ecosystem.
The particular decision at hand (and here is not the place to discuss it) is partly something GHC is already supporting (with enough flag settings), partly something it supported in 2006, so it can’t be threatening type safety.
A version (of a non-strict ML-style records/named fields) has been got working by a volunteer in a Haskell.
Heh heh I tried searching for the fake link in that post, first GHit was ‘Is Haskell a dead language’/5 dead programming languages we should never forget.
…and you of all people should know that these days, if it ain’t in GHC, it ain’t anywhere. That’s one reason why dependent types aren’t being implemented in Hugs ;-)
…are we records yet?
With how rare I need proper records I feel like this issue could just be solved with an extension that allows deriving clauses that run Template Haskell without weird splice restrictions. It would solve all the “too expensive to do this everywhere” concerns at the very least.
…or in other words: there’s no such thing as The Average UserTM. But there is a thing called Haskell and like most things, it could be better in various ways. So to all the people who bounced off Haskell “way back in the day” (or more recently): Haskell hasn’t been “staying still” regarding tooling, so grab a copy of the sources that interest (or annoy!) you the most, and join in!
Open source software isn’t just “a spectator sport”…
I completely agree with this comment. Haskell is a great language, but it’s not convenient by any means.
I have a lot more to say, but it’s long, so I decided to split it off into a separate thread:
This is really relevant. Commenting here in general, not specifically to the author. Two thoughts:
Suppose Haskell intentionally avoids those mainstream developers, that huge middle of the curve, those regular folks who don’t care about deep abstraction. If we ignore them, then we’ve sacrificed the largest pool of potential contributors and advocates, and our community remains minuscule.
Compare that scenario with Python: There’s an enormous wealth of large, active packages (graphics, web stacks, databases, pandas, numpy, essentially all of AI, etc.) And we’ve sacrificed the great wealth of a large community, like the rich trove of stackoverflow answers and tutorial blogs with live code samples. Python won because it attracted thousands of talented people.
If Haskell wants to be a narrow niche for the top end, then we should be absolutely clear about it, so that people can rationally choose. Broadly, we shouldn’t waste anyone’s time because that’s the ethical thing to do, and because we avoid creating more anti-Haskell sentiment.
On the inability of a language to satisfy both worlds, we should actively question that assumption. This is a worthwhile topic for the research community. Simple Haskell, NeoHaskell, and related initiatives proves there’s passion and demand for extending the bottom end.
People working in the top end benefit too, if only because the big mainstream now needs and appreciates their expertise! Think of all those career-boosting up-votes!
So if Haskell did satisfy both ends, and if all those mainstream people came here and grew the Haskell ecosystem, isn’t that a win?
https://stackoverflow.blog/2023/07/21/what-its-like-to-be-on-the-python-steering-council-ep-592 (transcript)
…is there a “Haskell [language] Steering Council” (or approximate equivalent thereof)?
FWIW: I don’t believe having a “high ceiling” and a “low bottom” are mutually exclusive goals. We’ve just focused more on “raising the roof” than “getting down with the boogie”… ahem… I think with more effort we can make the language a lot nicer for newcomers and still happily have crazy advanced features like DH.
I myself happily use Haskell all the time without using anything more than ADTs and monads. I only just recently delved into effects systems. I touched lenses once but I usually don’t need them.
…like in a programming-language introductory course: start with the basics, leaving the the more advanced features for later (or another course altogether). For example:
So how “newbie-friendly” is I/O in Haskell?
…perhaps other options for I/O should now be seriously considered.
One thing I’ve proposed is that we should stop saying monads, or at least be more clear as to what we’re referring to.
For instance, are we talking about monadic types (or type constructors, more strictly)? Are we talking about a particular monad instance? Are we discussing Monad, the typeclass? Maybe we’re talking about an essentially monadic form of programming, like JS promises? Or, perhaps, we’re actually discussing category theory.
Be specific; if we must talk about a type as a monad, call it the foo monadic type, if we’re talking about the instance, call it the Monad instance for bar, etc…
Going further than the suggestion in this link:
We should simply stop calling foo a monad whenever possible, and refer to it simply as a type when simply calling it by its name won’t do, and call it a monadic type when we are talking about the set of monadic types. This helps build intuition for the fact that there are many monads, and the commonality is their lawful instancing into the Monad typeclass, but are really quite different (unless you understand them as effect providers).
The other side effect is if learners get taught calling it a monad is wrong, or out of date, they also get instantly disconnected from the monad tutorial ecosystem, building intuition about monadic types at the same time we tell them to stop reading the freaking monad tutorials.
I don’t personally find Monads to be all that scary or difficult of a concept, and (if I may) I don’t consider myself to be particularly smart (im probably quite the opposite). Functors and Monads are just function transformers. I think you can teach the intuition for these concepts pretty easily just using some simple concrete examples like
fmap :: (a -> b) -> f a -> f b
-- concrete
maybeMapper :: (String -> Int) -> Maybe String -> Maybe Int
And so on with some dead simple examples. It’s easy to see the pattern happening here when it’s framed this way.
The only thing that tripped me up when I learned these was that I was so used to OOP, I had this notion of being “inside” of a class, and I couldn’t understand how I could use monad/functor functions without being “inside” of some type of class.
But I believe this difficulty always comes when learning a new concept, it’s no different than learning how to use variables for the first time, or for loops, or functions. I also recall having as difficult of a time (as monads) learning to use functions like foldl.
I have a friend who’s an accomplishment C++ programmer but a bit afraid (or atleast shy) of FP, and when I attempted to teach him monads, his confusion seemed to be more like “that’s it?” I don’t believe he ever internalized the concept but it was only because he felt like there was more to it than I had told him. It was like he was suspicious that I had lied to him and so refused to believe it. Or that it was so simple, it wasn’t worth remembering.
Anyways, my 2¢!
I find myself being very careful at work to say “X admits a Monad instance” rather than “X is a Monad” (and so on for other type classes).
Given that most non-Haskellers think of ‘class’ in an OOP sense; that’s the word we should be avoiding/being careful in our usage just as much as ‘monad’.
Haskell classes don’t encapsulate state; aren’t instantiated per data item. (A data decl inside an instance is a whole 'nother thing.) How do you explain class/instance to non-Haskellers?
“Interface and implementation” is enough to start building a path. That this is not a completely precise mapping has never posed a problem. If they come from a language with “traits”, all the better.
So this stuff isn’t my biggest priority either, which would probably be GHC modularity and build system concerns, but I can only beat that drum so hard without pissing everyone off. In other words, I don’t think I am taking away energy from that my first priorities, but spending energy I would otherwise be blocked spending at all by focusing on more things at once, does that make sense? (For similar reasons, I work on Haskell and Nix things in parallel also.)
I am trying to do this GHC Proposal 448 amending stuff because I think it is is good for Depenent Haskell and (more importantly) it will clean up the language for those that don’t even care about new expressive power.
(Probably the most exciting part for me would actually be deprecating type families; I am quite annoyed about how they work today, and have worked on projects in Haskell which us authors collectively decided to put on hiatus because the language wasn’t good enough (which I personally think was in large part frictions from type families).)
The variable binding rules for pattern signatures indeed have nothing directly to do with signature patterns (though the fact that type families having capitalized names being dubious might bring the two topics closer together), but I view this stuff a puzzle where it takes a number of fine adjustments to get to where we want with a new design that is still coherent. The journey is quite complex!
The build system and modularity stuff that I said was my first priority itself isn’t the end goal either. Really, I don’t like working on end goals much because by the time the benefits are obvious it’s usually much easier to find volunteers. I like instead working on these “yak shaves of yak shaves” where the plot is not at all clear, but far fewer people are interested and thus it seems like me doing or not doing the thing has much greater impact.
(To add more perspective, if the modularity of GHC was really good, I honestly believe @int-index and the other good folks working on DH could just go bang out a pretty complete DH prototype with less work, and then the proposal process could be about reconciling a fork which would make the big picture much clearer. Instead, it is too difficult to just make the thing, and so we have to design and implement as we go, which makes it easy to get snagged on various bikeshed level things, and meanwhile there is no working protoype. So ideally the modularity stuff could just be done first, and then modularity + DH would be less work over all; but it is infeasible to just have the DH work stop and wait for a number of perfectly valid/understandable reasons, so then both much precede in parallel.
@int-index had a blog post a while back which discussed "should we do Dependent Haskell or just work on Agda, with the observation that actually those things converge in that it is easier to compile Agda to a more powerful and similar Haskell than an older Haskell. I think that’s correct, and it is a somewhat related observation. A GHC family of libraries that supports a number of different frontend and backends would be a very powerful piece of software, made wiser by more perspectives, and prevented from “overfitting” any one of them. SPJ himself has similarly long wanted Core to work perfectly well for Strict or Lazy languages.)
