[HN Gopher] Technical dimensions of programming systems
___________________________________________________________________
Technical dimensions of programming systems
Author : jgrodziski
Score : 69 points
Date : 2023-03-16 11:23 UTC (2 days ago)
(HTM) web link (tomasp.net)
(TXT) w3m dump (tomasp.net)
| phantom32 wrote:
| Really interesting writeup!
| alexisread wrote:
| I think they're missing some dimensions.
|
| 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.
| di4na wrote:
| 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.
| zabzonk wrote:
| 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.
| shadowofneptune wrote:
| 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.
| zabzonk wrote:
| 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.
| shadowofneptune wrote:
| 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.
| mjburgess wrote:
| 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.
| skimdesk wrote:
| 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
___________________________________________________________________
(page generated 2023-03-18 23:01 UTC)