5 ms·

Also all "functional" programs have their state somewhere.. just usually much stricter isolated and manipulated - so no difference in statefulness. > I would r

Also all "functional" programs have their state somewhere.. just usually much stricter isolated and manipulated - so no difference in statefulness. > I would rather inherit someone's stateful JavaScript or Java than a complicated codebase by a seasoned Clojure, Haskell, Scala developer. I stand a better chance understanding the sequential code than a complicated recursive monad. Depending how it was written. True, but you add here the "complicated" attribute deliberately .. usually it is the other way round. The functional approach code is simpler to read and reason ( and usually not with much recursive monoids), while the believed sequential program has so many "concurrent" paths (even if there is no real concurrency, but just in the many hidden ways how the super distributed statefulness is manipulated).. not?

samsquire 4y ago
Your comment is very useful to me. It spurned a chain of events that you might find interesting. I am interested in parallel software and multithreading, so that's the kind of software I enjoy writing. The branches of a single threaded software can think of potential future interleavings. Your post inspired me to think of programs as "circular" or not. That is, they return to a steady state and can function properly no matter how many times they run and whether or not the execution is interrupted at any point. A program that is interrupted can leave the program state in an invalid state that cannot be recovered. So I started writing a parser to parse an assignment language. I plan to track object identities membership over time and see if objects get stuck in processing - they stop moving. program { available = {}; assigned = {}; main { program = programs { current_available = program.available { available += (current_available, 1); assigned - current_available; } item = program.requests { available (=) item { program.answers += item; available - item; assigned + (item, 1); } } } } } program { requests = []; requests += (add, 1); main { item = answers { new_requests = [(add, 1)]; available += (item, 1); new_request = new_requests { requests += new_request; } } answers -= answers; } }

samsquire 4y ago

Your comment is very useful to me. It spurned a chain of events that you might find interesting. I am interested in parallel software and multithreading, so that's the kind of software I enjoy writing. The branches of a single threaded software can think of potential future interleavings. Your post inspired me to think of programs as "circular" or not. That is, they return to a steady state and can function properly no matter how many times they run and whether or not the execution is interrupted at any point. A program that is interrupted can leave the program state in an invalid state that cannot be recovered. So I started writing a parser to parse an assignment language. I plan to track object identities membership over time and see if objects get stuck in processing - they stop moving. program { available = {}; assigned = {}; main { program = programs { current_available = program.available { available += (current_available, 1); assigned - current_available; } item = program.requests { available (=) item { program.answers += item; available - item; assigned + (item, 1); } } } } } program { requests = []; requests += (add, 1); main { item = answers { new_requests = [(add, 1)]; available += (item, 1); new_request = new_requests { requests += new_request; } } answers -= answers; } }