surely there must be some focused on naming things and cache invalidation?
on edit: yeah I guess cache invalidation is state too.
All programming philosophies are about state
191–200 of 254 posts
Re: All programming philosophies are about state
#192Dont have state.
Try to derive it from the data aka the environment.
Rather prefer adding state to the environment (timestamps, recipesteps of a product), then keeping seperate track from it, because seperation is, additional state.
And state is a curse:re. So dont.
If it cant be avoided, dont duplicate state, add a machine that resets it upon sensors detecting a changed environment (data) and revert wherever you can back to deriving it from data.
If it is unavoidable, make it concise, so that at least the maintainers can follow the state and see were it goes wrong.
Re: All programming philosophies are about state
#193I used to think this until I read Whitehead and Hickey and realized it’s all about time
Whitehead as in Alfred N Whitehead?
Re: All programming philosophies are about state
#194you can't really minimize state. functions are stored in the stack, which is... state.
The problem isn't that there is any state involved, it's that we as programmers must reason about that state.
Evaluating "(1 + 2) * 3" requires some state in the CPU, but I can treat it mentally as just an expression that be reduced down to 9 without me feeling like there's state involved.
The only thing that matters in my opinion is if it affects our ability to _reason_ about it
Re: All programming philosophies are about state
#195Data (state, context, whatever) is more important to structure than code. Make sure your programming language lets you structure data the way you feel is natural. The code comes later and the main function is to massage the data. At least this is how I usually think about it, but everyones mind works differently... :-)
Re: All programming philosophies are about state
#196Imperative: modifying state is the point of a bit-flipping machine; get out of my way so I can have fun! OOP: OK, I mostly had enough fun, can we try to tame the bit-flipping chaos with real-world analogies, without deflating all the fun? Functional: Any Monad is by definition an Endofunctor, which also means it's an object in the category of Endofunctors, where the monadic μ(flatMap) and η(unit) operators satisfy th…
Applause!
Re: All programming philosophies are about state
#197The article is grouping things together that don't belong in the same categories. OO, functional, imperative, declarative: these are ways of controlling dispatch . Monoliths and microservices are both ways to organize codebases and teams of programmers and control whether dispatch is intermediated by the network or not. Either way, both of these options are implemented by some kind of language in the previous categor…
All those things do actually fit in the broad category of “ideas pertaining to programming”. The author is illustrating a general notion. Far from being a problem, the divergent examples support the basic thesis.
Re: All programming philosophies are about state
#198Declarative/logic is a bit of meta-state IMO, the only state is exploration space, but the actual information has no state per se.
Also I wonder if algebraic thinking is not different from state, since you map / combine subsets of the domain[0] with more interesting operations. You don't got from 2->3->4, you can (+ 2 2).
[0] which some would say, is state, but here it's reified as a standalone value
Re: All programming philosophies are about state
#199The original author was smart in calling it programming philosophies as it avoids a lot of puristic discussion.
As mentioned elsewhere: Pure functional programming (as in lambda calculus and its friends) does not consider state. It consider expressions that need to be reduced – the user can on top of that build something that mimics state, which is entirely up the programmer.
However, I think the most productive way of assessing programming languages for real world software applications is by looking at state management, as it usually turns out to be the most complex part of that application.
Re: All programming philosophies are about state
#200Earlier quoted context omitted.
Yep, the FP scene is split into the pragmatic and the academic sides. I think it is not precisely delineated along the static vs dynamic sides: In addition to Elixir/Erlang, and Clojure we have eg F# and Elm from the static side in the pragmatic team.
I think the distinction you’re trying to make is that of ‘impure’ vs ‘pure’; ‘pragmatic’ vs ‘academic’ strikes me as a rather loaded choice of terminology, especially since languages like Haskell are rather widely used practically.
I don't think that's the distinction fulafel tried to make.
Elm is very much pure, yet it's on the pragmatic side: it forgoes certain powerful abstractions (higher kinded polymorphism, type classes), which enables the compiler to give very helpful error messages, and makes the language easier to learn.