User talk:Colby Russell/Draft:The case for accepting the W3C–WHATWG hypertext system as the universal medium, aka "Browsers, builds, and burdens": Difference between revisions
Discussion page of User:Colby Russell/Draft:The case for accepting the W3C–WHATWG hypertext system as the universal medium, aka "Browsers, builds, and burdens"
Content added Content deleted
(Created page with "1. Recognizing executable programs as a subset of hypermedia 2. Acknowledging the circumstances of our predicament (or: constraints are always a consideration in an engineeri...") |
(rm ALGOL 2020; now at User:Colby Russell/Pitches) |
||
(6 intermediate revisions by the same user not shown) | |||
Line 2: | Line 2: | ||
2. Acknowledging the circumstances of our predicament (or: constraints are always a consideration in an engineering problem) |
2. Acknowledging the circumstances of our predicament (or: constraints are always a consideration in an engineering problem) |
||
* Use the Ohm paper as an example of (the need for) live media <https://ohmlang.github.io/pubs/live2016/> |
|||
* Use Bob Nystrom's ad hoc, quasi-literate programming tools described in 'Crafting "Crafting Interpreters"' <http://journal.stuffwithstuff.com/2020/04/05/crafting-crafting-interpreters/> to make the case for 1 |
|||
* Use the Moonchild editor <https://harc.github.io/moonchild/> to make the case for 2 |
|||
** Use the Seymour paper ("we plan to adapt Seymour to use Python") as an example of how not to approach this <https://harc.github.io/seymour-live2017/> |
|||
* Consider Fielding's remark about "software design on the scale of decades: every detail is intended to promote software longevity and independent evolution. Many of the constraints are directly opposed to short-term efficiency. Unfortunately, people are fairly good at short-term design, and usually awful at long-term design. Most don’t think they need to design past the current release." <https://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven> |
|||
* "Almost as if" browsers were designed for sharing and interacting with hypermedia <https://floooh.github.io/2019/01/05/wasm-embedding.html> |
Latest revision as of 19:48, 17 August 2020
1. Recognizing executable programs as a subset of hypermedia
2. Acknowledging the circumstances of our predicament (or: constraints are always a consideration in an engineering problem)
- Use the Ohm paper as an example of (the need for) live media <https://ohmlang.github.io/pubs/live2016/>
- Use Bob Nystrom's ad hoc, quasi-literate programming tools described in 'Crafting "Crafting Interpreters"' <http://journal.stuffwithstuff.com/2020/04/05/crafting-crafting-interpreters/> to make the case for 1
- Use the Moonchild editor <https://harc.github.io/moonchild/> to make the case for 2
- Use the Seymour paper ("we plan to adapt Seymour to use Python") as an example of how not to approach this <https://harc.github.io/seymour-live2017/>
- Consider Fielding's remark about "software design on the scale of decades: every detail is intended to promote software longevity and independent evolution. Many of the constraints are directly opposed to short-term efficiency. Unfortunately, people are fairly good at short-term design, and usually awful at long-term design. Most don’t think they need to design past the current release." <https://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven>
- "Almost as if" browsers were designed for sharing and interacting with hypermedia <https://floooh.github.io/2019/01/05/wasm-embedding.html>