From 0d6f58c54a7af6c8b4e6cd98663eb36ec4e3accc Mon Sep 17 00:00:00 2001
From: Owen Jacobson <owen@grimoire.ca>
Date: Tue, 28 Jan 2020 20:49:17 -0500
Subject: Editorial pass & migration to mkdocs.

There's a lot in grimoire.ca that I either no longer stand behind or feel pretty weird about having out there.
---
 wiki/dev/entry-points.md | 56 ------------------------------------------------
 1 file changed, 56 deletions(-)
 delete mode 100644 wiki/dev/entry-points.md

(limited to 'wiki/dev/entry-points.md')

diff --git a/wiki/dev/entry-points.md b/wiki/dev/entry-points.md
deleted file mode 100644
index 0e56ce0..0000000
--- a/wiki/dev/entry-points.md
+++ /dev/null
@@ -1,56 +0,0 @@
-# Entry Points
-
-The following captures a conversation from IRC:
-
-> [Owen J](https://twitter.com/derspiny): Have you run across the idea
-> of an "entry point" in a runtime yet? (You've definitely used it, just
-> possibly not known it had a name.)
->
-> [Alex L](https://twitter.com/aeleitch): I have not!
->
-> [Owen J](https://twitter.com/derspiny): It's the point where the
-> execution of the outside system -- the OS, the browser, the Node
-> runtime, whatever -- stops and the execution of your code starts. Some
-> platforms only give you one: C on Unix is classic, where there's only
-> two entry points: main and signal handlers (and a lot of apps only use
-> main). JS gives you _a shit fucking ton_ of entry points.
->
-> [Owen J](https://twitter.com/derspiny): In a browser, the pageload
-> process is an entry point: your code gets run when the browser
-> encounters a `<script>` tag. So is every event handler. There's none
-> of your code running when an event handler starts, only the browser
-> is running. So is every callback from an external service, like
-> `XmlHttpRequest` or `EventSource` or the `File` APIs. In Node, the top
-> level of your main script is an entry point, but so is every callback
-> from an external service.
->
-> [Alex L](https://twitter.com/aeleitch): Ahahahahahahaha oh my
-> god. There is no way for me to contain them all. _everything the light
-> touches._
->
-> [Owen J](https://twitter.com/derspiny): This is important for
-> reasoning about exception handling! _In JS_, exception handling only
-> propagates one direction: towards the entry point of this sequence of
-> function calls.
->
-> [Alex L](https://twitter.com/aeleitch): Yes. This is what _I_ call a
-> stack trace.
->
-> [Owen J](https://twitter.com/derspiny): If an exception escapes from
-> an entry point, the JS runtime logs it, and then the outside runtime
-> takes over again. That's one of the ways callbacks from external
-> services fuck up the idea of a stack trace as a map of control flow.
->
-> [Alex L](https://twitter.com/aeleitch): Huh. Yes. Yes I can see
-> that. I mean, in my world, control flow is a somewhat handwavey idea
-> right now. I'm starting to understand why so many people hate JS-land.
->
-> [Owen J](https://twitter.com/derspiny): Sure. But, for example, a
-> promise chain is a tool for restructuring control flow. In principle,
-> error handling should provide _some_ kind of map of that, to allow
-> programmers -- you -- to diagnose how a program reached a given error
-> state and maybe one day fix the problem. In THIS future, none of them
-> do that well, though.
->
-> [Alex L](https://twitter.com/aeleitch): Yes. Truly the darkest
-> timeline, but this reviews why I am having these concerns.
-- 
cgit v1.2.3