blob: 5fc20f4b6299e8a7d244062a694189027ca52216 (
plain)
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
|
---
title: "Link clearance #1"
date: 2025-03-19T17:13:00-07:00
---
This series isn't periodical at all. It'll come out whenever I have enough of them accumulated over time.
- [Famous hotel signs](https://www.ling.upenn.edu/~beatrice/humor/foreign-hotel-signs.html). If I recall correctly this is linked from a Hacker News discussion on... something linguistics. The rest of the posts on this site are equally funny though.
- [Mozart2](http://mozart2.org) and [Clean](https://clean-lang.org). Two languages linked from The Lisp Curse post for being containing novel and desirable features, being not Lispes (and thus not the /most powerful thing ever/) yet still everyone can learn from.
- Two discussions on parsing from the [Oils](https://github.com/oils-for-unix/oils/wiki/Lossless-Syntax-Tree-Pattern) [shell](https://github.com/oils-for-unix/oils/wiki/Parsing-is-Difficult) project.
For the ambitious compiler writers who like to reuse their parsing infrastructure for editor tooling as well. See the HN and reddit links, there are some interesting back and forth in there too.
A few other descendent links that may be interesting and hard to find:
- [Python's pgen](http://python-history.blogspot.com/2018/05/the-origins-of-pgen.html).
- [On context-sensitivity]( https://eli.thegreenplace.net/2011/05/02/the-context-sensitivity-of-cs-grammar-revisited).
- Some sort of [omni-compiler-framework](https://kythe.io/docs/kythe-compatible-compilers.html)?
- [bnfc](https://github.com/BNFC/bnfc)
- Computer Science - Brian Kernighan on successful language design - [YouTube](https://www.youtube.com/watch?v=Sg4U4r_AgJU)
- A rather [interesting project](https://github.com/rtk0c/WinXInputEmu) that tries to do what my [WinXInputEmu](https://github.com/rtk0c/WinXInputEmu) does, but with remote thread code execution to patch out system functions instead of doing DLL hijacking. Looks much more featureful and much /much/ more complicated (likely unnecessarily).
- Pair of twin articles on [libraries](http://trevorjim.com/libraries-and-open-access) and [open access](http://trevorjim.com/open-access-should-not-mean-sole-access).
All of publishers (money!!?!?) and libraries (out of control) and readers (difficulty in accessing) hates electronic journals. A different route: stop doing the _storage_, stop trying to emulate physical paper electronically — produce PDF or whatever, send to customers, done. Let the libraries take care of the website and everything just like how they take care of printed materials. Maintain a minimal internal archive, suddenly a lot of cost and product leakage_ concerns are gone.
One notable descendent, [what are libraries for](http://web.archive.org/web/20110723192224/http://www.inthelibrarywiththeleadpipe.org/2011/what-are-libraries-for/) (out of the many in there):
- [For what is anything but a tool?](https://blog.sanctum.geek.nz/vim-koans)
- Yet another [pamphlet](https://research.swtch.com/vgo-mvs) (and fortunately, not a treatise) on dependencies.
|
