I've struggled to answer the question "what is this language for?" other than "it's just for me" — and that's probably good enough. But I also wanted to make something "complete" that others could use if they wanted to. Writing my own language was an incredibly rewarding experience, and I'd recommend everyone trying it.
Let me know if you have any questions or feedback, and please share your own experience if you've also made a language.
Auto-formatting is also easy: just don't do it. Does a toy language really need it? I have two languages with syntax coloring and zero languages with auto-formatting. I think syntax coloring is table stakes but auto-formatting is not. You can have an interesting toy language without auto-formatting.
> Auto-formatting is also easy: just don't do it.
I agree with this, except that auto-closing grouping symbols is extremely useful and turns out to be pretty easy to support.
Writing code that you love is like crafting it. You align subjects and data in beautiful flows of if/else or case/switch. You put multiple statements on a line if they encompass one "thought"
Try writing without a formatter when you are the sole author.
As for syntax highlighting I agree. You can get 80% of the way there with a vim regex of keywords, but it's one of the main things I'm solving by writing my own editor.
This doesn't have to be true! Zig's `zig fmt` doesn't wrap on column count but instead lets you insert breaks with a ",". While this does introduce a level of user discretion which can diminish the braindeadness of autoformatters, I find that it works a lot better because now I can choose where the reasonable place to break is. There may technically be more wiggle room for debate, but now you're spending less time debating variable names or whatever to get it to format not-awfully.
For me, for example, I was gonna go with async/await in my toy language, but didn't like the implementation and decided to explore a monad-like direction.
Edit: for VS Code:
https://code.visualstudio.com/api/language-extensions/syntax...
Great work of course, just a fun suggestion ;)
As someone who often learns by perusing both toy and production projects, almost any kind of code or language idea can be useful to me for learning, so I'm thankful for those projects.
Doesn't matter if it is production quality or experimental, or if the quality is good or bad. The funny thing is that HN has this meme about "the scientific process also being about negative results", but when it's software, people immediately treat it like a product, as if having more things in the world was a negative thing.
I will forever upvote those projects and star them on Github. And I am grown up enough to figure out by myself what they have to "offer".
I love this sentiment, and I'm glad you made this! I love reading different syntaxes for programming languages. You should be proud. Writing programming languages is _hard_.
I made an abstract programming language in 2023 (https://visionscript.dev). The language still needs _a lot_ of work and some bugs fixed. With that said, I had so much fun making it.
Though wouldn't it have been nicer as just a library for any functional language for more interesting use-cases like mapping an image of a bar chart to CSV or estimating coefficient of restitution of a bouncy ball?
That's one problem I always had with DSLs, as expressive as they can be for their domain, sooner or later you find yourself having to implement all the features of a modern high level language...
I had three main motivations for the project:
1. Learn how to write a programming language;
2. Explore the extent to which I could use a new language to help people learn computer vision, and;
3. Learn more about computer vision.
The goal was to create a language that is more suited for beginners, with the intent that you can build a vocabulary you can use to describe computer vision and programming more broadly. The extent to which this is/was achieved is unknown since I'd need to do a lot more work to get it in the hands of new developers, but nonetheless I enjoyed thinking and reading about this.> sooner or later you find yourself having to implement all the features of a modern high level language
A friend told me "but James, you can just use Python for this!" While that is true, there is definitely something to be said about _how_ you do something, as well as what you can and can't do. How a language works and what it can and can't do is in the hands of the language designer; these decisions are technically interesting to make.
> I made an abstract programming language in 2023
This is super cool. The block editor is especially impressive.
; these produce an error, since `b` isn't defined when the body of `a` is compiled
let a = \x -> (b x * 3),
b = \x -> (a x / 2)
It surprised me when this was called out, given that both a and b are defined in the one 'let'. Was there a specific reason you decided not to treat it as a 'letrec'? let x = x + 1
because the new `x` shadows the old one before `x + 1` is compiled. But if you're defining a recursive function, like this: let foo = \n -> foo(n + 1)
you need `foo` to be defined before you compile the lambda body, or else the compiler will think you're referencing an undefined variable.At one point I had an exception where, if the value of a variable being defined is a lambda, it defines the variable first to allow recursion, but not otherwise. But this felt inconsistent and kind of gross. Instead, I decided to have `def` expressions behave like that, and disallow recursion in `let`. `def` is always a function definition, so you'd almost always want that behavior, and I felt that since it has a different syntax, slightly different assignment semantics wouldn't be so bad.
For mutual recursion you have to go a little further, and find all the definitions in the block before you start compiling anything. So `def` expressions are also hoisted to the top of the block and pre-defined at the beginning. This felt ok to me since `def` expressions look like big, formal, static definitions anyway, and it didn't seem surprising that they would have whole-block scope.
One thing: I was confused (as others stated here I think) by the link to Robins Loan's website and thought it was an other article from you about Cassette.
Would you consider writing a blog post about how you created it (building the lexer, parser, etc.)? I would definitely be interested.
> How did you manage to use syntax highlighting for your own language on your website?
I used Pandoc to format a markdown file to HTML, which supports custom syntax definitions for code sections. (The relevent flags are `--standalone --template=template.html --syntax-definition=syntax.xml`.) The syntax definition is written in an XML format used by the Kate text editor (from KDE): https://docs.kde.org/stable5/en/kate/katepart/highlight.html
> One thing: I was confused (as others stated here I think) by the link to Robins Loan's website and thought it was an other article from you about Cassette.
Thanks, I'll clarify this or remove it soon.
> Would you consider writing a blog post about how you created it (building the lexer, parser, etc.)? I would definitely be interested.
For sure! I've been meaning to write up some of the technical aspects of the project, so those will appear on the site at some point in the future.
I also want to shout-out Berkeley Graphics, who made the monospace font. It's been my favorite for some time now.
I really like how it looks on your page, it makes the code blocks feel "cozy" for lack of a better word.
A clear and concise webpage that gets the message across perfectly without needing megabytes of 'content'.
I’ve talked about it on Hn a few times, but I wrote the language I use for work. Like you, the language is primarily for me, but my motivation was to prove some type theory and philosophical (mathematics) points I held as true but couldn’t visibly see for myself. It was a trek to get finished, but it was a very rewarding experience.
(see also Joel Moses on "beautiful crystal structure" vs "ball of mud")
Nice hack!