If your language guide isn't a powermetal song, what are you even doing?
https://www.youtube.com/watch?v=BsfXZjKLT9A
#powermetal #nanowarOfSteel #kotlin #jvm #languageDesign #programmingLanguages #devMetal

If your language guide isn't a powermetal song, what are you even doing?
https://www.youtube.com/watch?v=BsfXZjKLT9A
#powermetal #nanowarOfSteel #kotlin #jvm #languageDesign #programmingLanguages #devMetal

Question for the #programminglanguagetheory crowd.
When you define a parameterized type, you often need to put constraints on the type parameter.
For example, for a set implementation you'd want the type to be orderable, if you're implementing it with some sort of search tree, or equatable, if you're using something like linear search. But this leaks implementation details. You can't just change the implementation later because it might break client code.
I don't see an easy way around this, if you want to keep the requirements on the type parameter to a minimum. Is there any literature around this, or is this just how things are and we live with it?
#programming #programminglanguages #programminglanguagetheory #languagedesign
Running Code in a Programming Language Nobody Knows
Last month, I ran code in a programming language that nobody knew.
I'm not the first to do a thing like that. Ben Olmstead created Malbolge in 1998. It's a deliberately incomprehensible programming language that's likely impossible for anyone to really know; it took a search algorithm to generate the first program for it. Finding examples of an old, obscure language with no surviving practitioners is another potential method I imagine has been done a few times.
Nobody had ever known Nucleus when its compiler bootstrapped. Since it's 2026, I imagine many readers have already guessed large language models were involved. I gave a sample program and output to an LLM tool and told it to write a compiler in C. I then told the tool to add features to the language until it could rewrite the Nucleus compiler in Nucleus, resulting in a language that I did not know. LLMs do not "know" things and aren't somebody, so at that point, nobody knew Nucleus, yet there were about 4000 lines of it running in the compiler, able to produce real binaries that run on real computers.
Someone I mentioned this to asked why I would want to design a programming language without designing a programming language. I don't actually want to do that, but just as the compiler needed an initial implementation in another language in order to bootstrap, I found it much easier to work from a minimal working language than a blank slate. I had the idea for Nucleus for a long time and have not yet read the Dragon Book and written a compiler from scratch like I told myself I was going to.
As for the language itself, the basic idea is a language for manipulating memory at a low level like C, but with Lisp-like syntax and structural macros providing compile-time abstractions and safety-enhancing constructs with no runtime overhead. By the time it hits 1.0, Nucleus should be usable as a drop-in replacement for C anywhere C is used. I'm not the first to do a thing like that either, but other implementations I've seen actually compile a Lisp-like language to C. Nucleus targets LLVM directly.
I love how C# designers are trying to speedrun the reinvention of unions. 😅
I treat := as a proxy for "the language creator is at least slightly annoying".
I have been happy with the hit rate so far.
People need to stop taking language design advice from language creators whose only accomplishment is that their language got popular.
@CGM I see good in this: new and useful powers for #Python.
I see bad in this: a thing we knew about for a long time, present elsewhere, why so long coming?
I see neutral in this: things that can be provided by libraries instead of directly in the language should absolutely start in a library. If they earn a spot in the language itself, great.
I see sad in this: these words make it sound like #TCL is ahead and Python is behind overall. That doesn’t match my opinion or personal experience. Absolutely agree on this particular feature. And also I have stated many times "there is no best language", just choices more or less cost-effective for the problem at hand.
For the problems I’ve faced, with the tools I’ve had available, Python has been a more cost-effective choice than TCL the majority of the time. From your words, I took that you prefer TCL. Nothing wrong with that!
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.