Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

All programming philosophies are about state

worldofbs.com

Post reply on HN
Print view View original

211–220 of 254 posts

Re: All programming philosophies are about state

#211

Post by bradrn »

tasuki wrote: post #200
bradrn wrote: post #166

Earlier quoted context omitted.

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.

> Elm is very much pure

Huh… you’re quite right. I always thought it was impure. In that case I retract my previous comment (pity I can’t edit it any more!).

Re: All programming philosophies are about state

#213

Post by lysecret »

ahartmetz wrote: post #174
kazinator wrote: post #73

Imperative: 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…

...and it's a real shame that Haskell has to be like that. I feel like much of the, sorry, mathematical wankery, is well separable from the stuff that actually makes program behavior more predictable in the functional style. I hear that F# has some success at doing exactly that.

Can confirm been working with F# for 2 months and I really miss the strong type system, DU and match statements when I go back to Python.

Re: All programming philosophies are about state

#214

Post by thesz »

_skel wrote: post #56

The 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…

I vehemently disagree.

It is really about state, dispatch is an implementation detail and can be simulated in many languages.

The main difference between monoliths and microservices is in coherent and, if possible, atomic changes in state of different subsystems. Monoliths allow use of blocking primitives or atomic transactions in software transactional memory to achieve that, to do so with microservices is much harder.

The very existence of many implementations of database systems is an attestation that many, if not most, software systems require consistent and atomic transactional processing with regard to state.

State is central to all software.

With what dispatch method to achieve coherency in the processing of state changes is an implementation detail.

Re: All programming philosophies are about state

#215

Post by noisy_boy »

unwind wrote: post #167
q845712 wrote: post #4

It's been a while but I used to enjoy telling folks in the early years of their career that software engineers and anarchists have a lot in common because both view "the state" as the main cause of problems.

Wow, that's great, thanks! As a dad and Certified Card-Carrying member of the International League of Punists I feel this is really profound. Not at all in my political direction, but who cares it's the pun that matters. Also, it would make an epic t-shirt in the hands of someone with some actual artistic skills. Is there such as a thing as missing a cool t-shirt you haven't seen? :/ "Down with the State", "Shrink th…

"State -> Less State -> Stateless"

Re: All programming philosophies are about state

#216

Post by devonkim »

nkzd wrote: post #142
_skel wrote: post #56

The 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…

Younger developer here. What does non-SOA style CRUD app look like?

XML-RPC based apps might count but they’re generally all under SOA in my experience. A real-time desktop application with some networked features to manipulate documents like via websockets may count as CRUD but not follow any SOA kind of architectural or interface conventions.

Re: All programming philosophies are about state

#217

Post by nicklaf »

harry8 wrote: post #112
strangemonad wrote: post #59

I used to think this until I read Whitehead and Hickey and realized it’s all about time

I thought maybe you were referring to a known text or paper. "whitehead and Hickey" search links back to this comment and only one other thing that can't be relevant. So, WTF are you talking about that we should know it and search engines don't?

Google turns up a Clojure library called Avout [0].

The library itself isn't too important here, but its website cites the philosophy of Rich Hickey and Alfred North Whitehead on state being an illusion:

Rich Hickey has spoken eloquently on mutable state in his talk "Are We There Yet?" [1]. To summarize, Rich and Alfred North Whitehead [2] don't believe in mutable state, it's an illusion. Rather, there are only successions of causally-linked immutable values, and time is derived from the perception of these successions. Causally-linked means the future is a function of the past; processes apply pure functions to immutable values to derive new immutable values, and we assign identity to these chains of values, and perceive change where there is none.

Hickey's talk itself is quite interesting and goes into detail on the relevance of Whitehead's ideas in his book Process and Reality to concurrent programming.

[0] https://avout.io/

[1] https://www.infoq.com/presentations/Are-We-There-Yet-Rich-Hi...

[2] https://archive.org/details/AlfredNorthWhiteheadProcessAndRe...

Re: All programming philosophies are about state

#218

Post by lucideer »

_skel wrote: post #56

The 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…

