what’s the appeal of haskell? (this is a genuine question.) i’ve been a bit curious about it for a while but haven’t really found the motivation to take a closer look at it.
purely functional paradigm (immutable data structures and no shared state, which is great for e.g. concurrency) and advanced type system (for example you could have linear types that can be only used once). Lisps build on the premise that everything is data, leaving little room for bloated data structures or tight coupling with call chains that are hard to maintain or test. In Haskell on the other hand, everything is a computation, hence why writing it feels more like writing mathematical equations than computer programs somehow. It might, along Scala be good for data-driven applications.
Also the purely functional syntax means that on average, functional programming languages will arrive at the same solution in approx. 4 times less LOC than procedural/OO according to some research. Just look at solutions to competetive programming problems.
And even though I’m not a big fan of opinionated frameworks, compare some Phoenix codebase to a Symfony or even a Rails one to see how much cleaner the code is.
But if you’re new to FP you should rather pick Scheme, Elixir or Clojure since the paradigm itself can be a little bit hard enough to wrap your head around at first (though Elixir and is a bit imperative, depends on how deep are you ready to dive in), not to mention having to learn about ADTs and category theory.
My favorite feature is how currying is applied literally everywhere. You can take any function that accepts 2 args, pass in a single arg and return a new function that accepts one arg and produces the result. In Haskell, this is handled automatically. Once you wrap your head around using partially applied and fully saturated functions you can really start to see the power behind languages like Haskell
It’s been noted that functional code accumulates less bugs, because there’s no way to accidentally change something important somewhere else, and Haskell is the standard for functional languages. Also, it might just be me, but the type system also feels perfect when I use it. Like, my math intuition says there’s no better way to describe a function; it’s showing the logic to me directly.
Where Haskell is weak is when interactivity - either with the real world or with other components - comes up. You can do it, but it really feels like you’re writing normal imperative code, and then just squirreling it away in a monad. It’s also slower than the mid-level languages. That being said, if I need to quickly generate some data, Haskell is my no-questions go to. Usually I can do it in one or two lines.
Out of curiosity, what kind of data do you generate with Haskell? And would be willing to show an example of a one or two liner that generates the data? 🙏
It looks like I was last searching for 12-member sets of permutations of 7 which come close to generating every possible permutation of seven elements, as well as meeting a few other criteria, for an electronics project. It ended up being more like 10 lines plus comments, though, plus a big table generated by GAP, which I formatted into a Haskell list using probably a line of Haskell plus file loading.
Unfortunately for providing code, me playing with the finished algorithm has eaten up my whole 100 lines of history. So, here’s a two-liner I posted on Lemmy before, that implements a feed-forward neural net. It’s not exactly what you asked for, but it gives you an idea.
In practice, you might also need to define relu in another line:
relu x = if x > 0 then x else 0
Edit: No wait, I think that was a different problem related to the same project. There’s another module attached that generates all permutations of n items. After breaking it up so it’s a bit less write-only:
<span style="color:#323232;">allPermutations :: Int -> [[Int]]
</span><span style="color:#323232;">allPermutations 1 = [[0]]
</span><span style="color:#323232;">allPermutations n = concat $ map (addItem $ allPermutations (n-1) ) [0..(n-1)]
</span><span style="color:#323232;">
</span><span style="color:#323232;">addItem :: [[Int]] -> Int -> [[Int]]
</span><span style="color:#323232;">addItem old new = map (y -> new : map (fitAround new) y) old
</span><span style="color:#323232;">
</span><span style="color:#323232;">fitAround :: Int -> Int -> Int
</span><span style="color:#323232;">fitAround n y
</span><span style="color:#323232;"> | y >= n = y+1
</span><span style="color:#323232;"> | otherwise = y
</span>
I just recently read the man page for GNU Parallel, and that seems like a pretty nifty tool to generate permutations of data as well. It’s command-line so great for scripts, utilizes many cores, quick to do without mind-bending Haskell project setup, etc…, for anyone interested. 🙂👍
I’ll look into it, although this probably wasn’t directed at me. GHC can compile multi-threaded, and “setup” here was just opening GHCi and starting, and then moving it into files once it got large enough I didn’t want to repeat the work, so I’m happy.
I still haven’t been able to learn project setup with Haskell and know exactly what I’m doing lol. But I’m glad you have a working setup! But yeah, do look into parallel if you want, maybe it can prove useful, or not. It was directed at you, considering your use case of generating permutations. :-)
I learned some Haskell. Did some problems on Advent of Code and such. But since then I’ve heard about OCaml, which seems super interesting. Hopefully the tooling is simpler, but I’ve not had time to try anything yet.
I never looked into this, so I have some questions.
Isn’t the overhead of a new function every time going to slow it down? Like I know that LLVM has special instructions for Haskell-functions to reduce overhead, but there is still more overhead than with a branch, right? And if you don’t use Haskell, the overhead is pretty extensive, pushing all registers on the stack, calling new function, push buffer-overflow protection and eventual return and pop everything again. Plus all the other stuff (kinda language dependent).
I don’t understand what advantage is here, except for stuff where recursive makes sense due to being more dynamic.
Some languages have to optimize it with various tricks. There’s a good reason why I call heavily functional “programmer wankery”. It took me a while to run into an issue that was caused by a variable modified in a wrong way, which I fixed by saving the value of the variable before a call that seems to alter it. Probably I should have instead properly fix it so I could understand the actual root cause, but I have limited time to spend on things.
They aren’t talking about using recursion instead of loops. They are talking about the map method for iterators. For each element yielded by the iterator, map applies a specified function/closure and collects the results in a new iterator (usually a list). This is a functional programming pattern that’s common in many languages including Python and Rust.
This pattern has no risk of stack overflow since each invocation of the function is completed before the next invocation. The construct does expand to some sort of loop during execution. The only possible overhead is a single function call within the loop (whereas you could have written it as the loop body). However, that won’t be a problem if the compiler can inline the function.
The fact that this is functional programming creates additional avenues to optimize the program. For example, a chain of maps (or other iterator adaptors) can be intelligently combined into a single loop. In practice, this pattern is as fast as hand written loops.
A great point in favour of maps is that each iteration is independent, so could theoretically be executed in parallel. This heavily depends on the language implementation, though.
Imperative for loops have no guarantee at all that iterations could be executed in parallel.
You can do some (usually expensive, and never complete) analysis to find some cases, but smart compilers tend to work the best the dumbest you need them to be. Having a loop that you can just blindly parallelize will some times lead to it being parallel in practice, while having a loop where a PhD knows how to decide if you can parallelize will lead to sequential programs in practice.
Compiler optimizations like function inlining are your friend.
Especially in functional languages, there are a lot of tricks a compiler can use to output more efficient code due to not needing to worry about possible side effects.
Also, in a lot of cases the performance difference does not matter.
I’m not familiar with any special LLVM instructions for Haskell. Regardless, LLVM is not actually a commonly used backend for Haskell (even though you can) since it’s not great for optimizing the kind of code that Haskell produces. Generally, Haskell is compiled down to native code directly.
Haskell has a completely different execution model to imperative languages. In Haskell, almost everything is heap allocated, though there may be some limited use of stack allocation as an optimization where it’s safe. GHC has a number of aggressive optimizations it can do (that is, optimizations that are safe in Haskell thanks to purity that are unsafe in other languages) to make this quite efficient in practice. In particular, GHC can aggressively inline a lot more code than compilers for imperative languages can, which very often can eliminate the indirection associated with function calls entirely. gitlab.haskell.org/ghc/ghc/-/…/generated-code goes into a lot more depth about the execution model if you’re interested.
As for languages other than Haskell without such an execution model (especially imperative languages), it’s true that there can be the overhead you describe, which is why the vast majority of them use iterators to achieve the effect, which avoids the overhead. Rust (which has mapping/filtering, etc. as a pervasive part of its ecosystem) does this, for example, even though it’s a systems programming language with a great deal of focus on performance.
As for the advantage, it’s really about expressiveness and clarity of code, in addition to eliminating the bugs so often resulting from mutation.
So it basically enables some more compiler magic. As an embedded guy I’ll stay away from it, since I like my code being translated a bit more directly, but maybe I’ll look into the generated code and see if I can apply some of the ideas for optimizations in the future.
I looked at the post again and they do talk about recursion for looping (my other reply talks about map over an iterator). Languages that use recursion for looping (like scheme) use an optimization trick called ‘Tail Call Optimization’ (TCO). The idea is that if the last operation in a function is a recursive call (call to itself), you can skip all the complexities of a regular function call - like pushing variables to the stack and creating a new stack frame. This way, recursion becomes as performant as iteration and avoids problems like stack overflow.
Not just calls to self - any time a function’s last operation is to call another function and return its result (a tail call), tail call elimination can convert it to a goto/jump.
That looks like an IBM PC. I recognize it from my childhood years when the father of a friend (who worked for IBM) had one in the early 80’s. That dude is probably as nerdy as he looks. So not a dumb terminal, it’s one of the first home computers.
Yep, looks about right. The photo to too dark to see the .25" drives but with all those boxes, it’s clear it gets use. I can almost hear that damn dot matrix printer though because I had that model one at home as a kid . That thing was LOUD.
Or the satisfying ka-thunk when you pushed the bar on the floppy drive to lock the disk in place. We had a modified one when I was growing up that had a five MB hard drive.
Even if it is a terminal, its connected to a computer. Arguing otherwise is a bit pedantic, its not like he is physically on the computer/terminal either.
Here an image of an old IBM-PC: www.7dayshop.com/blog/…/Ibm_pc_5150-1024x951.jpgNote that The dark area here is for floppy Disks. One to boot from and one for data, so it probably doesn’t have a hard drive. I think it looks pretty much like the one in the meme. Also, computer desks like this were back then very common at home and probably not in offices or universities. Furthermore, he has several boxes with floppy disks beside the desktop. A dumb terminal would have no need for floppy disks, but one of the old PCs would need a lot of them.
So all in all, I think it is most likely a real computer.
True, he is sitting at a terminal - but it appears to be connected to an IBM 5150 or similar. So maybe not so dumb!
Looking at the rest of things more carefully - very likely a 5150, if not definitely. Iconic and hugely popular PC for its era, so it would make sense for sure.
Imagine the sound it made in its days, all those FDD and HDDs, I remember when I got my first PC in 1999, I found the FDD was surprisingly loud, like a dot printer, then my first CD burner, it was as loud as a hair dryer on turbo, fast forward to a few years ago, when I changed my case fans to Arctic P12s and had to double-check if my PC is on because I couldn’t hear it, and now it’s even more quiet because my new PSU funny spin it’s fan in idle, unfortunately my GPU is loud AF when playing games, thinking about repasting it
programmer_humor
Oldest
This magazine is from a federated server and may be incomplete. Browse more on the original instance.