A common problem I have when arguing that "mechanistic models" are qualitatively different from "descriptive models" is describing what it is about "mechanism" that's being modeled. I see it as a spectrum. Compartment models provide a good example. Some ODE contains a term that homogenizes all the stuff that happens inside cells versus, say, the intercellular matrix. Because there are 2 compartments, identifiable by terms in the equations, you can say it's "mechanistic" ... funging a bit on the "-istic" suffix. If I make some claim like: "Any one cell might behave differently from any other cell based on its history", then we could create another compartment, cells of type 1 and type 2. We can do that progressively until there's a compartment for each particular cell (and each particular extra-cellular space engineered by the actions of the cell).
In this sense, FP is similar to OOP in its particularity, and they contrast with homogenizing paradigms like systems dynamics models. What I'd *like* to do is find a way to emphatically ask my clients: "Does particularity matter?" Chemistry seems to say "no" for the most part. Microbiology seems to waffle a bit between small and large molecules. Medical scale biology is decidedly in the "yes" category, what with individualized treatment and "no average person" problems. Social systems are like inverted microbiology, where at smaller scopes, the answer is "yes", but at huge scopes the answer becomes "no" again. I'm too ignorant of quantum theory to say, but it seems like decoherence implies it may waffle a bit too. The answer to that question *should* help me choose the paradigm(s) for the analogs I build. Until I have a competent way to emphatically ask the question, though, my pluralism facilitates agile analogies. I argue for multi-models ... integrationist analogs that facilitate the composition of different models of computation. Reliance on any one computational paradigm *before* having a competent estimate for the analog's requirements is dangerous. I guess it doesn't much matter how pure Rust is. It seems well situated for integrationism, which is the only reason I haven't given my friend an answer, yet. If I do "join", I'll probably do it as 1099 for now so I can treat him like a client instead of a boss. On 9/22/20 7:32 PM, Marcus Daniels wrote: > I think linear/affine types as in Rust are cool. For one thing, they seem > plausible for physical analogues to computation, like your infinitely-long > expressions. In a biochemical system it often wouldn't make sense to `share' > a variable across several expressions. A `physical' function would consume > its inputs. Similarly linear types are like the no-cloning theorem for > quantum states. It's a small change for a person used to writing functional > programs to get in the habit of using linear types. Similar to Swarm's > notion of switching phases, but where the switching of the method sets is > understood by the compiler and can be enforced. Even besides the physical > intuition, linear types provide a low-overhead way to manage memory, like is > the norm for complex stack-allocated objects in C++. -- glen ep ropella 971-599-3737 - .... . -..-. . -. -.. -..-. .. ... -..-. .... . .-. . FRIAM Applied Complexity Group listserv Zoom Fridays 9:30a-12p Mtn GMT-6 bit.ly/virtualfriam un/subscribe http://redfish.com/mailman/listinfo/friam_redfish.com archives: http://friam.471366.n2.nabble.com/ FRIAM-COMIC http://friam-comic.blogspot.com/
