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

61–70 of 254 posts

Re: All programming philosophies are about state

#62

Post by frutiger »

epolanski wrote: post #39
chowells wrote: post #8

That doesn't really seem like a good summary of functional programming. It has state all over the place. But it's true that functional programming is about state management. I'd argue that the functional approach to state management is to make state explicit and visible.

FP is about evaluating expressions and it doesn't have state all over the place. I would also add that statefulness is incredibly hard and complex to get right in complex applications and pure fp languages like haskell lack enough emphasis on runtimes to handle this gracefully.

> FP is about evaluating expressions and it doesn't have state all over the place.

All the state is in the function stack and the instruction pointer.

Re: All programming philosophies are about state

#63

Post by philosopher1234 »

pasquinelli wrote: post #45
philosopher1234 wrote: post #6

i want to see someone elaborate a state-maximizing, instead of state-minimizing, philosophy. lean in

i've been thinking about this for a while. my basic question is: languages give or don't give features mostly to avoid spaghetti code; what if what's really needed is tools to make dealing with spaghetti code easy?

I’m right there with you. It feels much more interesting than the 3 strategies we have collectively formulated for avoiding code. Those strategies have plateaued. Functional programming isn’t good enough. We need something different.

Re: All programming philosophies are about state

#68

Post by layer8 »

armchairhacker wrote: post #60

State = context. In a pure functional language the state would be concerted into extra function parameters. Many bugs arise from unexpected context: programmer writes code expecting one context but gets an oddly-shaped context they weren't planning for (the other bugs are typos, where the context is correct but your code is not what they planned it to be, or when downstream code has different behavior than they expec…

State is not the same as context, because (nonpure) functions also perform state changes, and concurrent execution can cause shared state to change at any time during the execution of a function, including for objects the function created itself (weren’t existing context).

Bugs arise from incorrect assumptions. These can be assumptions about state or context, but really it can be any kind of assumption. Assumptions are a kind of dependency. Minimizing dependencies also helps to minimize assumptions. Similarly, statically checked type systems help by having the compiler double-check at least some of the developer’s assumptions. The more powerful the type system, the more assumptions can be expressed and hence checked.

OOP tries to minimize the assumptions and dependencies between code by encapsulation/data hiding and interface contracts. FP tries to minimize them by having the result of a function only depend on its parameters. Declarative programming tries to minimize them by having the program only describe relationships between inputs and outputs.

How to minimize the assumptions a given piece of code has to make, and minimizing its dependencies, are the bedrock of all software engineering advice, IMO.

Re: All programming philosophies are about state

#70

Post by bawolff »

jxf wrote: post #66

This article makes an error: All programming philosophies are about state, but they're not _just_ about state.

Disagreeing with someone's thesis is not the same as them making an error. Like maybe you don't find their argument compelling, but that's not the same as them making a factual error.
Post reply on HN