diff options
| author | Aki <please@ignore.pl> | 2021-07-25 19:17:40 +0200 |
|---|---|---|
| committer | Aki <please@ignore.pl> | 2021-07-25 19:17:40 +0200 |
| commit | ad76e9b885c9b9692074cf5b8b880cb79f8a48e0 (patch) | |
| tree | 603ebe1a1dbcd9251c84c1c954b7b4dc5b986cc3 /hunt_for_lex_and_yacc_the_dinosaur.html | |
| download | ignore.pl-ad76e9b885c9b9692074cf5b8b880cb79f8a48e0.zip ignore.pl-ad76e9b885c9b9692074cf5b8b880cb79f8a48e0.tar.gz ignore.pl-ad76e9b885c9b9692074cf5b8b880cb79f8a48e0.tar.bz2 | |
Initialized website as git repository
Diffstat (limited to 'hunt_for_lex_and_yacc_the_dinosaur.html')
| -rw-r--r-- | hunt_for_lex_and_yacc_the_dinosaur.html | 71 |
1 files changed, 71 insertions, 0 deletions
diff --git a/hunt_for_lex_and_yacc_the_dinosaur.html b/hunt_for_lex_and_yacc_the_dinosaur.html new file mode 100644 index 0000000..a783a20 --- /dev/null +++ b/hunt_for_lex_and_yacc_the_dinosaur.html @@ -0,0 +1,71 @@ +<!doctype html> +<html lang="en"> +<meta charset="utf-8"> +<meta name="viewport" content="width=device-width, initial-scale=1"> +<meta name="author" content="aki"> +<meta name="tags" content="programming, language, abstract, semantic, structure, program"> +<link rel="icon" type="image/png" href="cylo.png"> +<link rel="stylesheet" type="text/css" href="style.css"> + +<title>Hunt for Lex and Yacc, the Dinosaur</title> + +<nav><p><a href="https://ignore.pl">ignore.pl</a></p></nav> + +<article> +<h1>Hunt for Lex and Yacc, the Dinosaur</h1> +<p class="subtitle">Published on 2020-06-20 23:36:00+02:00 +<p><q>Everything is text</q> we were told. Imagine that with this assumption we plan to take on a dinosaur. Indeed, this +is one of the greatest jokes ever done in history of programming. Lex manual page said that there is an asteroid that +will kill it for us. There is none, and the dinosaur is what we created ourselves and what we are made of. +<p>Human and computer interaction is quite limited. It doesn't help that we express ourselves in a very inefficient and +quite bizarre ways. The basis for a chunk of communication is a language, and using it in combination with text in order +to communicate with computers was undeniably a well-made choice, and perhaps even natural to some extent. Designing and +creating languages entirely to express what computer is supposed to do was an expected consequent action. Creation of +tools like <a href="http://dinosaur.compilertools.net/">Lex and Yacc</a> was also predictable, and obviously there is +nothing wrong with it.</p> +<img src="hunt_for_lex_and_yacc_the_dinosaur-1.png" alt="rifle"> +<p>With introduction like this, it feels like I haven't got anything else to write. Regarding this level of abstraction, +yeah, it's not like we can easily change ourselves as human beings. However, if we change the level, we have something +to discuss. That thing, or rather things are the form our written language takes, intermediate abstractions we use, and +tools or interfaces that are between us and the machine. +<p>I'll focus here on a selected tiny bit of the problem, and if you feel interested in the whole thing, check out e.g. +<a href="http://worrydream.com/">Bret Victor</a>'s talks, especially <a href="https://vimeo.com/115154289">The Humane +Representation of Thought</a>. +<p>Now then, for me it looks like the source code is dominantly structured similarly to books. It has table of content, +maybe index, and the content itself. Sometimes there might be some annotations or references to other books. In general, +the content is one sequence. It could be divided into chapters or paragraphs, but it's still one book. Source code +behaves the same way: it's one thing presented to the system that processes it. In some cases, the source is structured +using files as a unit, but the strictness of this approach varies, and the goal for such structuring is so that the +programmer can understand it better. In the end, computer usually receives the source as a whole anyway (like: "here, +the program consists of these files; parse them, compile, link, whatever"). +<p>The abstract structure of the program is pretty much always explained to the computer using the features present in +the language. It sounds obvious to do so. Thing is, we have more ways of expressing complex structures or hierarchies to +computer than just plain text. +<p>Files and databases. More generally, a dedicated <i>thing</i> that expresses <em>only</em> structure of the program. +Yes, even using a text file, if you must. It doesn't matter. What's important is to have a dedicated, readable for both +the programmer and the machine way of structuring the program (not just source) that is closer to a graph that's similar +to the abstract semantic graph. The closer we get to this graph representation, the easier it gets to maintain the +source and understand the program it describes. Name or parameter position changes, division of classes into smaller +pieces, movement of functions from one entity to another, separating entire functionality into an external module; all +of those and possibly more become either trivial or non-existent tasks. +<p>Of course, some of the mentioned methods are less capable than the others. Filesystems aren't really a tool to create +graphs, and text files are terrible at referencing. Additionally, a language that wants to be structured like this +should provide tools for developers. They should be simple and specialized with an interface that lets them be easily +integrated into more verbose toolsets. One example that tried something similar is Smalltalk with its environment. +<p>You may ask now: "Isn't that what IDEs are?" Similar, but not quite the same. Modern IDEs are the essence of the law +of the instrument: "I'm a text editor and the source is all text, therefore everything I do is change the text!" Some of +them just got better at it. The other problem is that they are external to the environment of the language. An intruder +that seeks information on its own. Look at LLVM and amazing things it produced by exposing smaller and smaller things to +developers. +<p>The goal is to extract part of the programming language into something new. The key is to find a balance between the +representation, readability, ease of integration, and the tooling. Modern programming languages try to accomplish that +through verbose text editing, which sooner or later might become a dead end. Exposing the representations that are used +internally by the compilers and interpreters to the external tools and the user either through data or small specialized +tools may help us to avoid such fate. Allowing user to interact with more abstract representations in a meaningful way +will prove itself beneficial. +<p>We are here not to kill a dinosaur. It's impossible for us to do as of now. We are here to reduce it to a smaller +animal. Perhaps a chicken. It will live on our farm, we will take care of it, and in exchange it will give us some eggs. +I believe we have more than just one way to describe the abstract programs that sit in our heads.</p> +<img src="hunt_for_lex_and_yacc_the_dinosaur-2.png" alt="chicken"> +</article> +<script src="https://stats.ignore.pl/track.js"></script> |