This might be one of the rare times it's worth it. The C# team alread has the experience and tooling to maintain a language. Maintaining a DSL might be a reasonable choice for them.
It's rarely a good idea for app or library devs to make a similar decision.
Yes, this reminds me of meta-programming in languages like Python, it's useful if you want to create a framework like Django, but if you work on products, chances are good you should not use it.
Besides that, in Buenos Aires, for instance, every access to the street has its own address. A building with 2 entrances (front door and garage) has 2 addresses, etc.
You can pay the penalty and get safe container access, too. AFAIK, C++ standard containers provide both bounds checked (.at()) and unchecked ([]) element retrieval.
Now we are getting down to a philosophical issue (but I think an important one).
In Rust, they made the safe way of writing things easy (just write v[x]), and the unsafe one hard (wrap your code in 'unsafe'). C++ is the opposite, it's always more code, and less standard (I don't think I've seen a single C++ tutorial, or book, use .at() as standard rather than []), to do bounds checked.
So, you can write safe code in both, and unsafe code in both, but they clearly have a default they push you towards. While I think C++'s was fine 20 years ago, I feel nowadays languages should push developers to write safer code wherever possible, and while sometimes you need an escape hatch (I've used unsafe in a very hot inner loop in Rust a couple of times), safer defaults are better.
And how do we escape those characters? With ESC (27)? Inside a SI/SO (15/14) pair?
I think CSV or TSV are good enough. People keep trying to find a format where you can separate the records and fields with a simple string.split and there's no need to contemplate escapes.
But that's not possible, no matter the format you'll have to parse it right. And then, a format that uses visual delimiters has the obvious advantage of being editable with any text editor.
The only things Pascal has going for it nowadays are: (1) static executables and (2) some good libraries (and not many at that). As a language it's extremely primitive and unergonomic, and the Free Pascal maintainers don't really want to improve it because they are used to it.
As an implementation, it's the slowest compiled language there is. Everything is heap allocated (and reallocated) and it doesn't even have an efficient allocator, not to mention garbage collector.
The only reason there is to use Pascal nowadays is when you need one of the two things I mentioned and the results offset the torture that is programming in that language.
There is a Help->Rules link on all of the puzzles linked here. It can be a little tricky to decipher them if you're coming to them completely brand new, however. I mostly use them as a refresher.
Last year I needed to make a small webapp to be hosted on a Windows server, and I thought RedBean would be ideal for it. Unfortunately it was too buggy (at least on Windows).
I don't know whether RedBean is production-ready now, but a year and a half ago, that was the catch.
Give the latest nightly build a try: https://cosmo.zip/pub/cosmos/bin/ Windows has been a long hard march, but we've recently hit near feature completion. As of last month, the final major missing piece of the puzzle was implemented, which is the ability to send UNIX signals between processes. Cosmopolitan does such a good job on Windows now that it's not only been sturdy for redbean, but much more mature and complicated software as well, like Emacs, GNU Make, clang, Qt, and more.
To add some context as to why businesses wouldn't survive it, that war happened between 00001864 and 00001870, and wiped more than 00000050% of the male population (estimates vary).
Sorry, I wasn't clear. I was complaining about the hypocrisy and double standards.
It's all well and good that they didn't doxx the guy in the costume. I'm just saying that they also should have respected Scott Alexander's wishes, which were arguably even more justified.
