All environments are stateful, by necessity. A stateless system would have no input, no output, and consume no electricity. How much the programming requires thinking about that state is one technical dimension.
Abstract algorithms given in computer science could meet that condition, so long as they're defined on a turing machine.
Eg., you could have a gravitationally stable solar system whose planets, etc. you identified with terms (etc.) and observe that the whole thing runs at zero-energy.
This distinguishes abstract algorithms, which are just restatements of mathematics, from "programs" which are algorithms defined for electrical devices with relevant useful capacities.
Yes, I meant the latter, the actual execution. Kevlin Henney puts it well in his talks (paraphrase):
"Functional programming is great! You don't need to worry about the outside environment, it just works! Why, even if you unplug the computer, it just works—no, wait. These are all abstractions."
The execution environment is the invariant the webpage starts out with. The programming environment, and its relation to state, can be changed.
A 7400 NAND gate has no state, but it has inputs and outputs and consumes electricity to do useful work. Using lots of them you can build quite non-trivial systems.
Namely mutability, side effects, formal verification ie. How equational / axiomatic a language is, how static/dynamic a language is (runtime typing etc), how concurrent, how scoped a language is eg. Red vs Koka.
All of the above have a massive influence on the structure and intent of a language.
An inspiring collection of thoughts. The section on feedback loops had me thinking: Would it be possible to program without feedback (or with minimal feedback). How would that look?
Pen and paper still has some feedback as one can see more than can be held in working memory.
12 comments
[ 3.5 ms ] story [ 28.1 ms ] thread> Programming is done in a stateful environment, by interacting with a system through a graphical user interface.
i think all statments in that sentence could be argued with.
Eg., you could have a gravitationally stable solar system whose planets, etc. you identified with terms (etc.) and observe that the whole thing runs at zero-energy.
This distinguishes abstract algorithms, which are just restatements of mathematics, from "programs" which are algorithms defined for electrical devices with relevant useful capacities.
if i enter (+ 1 2) which is a lisp program, where is the state? in the context of lisp.
but of course, everything is stateful at the end of the day - that's what your cpu is up to.
"Functional programming is great! You don't need to worry about the outside environment, it just works! Why, even if you unplug the computer, it just works—no, wait. These are all abstractions."
The execution environment is the invariant the webpage starts out with. The programming environment, and its relation to state, can be changed.
Namely mutability, side effects, formal verification ie. How equational / axiomatic a language is, how static/dynamic a language is (runtime typing etc), how concurrent, how scoped a language is eg. Red vs Koka.
All of the above have a massive influence on the structure and intent of a language.
Koka has to be lexically scoped, to cleanly handle effect types: https://koka-lang.github.io/koka/doc/book.html#sec-hello-wor...
There is a world of difference between these approaches, both in terms of the runtime/compiler support, and the real-world use cases.
Pen and paper still has some feedback as one can see more than can be held in working memory.
edit: typo