diff options
| -rw-r--r-- | 2021/talks/structural.md | 68 |
1 files changed, 27 insertions, 41 deletions
diff --git a/2021/talks/structural.md b/2021/talks/structural.md index 70bf077a..889de8a0 100644 --- a/2021/talks/structural.md +++ b/2021/talks/structural.md @@ -8,50 +8,36 @@ # Tree-edit: Structural editing for Java, Python, C, and beyond! 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. - - +In this talk, I'll discuss a vision for how writing code could be, where the +editing operations map directly to the primitives of the language itself -- and +my humble attempt of implementing this vision. **tree-edit** seeks to provides a +structural editing plugin supporting conceivably any language with a tree-sitter +parser. + +**Structural editing does not have to be relegated to lisps or niche DSLs.** + +I liken the state of code editing today to writing assembly. The reason why +people like Python more than assembly is that for most purposes, the building +blocks of the language are mismatched with our thought process. We don't think +in terms of registers and addresses, 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, +deleting expressions and statements? + +I'll also discuss the implementation of `tree-edit`, which uses a novel +combination of the fantastic +[tree-sitter](https://github.com/emacs-tree-sitter/elisp-tree-sitter) parser +with an embedded logic programming DSL ([miniKanren](http://minikanren.org/), +using elisp port [reazon](https://github.com/nickdrozd/reazon)) to power it's +syntax tree generation. + +Check out the GitHub repo at: https://github.com/ethan-leba/tree-edit # Outline -- 5-10 minutes: (brief description/outline) - - discuss motivation - - demonstrate tree-edit - - demonstrate tree-edit syntax tree generation engine +- Discuss motivation (Why should I care?) +- Demonstrate tree-edit (Live-coding with `tree-edit`) +- Demonstrate tree-edit syntax tree generator (Elevator pitch on miniKanren) <!-- - 20 minutes: (brief description/outline) |