The longest and the most exhausting discussion for me personally is around the 'base' split and GHC internal modules.
It feels (to me personally) that the discussion is just circling around the same topics with no progress, and it's becoming too difficult to steer it 😞
The most controversial discussion is about adding types like Int8, Int16, Int32, Int64, Word8, etc. to Prelude.
I think the paradigm is pretty distant from Python and more traditional languages. I think someone comfortable with #Haskell may be more comfortable with #Rust, but I've already said more than I know ;)
Any #emacs users that store per-project #comint history using #projectEl? Especially if it's for #haskell and #haskellMode. I don't expect there will be Haskell specific things... but who doesn't like a copy-paste solution 🙃 Any thoughts in general on per project histories with desktop-save-mode?
One piece of advice I offer to younger software engineers (which means pretty much all software engineers, TBH) is to learn #Haskell, even if you never write a line of production code in it. It will help you look at and attack problems in new ways.
@nilmethod sbcl is generally faster than most schemes (but chez certainly gives it a run for its money), but #guile and #chez are incredibly fast in terms of start up and compile times. I read somewhere that chez bootstraps #idris in about 2 minutes, for example (I think #haskell took over 20 minutes when it was the implementation language).
Does anyone have a favourite intro to FFI in #haskell? I've read the stuff on wiki.haskell.org, and the docs for the FFI language extension, but I think I'd benefit from something a bit more opinionated? Maybe a tutorial, ideally using Stack?
Also does the warning about using capi over ccall still agree with received wisdom?
#PureScript is almost the perfect #Haskell replacement. Not only for the things it brings to the table, but also for the things it does not.
I mean actual features missing from PureScript and not gotchas like no historical baggage!
Some examples below. All of them are good for simplicity and newbie friendliness!
No laziness.
Laziness makes it harder to reason about performance. There are easy workarounds for most common usecases for laziness, and employing clever laziness tricks is usually not worth the cost of complicating the codebase.
PureScript's TCO only works in special cases. Normally you wouldn't even need to deal with this because existing implementations of functions like map, foldr etc. are already tail recursion safe. For the rare cases when you need to manually recurse, you can use tailRec and tailRecM to ensure stack safety.
No special syntax or support for linked lists. Strings are not simply lists of chars.
This could potentially be put in the "no historical baggage" category. But I feel that a lot of people, especially newbies, view the special treatment of lists and strings as a plus for Haskell.
However, the focus on lists causes massive confusion for newbies when they are encouraged to use types like Vector and Text in production instead. The special inbuilt syntax also is an active impediment for learning (for example, how do you refer to the higher kinded List type when deriving an instance? It's a mental leap to get to [] in instance Foo [] where).
No special syntax for Tuples.
Much of what was said for lists also applies to tuples. The special syntax is confusing to newbies and causes code complications. For example, each length of tuple is a separate type, and typeclasses in Haskell need to derive instances for each separately. They usually derive instances for tuples only up to length 7.
In addition, it's rarely needed. I am yet to find a usecase for tuples where PureScript's wonderful support for records doesn't suffice. I thought one such usecase was case matching on multiple values (case (v1, v2) of ...), but PureScript supports multi case match for this exact usecase and avoids unnecessary boxing (In PureScript you would write case v1, v2 of ...).
@mousebot but here, I'll give it a shot based on vibes
Plato: #Agda (the Idea of the Good, proto-Maoist non-conformists)
Aristotle: #C (arch reactionary)
Duns Scotus: #ASM (simple brittle concepts but with plenty of haecceity)
Spinoza: #CommonLisp (OG that everyone thinks is fresh bcs its dynamic)
Descartes: #MLIR (ghost in the machine)
Kant: #CPP (critique of Pure C)
Hegel: #Genera (the absolute Idea as self-reflective system)
Nietzsche: #Scratch (the primacy of appearances)
Marx/Lenin: #ML (self-explanatory)
Freud: #GDB (not phil, but rather the original debugger for all the problems of phil)
Heidegger: #forth (the anti-technology technologist's lang of choice)
Wittgenstein: #Prolog (all there is are the facts)
Stalin: #Haskell (forces you to do things "correctly" even when its neither the best option for the situation nor the most performant; the extreme ML)
Lacan: #rr (meta-debugging, non-linear retroactive causality of the signifier, on top of gdb)
Deleuze: #MaxMSP (thinks programming should be art, thinks art is about infinite flows, elaboration of Nietzsche)
Federici: #SpritelyGoblins (super witchey)
Derrida: #AWK (theres nothing outside the text)
Malabou: #Python (everything is neurobiological including language itself)
Badiou: #Scheme (the generic is the Idea of the Good)
Butler: #Rust (the new generation of Kantians doing things right, performatively)
I feel like I shouldn't be this proud of it, but I just wrote a recursive descent parser from scratch in one go in C and debugged a small problem (off by one error of course) using gdb; all in under half an hour.
@clementd They certainly are extremely handy. And apparently these people have even found a way to make them extremely performant, i.e., only about 50% slower than a bison generated parser: https://dl.acm.org/doi/epdf/10.1145/3409002
I didn't do with Haskell much but the attitude around tooling there reminds me a bit of Python about 15 years ago. Tooling existed but if it fails you get 3 different answers, some involving "just write your own solution". (And now with Python we do have too many solutions...)
Has very smart ideas though has trouble moving away from academia.
Its trajectory hasn't been that of Python.
So I have a few thoughts on why Haskell is not more popular.
Haskell sort of dropped the ball by not being more user friendly. This is not about "keeping Haskell simple" - I like the fancy types and advanced features in Haskell and I wish it would get more such features - this is specifically about the community and the new user onboarding experience and how to fix it.
「 It’s true that if you’re managing a software project the choice of tools does matter, but this choice pales in comparison to the following simpler ways to mitigate risk:
Offset the risk using as many legal and insurance instruments possible.
Having a highly liquid talent pool.
Factoring software failures into the expectations and economics of projects.
Learning a #programming language that challenges your notion of what programming is might be one of the most rewarding things once it "clicks" and you start seeing the bigger picture. Whether that's #Clojure, #Rust, #Haskell, #Datalog or whatnot — doesn't really matter. They're systematic, and when you see the system, that's empowering.
I’m (experimentally) extending the hs-all-in-one tool to munge the whole GHC source code into a single #Haskell module. I now have a 680k loc, 41MB file. Doesn’t work yet, still fighting the renamer.
「 As the name suggests, with purely functional programming, the developer can write only pure functions, which, by definition, cannot have side effects. With this one restriction, you increase stability, open the door to compiler optimizations, and end up with code that’s far easier to reason about 」
— IEEE Spectrum
“Hackett is a statically typed, pure, lazy, functional programming language in the Racket language ecosystem. Despite significant differences from #lang racket, Hackett shares its S-expression syntax and powerful, hygienic macro system. Unlike Typed Racket, Hackett is not gradually typed—it is designed with typed programs in mind, and it does not have any dynamically-typed counterpart.” - https://lexi-lambda.github.io/hackett/ #haskell#lisp
I've been learning about Delimited Continuations lately, because I have recently learned that several programming language theory heavyweights, including Oleg Kiselyov, now believe the classic continuation control construct, e.g. "call/cc" in the #Scheme language, were big mistake that make program optimization needlessly difficult, though I don't fully understand why this would be the case. Unfortunately, "call/cc" is encoded in the Scheme language standard, so compiler authors need to come up with work-arrounds -- who knew at the time of the first revision (1975) it would be a bad idea?
Delimited Continuations solve the problems inherent in continuations (again, I don't understand why), and are composable, meaning it is easy to write modular pieces of code using continuations in isolation that can all be made to fit nicely together with a few simple high-order functions.
I had also heard Alexis King give a presentation, who if you don't know is a brilliant young computer scientists who implemented an S-Expression based embedded #Haskell in #Racket called "Hackett" , who was talking about using delimited continuations to improve the performance of Free Monads and the "Monadic Effects" libraries built on top of them. She mentioned that the GHC runtime already provides delimited control primitives. https://www.youtube.com/watch?v=0jI-AlWEwYI