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

161–170 of 254 posts

Re: All programming philosophies are about state

#161

Post by dgb23 »

xmonkee wrote: post #100
bcherny wrote: post #71

Earlier quoted context omitted.

“He who is not a républicain at twenty compels one to doubt the generosity of his heart; but he who, after thirty, persists, compels one to doubt the soundness of his mind.”

God, this is such condescending nonsense. The older I get, the more left I lean, because the more of the world you see the more you see what chaos our current ideology has wreaked upon it. The only people I see going the way this quote does are unthinking idiots who were fashionably "liberal" in their youth without understanding any political theory, and are now fashionably "conservative" with even lesser understandi…

I personally find it more and more difficult to subscribe to any ideology.

I think societies, states and economies are emergent properties of people living together. But the more I know people, the less I believe overarching systems, models and grand narratives.

They are all wrong. Not only in respect of what should be. We can’t even agree on what is or has been.

Re: All programming philosophies are about state

#162

Post by valenterry »

vc8f6vVV wrote: post #50
epgui wrote: post #9

Earlier quoted context omitted.

I think what you're missing is that functional programming is about referential transparency. There should be no need for an instruction pointer in your mental model.

Not really. Try to interact with DB in FP. Yes, there is a referential transparency ... when combining functions which call DB (e.g. using monads). As a result you get a composite function, which is the same every time you run that composition. Who cares really? When you execute that composite function though you will potentially get different results and your "referential transparency" goes out the window. Of course…

> So c = ? Still transparent?

No, it's not. and a and b are neither in your second example, otherwise they could not produce any result that could be combined with +. Unless `{ .... some complex code ... }` is just `return 42`.

Referential transparency means that we can evaluate the same thing over and over again and getting exactly the same value back. Obviously that does not work with what you have constructed.

It helps when you annotate your examples with return types. That will make things clear very quickly.

Re: All programming philosophies are about state

#163

Post by jraph »

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…

This made me smile. I'm not sure I get the declarative one though, can someone expand on this? Is it because the sentence is very declarative? or because declarative programming allows lets to declare expensive to compute stuff (by mistake) too easily?

Re: All programming philosophies are about state

#164

Post by coldtea »

_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.

Not really. They are orthogonal to dispatch, which is why you can have different dispatch strategies with all (or at least most) of them. Dispatch is an implementation detail.

Re: All programming philosophies are about state

#165

Post by bradrn »

epwr wrote: post #138
bradrn wrote: post #126

Earlier quoted context omitted.

I feel I should point out that that ‘functional’ quote is (a) only applicable to pure, strongly-typed functional languages, and (b) pretty much irrelevant unless you happen to be interested in category theory.

You might want to look a bit more closely before you write functional programming off like this. Eg. Clojure is a modern functional language that is used for a lot of things & happens to be dynamic.

Since when was I writing off FP? My main language for personal projects is Haskell. I was just pointing out that the category theory stuff isn’t really relevant at all.

Re: All programming philosophies are about state

#166

Post by bradrn »

fulafel wrote: post #140
bradrn wrote: post #126

Earlier quoted context omitted.

I feel I should point out that that ‘functional’ quote is (a) only applicable to pure, strongly-typed functional languages, and (b) pretty much irrelevant unless you happen to be interested in category theory.

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.

Re: All programming philosophies are about state

#167

Post by unwind »

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 the State", "Less State -> More Good", "No State, No Problems", "Spread the State", "No State/Stay Pure"? Oh my kingdom for a programming-literate copywriter.

Re: All programming philosophies are about state

#168

Post by coldtea »

kilgnad wrote: post #132
_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…

There is a bit of categorical mixing going on and the author fails to identify actual hierarchies within the programming styles. But he does see, correctly, that it all has to do with state management. I'll point out what he got mixed up: First OO programming is a specific style of imperative programming. OO is simply imperative programming with state and functions scoped into instances. If you are doing OO, you are…

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++/Smalltalk and such (doesn't even matter if Smalltalk for example has a different conceptual model for its OO or different dispatch mechanism, etc).

And sure, "well, actually Lisp has CLOS" -- but OO and functional as commonly used (and as the author uses it) means the part of functional that's about first class functions and immutable data and purity, and OO means Java/C++ style classes and coding style.

Ditto for "imperative", which in TFA just means "C style more direct manipulation of state", even if OO in say C++ is still imperative in the academic sense of the term (and, heck, even that is not that clear cut. "Procedural" programming for example is still imperative in its manipulation of data, but the terms have been used in academia and industry to describe different things. So it's not about a naive application of the definition, but rather about the intention behind the term).

>Declarative programming, on the other hand, can be stateless or stateful so it doesn't really apply here.

Again, for the purposes of TFA, it doesn't matter if declarative can be "stateless or stateful".

The author doesn't say that the programming language philosophies are about "different approaches to state across a single axis" (e.g. stateless vs stateful). He just says that they are about "different approaches to state" period.

In this case, regarding declarative programming, the difference is not "keeping state or not", but "the programming managing whether state is kept or not (and how)" vs "the language managing it and the programmer just declaring their intentions".

>This thing is immutable state. Imperative programming with immutable state IS functional programming.

Not in any colloquial use of the term. SSA form might be "functional programming", but it's not what 99% of devs (and the author) means by functional programming, which includes the trappings and idioms offered by traditional languages called functional programming languages.

Re: All programming philosophies are about state

#169

Post by vinodkd »

Funny, I arrived at this "all software is.." piece last week.

Hypothesis: All of software *is* about change management ----

It dawned on me that all the software design efforts - Design patterns, programming styles, management practices - are all geared towards one thing at its core - managing change. For example:

* Command pattern: Figure out all the things that can be called and instead of a giant if/switch, look them up by name and call them. That way when you need to *change* the list of things you want to call, nothing else is affected.

* Structured programming: Keep the common code in one place and call them from many places. That way when the common code *changes*, we can contain the change to one place

* Object Oriented Programming: Keep the data and behavior common to one actor in the system contained in an object/class so that when it *changes* we have to change only that thing.

* Functional programming: *Changing* data is bad. Instead create copies of data and change them.

* Scrum: It's hard to predict too far into the future because things *change*. So let's try to plan for just the next n weeks.

Re: All programming philosophies are about state

#170

Post by drsopp »

wruza wrote: post #154

I’ve been a programmer all my life, got first sw job around 2000 in business-oriented area (consulting + programming + “ops”). Before that were 5-7 years of toy programming as a kid. I experimented with tech a lot, got into paradigms early and never restricted myself to a single language/env/os/hw. I haven’t created nothing big, stellar or rocket science, but a couple of my projects lived for 10-17 years and counting…

Thinking about state helps me write better code. If the codebase for a project is small enough, and I can enumerate all states and all ways that states can change into other states, I can make code that is so stable it can run indefinitely. Very satisfying. The next logical step from this point, I guess, is TLA+ (I still haven't tried it).
Post reply on HN