Technical dimensions of programming systems(tomasp.net)
tomasp.net
Technical dimensions of programming systems
https://tomasp.net/techdims/
14 comments
Red vs Koka?
Sorry, I missed this question:
Red (also Rebol) is dynamically scoped:
https://stackoverflow.com/questions/21964110/is-there-a-over...
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.
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.
intro:
> 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.
> 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.
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.
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.
difference between programming environment and program execution environment?
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.
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.
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.
"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.
I find fascinating that the authors analysed only systems that are nearly all "fringe". The Web itself is not really used as described either.
It sounds like this work end up producing something that does not even consider the reality of the field but only what the author's imagine the field would be.
In that scope it is deeply interesting of course. And what they point to in the opening is important. But i would have loved an implementation that does look at how easy each system make testing. Composability. Refactoring. Linting. Different compilers. Repl. New projects. Compiler driven development. Formatting. Etc
There is a wide analysis of the technical side to do there between php and Rust as example. It feels like a missed opportunity.
It sounds like this work end up producing something that does not even consider the reality of the field but only what the author's imagine the field would be.
In that scope it is deeply interesting of course. And what they point to in the opening is important. But i would have loved an implementation that does look at how easy each system make testing. Composability. Refactoring. Linting. Different compilers. Repl. New projects. Compiler driven development. Formatting. Etc
There is a wide analysis of the technical side to do there between php and Rust as example. It feels like a missed opportunity.
The last author is the author of
Write your own Excel in 100 lines of F#
https://news.ycombinator.com/item?id=20791775, 84 comments.
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.
edit: typo
Pen and paper still has some feedback as one can see more than can be held in working memory.
edit: typo
Really interesting writeup!
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.