I might give up on Haskell tbh. everything about the language - from reading it, to writing it, to installing and managing its tooling, to looking up documentation - takes so much effort. it’s exhausting to work with
@kasdeya I wish I was more familiar with haskell before replying but I am wondering/maybe guessing you'd agree static analysis is cool in the sense that python has typing but also we get not to care? Typed code really helped me make and maintain software over longer periods so I loved the addition of static analysis ^^ though I dislike it when it slows me down while prototyping, I mostly experience that in c++ and suspect the slowdown is for many many other reasons that are hard to separate xD
@tropicaltrevor yep that’s exactly how I feel! I love typechecking and type annotations in Python and whenever I’m in a language that doesn’t have that I tend to feel a little lost. but it’s really important for me to be able to opt out of that too
the reason why I made my first post was because I ran into a situation where I had written a Haskell function that I was 100% certain would work, but I just could not explain it to the Haskell type system in a way that it could understand. and it kept giving me really arcane type errors - even if I let it infer the type itself
if I were using Python I could just opt out of having type annotations for that function, but Haskell insisted that I figure out what would please it, and I just couldn’t :/
@kasdeya i get it 😅 the way i program in statically typed systems is very much types first, because trying to write code and *then* add types is usually a recipe for disaster
on the plus side, since i've bought totally into static typing, i get to design my programs first through the approximation of types. once that hangs together in a way that makes sense, i can implement the code that the types were an approximation of
@kasdeya there's usually some co-design between the layers (e.g. i'll try out a type, and if that type ends up excluding the behavior i wanted, i'll go back and have a more careful think about how the system should hang together in the first place). and not everything has to be represented in types -- that's why it's an approximation!! i know a lot of people try too hard to make that approximation exact, but that's fighting the strength of types 🫠
@liese this totally makes sense! and it’s actually how I do this in Python too. I’ll start by writing the types and parameter names of the function, then I might write a docstring (which I use almost like pseudocode to tell myself what I want the function to do) and then I write the function itself
although… I’m not exactly an expert at typing yet lol and sometimes I just can’t figure out how to type something so that the typechecker is happy, and I just use Any instead, or some other shortcut hehe. so I feel pretty lost in a language that insists that I figure its type system out
@kasdeya have you seen any of Scott Wlaschin's stuff? like his book "domain modeling made functional" or his website https://fsharpforfunandprofit.com/ ? they're some of my favorite and most recommended resources for getting started with statically typed functional programming. he tries very hard to not use mathematical jargon and explain things in plain english :)
@liese oohh I haven’t but that sounds great for me! I have been meaning to try F# at some point - I think you might’ve been the one who originally recommended it
although now that I look at it a little more, it looks intimidatingly similar to Haskell on the surface. it looks like it has much better documentation though omg - so that’s a huge plus that I really appreciate
I’ll definitely give this site a look when I get the chance, and thanks for mentioning it
@kasdeya i always got the sense that f# was much friendlier overall than haskell... the haskell rabbit hole goes *uncomfortably* deep haha. (and i say that as a haskell user who's never quite sat down with f# properly, only read wlaschin's stuff)