1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
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"]]
|
