Rework tree-edit abstract

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)