From 886ae437fee6a674f7b2757062f1b8a91275457a Mon Sep 17 00:00:00 2001
From: Sacha Chua <sacha@sachachua.com>
Date: Fri, 8 Oct 2021 01:58:03 -0400
Subject: Add talk pages for 2021

---
 2021/talks/structural.md | 71 ++++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 71 insertions(+)
 create mode 100644 2021/talks/structural.md

(limited to '2021/talks/structural.md')

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 &copy; 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 &#x2013;
+like
+shoving a square peg into a round hole. But how could it be otherwise?
+That's
+simply what 'programming' was&#x2026; 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 &#x2013;
+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 &#x2013;
+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"]]
-- 
cgit v1.2.3