In a more perfect world. Obviously Allen is responding to the real experiences where not enough remembering ...wastes prior learning.. Still, awful lot (and ever more) to sift through, to find what to remember, and what to selectively forget...
-
-
Replying to @ruthmalan @wycats
Experimentation becomes engineering becomes blackboxes. We aren’t very good at documenting worked out, well engineered solutions so they can found and reapplied in the future.
2 replies 1 retweet 2 likes -
Replying to @awbjs @ruthmalan
The RFC process used by Rust (and Ember, and React, and Yarn) does a great job of capturing understanding at the moment a decision was made, and also at mandating a certain amount of archaeology.
1 reply 0 retweets 2 likes -
Since these communities are the targets of the "forgetting lessons" critique, I want to gently push back. Instead, I think we should cheer on these kinds of processes and help those interested in learning from the past do so.
1 reply 0 retweets 0 likes -
Replying to @wycats @ruthmalan
I certainly wasn’t intending to critique any specific communities. Just a thought triggered by a tweet. I absolutely will cheer on such processes and encourage them to more broadly disseminate their experiences.
1 reply 1 retweet 2 likes -
Replying to @awbjs @ruthmalan
Concretely, are you thinking of specific prior art for retaining high fidelity source information across many-stage compilation pipelines where the steps are built by different people, and where the output is a single file (like an executable binary)?
1 reply 0 retweets 1 like -
Replying to @wycats @ruthmalan
Well, a deep literature search is always a good starting point. Also, Eclipse and VisualStudio are both examples of systems with an extensible language services API and plugin architect.
1 reply 0 retweets 2 likes -
Replying to @awbjs @ruthmalan
I work on these kinds of systems and do literature searches, but: 1. Papers are very often not available without significant $ 2. Papers are very rarely (but not never) relevant to these software engineering questions 3. Visual Studio is closed source
2 replies 0 retweets 1 like -
4. The issue is source-to-source pipelines, not language services. They're connected but source to source pipelines need more decoupling and lean harder on standardization.
1 reply 0 retweets 1 like -
5. Today's JS tooling is by far better than anything that these other systems have done *for JS*, especially on the static analysis front, despite very significant efforts in those systems to support JS.
1 reply 0 retweets 0 likes
The issue is one of standardization, both around the "spec" (which could use some improvement) and shared abstractions (so people tend to build compilation stages that produce high fidelity output).
-
-
Low level tools like jscodeshift/recast do a good job at this, but small details do us in. One example of a small detail is inconsistency in tooling about where to put the sourcemap, and how to communicate where you want it to go
1 reply 0 retweets 1 like -
(inline vs alongside, and if alongside, based upon which root directory). This is a small detail, and one that would benefit from standardization, but not a consequence of failing to review Eclipse and Visual Studio closely enough.
0 replies 0 retweets 3 likes
End of conversation
New conversation -
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.