#languagedesign — Public Fediverse posts
Live and recent posts from across the Fediverse tagged #languagedesign, aggregated by home.social.
-
Just published my end-of-year overview. 2026 is the year I stop outlining and start building.
Would love to have a conversation with anyone interested in the topic!
https://warmsignull.github.io/posts/toward-a-unified-general-language-overview/
#programming #languagedesign #compilers #systemsprogramming #metaprogramming #introspection #opensource #buildinpublic
-
Just published my end-of-year overview. 2026 is the year I stop outlining and start building.
Would love to have a conversation with anyone interested in the topic!
https://warmsignull.github.io/posts/toward-a-unified-general-language-overview/
#programming #languagedesign #compilers #systemsprogramming #metaprogramming #introspection #opensource #buildinpublic
-
Just published my end-of-year overview. 2026 is the year I stop outlining and start building.
Would love to have a conversation with anyone interested in the topic!
https://warmsignull.github.io/posts/toward-a-unified-general-language-overview/
#programming #languagedesign #compilers #systemsprogramming #metaprogramming #introspection #opensource #buildinpublic
-
Just published my end-of-year overview. 2026 is the year I stop outlining and start building.
Would love to have a conversation with anyone interested in the topic!
https://warmsignull.github.io/posts/toward-a-unified-general-language-overview/
#programming #languagedesign #compilers #systemsprogramming #metaprogramming #introspection #opensource #buildinpublic
-
After thought (thought I didn’t plan to put into it), I don’t think "NULL coalescing" and "NULL chaining" needs to be built in to the #ProgrammingLanguage, and here’s why:
* If you’re getting just one thing, the getter can take an optional default result value. #Python works like this in `getattr`, `.get`, and things of that nature. Having an operator for this is fine, but it seems obvious you don’t **need** the language to do it for you.
* If you’re walking down a long uncertain chain, I have two arguments:
* Knowing the path that leads down into the object to the specific thing you want kinda sounds like an #Encapsulation violation. Why do you know so much about the internals of this object. If this deep property is important, maybe it’s part of the interface of the top-level thing. Maybe this is just bad design.
* Diving deeply involves lots of possibilities: possible defaults, actual methods of finding the named thing (allow inheritance? Is it an attribute? Is it an element of an array? Etc), did you want to just stop or raise an exception?Does saying what you want really come out to a simple, clean, understandable, one-line, expression?Maybe I’m biased because I don’t have these operators in my day-to-day language; and also can’t remember hitting this situation. And I can certainly see such operators could be helpful. I’m not a language designer. But from my actual experience, in this case, the juice just isn’t worth the squeeze.
-
Kotlin and Go couldn't be approaching their error handling pains more differently.
Go: https://go.dev/blog/error-syntax
Kotlin: https://medium.com/@internetcreationist/exploring-rich-errors-in-kotlin-a-game-changer-from-kotlinconf-2025-ea11ae23b585TL;DR: While Kotlin is getting rich errors, Go is getting... nothing. And please stop asking for it, the community clearly won't come to a consensus.
Like it or not, `if err != nil` is here to stay.
#GoLang #Kotlin #ErrorHandling #LanguageDesign #ProgrammingLanguages #DevThoughts
-
As I think I mentioned recently (in my LispNYC talk?), McCarthy, at least by time of the standards, wanted there not to be any single dialect of Lisp that claimed the unadorned name Lisp. So there was syntactic room for dialects to compete.
There was discussion in design of EuLisp, an influence on ISLISP, about layers. EuLisp had 3 layers, I think. That layering didn't make it into ISLISP. I don't recall it being proposed for CL, though I might be forgetting at this point.
It was never clear to me, though I was not part of their community, whether the underlying language was a subset of, or just an implementation language for, the surface language.
My only very concrete memory was that someone wanted some transform T such that L1 = T(L0) to be applied at some point. Maybe this came up in the CL macros committee. I was pretty adamant that CL did not need macro "hygiene" like Scheme has.
The urgency of that is due to Scheme's choice of being what I called a Lisp1 (the names Lisp1 and Lisp2 in this context are no relation to versioning you referred to in reference to Lisp 1.5, but are abstract categories that address how many variable namespaces are in the language).
Various characteristics of CL, including but not limited to being a Lisp2, helped insulate it from name collisions in the macro system, so the macro system didn't need to have formal hygiene like in scheme, or so I claimed.
I don't think the CL community wanted to change its macro system. Indeed I'd go so far as to say the easy writing of macros is strongly correlated with the rapid success of the family of Lisps that became CL. Breaking something that was succeeding wildly seemed ill-advised, or at least that's how I perceived things. Obviously this was a community discussion.
The fact of a package system rather than a lexical module system was also relevant to this. It's a subtle issue, but important. Scheme is a language defined by its programs' texts. In Common Lisp, the language semantics is on objects.
Speaking only very approximately here for brevity, the compiler operates on lists made of conses and symbols, not text made of parens and alphanumeric tokens. So there need be no source text in CL. Gensyms can easily be created by macros for variable names in CL, something you can't do in Scheme without help of a hygienic macro system to do rewrites for you. The use of gensyms further insulates macros from name collisions that would be routine in scheme if it had a CL-style macro system.
I think the way in which the package system, the macro system, and the namespacing form a kind of ecosystem is ill-understood by most users, even though they're comfortable with the effect. It only matters to understand it if someone suggests changing one of these without changing the others.
It's sometimes hard for someone from the Scheme community to understand why macro hygiene isn't needed in CL if they don't get how packages are fundamentally different than lexical namespacing. So they propose isolated changes thinking it will solve a problem that isn't really there. It's also hard for them to get why CL users see such proposals as adding complexity rather than removing it.
Goung one level meta, it's worth observing that there are not good language features and bad language features, but good within a context or bad within a context. People sometimes get a feature they like and want to impose it on other languages, not seeing that's harmonious in some and not others.
Context matters in assessing abstracts like goodness. It's the harmony of the ecosystem that matters. Adopting change, even well-meaning change, can be very disruptive, sometimes causing unexpected cascade effects (and community cost in both dollars and happiness) one doesn't realize will be needed.
Some of this is covered in the paper Gabriel and I wrote called Technical Issues of Separation in Function Cells and Value Cells. We were tasked by X3J13 to write such a thing because we disagreed on how things should go and between the two of us would likely hit all the issues. :) If you read carefully, you'll see the paper is a kind of debate between us where one would say something and the other would say "yeah, but.." and inject counterpoint. (This is the origin of the namespacing categories Lisp1/Lisp2. Also, the original paper, titled just Issues of Separation in Function Cells and Value Cells was longer and more X3J13-specific. We tightened it up for journal publication, mostly at Gabriel's insistence, as "Technical Issues..." to emphasize some dropped politics.) https://www.nhplace.com/kent/Papers/Technical-Issues.html
I may be far afield and I have no idea if that answers your question or just creates more questions, so I'll stop. :)
#CommonLisp #EuLisp #ISLISP #Lisp #Macros #HygienicMacros #LanguageDesign #Standardization