Like a moth to flame, I'm drawn to Haskell every 6 months or so. What drives me to it is its ability to express concepts (once you're used to it) parsimoniously - like the point-free style in the example. Monads, I can understand/manage. But by the time I hit Monad Transformers (and the n different packages available), the excitement turns into a headache.
It's also a bummer that you need the containers package for basic DS. So, batteries not included, unlike Python. This also means that you need to use a package manager (stack or cabal) even for non-trivial programs, where a one-line ghci command line would have been more ergonomic.
That said, learning Haskell has had a very positive effect on how I think about and structure the programs I write in other languages ("functional core, imperative shell"). I don't think I'll ever program in Haskell in any semi-serious capacity. But these days, I get my daily functional fix from using jq on the command line.
Back a decade+ ago when I was still using Microsoft in a corporate environment, I found F# and loved it because it changed how I thought about programming (in a very good way) with its being very concise, allowing me to naturally express algorithms, and giving the "functional core, imperative shell" functionality one can't get in the old-and-new-school VS.NET solution sets that comprise a tiered client-server WCF-based model (thanks in large part to the utterly brilliant Juval Lowy's IDesign approach).
Unfortunately, F# was very much a second-class citizen in the VS.NET space, so it was only useful for banging out tight C# classes in F# first, then translating them over to C#. (My fundamental db access classes were developed in F# then translated to C#; the crux were a parallel pair of isomorphic classes that did design-time swappable DB2 and SqlServer access.)
Beyond my refusal to use Microsoft for my OS anymore, it looks like F# has transitioned away from the original Don Syme authored minimal OCaml-based v2, into much more automagical v3+ stuff that I'm not interested in. They're a brilliant design team, but well beyond what I need or want for my needs.
At the end of the day, it's hard to keep things simple, yet effective, when the tool designers we depend on are always one-upping themselves. Somehow, it seems like a natural divergence as design tooling expands to meet the our expanding needs as devs. What's good is that our perspective gets levelled-up, even if the tools either out-evolve our needs/desires or just plain fail to meet them.
Or perhaps Computation Expressions? But those are an integral part of F# and one of the key reasons why it's so flexible and able to easily keep up in many areas with changes in C# - something that require bespoke compiler modification in C# is just another CE* in F# using its type system naturally.
If you want to get back to F#, it has gotten really easy to do it because .NET SDK is available in almost every distro repository (except Debian, sigh) - i.e. `brew install dotnet`/`sudo apt install dotnet9`.
Thanks for the links and help. That's really excellent.
Still, I'm old enough to remember "embrace and extend and extinguish" so I keep Microsoft off my linux boxen. I reject their corporate mandate and the directions their profit-motive has taken them. Besides, I wouldn't ever want my Unix systems to depend on their software's security.
This criticism could be very well placed against Google nowadays.
While at it, please ask Golang team to change YouTube policies.
You may also want to avoid Rust, Java, TypeScript, C and C++. For they too are """tainted""". For good measure, VS Code must be avoided at all cost and, which is terrible news, probably the Linux kernel itself.
Yeah, I'm not a fan of Google at all. I like companies that keep "don't be evil" in their Mission Statement.
No Rust here.
Never cared for Java, its generics were crap, then .NET v2 was here with F# and, welp, Java's boxed ints were crap, too, so nope.
No TypeScript. Javascript was built in a week (or something); ubiquity is not to be confused with good design. So, no node, too, in case you were curious.
C and C++?!? I used C in 1990 in OS class recompiling the Minix kernel for assignments. No Microsoft there, bro.
VS Code is not welcome in my home, either.
No Linux kernel? No biggie, I prefer OpenBSD anyway. Does it run vi, C/C++, and Python3? Of course it does. I'm good to go, dude.
I hope you enjoy your adware version of Windows, which is going to be ALL versions of Windows.
For better or worse, it's time to realize it's not the 90s, 00s or even 10s anymore.
I use macOS as a main device with Linux and Windows for verifying and measuring behavior specific to their environment, while doing so from VS Code. I have a friend who has his home server farm hosted on FreeBSD, still using .NET. Oh, and luckily most of the tools I use are not subject to ideological and political infighting.
I like when the technology can be relied on being supported in the future and be developed in a stable manner without sudden changes of project governance or development teams. The added bonus is not having to suffer from the extremely backwards and equally sad state that Python and C/C++ find themselves in tooling-wise. Python is somewhat fixed by uv, C/C++ - not so much.
Unless you boot to terminal, while taking advantage of Microsoft contributions to the Linux kernel, Mesa is the thing that allows your graphics desktop to take advantage of your graphics card.
Are you sure none of the binaries being used by you wasn't implemented in Rust.
By the way, the Rust contributions to the Linux kernel are mostly driven by Google and Microsoft employees.
Maybe something to do with autodiscovering, autogenerating, and then utilizing interfaces over the net. I never used it, but watched a couple of the F# guys' vids about it. That's the extent of my involvement, but that was 10+ya, so my memory is a bit fuzzy.
As the comment below alludes to, how many people are just going to import requests as r and then break something else instead of just hitting the client?
In the case of Python, both you the developer and the users need all these packages installed. So it's trouble in perpetuity. The saving grace with Haskell is that it compiles to native binary, so only the developer takes the bullet.
It's also a bummer that you need the containers package for basic DS. So, batteries not included, unlike Python. This also means that you need to use a package manager (stack or cabal) even for non-trivial programs, where a one-line ghci command line would have been more ergonomic.
That said, learning Haskell has had a very positive effect on how I think about and structure the programs I write in other languages ("functional core, imperative shell"). I don't think I'll ever program in Haskell in any semi-serious capacity. But these days, I get my daily functional fix from using jq on the command line.