|
And for a real question, after my initial laugh.
I've read several intros to functional programming. Nothing I've read answers the question, "How do real-world functional programs handle changes to huge-size data-blocks without clobbering memory?"
In other words, say you create a word processor. The functional programming explanations I've seen indicate you have a 'document' in memory that might be 2 MB. If you add a letter to the document via a keystroke, in order to keep it immutable, you need to generate an entirely new 2 MB block with the added character, which becomes the 'new' document. The program always updates to that 'new' document, in order to eliminate mutability.
Something has to be wrong with my understanding, because if that is the case functional programming cannot handle real-world word processors and other editing chores because it will just start shuffling around huge blocks of memory, trashing the cache and becoming slow as dog poo in snow.
|
|
|
|
|
David O'Neil wrote: In other words, say you create a word processor. The functional programming explanations I've seen indicate you have a 'document' in memory that might be 2 MB. If you add a letter to the document via a keystroke, in order to keep it immutable, you need to generate an entirely new 2 MB block with the added character, which becomes the 'new' document. The program always updates to that 'new' document, in order to eliminate mutability.
One way might be to divide the document into smaller portions (e.g. paragraphs), each immutable, and a list of paragraphs. Updating a keystroke would then consist of (a) making a new copy of the paragraph, and (b) making a new copy of the list, which points to the new paragraph.
Nowhere does it say that all the data in a functional program must consist of a single block.
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows.
-- 6079 Smith W.
|
|
|
|
|
|
|
interesting link. Thanks
M.D.V. 
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
Rating helpful answers is nice, but saying thanks can be even nicer.
|
|
|
|
|
|
Had the author met Booch, Rumbaugh and Jacobson twenty five years ago, she would have had a different opinion.
|
|
|
|
|
I agree with him on many of his OOP criticisms.
Truth to tell, with the benefit of hindsight, every OS, every framework, every language would be different to the ones we use.
The sad reality, though, is that we now live in a world of (often huge and clunky) objects and that's the world that we have to interact with; so even if we write our bits in an object-free way, there's still going to be a whole ton of boxing and unboxing to be done in the middleware whenever we need to talk to something else. We simply can't be entirely object free in an object-obsessed world.
Coders, in retrospect, probably did embrace OO with too much enthusiasm and we're quite possibly about to see a generation dive done the FP rabbit-hole with the same blind devotion and similarly mixed results.
Whenever you find yourself on the side of the majority, it is time to pause and reflect. - Mark Twain
|
|
|
|
|
That's a lot of words and claims but I'm still trying to find actual examples, especially in the "Real world examples, please!" sections.
In any case Beta was better than VHS and JavaScript will end up ruling the world.
cheers
Chris Maunder
|
|
|
|
|
My comment on the article posted to the site:Quote: A gigantic cauldron of boiling spew delivered with the fervent self-righteousness of the true believer who has seen the Light (Erlang). A symphony of anger with hyperbole at top volume in crescendo after crescendo.
yawn …
I wonder if they will delete it ?
I will admit that the article has reinforced my preexisting curiosity about what's so cool about FP. I already write code in C# that generates functions based on generic templates (not using reflection, or building Expressions), code that allows chaining of generic functions, merging, etc.
Hopefully, I will locate some sober authors.
«Where is the Life we have lost in living? Where is the wisdom we have lost in knowledge? Where is the knowledge we have lost in information?» T. S. Elliot
modified 26-Jul-19 4:48am.
|
|
|
|
|
BillWoodruff wrote: the article has reinforced my preexisting curiosity about what's so cool about FP
Recently I read Manning | Functional Programming in C#[^] which I found a great introduction. Not theory driven like Seemann's blog From design patterns to category theory[^] but more oriented to normal programming tasks. Still I have to get some more understanding of the Functional Paradigma, but that was a good start.
Oh sanctissimi Wilhelmus, Theodorus, et Fredericus!
|
|
|
|
|
Thanks, Bernhard; if you recommend it, I will read it 
I have "Real World Functional Programming: With Examples in F# and C#" by Tomas Petricek, Jon Skeet [^] waiting for my one-good-eyeball-to-screen ration 
Manning's site touts the book with this quote: Quote: From the Foreword: You will never look at your code in the same way again.
Mads Torgersen, C# PM, Microsoft
cheers, Bill
«Where is the Life we have lost in living? Where is the wisdom we have lost in knowledge? Where is the knowledge we have lost in information?» T. S. Elliot
|
|
|
|
|
The bad thing with Functional Programming is: it is harder to grasp than Object-Oriented Programming. And most people actually fail with the basic ideas of OOP (e.g. SOLID)...
Writing "class" on top of a bunch of lines of code is NOT OOP, but many people think so.
Oh sanctissimi Wilhelmus, Theodorus, et Fredericus!
|
|
|
|
|
The worst thing about functional programming is its poor resilience to non-ideal development situations.
When large organizations maintain code over long periods of time, non-ideal practices constantly leak in. Hurried developers updating confusing code may be bad for object-oriented code bases but is horrible-to-fatal for functional-style code.
|
|
|
|
|
jesarg wrote: non-ideal development situations
I've never known any other type.
«Where is the Life we have lost in living? Where is the wisdom we have lost in knowledge? Where is the knowledge we have lost in information?» T. S. Elliot
|
|
|
|
|
jesarg wrote: When large organizations maintain code over long periods of time, non-ideal practices constantly leak in. Hurried developers updating confusing code may be bad for object-oriented code bases but is horrible-to-fatal for functional-style code.
I would appreciate hearing about a specific case of this you have seen. What type of change to code unique to FP would cause problems that would not be flagged at compile time ?
«Where is the Life we have lost in living? Where is the wisdom we have lost in knowledge? Where is the knowledge we have lost in information?» T. S. Elliot
|
|
|
|
|
The first developer writes code.
The second developer updates the code, despite slightly misunderstanding the first developer's code, making the resulting code confusing and prone to bugs.
The third developer updates the code, while slightly misunderstanding the first developer's code, the second developer's code, and the second developer's misunderstanding of the first developer's code, making the resulting code more confusing and bug-prone.
The fourth developer updates the code, seriously misunderstanding the first developer's code, the second developer's code, the third developer's code, the second developer's misunderstanding of the first developer's code, the third developer's misunderstanding of the first developer's code, the third developer's misunderstanding of the second developer's code, and the third developer's misunderstanding of the second developer's misunderstanding of the first developer's code.
Etc. until maintenance is impossible, bugs never get fixed, and rewrites are demanded.
This problem isn't unique to functional programming, but using a functional style amplifies the compounding negative effects (which is why start-ups have success stories of using functional languages and large organizations don't). When using more procedural styles, the negative side effects of not fully understanding the code being updated are lower.
You can read about project successes and failures with LISP; they don't specifically mention the effect I described, but they seem to have experienced it nonetheless.
http://www.paulgraham.com/avg.html
https://www.quora.com/Does-Yahoo-Stores-previously-Viaweb-still-use-Lisp
https://discuss.fogcreek.com/joelonsoftware/default.asp?cmd=show&ixPost=31402
|
|
|
|
|
So in the end it boils down to a simple point: most programmers are not capable of grasping concepts which go beyond simple procedural statements (like if or switch or assignments).
Oh sanctissimi Wilhelmus, Theodorus, et Fredericus!
|
|
|
|
|
@BHiller Or, it boils down to some programmers have a bias, a prejudice, for, or against, FP or OOP ... that they cannot articulate, or cannot describe any specific example they have actually encountered ?
It is inevitable we have biases, and, it is a fact that many programmers tend to "fall in love" with their languages/tools to a certain degree, sometimes comically extreme ... I think of a hilarious encounter I had with a FORTH "messiah" in the 1970's.
I like Gandhi's statement: "I want the winds of all the cultures to blow around my house, but I don't want to be knocked over by any of them."
By the way, I hate VB 
«Where is the Life we have lost in living? Where is the wisdom we have lost in knowledge? Where is the knowledge we have lost in information?» T. S. Elliot
|
|
|
|
|
The experts in functional programming run each over with messes just like the novices do. It boils down to functional programming giving people more power than they are likely to handle well.
|
|
|
|
|
That's true for quite any programming language/paradigm, even FORTRAN.
Oh sanctissimi Wilhelmus, Theodorus, et Fredericus!
|
|
|
|
|
I asked you for specifics, and you come up with this ? What you describe has nothing specific to do with either OOP or FP.
«Where is the Life we have lost in living? Where is the wisdom we have lost in knowledge? Where is the knowledge we have lost in information?» T. S. Elliot
|
|
|
|
|
I tend to think of OOP as a Platonic philosophy, a way to express "ideal/pure Forms" and their inclusive/exclusive/hierarchical relations. I really like SOLID as an Aristotelian "techne," a set of principles for how to structure the creation, use, interaction, of the (necessarily imperfect !) instances of those "Forms."
While I see OOP as the best way to model hierarchies, I (currently) wonder how suited it is to typical modern multi-threaded apps driven by asynchronous events ... where any damn thing can happen any damn time 
Is it "right" to indict OOP with the charge of criminal mutability of state ... rather than indict the programmer who does not control access/mutability using the provided tools, such as ... in C# ... Linq, System.Collections.Immutable, and such pedestrian access modifiers as 'readonly ?
«Where is the Life we have lost in living? Where is the wisdom we have lost in knowledge? Where is the knowledge we have lost in information?» T. S. Elliot
modified 26-Jul-19 12:43pm.
|
|
|
|
|
A recent report from WhiteSource, an open-source security and license compliance management platform, highlights how developers should be in charge of application security and how organizations are investing heavily to produce secure code. You build it, they break it
|
|
|
|
|
“The sky is falling; uninstall VLC right now!” That’s the advice some websites are providing. But the purported VLC flaw is overblown—and, according to VLC’s developers, may not even be a real risk. "Fake news! Fake news!", some guy
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
