Dreaming the future of software; Project Editor ECMAScript 2015; Reformed Smalltalker JavaScript historian dl.acm.org/doi/abs/10.114… @allenwb@mastodon.social
Sherwood Oregon USA
- Tweets 8,520
- Following 218
- Followers 6,373
- Likes 436
A lot of twitter chattering today about resumable exceptions and “Algebraic Effects”.
I thought some of the old Smalltalkers out there might be amused by the original proposal for what ultimately became the Smalltalk’s standard exception system.
wirfs-brock.com/allen/files/…
When "exception" handling was first being explored in prog languages it quickly emerged that there were two possible approaches: non-resumable(c++, Java, JS, etc) & resumable(Common Lisp, Smalltalk, etc).
Seems to me that basically:
"Algebraic Effects"===resumable exceptions
1
5
35
I once implemented a “fluid variables” (e.g., dynamically scoped) package for Smalltalk. It was trivial using resumable exceptions, because resumable exceptions are really just dynamically scoped functions bindings.
I'm new to Algebraic Effects, but in dynamic languages, at least the examples on that post that weren't about recovering... it feels like dynamic variables?
3
When "exception" handling was first being explored in prog languages it quickly emerged that there were two possible approaches: non-resumable(c++, Java, JS, etc) & resumable(Common Lisp, Smalltalk, etc).
Seems to me that basically:
"Algebraic Effects"===resumable exceptions
5
7
78
A long standing trope in computer science (and probably elsewhere) is to take an old idea and rebrand it with a new name. Sometimes this is intentional (based on old knowledge) and sometimes accidental (unaware of history). I'm not sure which applies here.
2
2
18
If we expect to rely on a GC as a reliable foundation for managing non-memory resources, we should probably start by changing that subsystems name (and how we think about it) to something like “REsource Management Oracle” (REMO)
This is the original post I wrote on this topic. The actual idea of thinking about the finalization problem in terms of resource management heuristics is due to George Bosworth.
lists.mozilla.org/pipermail/…
I only remember when Allen Wirfs-Brock said that on the es-discuss mailing list. I don't know if he was quoting something earlier.
5
One of the best technical rants ever. Well done Jason!
(This is tweet 3; start from the beginning)
WeakRefs are like cigarettes. You might really want one, you might convince yourself you need one, but it’s never good. The proposal itself says things like “they are best avoided if possible”. Not making it up.
1
4
19
QuickJS is quite impressive, but this assertion is kinda BSish.
All the spec does is enumerate where "tail postion" occurs in JS and then in a spec-ish way say reuse the current stack frame.
Minimizing stack size should have great practical interest in resource limited impls
The QuickJS site says:
“We believe the current specification of tails calls is too complicated and presents limited practical interests.”
1
3
12
2/2
In an implementation, identifying tail calls is probably simpler then what it takes to define them in term of grammer productions within the spec.
Cc/@getify
1
1
9
Yes but that doesn’t explain the behavior of block nested var. Given that all JS declarations are “instantiated” at entry to their scope. The only real distinction of var is that the declaration is “hoisted” across intervening scopes to a function/global /module scope.
1
I’d say leadership, not management.
At some point you may discover you have goals that far exceed what you can personally code. You have to lead others in order to reach your goals.
Leaves little time for actual coding. But doesn’t mean you have to become non-technical
nitter.catsarch.com/krzyzanowskim/status/1…
I'm living this particular answer right now.
ALT a screenshot of the answer from Alejandro Ramirez
1
2
17
The original proposal used the name EphemeronTable for what became WeakMap.
My preference was to call it ObjectRegistry as that seems to better reflect the primary use case.
wiki.ecmascript.org/doku.php…
🤯 JavaScript WeakMaps are not actually weak: they refer strongly to their contents as long as the key is alive.
This brings the list of imprecisely-named ECMAScript APIs to:
➡️ Map → OrderedMap
➡️ Set → OrderedSet
➡️ Promise.race → Promise.anySettled
➡️ WeakMap → Ephemeron
1
14
A secret obligation of language designers is to ensure lifetime employment opportunities for compiler writers.
I think there are more concerns here than just parsing overhead.
1)The recommendation moves most parsing of the literal from “parse-time” to “execution time”. This could be significant to implementations and apps (eg @moddabletech ) where “parse-time” is pre-deployment.
1/
1
1
11
I think the is another way to characterize this dichotomy.
At any level of abstraction most devs
try to do things simply. What do you do when that can't solve the problem?
1) build powerful/complex tools?
2) create a new higher level of abstraction that renews simplicity?
1/
One kind of dev feels empowered when they solve low-level problems using the minimal approach (least code, least powerful tools, etc).
Another kind of dev feels empowered when they use the maximal approach (most powerful tools) and thus focus on solving higher level problems.
1
1
6
@BrendanEich answered @getify’s question about ToBoolean but didn’t address why Symbol.toPrimitive exists.
I invented Symbol.toPrimitive for a very specific purpose, so here’s the story:
1/
@awbjs what was the reasoning for providing Symbol.toPrimitive? and why not also a ToBoolean hook?
1
4
14
16/16
So that’s the story of Symbol.toPrimitive. If you look at the other predefined symbols you will see that most of them correspond to various rarely used magic hooks that allow self-hosting without complicating the set of Proxy traps.
1
4