6 ms·
The question is valid if you intend to stick with one paradigm and keep it pure. For any practical purposes, that's useless crap. Nothing wrong with writing th
by yason 8y ago
The question is valid if you intend to stick with one paradigm and keep it pure. For any practical purposes, that's useless crap.
Nothing wrong with writing the gist of your program written in functional way, keeping things immutable, allowing for orderless execution and lazy evaluation. But because your program interfaces with the real, consequential world it must realise all that computation at the pivot points where there is I/O and it suddenly matters that the lazy evaluation is complete.
Have a procedural loop to drive your events and other practical stuff and, from there, launch functional computations to calculate a completely or partially new state for your program. Keep things mostly immutable but do mutation in certain specific locations where it makes sense.
Clojure is good at drawing the line where the programmer sees it fit best. Multi-paradigm has always beaten pure ideologies hands down when it comes to delivering useful programs that actually work without making programmers do mental gymnastics for the sake of purity. (They should reserve their efforts to be mentally gymnast in the real-world problem they're solving.)
You don't want to write all of your program in object-oriented, procedural, functional, declarative, or whatever paradigm you have a thing for. They all do some things well and suck at others. Use them like tools, the right one for the right job.
- ballenf 8y ago> Multi-paradigm has always beaten pure ideologies hands down when it comes to delivering useful programs that actually work without making programmers do mental gymnastics for the sake of purity. Don't think anyone is arguing with that (even the author of this piece). But the functional patterns that contribute to useful programs today are the direct result of the kind of pure theoretical thinking here. To me, your argument could be used against any theoretical research in any field. None of it is of practical use until it is.
- dahart 8y ago> Don't think anyone is arguing with that (even the author of this piece) The author is openly and explicitly arguing for a single paradigm, and he clearly stated in the article that he is in favor of, and calling for people to do the mental gymnastics for the sake of purity. > the functional patterns that contribute to useful programs today are the direct result of the kind of pure theoretical thinking here. FP isn’t pure theoretic, so I’m not sure what you mean. The foundations haven’t changed considerably in decades, and it has been possible and practical to write high-level FP code to, say, compute factorials or whatever, for decades. FP is great as a high-level design tool to simplify and reduce mutable state. But there’s no evidence that taking it to the limit with human interaction and hardware is even possible or what it means or why it’s useful. > your argument could be used against any theoretical research in any field. None of it is of practical use until it is. But you neglect to mention that much theoretical research never becomes practical, and some is proven impossible. Practicality is and always will be a useful and valid argument, even if it’s occasionally wrong.
- platz 8y ago> for the sake of purity. The post was about choosing a representation for sake of composition. In this case, the composition happens to be pure because it is mathmatical, but the simplest composition was the actual goal, not just any kind of purity.
- dahart 8y agoThe post discusses weak vs strong composition, not simple vs complex. The goal is FP for I/O so that composing is pure, so that it’s strong, whatever that means. We already have simple composition of programs with Von Neumann I/O, so I’m not sure I can agree with you. To that end, I found his example of number composition quite unconvincing. He said we use binary and not strings for composability. That’s not true. Numbers represented as strings are no less composable. The only real downside is they’re less memory and time efficient, but string based numbers are just as composable as binary numbers.
- marcosdumay 8y agoPast performance is no guarantee of future outcomes. If a non-imperative paradigm enables the creation of a different architecture that consistently beats the von Neumann adaptions we can create, you can bet people will get out of their way to write everything on that paradigm, whatever mental gymnastics is required. Besides, most of the programming world has been imperative-only from the beginning until just a few years ago. I don't know where you see all that multi-paradigm success.
- cwyers 8y agoBeats it by how much? Computers today are basically an accretion disc of suboptimal decisions made for the sake of backwards compatibility. You would have to demonstrate a huge leap in performance to wipe the slate clean.
- marcosdumay 8y agoI'm not sure by how much. Currently there is another tread here about people getting out of their way to push into userspace, on each application, all the crazy network protocol handling. Developers seem quite ok with that, as much that I feel out of place bothering about the complexity. We also have a lot of people rewriting legacy stuff on Rust, just for bit of extra confidence. Currently, people have got out of their way to create artificial intelligence guided real-time optimizers that converts von Neumann code into graph-machine code on x86, because it performs better. But it gets very close to optimum usage of the graph machine, so there is no need for most people to actually learn it.
- hyperpape 8y agoI think the piece is about programming models, not computer architecture. The idea might suggest alternative architectures, but that’s not what the post is about.
- coldtea 8y ago>Past performance is no guarantee of future outcomes. No, but it's the best predictor of them. >If a non-imperative paradigm enables the creation of a different architecture that consistently beats the von Neumann adaptions we can create, you can bet people will get out of their way to write everything on that paradigm, whatever mental gymnastics is required. Well, if wishes were horses beggars would ride. Let's have someone build and showcase this "different architecture" before we drop the current one.
- hyperpape 8y agoParagraphs 1,2 and 5 are literally repeating objections the author tried to address without mentioning his answers and why they succeed or fail. You’ve completely failed to engage with the piece.
- arambhashura 8y agoGenuine question: what are some accessible examples of real-world programs that use multiple paradigms "well"?
- gronne 8y agoThats some what subjective. If you look to python pandas or Gnu R programs; that would be paradigme hybrids (good ones mostly). I personally enjoy coding so much more if I can use the right tool for the job.
- rocqua 8y agoScala maybe? It does both OO and functional.
- keithnz 8y agomany C# programs now leverage a lot of functional capabilities through Linq. More so in F#. C# is more imperative with functional mixed in and does little to stop you doing functional "evils" F# is more functional with ability to mix in imperative and mutations and stops you from doing functional "evils" unless you say you want to be evil
- mercer 8y agoI like Elixir/Erlang's 'weird' approach to this, where it primarily uses an FP approach for the code, but an OO-like approach for the runtime (keeping state in processes). The OO being perhaps closer to Alan Kay's original ideas (as I understand it) is nice too. I'm not experienced enough to judge how well it does all this though.