4 ms·

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 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.

thierrydamiba 2y ago
I feel like to use even the most basic python tools I need to use a package manager or find solutions for mix matched dependencies. Is this problem unique to me?
- elbear 2y ago
  Yeah. I feel nobody uses the standard library. Even for stuff like HTTP there is requests.
- reidrac 2y ago
  It all depends. For a quick script that I can write in 15 mins that uses an HTTP client, JSON and joins two APIs together, the standard library is OK. To be fair, it could be almost a bash script (using curl and jq or something like that), but I'm more comfortable with Python. So for one-off (or almost one-off) scripts, the standard library is worth avoiding dealing with dependencies.
  - thierrydamiba 2y ago
    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?
- penguin_booze 2y ago
  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.
tome 2y ago
> It's also a bummer that you need the containers package for basic DS. So, batteries not included Batteries are included, because containers ships with every distribution of GHC, and you don't need to use stack or cabal to expose it: % ghci GHCi, version 9.4.8: https://www.haskell.org/ghc/ :? for help ghci> import Data.Map ghci> singleton 5 "Hello" fromList [(5,"Hello")] Please try the same at your end and if it doesn't work for you then you can let me know and I'll try to help you resolve the issue.
- penguin_booze 2y ago
  Whoa, is this a recent addition? I could be out of touch for a while, TBH.
  - tome 2y ago
    I'm not sure, but I don't remember a time when it didn't work like this.
MrMcCall 2y ago
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.
- FrustratedMonky 2y ago
  I love F#, but haven't used it in a few years. "more automagical v3+ stuff" What is going on with this? Any examples?
  - MrMcCall 2y ago
    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.
  - neonsunset 2y ago
    Perhaps type providers? Sadly they didn't really take off, they work but remain a niche feature. At least I'm not aware if any other feature fits this description closer. https://learn.microsoft.com/en-us/dotnet/fsharp/tutorials/type-providers/ https://learn.microsoft.com/en-us/dotnet/fsharp/tutorials/ty... 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. * with notable exception being "resumable code" which is the basis of task { } CE and similar: https://github.com/fsharp/fslang-design/blob/main/FSharp-6.0/FS-1087-resumable-code.md https://github.com/fsharp/fslang-design/blob/main/FSharp-6.0... 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`. I have also posted a quick instruction on compiling F# scripts to native executables in a sibling comment: https://gist.github.com/neon-sunset/028937d82f2adaa6c1b93899e358e1c0 https://gist.github.com/neon-sunset/028937d82f2adaa6c1b93899...

thierrydamiba 2y ago

I feel like to use even the most basic python tools I need to use a package manager or find solutions for mix matched dependencies. Is this problem unique to me?

elbear 2y ago
Yeah. I feel nobody uses the standard library. Even for stuff like HTTP there is requests.
reidrac 2y ago
It all depends. For a quick script that I can write in 15 mins that uses an HTTP client, JSON and joins two APIs together, the standard library is OK. To be fair, it could be almost a bash script (using curl and jq or something like that), but I'm more comfortable with Python. So for one-off (or almost one-off) scripts, the standard library is worth avoiding dealing with dependencies.
- thierrydamiba 2y ago
  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?
penguin_booze 2y ago
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.

tome 2y ago

> It's also a bummer that you need the containers package for basic DS. So, batteries not included Batteries are included, because containers ships with every distribution of GHC, and you don't need to use stack or cabal to expose it: % ghci GHCi, version 9.4.8: https://www.haskell.org/ghc/ :? for help ghci> import Data.Map ghci> singleton 5 "Hello" fromList [(5,"Hello")] Please try the same at your end and if it doesn't work for you then you can let me know and I'll try to help you resolve the issue.

penguin_booze 2y ago
Whoa, is this a recent addition? I could be out of touch for a while, TBH.
- tome 2y ago
  I'm not sure, but I don't remember a time when it didn't work like this.

MrMcCall 2y ago

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.

FrustratedMonky 2y ago
I love F#, but haven't used it in a few years. "more automagical v3+ stuff" What is going on with this? Any examples?
- MrMcCall 2y ago
  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.
- neonsunset 2y ago
  Perhaps type providers? Sadly they didn't really take off, they work but remain a niche feature. At least I'm not aware if any other feature fits this description closer. https://learn.microsoft.com/en-us/dotnet/fsharp/tutorials/type-providers/ https://learn.microsoft.com/en-us/dotnet/fsharp/tutorials/ty... 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. * with notable exception being "resumable code" which is the basis of task { } CE and similar: https://github.com/fsharp/fslang-design/blob/main/FSharp-6.0/FS-1087-resumable-code.md https://github.com/fsharp/fslang-design/blob/main/FSharp-6.0... 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`. I have also posted a quick instruction on compiling F# scripts to native executables in a sibling comment: https://gist.github.com/neon-sunset/028937d82f2adaa6c1b93899e358e1c0 https://gist.github.com/neon-sunset/028937d82f2adaa6c1b93899...