Hacker News Reader

Comment by AnimalMuppet | Hacker News Reader

No. No, I really shouldn't.

Yes, I might gain a better understanding of how things work. I can do that lots of ways; others may be a better use of my limited time. (For that matter, doing other things that don't give me a better understanding of how things work may be a better, more valuable use of my limited time.)

Yes, I could get a language that fits what I need better... in theory. In practice, it would be buggy, inconsistent, and incompletely implemented. It would not actually fit what I need better than existing languages.

View on HN

You should write a language for the same reason you should write a game.

It's not hard for a game to touch all sorts of corners of the computer world that routine work will never come near. Games are great because they're easy to focus on, you know pretty much precisely what you want it to do. They also tend to be made of small parts, yet extensible, in terms of adding features if you still have wind in your sails.

And if not, hey, you have a few more data structures under your belt. Who knows when those may come in handy again.

Languages are similar. Get past a few "hard parts" and they can be a fun ride.

For extra fun, put the language into your game. Dog food for everyone.

The article doesn't claim that you should make a language and actually use it - the author focuses on the learning experience. He makes valid points.

No, it's probably not the right learning experience for everyone (clearly, it won't be yours), but there's definitely value in it for some people. And if reading the article nudges a few more people to take that learning dive, I think that's a good thing.

Having written several toy languages, I think that the process is supremely educational in ways that other efforts are not. In particular, it gives you an awareness of how these things can go wrong so that you can see where your day job efforts can go wrong if extended too far in some direction. You always learn about distinctions that were never apparent before you got into the details.

Without the freedom to make a mess of things, you live too cautious a life. It's worth digging in to some of these efforts even if they do wind up a mess. It's not because the mess will be meaningful. It's because you will understand better what was good and bad about what you did and how you got there.

How is using a language that is buggy, inconsistent, and incomplete any better than use a better language to write an app that is buggy, inconsistent, and incomplete?

Checkmate.

Umm if we are looking for analogies. I would prefer a castle built on rock rather than one built on sand.

Better than a sandcastle built on a rock, I suppose...

> rather than one built on sand

Well, that is exactly what your app is if it's built on modern "state of the art" tooling - you're probably pulling in a thousand trivial dependencies; every day, something gets updated, and you're rolling dice on whether or not your program will build.

Writing your own language to build your app in creates a lot of big problems, but not those particular problems.

Yes, my apps are buggy, inconsistent, and incomplete (as are all apps). But they're less bad than my language would be, because they're my day job, and my language wouldn't be.

So, not checkmate at all.

Different context, though. I'm pretty sure that my Java/Go/Kotlin apps are buggy. So what, bugs are always exist. Just fix them. But as a language user, it's not my job to fix compiler/RTL library bugs. Write a bug report on GitHub, instead.

But when you are designing a programming language and writing the interpreter/compiler, well you are on your own :D

Reply on news.ycombinator.com