diff options
Diffstat (limited to '2021/talks/structural.md')
| -rw-r--r-- | 2021/talks/structural.md | 71 |
1 files changed, 71 insertions, 0 deletions
diff --git a/2021/talks/structural.md b/2021/talks/structural.md new file mode 100644 index 00000000..1c9618f8 --- /dev/null +++ b/2021/talks/structural.md @@ -0,0 +1,71 @@ +[[!meta title="Why structural editing is the future of code editing, and a novel approach for editing everyday languages"]] +[[!meta copyright="Copyright © 2021 Ethan Leba"]] +[[!inline pages="internal(2021/info/structural-nav)" raw="yes"]] + +<!-- You can manually edit this file to update the abstract, add links, etc. ---> + + +# Why structural editing is the future of code editing, and a novel approach for editing everyday languages +Ethan Leba + +I liken the state of code editing today to the early days of computer +science, +when assembly was the only language available. When writing assembly, first +we +think of how they want the logic of the program to behave, and then secondly +translate this logic into Assembly. A tedious and error-prone process – +like +shoving a square peg into a round hole. But how could it be otherwise? +That's +simply what 'programming' was… until we realized there were far better +ways to +suit our languages to fit the way that we humans think. + +The problem with assembly is that fundamental building blocks of the +language don't match the way we think of programs: we don't think in +terms of pushing and popping registers, we think in terms of +variables, functions, etc. So when we write and edit code, why do we +edit in terms of deleting, inserting, replacing characters – +not wrapping, inserting, raising and deleting expressions and +statements? Because of the mismatch between the way we reason about +code and the way that we edit it, we must translate our intents into +the sequence of character manipulations that achieve it. + +In this talk, I'd like to discuss a vision for how writing code could be – +A +paradigm where the editing operations match the way that we think. I'll also +demonstrate a work-in-progress package 'tree-edit', which seeks to achieve +this +vision, providing a framework for structural editing in any language that +the +tree-sitter package supports. + +I'd also like to discuss the implementation of 'tree-edit', which uses an +embedded logic programming DSL in a novel way to power it's syntax tree +generation. + + + +# Outline + +- 5-10 minutes: (brief description/outline) + - discuss motivation + - demonstrate tree-edit + - demonstrate tree-edit syntax tree generation engine + +<!-- +- 20 minutes: (brief description/outline) + - discuss motivation + - discuss prior art (paredit, lispy) + - demonstrate tree-edit + - demonstrate and discuss tree-edit syntax tree generation engine + +- 40 minutes: (brief description/outline) + +same as 20 minutes, with more detailed discussion of the implementation. + +--> + +[[!inline pages="internal(2021/info/structural-schedule)" raw="yes"]] + +[[!inline pages="internal(2021/info/structural-nav)" raw="yes"]] |