forked from lamdu/lamdu.github.io
-
Notifications
You must be signed in to change notification settings - Fork 0
/
index.html
331 lines (221 loc) · 20.9 KB
/
index.html
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
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
<!DOCTYPE html>
<html>
<head>
<meta charset='utf-8' />
<meta http-equiv="X-UA-Compatible" content="chrome=1" />
<meta name="description" content="Lamdu : Lamdu - towards the next generation IDE" />
<link rel="stylesheet" type="text/css" media="screen" href="stylesheets/stylesheet.css">
<title>Lamdu</title>
</head>
<body>
<!-- HEADER -->
<div id="header_wrap" class="outer">
<header class="inner">
<a id="forkme_banner" href="https://github.com/Peaker/lamdu">View on GitHub</a>
<h1 id="project_title">Lamdu</h1>
<h2 id="project_tagline">Lamdu - towards a new programming experience</h2>
</header>
</div>
<!-- MAIN CONTENT -->
<div id="main_content_wrap" class="outer">
<section id="main_content" class="inner">
<h1><a name="project-lamdu" class="anchor" href="#project-lamdu"><span class="octicon octicon-link"></span></a>Project Lamdu</h1>
<p>This project aims to create a next-generation live programming environment that radically improves the programming experience.</p>
<p>
<img src="http://i.imgur.com/hECq16R.gif"/><br>
"Live programming" means that the code is being executed as you type it.
</p>
<p>The main idea behind the Lamdu project is that the canonical representation of programs should not be text, but rich data structures: Abstract syntax trees.</p>
<p>Our programming tools, UIs and ecosystems should take advantage and expose this structure. This has some far-reaching implications, which will be described below.</p>
<h2><a name="programming-language" class="anchor" href="#programming-language"><span class="octicon octicon-link"></span></a>Programming Language</h2>
<p>
Lamdu's programming language is a functional programming language inspired by
<a href="https://www.haskell.org/">Haskell</a>.
Language's design decisions <a href="https://medium.com/lamdu-blog/designing-programming-languages-with-ides-in-mind-de890989dfa">are affected by the different trade-offs</a> of live programming and AST editing, and for this reason Lamdu isn't made for an existing textual language.
</p>
<p>We believe that Haskell is a good inspiration for Lamdu's language due to 2 main traits:</p>
<ul>
<li>
<strong><a name="rich-and-powerful-type-system" class="anchor" href="#rich-and-powerful-type-system"><span class="octicon octicon-link"></span></a>Rich and Powerful Type System</strong>
<p>Haskell has one of the richest and most powerful type systems, which allows a smart IDE to guide the programmer quickly through the space of type-correct programs. In practice, this reduces much of the cognitive burden of writing programs and the number of input gestures/keystrokes required to write or edit programs.</p>
<p>While static typing is considered a hurdle by many programmers who choose to use dynamically typed languages such as Python, we believe that a type-aware structural editor and type inference makes static typing easy to use, helpful and fun.</p>
</li>
<li>
<strong><a name="effect-typing" class="anchor" href="#effect-typing"><span class="octicon octicon-link"></span></a>Effect Typing</strong>
<p>Haskell has explicit type-level separation of effectful components from pure components.
Real Haskell programs demonstrate that the majority of code can be written as pure components.
This allows a live environment to actually execute code as it is being edited, safely, and bring the benefits of spreadsheets to general purpose programming.</p>
</p>
</ul>
<p>How Lamdu's language differs from Haskell:</p>
<ul>
<li>
<strong><a name="explicit-argument-names" class="anchor" href="#explicit-argument-names"><span class="octicon octicon-link"></span></a>Explicit argument names</strong>
<p>
<img src="http://i.imgur.com/t57WMQo.png" width=312/> <br/>
In function applications, arguments are tagged by names
rather than using their position to differentiate them
(similar to Objective-C).
</p>
<p>
Most programming languages, which use "positional arguments",
were designed for the programmers typing the code letter by letter,
and so they refrained from tagging the function arguments.
We believe that this tagging helps readability and also provides
helpful context when writing the code.
</p>
</li>
<li>
<strong><a name="eager-evaluation" class="anchor" href="#eager-evaluation"><span class="octicon octicon-link"></span></a>Eager evaluation / explicit lazy-evaluation</strong>
<p>
<img src="http://i.imgur.com/EKrwRme.gif"/> <br>
The example above uses the logical-or operator (aka "||"),
which does not compute the second predicate if the first one is true.
In most languages the logical-or operator is built into the language itself
(and not its library) as one cannot define it by themselves to not
evaluate its right argument when not needed.
</p>
<p>
Haskell allows users to define control structures such as logical-or
and many others, via its behavior of lazy evaluation -
expressions are not evaluated until their value is required.
But lazy-evaluation-everywhere also has drawbacks
(for example it makes memory use hard to predict).
</p>
<p>
To use eager evaluation but still get the benefits of lazy evaluation
(user/library defined control structures and many more)
we made the syntax for "deferred computations" (aka functions with no arguments)
very lightweight - simply a preceding ◗ symbol.
As the user uses the logical-or operator this gets written for them automatically on the operator's right side.
</p>
</li>
<li>
<strong><a name="structural-type-system" class="anchor" href="#structural-type-system"><span class="octicon octicon-link"></span></a>Structural type system</strong>
<p>
In many programming langauges defining structs/records
takes more effort than using "a tuple".
</p>
<p>
Lamdu, however, makes creating ad-hoc record types easy
without requiring the ceremonious type declarations.
So records are used instead of anonymous tuples,
making it easier to understand the meaning of values.
</p>
<p>
Lamdu's type system "gets out of your way" with full
row-polymorphism and column-polymorphism.
Nominal typing (type declarations) is also available and
is necessary for types which are hard for type-inference to infer,
such as recursive types and types with "higher-rank-polymorphism".
</p>
</li>
</ul>
<h2><a name="lamdu-benefits" class="anchor" href="#lamdu-benefits"><span class="octicon octicon-link"></span></a>Lamdu Benefits</h2>
<h3><a name="no-syntax-errors" class="anchor" href="#no-syntax-errors"><span class="octicon octicon-link"></span></a>No Syntax Errors</h3>
<p>Editing programs as rich structures means there are no syntax errors</p>
<h3><a name="incremental-type-errors" class="anchor" href="#incremental-type-errors"><span class="octicon octicon-link"></span></a>Incremental Type Errors</h3>
<p>Type errors are incremental, meaning that type information available from previous, valid states of the program is available to provide better, more localized type errors.</p>
<p>Incremental type checking is much cheaper than full recompilation as featured by mainstream IDE's, allowing a snappy experience.</p>
<p>Type error feedback is immediate, while the edit is still fresh in the programmer's mind.</p>
<p>Type errors are confined and localized to the sub-expression involved, made simple and comprehensible.</p>
<p>Type information is not lost when type errors exist, allowing the IDE to guide the programmer in resolving type errors intelligently.</p>
<h3><a name="better-completions" class="anchor" href="#better-completions"><span class="octicon octicon-link"></span></a>Better Completions</h3>
<p>When types are rich enough, much of the program structure can be inferred from the types.</p>
<p>This affords significantly more powerful and intelligent completions than found in mainstream IDE's.</p>
<h3><a name="live-execution" class="anchor" href="#live-execution"><span class="octicon octicon-link"></span></a>Live Execution</h3>
<p>Frees the programmer from having to trace code execution in their head.</p>
<p>Debugging pure code means expanding sub-expressions that have the wrong result, and following through the sub-expressions that contain the mistakes. This should be a much easier experience than stepping through code.</p>
<h3><a name="safe-refactoring" class="anchor" href="#safe-refactoring"><span class="octicon octicon-link"></span></a>Safe Refactoring</h3>
<p>The IDE has much stronger guarantees about the meaning and structure of the code. This allows refactoring to be <em>completely</em> safe.</p>
<p>Safe refactoring allows programmers to keep the code tidy, without fear of regressions.</p>
<h3><a name="better-collaboration" class="anchor" href="#better-collaboration"><span class="octicon octicon-link"></span></a>Better Collaboration</h3>
<p>One of the most difficult things about collaborative development is handling merge conflicts.</p>
<p>The vast majority of merge conflicts are results of non-functional changes: Renames, reformatting, textual movement of code lines between files, etc.</p>
<p>In Lamdu, "names", the "position" of the code and other non-functional aspects of code are separate from the code itself, and avoid conflicts.</p>
<h4><a name="rename-conflicts" class="anchor" href="#rename-conflicts"><span class="octicon octicon-link"></span></a>Rename conflicts</h4>
<p>To get a conflict due to "rename" operations, two developers must rename the same variable to two different names. Even then, the code is still executable, but its on-screen rendering will display a localized conflict.</p>
<h4><a name="formatting-conflicts" class="anchor" href="#formatting-conflicts"><span class="octicon octicon-link"></span></a>Formatting conflicts</h4>
<p>Formatting is automatic, so there is no way to generate a conflict.</p>
<h4><a name="code-movement-conflicts" class="anchor" href="#code-movement-conflicts"><span class="octicon octicon-link"></span></a>Code movement conflicts</h4>
<p>The "position" of code is meta-data attached to the code, helping to find that code and position its rendering.</p>
<p>Since code is not structured into text files, code "position" conflicts are similarly less harmful, less likely and localized.</p>
<h4><a name="change-tracking" class="anchor" href="#change-tracking"><span class="octicon octicon-link"></span></a>Change tracking</h4>
<p>Instead of heuristically guessing what changed in the code, as traditional version control systems do, Lamdu uses an integrated revision control system and records the changes by the programmer as revisions.</p>
<p>This acts as a record of the developer's intent, allowing the RCS to distinguish, for example, between function deletion and writing of a similar function, and the modification of that same function. The recording of intent helps prevent and resolve conflicts.</p>
<h3><a name="regression-debugging" class="anchor" href="#regression-debugging"><span class="octicon octicon-link"></span></a>Regression Debugging</h3>
<p>Integrated revision control and live test cases will allow "Regression Debugging".</p>
<p>When a change causes a regression, the root of the problem can be found quickly, by finding the deepest function application whose result value diverged from the correct version of the code.</p>
<h3><a name="automatic-formatting-and-sugaring" class="anchor" href="#automatic-formatting-and-sugaring"><span class="octicon octicon-link"></span></a>Automatic Formatting and Sugaring</h3>
<p>Lamdu attempts to take away as much inconsequential freedom from the developer, to free his mind and his key strokes to deal with the parts that matter in the code. Thus, Lamdu does not provide means to edit formatting on a case-by-case basis. Generalized changes to layout rules can be provided, instead.</p>
<p>Additionally, to avoid further stylistic dilemmas, Lamdu uses automatic sugaring of code, as a duel of the typical "de-sugaring" done by textual languages.</p>
<p>The code is edited and displayed in its sugared form. The edits to this form are translated to lower-level, simpler edits of the stored language, which is de-sugared. Lamdu uses "co-macros" that capture patterns in the lower-level code and automatically sugar it to canonical form. This frees the programmer from worrying about whether to use sugar for each particular case.</p>
<h3><a name="visualization" class="anchor" href="#visualization"><span class="octicon octicon-link"></span></a>Visualization</h3>
<p>Textual languages can have extensible syntax for rendering and parsing values of custom-defined data-types. A rich structural IDE can take this further, and allow defining extensible UI components to render and edit values of custom-defined data-types.</p>
<p>In effect, this allows for more powerful DSL extensions to the language. These DSLs are not just custom data-types and combinators, but also rich UIs with optimized key bindings to work with that DSL.</p>
<p>For example "do notation" can be implemented as a co-macro (see above) to capture the >>= to lambda syntactic form. Then, a customized UI that edits the "do notation" sugared form can be provided, extending the language.</p>
<p>Similarly, a binary tree implementation may be edited with a rich UI that visualizes the trees. The inputs, outputs and subexpressions with tree-typed values will use such rich visualizations, instead of flat textual renderings.</p>
<h3><a name="transparent-build-process" class="anchor" href="#transparent-build-process"><span class="octicon octicon-link"></span></a>Transparent Build Process</h3>
<p>Today's tools treat the compiler as an opaque, black box, which may or may not apply a set of optimizations to the source code, with great or catastrophic results. Some experts are aware of tooling options to display the intermediate steps in the compiler in an arcane, difficult-to-understand notation.</p>
<p>We intend to make the build process, including compilation, be an explicit pure transformation of the code into intermediate and final forms. The steps of this transformation can be visualized by the live programming environment similarly to the visualization of execution of all pure code.</p>
<p>This will allow far easier inspection of the optimization process, taking away much of the "magic" involved in getting optimizations to fire properly.</p>
<h1><a name="similar-efforts" class="anchor" href="#similar-efforts"><span class="octicon octicon-link"></span></a>Similar Efforts</h1>
<h2><a name="inventing-on-principle" class="anchor" href="#inventing-on-principle"><span class="octicon octicon-link"></span></a>Inventing on Principle</h2>
<p>
<a href="http://worrydream.com/">Bret Victor</a> presented amazing demos in his <a href="http://vimeo.com/36579366">inspiring talk in January 2012</a>.
He made quite a convincing case for "live programming" which inspired several projects in this field.
Since then he made <a href="http://worrydream.com/#!/DrawingDynamicVisualizationsTalk">more impressive demos</a>.
</p>
<h2><a name="alive" class="anchor" href="#alive"><span class="octicon octicon-link"></span></a>Alive</h2>
<p>
<a href="https://comealive.io/">Alive</a> is a plugin for Visual Studio
that provides live coding features for C#.
It is a commercial product currently in Beta.
</p>
<h2><a name="unison" class="anchor" href="#unison"><span class="octicon octicon-link"></span></a>Unison</h2>
<p>
<a href="http://unisonweb.org">Unison</a> by Paul Chiusano is another next-generation programming platform project.
</p>
<h2><a name="light-table" class="anchor" href="#light-table"><span class="octicon octicon-link"></span></a>Light Table and EVE</h2>
<p>Inspired by Bret Victor, <a href="http://www.kickstarter.com/projects/ibdknox/light-table">Light Table</a> by Chris Granger is an IDE with some "live coding" features. Chris launched the project at <a href="http://www.kickstarter.com/">Kickstarter</a> at April 2012 and raised more than 300K$ for the project.
Soon after Chris founded a company, <a href="http://www.kodowa.com/">Kodowa</a>, with Robert Attorri, which joined Y-Combinator's "Summer 2012 batch".</p>
<p>Chris moved on and is now working on <a href="http://witheve.com/">project "EVE"</a> where they design a new programming language aiming to bring the power of computation to everyone</p>
<h2><a name="projucer" class="anchor" href="#projucer"><span class="octicon octicon-link"></span></a>Projucer</h2>
<p><a href="https://www.juce.com/projucer">Projucer</a> by Julian Storer (Jules), also inspired by Bret Victor, is a live programming IDE for C++ using the Juce cross-platform framework.</p>
<p>It integrates with <a href="http://llvm.org/">LLVM</a>'s just-in-time compiler to provide fast compilation and advanced features similar to those in Bret Victor's demos. It aims to be a "Light Table for 'Real Programmers'".</p>
<p>It initially aims to provide live coding specifically to GUIs, but later for other uses, specifically uses in the Audio niches in which Jules and Juce focus on.</p>
<p>Projucer is not open source and is planned to be a commercial IDE.</p>
<p>The project launched at September 2012 and it looks like Jules was mostly busy with other projects since then.</p>
<h2><a name="subtext" class="anchor" href="#subtext"><span class="octicon octicon-link"></span></a>Subtext</h2>
<p><a href="http://subtextual.org/">Subtext</a> by Jonathan Edwards is a similar effort from 2004.</p>
<p>In his <a href="http://subtextual.org/demo1.html">Subtext 1</a> demo and talk, Edwards presents a live programming environment of a simple dynamic language.</p>
<p>In his <a href="http://www.subtext-lang.org/subtext2.html">Subtext 2</a> demo, Edwards presents an inspiring way to edit canonical representations of conditional and type-dispatch code.</p>
<p>The Subtext project was the main inspiration for the Lamdu project.</p>
<h2><a name="conception" class="anchor" href="#conception"><span class="octicon octicon-link"></span></a>Conception</h2>
<a href="https://github.com/shurcooL/Conception-go">Conception</a> by Dmitri Shuralyov is a interactive IDE for Go inspired by Bret Victor, Light Table and Subtext.
<h2><a name="other-related-links" class="anchor" href="#other-related-links"><span class="octicon octicon-link"></span></a>Other Related Links</h2>
<ul>
<li><a href="http://www.youtube.com/watch?v=TS1lpKBMkgg">We're doing it all wrong</a> by Paul Phillips: Paul describes his frustrations with Scala and programming general, and describes a vision we believe overlaps with the Lamdu project greatly.</li>
<li><a href="http://www.youtube.com/watch?v=pqtqaL_ojpk&feature=plcp">Functional programs that explain their work</a>.</li>
</ul>
</section>
</div>
<!-- FOOTER -->
<div id="footer_wrap" class="outer">
<footer class="inner">
<p class="copyright">Lamdu maintained by <a href="https://github.com/Peaker">Peaker</a> and <a href="https://github.com/yairchu">yairchu</a></p>
<p>Published with <a href="http://pages.github.com">GitHub Pages</a></p>
</footer>
</div>
<script type="text/javascript">
var gaJsHost = (("https:" == document.location.protocol) ? "https://ssl." : "http://www.");
document.write(unescape("%3Cscript src='" + gaJsHost + "google-analytics.com/ga.js' type='text/javascript'%3E%3C/script%3E"));
</script>
<script type="text/javascript">
try {
var pageTracker = _gat._getTracker("Lamdu");
pageTracker._trackPageview();
} catch(err) {}
</script>
</body>
</html>