> OO, functional, imperative, declarative: these are ways of controlling dispatch.

Two problems with this statement:

1. imperative & declarative are about dispatch, OO & functional are about much more (dispatch being one of the most negligible components)

2. dispatch is extremely concerned with state: e.g. for declarative, state is handled by the "dispatcher", whereas for imperative state is an extra responsibility of core logic - the approaches to state handling is one of the most important differentiators between these paradigms.

As for your 2nd & 3rd paragraphs, 100% agree but they don't seem to contradict the article so I'm not sure what point you're making.

Re: All programming philosophies are about state

#219

Post by coldtea »

kilgnad wrote: post #185
coldtea wrote: post #168

Earlier quoted context omitted.

I think your mistake is that it's not about the "abstract"/academic/philosophical or etymological meaning of those terms (functional, imperative, etc). It's about their meaning (as used for decades) within the developer community at large, as established and commonly understood. And in that, there's absolutely a functional vs OO dichotomy, the first meaning Lisp, Haskell, etc, and the latter meaning Java/C++/Smalltal…

>I think your mistake is that it's not about the "abstract"/academic/philosophical or etymological meaning of those terms (functional, imperative, etc). No mistake made by me. The popular or even academic usage of the terms isn't relevant to the topic here. The reason is because the way these terms are used are highly inconsistent even in academia. They're not formally defined, they're just used for informal fuzzy co…

>All of these programming styles, more or less can imitate each other when managing state. None of them have a crystal clear way of handling state that's specific to their style. OOP can imitate Imperative and vice versa.

And the point is that this doesn't matter. It's not about C++ OOP being able to "imitate imperative" or not, it's about what C++ (or OOP in general) adds to the table regarding how programmers should think and hide state.

>All the other styles including the SOA stuff is just fluff. Different ways of doing the same thing.

Like above, you're still reasoning from lower levels of abstraction to point the similarities and underlying unity, whereas TFA is all about the level of working with each language and its "programming paradigm" as a programmer.

It's like you're arguing that "in the end, chemistry is just physics". Or worse, "in the end, cooking is just physics". Sure, but that is pedantically irrelevant information in a regular cookbook or when talking about national cuisines.

>Try writing fibonacci with everything immutable in say something simple like JS or python. Good luck doing it without using recursion or reduce. The isomorphism between FP and imperative programs that use immutable variables is something well known, but apparently, not by you.

My whole point was that it's not about the isomorphism, but the higher level trappings. Funny how you've managed to miss the whole argument, it's not even like I didn't spell it out (or like I haven't already said that SSA is nominally "functional programming") but it doesn't matter

Re: All programming philosophies are about state

#220

Post by catapart »

osigurdson wrote: post #141

It seems that the author is trying to make a kind of grand statement but the epiphany isn't felt. A program without any state seems uninteresting, state without logic to manipulate it seems uninteresting as well - no computer ships with only registers or only an ALU after all. It seems that we must include logic in the discussion as well but if we do, the title needs to be updated to "all programming philosophies are…

I feel this, but I think it's just a thing that programmers do. It was 10 years ago when I realized that all programming methods are about dealing with (conceptualizing/architecting) state. It made a lot of stuff "simple" to me that had previously been "complex" and I got a lot of value out of that change in paradigm. Not so much that I didn't assume all my peers didn't already know it (I find I'm usually "behind the curve" when it comes to piecing obvious things together), so didn't evangelize it to anyone, but I definitely understand why someone would.

It feels secret, because no one really talks directly about how all programming paradigms are about state. But once you realize it, you can start to see how a lot of high-level programmers reference it when they talk, all the time. Just something that "everybody knows", once you spend enough time working in code.

Personally, it wasn't the realization that it's all about state that was particularly exciting. It was using that new interpretation to understand how I could mix and match different types within a single project, to make each separable/modular piece of it, rather than dogmatically sticking to a single paradigm throughout. I think there's a definite mental breakthrough when a programmer can confidently use multiple different state paradigms to handle what would otherwise be a clunky or unwieldy implementation in a single paradigm.

Post reply on HN