Re: making Code More Accesible
This text is an excerpt from my reply to an inquiry I received about Glisp. The sender was interested in my thoughts on the difficulties of learning programming languages and their bias toward English, which they asked about in a previous email.
- - -
Hi ***,
Thank you so much for reaching out! I’m really interested in ***** and would love to learn more about which domain you’re designing the language for and what kind of syntax you’re considering.
Although I haven’t made much progress on implementing Glisp itself in recent years, I’ve been actively developing peripheral libraries that function as its “standard library”—such as linear algebra utilities and a reactive programming system that handles user I/O. While Glisp is currently focused on vector-based graphic applications, my ultimate goal has been to create a general-purpose language that extends “programmability” to GUI-based software. Rather than being a language for writing traditional programs, Glisp is designed to function more like a configuration/project format—akin to XML or JSON—that can be used in design tools. To achieve this, I’m working on implementing a purely functional, declarative evaluation strategy with lazy evaluation, where computations propagate backward from the needed subexpressions. I hope to have this implemented by the end of the year.
Regarding the challenges of learning coding and the “ Latin script-centrism” in programming language design, I strongly resonate with these issues as a Japanese speaker.
Why Syntax Matters Less in a Visual Programming Context
For the former, Glisp is ultimately meant to be integrated with a visual programming (VP) environment. S-expressions, with their heavy use of parentheses, are often seen as intimidating—even among programmers (except perhaps traditional Lisp hackers like Paul Graham). Compared to mainstream languages, Lisp syntax can feel unapproachable. However, in the context of VP, the situation changes drastically: the textual syntax itself becomes secondary, and what truly matters is the simplicity of the Abstract Syntax Trees (ASTs). This was the primary reason I chose Lisp—its syntax tree structure is simple enough to be directly passed as props to UI frameworks like React or Vue, and it makes easy to implement parsers and evaluators in other host languages. Of course, to be honest, another reason is that I’m not a formal computer science graduate—Lisp just made language implementation easier for me! Interestingly, JSON, despite being syntactically verbose, is still widely used—especially for API responses. This suggests that human writablitiy and readability isn’t always the highest priority in domains where code is primarily written and read by programs rather than humans. This is even more evident in VP environments.
If we dig deeper into human readability, it’s fundamentally about minimizing working memory usage when reading sequentially in a linear medium like text. In this regard, deep nesting must be avoided. Most languages try to mitigate this through infix notation, shorthand syntax, and syntactic sugar to make nesting visually shallower. However, this comes at the cost of parsing complexity, requiring operator precedence rules and token backtracking. It also increases the cognitive burden on users, who must remember precedence rules and associativity—left or right. While basic precedence like ^ > * > + is intuitive to most programmers with a middle-school math background, things get more complex in languages like Haskell, where operators themselves can be user-defined.
Latin Script-Centrism in Programming
When it comes to the issue of Latin-script Centrism in programming, Glisp takes a simple approach to addressing this issue: it just eliminates built-in reserved keywords based on English. Fortunately, in Lisp, control structures like if or while are just ordinary macros. By allowing any Unicode characters in symbols, users can define aliases in their native language.
For syntax elements like let or function, where traditional languages use reserved keywords, I’ve opted for symbol-based syntax that doesn’t rely on words. For example, function definitions can use=> (e.g. (=> [x] (* x 2))), and scope declarations can be written like this:
code:clj
{
x = 1
y = 2
(+ x y)
}
However, for constructs like match, which require more specialized parsing rules, I’m still debating whether to assign symbolic representations.
A more fundamental issue is that, even if we allow multilingual symbol names, the way function application is structured mentally follows an implicit grammatical model. English and many other languages position verbs before objects (V O1 O2 ... ), but Japanese follows an O1 O2 V structure.
One potential solution is to make the language purely functional, treating function application as a noun phrase with adjectival arguments, rather than an imperative command. However, even this doesn’t fully address the issue—grammatical structures like postpositional adjectives (e.g., Noun Adj1 Adj2 ...) are specific to Romance languages like French or Italian.
While Lisp macros are generally powerful enough to introduce infix or postfix notation, Glisp’s tight coupling with a VP environment makes preprocessing-based syntax transformations less viable.
Anyway, the linguistic biases in programming languages and the mental models enforced by syntax are fascinating topics from an HCI perspective as well. If you know of any prior research in this area, I’d love to hear about it.
Apologies for the lengthy response—your email gave me an opportunity to rethink my project, and I may even write a blog post about it later.
I’d be happy to chat online! However, I’m not the most confident English speaker, so I’d appreciate it if you could share a bit more about your research background and the current design of ***** beforehand.
Looking forward to your response!