Sure, I agree that that's the proper, academic, and purely functional way to handle state. Whether or not that introduces its own set of problems I'll leave as a thought exercise for the reader.
The key phrase in my comment was "casual FP practitioner." I'd only hoped to show OP a way to painlessly introduce some principles from the FP world , ones with, IMO, real and immediately obvious benefits, without cramming "monads and combinators and category theory oh my!" down his or her throat.
I tend to prefer simple, dumb, readable code to academic elegance, and I've found that treating data as immutable (whether it actually is or not under the covers) and preferring data transformation to state manipulation are two ways to get closer to that goal.
Sorry, I don't have any links to share off hand. But I do have some comments:
Of course we all have to deal with state, otherwise our programs are essentially useless.
As a casual FP practitioner, I try to make web-based design decisions that minimize the number of places where I handle state. The majority of the functions that I write just take values and return some referentially transparent transformation of their inputs.
So for me it's really more about black-boxing and forgetting (once it's thoroughly tested) about 90% of my code, thus hopefully limiting the scope of my state related wtf moments to the other 10%.
There was a time in my life where I thought that this sort of design was obvious and everybody was doing it. I've since learned, through lots of painful maintenance and debugging, that this is not at all the case :/
But if RunwayFinder intends to attack the validity of the patent by claiming obviousness or something similar, I see the analogy as more like:
me: This was no-one's apartment when I got here. There are thousands like it, in fact an infinite supply. Get your own.
burglar: Well, we'll work that out in court. In fact I own all of them.
me: No, it was public land and I just built my apartment here.
burglar: Well, how about you sign this lease. Just put your John Hancock here, and I won't give you any trouble about staying here. I won't even charge you any rent this month.
With the above dialog, doesn't the signing of the lease imply an acceptance of the burglars ownership of not only this apartment but all of these apartments?
I am not a lawyer, obviously, just someone who likes analogies.
Doesn't the simple act of accepting a (free or otherwise) license from someone imply that that you accept their right to grant said license?
Both parties I'm sure are aware of this; it's simply posturing on FlightPrep's part with the hope that RunwayFinder will be dumb enough to accept it and thereby lose in the long run.
Sure, I agree that that's the proper, academic, and purely functional way to handle state. Whether or not that introduces its own set of problems I'll leave as a thought exercise for the reader.
The key phrase in my comment was "casual FP practitioner." I'd only hoped to show OP a way to painlessly introduce some principles from the FP world , ones with, IMO, real and immediately obvious benefits, without cramming "monads and combinators and category theory oh my!" down his or her throat.
I tend to prefer simple, dumb, readable code to academic elegance, and I've found that treating data as immutable (whether it actually is or not under the covers) and preferring data transformation to state manipulation are two ways to get closer to that goal.