Just enough info to keep you asking questions. Sounds like a cult.

Solutions for what? Generic “challenges”? And whatever follows in this section doesn’t really seem too related to custom programming languages, other than the PHP reference (but I’m not sure how mentioning that solves anything, or why you would put it into that section).

That part was about how one small decision can snowball into something huge, like PHP, where the guy just wanted an easier way to do something and ended up creating a language that's everywhere today. Sometimes the "harder" path turns out to be the more interesting one. That's the point: don't give up when things get hard. Push through and you don't just solve your actual problem. you may walk away with some real experience, maybe even something bigger than you expected. But don't treat these stories like they're some deep life lesson. I wanted to unpack what expertise means to the dev community, through a couple of stories that tie into it. Drawing a bit of a parallel to today: AI's everywhere now, and sure, it gives us a shortcut but it's also making us less curious and quicker to hand problems off to a machine. IMHO, used to be more fun that way.

Our whole "build your own custom language" thing also happened kind of by accident. We're glad it turned into something that's not just useful for our devs, but actually interesting to the wider dev community too, cause that's for people who like getting to the bottom of kinda mundane things, same as the guy who made the series, our C++ architect.

As for why we call it PVS-Studio's expertise specifically. Developers are basically the core of what we do. They're the ones who actually hold the knowledge behind our analyzer. And a big part of being a static analysis dev is digging deep into a language to find its weird edge cases and bug patterns, that's literally how you build diagnostic rules. So our expertise really comes down to understanding how languages work under the hood. The videos on building your own language were actually made for new hires at first, that was a fun and fast way to get them thinking like we do. And honestly, that's kind of the whole point: these webinars are our expertise. We just figured other devs outside the company might find them just as interesting.

Thanks for the thoughtful comment, genuinely appreciate it. Hope that clarifies things. But if not, pls ask =)

This one's purely a toy, it doesn't have a specific purpose beyond demonstrating the basics every programming language has (for the one curious about it ofc)

What's the tl;dr? What's the language for?

I scrolled through, but it wasn't quite obvious.

If the unicorn were to just dig downwards a little, it could get ahead quite a bit.

I don't know if it's just me, feel free to ignore my feedback, but the article feels a bit random in terms of overall structure.

Here are the parts that confused me the most:

Now, it's time to lay our cards on the table and tell you what solutions we had in mind.

Solutions for what? Generic "challenges"? And whatever follows in this section doesn't really seem too related to custom programming languages, other than the PHP reference (but I'm not sure how mentioning that solves anything, or why you would put it into that section).

Today, we'll share our experience, which may inspire you to enhance your expertise. What gives rise to expertise in programming?

Wasn't the article about making a programming language? That seems mostly unrelated to generic expertise in programming. Story #1, #2, #3 in the top section seem unrelated too.

What does expertise mean for PVS-Studio?

What expertise, in making custom programming languages? The section seems to be about something else, an analyzer and diagnostics. I understand those could be in some situations considered related, but there seems no motivation given why you would think they are here. So it feels a bit disjointed.

Revealing secrets

About what, making a custom programming language? Nothing that comes right after seems an actual secret, let alone one relevant for custom programming languages.

It might be just me being a bit dense. However, I can't shake the feeling that this article could have worked better if cut down to less than a quarter of the length, and with some more focus on a clear topic.

Since we are talking about language design. What are thoughts about PERL in 2026 ?

Making a programming language is easy. Making a good one is very hard.

Suck it, bokmål

/s

Enticing. I'd like to do some testing to see how the emitted code size stacks up against Zig.

Of course, it is only a matter of time before someone takes this and bolts an OOP system on top; the result will be called C3 Plus Objects, or C3PO for short.

Lean is a quite advanced design.

Must be an art project :D

My favorite one remains the Piet.

And also my favorite programs is How to compute Pi in Piet, where result precision depend on the resolution of program image 🤣: https://www.dangermouse.net/esoteric/piet/samples.html

"NOR is a universal logic gate and thus can be used to make the other gates, just in a much less convenient way." Respect!

https://esolangs.org/ is a great place to find a ton of esolangs

I like clicking the "Random Page" button and surfing around on it

All those listed here are on there I believe as well as classics like Brainf**k, Malbodge, Piet, etc

Here are some of mine: https://esolangs.org/wiki/User:BlueOkiris

Yeah, I was quite irritated copying that for the quoting 😅

"while remaining readable,"

X Doubt

Haven't the time right now to read fully, but a quick glance made me feel like someone fleshed out Brainfuck into a proper language. Sounds interesting, although I must admit my programming days are long behind me.

Significant whitespace, minimal ceremony

Well that's an oxymoron. If you're having to alter the whitespace instead of the code because the whitespace is significant than all you have is ceremony.

Nim has python-esque syntax and its compiler does not need llvm or rust - it only needs a c compiler if you build it from source. It currently has a significant amount of packages that can be imported, making it easier/faster to get your end result. Nim also has plenty of packages for microcontrollers. Most of the stuff listed on Kore's "Unimplemented Features (TODOs in source)" are working on Nim, too.

More importantly, existing for longer means there's a larger community and several questions of "how do I do X" that have been answered, which is a bigger advantage for choosing Nim in this situation

The person creating this language clearly believes it has things to offer that existing languages do not.

Because unless there is a technical advantage to it, creating a new language that does the same or less than another already existing one just splits and weakens both.

Why should someone rule this language out over Nim?

looks very promising!