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

41–50 of 254 posts

Re: All programming philosophies are about state

#41

Post by Twisol »

philosopher1234 wrote: post #6

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

The MOV-only CPU [1, 2] is probably about as close to this as you can get. If you think about it, every structured programming affordance is sugar for writing a state machine. MOV-only pushes all control flow into a state machine, and does so without using any branches itself. It's all MOVs all the time.

[1] https://github.com/xoreaxeaxeax/movfuscator

[2] https://harrisonwl.github.io/assets/courses/malware/spring20...

Re: All programming philosophies are about state

#42

Post by manmal »

epgui wrote: post #34
manmal wrote: post #32

Earlier quoted context omitted.

They are orthogonal. React (FC) is a declarative _and_ functional approach. The declarative part is where React code describes what should be rendered, instead of adding/removing DOM elements manually. The old React is not 100% functional (partially OO), but it still is declarative.

They're not orthogonal. I believe one is a subset of the other, but at a minimum they overlap.

Using extremes for both, that would mean there is overlap between languages like Haskell and languages like SQL?

(Edited for clarity)

Re: All programming philosophies are about state

#43

Post by dustingetz »

rightbyte wrote: post #3

"Functional - Modifying state is hard to get correct; keep it at the boundaries and keep logic pure so that it is easier to verify the logic is correct." My main beef with functional programming is that you essentially put the state in the "instruction pointer" and its history of walking the call stack instead of bound to symbols. It does not fit my way of thought. I personally prefer more or less statemachines.

modern FP (effect systems) says the opposite - having separating the pure from the impure, we can now bring them back together and orchestrate fine grained fabrics of effects at greater scale with deterministic lifecycle and strong real source cleanup guarantees; for example signals based reactive dom rendering

Re: All programming philosophies are about state

#44

Post by analog31 »

philosopher1234 wrote: post #6

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

BASIC, as in the original line-numbered version. Every variable is global. Every line is an entry point. The philosophy is: It works just fine, so long as you're careful.

Also: Any assembly language that predates memory protection.

Re: All programming philosophies are about state

#45

Post by pasquinelli »

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?

Re: All programming philosophies are about state

#46

Post by [deleted] »

epgui wrote: post #9
rightbyte wrote: post #3

"Functional - Modifying state is hard to get correct; keep it at the boundaries and keep logic pure so that it is easier to verify the logic is correct." My main beef with functional programming is that you essentially put the state in the "instruction pointer" and its history of walking the call stack instead of bound to symbols. It does not fit my way of thought. I personally prefer more or less statemachines.

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.

[deleted]

Re: All programming philosophies are about state

#47

Post by manmal »

epgui wrote: post #31
pharmakom wrote: post #13

Functional and declarative are the same to me

They're related, but "declarative" is a broader category that includes relations. Functions are a special case of relations (see also: prolog, datalog, sql...).

You can write declarative code in an imperative language, and you can write non-declarative code in a functional language (eg IO monad). So IMO they can’t be related.

That’s assuming that „declarative“ means „describing outcomes rather than describing process“.

Re: All programming philosophies are about state

#49

Post by actually_a_dog »

eyelidlessness wrote: post #21
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.

Former long time anarchist, current long time FP proponent, presently having a laugh with you on this.

Have a laugh at this then, too: http://wiki.c2.com/?AnarchyProgramming

Re: All programming philosophies are about state

#50

Post by vc8f6vVV »

epgui wrote: post #9
rightbyte wrote: post #3

"Functional - Modifying state is hard to get correct; keep it at the boundaries and keep logic pure so that it is easier to verify the logic is correct." My main beef with functional programming is that you essentially put the state in the "instruction pointer" and its history of walking the call stack instead of bound to symbols. It does not fit my way of thought. I personally prefer more or less statemachines.

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 one can write a "pure" FP program without effects, but any side effect reduces referential transparency to combining functions, is it really easier to reason about computations this way? Nope, it is not.

Basically how FP sells:

  def a
    1
  end

  def b
    2
  end

  def c
    a + b
  end
You see? c = 3! Now try to apply this logic to (real world with effects):

  def a
    (conn: DBConn) => { .... some complex code  ... }
  end

  def b
    (conn: DBConn) => { .. another complex code ... }
  end

  def c
   (conn: DBConn) => a(conn) + b(conn)
  end
So c = ? Still transparent?
Post reply on HN