Debugging in a strict FP language is pretty much exactly like debugging in an imperative language. Debugging in a lazy FP language requires somewhat different approaches, but still does not have the problems you are implying here.
> In the end, the result is wrong, good luck finding where.
This is not true. If this was true, nobody would be able to build significant things in FP languages.
> Optimization aside, what you code is what the
computer runs.
> But then you end up with something that doesn't
look at all like what your wrote.
No, you can trace code down through the compiler
transformations and generally understand what
is going on at each level of abstraction.
Compilers for imperative languages are just as
"magical".
I like FP but debuggers fail with FP because debuggers are imperative tools. There's a definite miss match in both UI and concept. It's not the fault of FP itself, it's more the fault that we haven't come up with such an interface yet.
If you want an FP debugger the interface has to be able to step by step evaluate an expression. Since FP is just a giant expression, how is it evaluated step by step? Break points will be different and stepping through it will be different as well.
Take for example:
(1 + 2) * 3 + 2
Stepping through it with a debugger would look like this (imagine the expression transforming at each step):
(1 + 2) * 3 + 2
(3) * 3 + 2
9 + 2
11
A break point would look like this (square brackets indicate a GUI marker)
(1 + 2) + [(4 * 6)] + 1
A run until breakpoint will evaluate to this:
(3) + [(4 * 6)] + 1
That's it. Debugging FP is about stepping through expressions. Debugging Imperative programming is about stepping through statements. And the unique thing about "stepping" through an expression is that the expression is getting reduced (aka changing) at every step.
You need a complete UI overhaul for FP to work. This tends to be harder in terms of building a UI, because text by nature is a one to one mapping to procedural instructions as text Lines are equivalent to instructions. However for FP everything can basically be on one line, so text doesn't really fit and thus you actually need a more dynamic UI for a proper FP debugger.
Functional programming doesn't actually compete with imperative programming.
In practice, functional programming is a way of organizing imperative programs. Kind of like how OO is a way of organizing imperative programs.
Almost all applications written in Haskell use the IO monad quite a bit, for example. Large Haskell projects generally use a lot of C libraries, and sometimes even directly include C code for performance sensitive bits.
I think part of the problem is no implementation has an exciting story about writing the "shell" part in a different language. I love love love writing purely functional code. Probably my favorite thing to do. But what a lot people who also like functional programming are missing is writing imperative code in functional languages almost invariably sucks. At the end of the day we all have to write the "shell" part of our Haskell programs, and my programs always end up in a horrific mess of IO, State and other monads.
> writing imperative code in functional languages almost invariably sucks.
I don't agree at all!
Haskell is extremely pleasant for imperative programming.
There's a learning curve for sure, but you get a lot in return. (STM is one small example). I would much rather write imperative Haskell than Python.
It does gets messy when you start writing really low level code (direct pointer manipulation, etc). And it sucks for small scripts (too much project boilerplate, small standard library). But those are the only real pain-points.
> At the end of the day we all have to write the "shell" part of our Haskell programs, and my programs always end up in a horrific mess of IO, State and other monads.
You can very successfully keep nearly all IO at the edges and do the heavy lifting in pure functions if you make it a goal.
Billions of people in this world would agree unreservedly with the sentiment in question. Only a very specific class of people would have a negative reaction to this.
If you don't want to "hang with that crowd" then there's nothing to worry about here w.r.t filter.
I wouldn't read too much into this - this sentiment is quite frequent here by some more vocal members, and HN is very far from being representative of general population (which is very good in this regard, since mankind would be over in 2-3 generations).
I have personally a very different opinion - smart handy balanced successful (in life, pursuit of happiness, usefulness to society) people should have more kids/kids more frequently as they do, of course if they are able to do so physically, emotionally and overall mentally. Why - this world desperately needs more of such people, and instead gets explosion of poor uneducated farmers or basic factory workers.
Quiet average (or under-average) majority never changes much, they listen to what they should think, what is right, cool etc. Decision processes based mostly on emotions, which is always flawed long-term (and mass media abuse this to no end). We as mankind are clearly heading to self-destruction if we continue this trajectory long enough (longer than doomsayers preach but not absurdly long).
Also majority of childless older folks I've met are in one of these categories: 1) physically impossible, didn't want to go through adoption bureaucratic hell; 2) would be OK with kids but didn't meet the right partner during say age 20-45; 3) didn't want them earlier and when decision changed they realized it was too late (I know quite a few guys in this bracket too). Those that made this decision consciously at early age and stand by it till death without regrets are really small minority.
Even those fearing overpopulation are helping shrink it a bit if they have 2 kids max (equilibrium is somewhere around 2.1 IIRC). There are other points but I don't want to end up with article on this topic. Suffice to say, in my view, life is a (short) game that shouldn't be played on easy difficulty (=no kids) to get most out of it.
If that makes me some arrogant a-hole for stating that, because I ruffled some underlying feathers of somebody online is of no concern to me. Being people-pleaser is a shitty life from all possible angles.
I find this phrase "Automatic Currying" that people are using in this thread to be very strange.
It implies that `(add 3)` is being magically converted into `(\x -> (add 3 x))` by some fancy front-end feature.
But no, `add` is just a function that returns a function.
This pattern is core to the entire paradigm of functional programming, all the way down to the lambda calculus.
All functional programming languages are essentially just fancy syntax around lambda calculus. They have different implementation strategies (strict vs lazy), different type systems, and they have been extended with different primitives (floats, operations on floats, etc).
But at their core, they are all just lambda calculus.
In the lambda calculus, there is ONLY functions, and all functions take one argument. There are no tuples. So, multiple arguments are implemented with the pattern in question. For example:
Compiling functional languages to other high-level language s generally has pretty awful performance compared to simple native compilation. Even compiling to C has it's limitations.
The fact that Go has a nice compiler doesn't really help, because the code generated by the functional compiler will have usage patterns that are very different from what the Go compiler is designed around.
You have been intensely socialized to behave like a robot in person. To wear a mask and not do anything that stands out.
People expect this, so doing anything "off script" around other people makes them EXTREMELY uncomfortable. If they are strangers, they usually "filter you out", pretend they don't notice, and create distance. If they are associated with you, they will immediately begin pressuring you to stop in increasingly less subtle ways.
Everything about our social interactions is completely scripted. We are choosing between pre-approved scripts that we learned movies and shows. In our public behavior, we are literally just executing software that has been uploaded to our brains.
You mostly don't notice this because that's all you've ever known. However, if you deliberately force yourself outside the script YOU WILL NOTICE, and you will notice very, very intensely.
As a consequence, most of the "interesting" people that you meet in real life are hiding, taking on the same exterior behaviors as everyone else.
I don't have a big-picture answer for you, but I'll point out that there are a lot of performance-relevant details that are different between the two protocols.
A torrent is basically a filesystem, dumped into a single large bytestring, broken into constant size chunks. Then there is a fairly small swarm of nodes trading those chunks. Most of those nodes are trying to download everything, and want to saturate inbound/outbound pipes.
- IPFS is a single massive DHT for advertising who has what for every single blob in the entire network. Most nodes have a tiny subset of that data.
- IPFS does not use a constant block size.
- IPFS uses a "multihash" instead of hard-coding a specific hash function. This adds parsing time to hashes, and means that hashes are not a consistent size, and they have sizes that don't fit cleanly into words.
Those are just some details that I happen to know off the top of my head, but you start to see the picture. In every architectural trade-off, IPFS goes for the more general thing, instead of the performant thing.
Debugging in a strict FP language is pretty much exactly like debugging in an imperative language. Debugging in a lazy FP language requires somewhat different approaches, but still does not have the problems you are implying here.
> In the end, the result is wrong, good luck finding where.
This is not true. If this was true, nobody would be able to build significant things in FP languages.
> Optimization aside, what you code is what the computer runs.
> But then you end up with something that doesn't look at all like what your wrote.
No, you can trace code down through the compiler transformations and generally understand what is going on at each level of abstraction.
Compilers for imperative languages are just as "magical".