Hacker News Reader

Comment by ghoward | Hacker News Reader

I have also been working on a programming language, but longer than the author of this piece (since 2011), and the author is correct.

Designing a language consumes you; you never see programming the same way again. Whenever I write C (I'm implementing the interpreter in C), I get annoyed because I have to work around C's warts to do what I want, and that is only happening because I think in my language.

And the design never stops. As mentioned, I've been designing mine since 2011, and I'm only now writing an interpreter after two failed attempts to bootstrap a compiler.

So the author is correct: don't write a programming language unless you are prepared to be marked and scarred for life.

View on HN

> I get annoyed because I have to work around C's warts to do what I want, and that is only happening because I think in my language

That is exactly what motivated me to start thinking about my own language and what made me want to keep working on it in the early to mid 1990s. Luckily, I started learning several languages so that I'd have a better idea of the design space. Someone suggested I take a look at a relatively unknown language called Python because it fit how I was thinking about things. He was right and that was the anecdote for me - finding a language that fit how I thought about programming well enough to eliminate enough of the annoyances that were my motivation.

The lesson... If you're thinking about designing a language, study as many other languages as you can so that you get a better sense for the design choices involved and how various concepts fit together. Ask people experienced with those languages what they like / dislike about them. Write something challenging enough to get a first hand understanding of some of those pros and cons. If you push on with your own language, this will help your efforts significantly. If you get lucky, you might find a language that stops your descent into the rabbit hole.

The above might only work if you can accept that languages are sufficiently complex that they all have real problems, even yours when it's "done".

> If you're thinking about designing a language, study as many other languages as you can so that you get a better sense for the design choices involved and how various concepts fit together.

I've written C, C++, Python, Ruby, Lua, Bash, POSIX sh, C#, Java, JavaScript, Common Lisp, Racket, Haskell, bc, dc, Zig, BASIC, Tcl, and some others I'm probably forgetting, and I've studied Rust, D, Ada, Idris, Coq, Isabelle/HOL, HAL/S, OpenGL shaders, Cilk, Cyclone, Ceylon, Scala, Clojure, Kotlin, F#, Scheme Lisp, Jai, Julia, Perl, Nim, and probably even more that I am forgetting.

Does all of that count? :)

> Ask people experienced with those languages what they like / dislike about them. Write something challenging enough to get a first hand understanding of some of those pros and cons. If you push on with your own language, this will help your efforts significantly.

Yes, I agree. And I have done all of that.

> If you get lucky, you might find a language that stops your descent into the rabbit hole.

"Lucky" is the operative word. Unfortunately, I'm picky and haven't been that lucky.

It is interesting to see such an extensive list that doesn't include Smalltalk or Forth. The lack of Pascal/Modula-2/Oberon is not a problem given Ada. Not having APL (or J or K) might not hurt if you get the needed ideas from Julia. Other languages such as Cobol (or the microcomputer equivalent such as dBase) most people can probably live without.

Ah, whoops. Smalltalk and Forth are two languages that I have written a bit of code in and studied extensively. I did say that I was probably missing some.

Oh, and Go. I've written some Go.

> don't write a programming language unless you are prepared to be marked and scarred for life

I can vouch for that! Fortunately, I have a great team to collaborate with.

I was looking for your comment in this thread and I'm not disappointed.

It's fortunate you went ahead despite every thing telling you to do otherwise. And then tricked other people into joining you. A bit evil probably but they consented, in the end. You are probably only partly responsible.

D doesn't need a Reality Distortion Field. People that take the time to learn it find it very pleasant and productive.

It does not require that much time either.

Article author here. The two years mentioned in the post is the time spent actually implementing it. I spent a few more years thinking about it prior, and I thought that implementing the basic ideas would prove, our not, whether it worked, and then I'd be done.

Well, guess what, it didn't actually turn out that way. At least I'm more understanding of people who annoyingly promote their own languages all the time.

> So the author is correct: don't write a programming language unless you are prepared to be marked and scarred for life.

I write and wrote internal languages mostly; a bunch of them made it to production inside larger (for my country) companies for years and even a decade. The scarring part is that I always add the features I want and when I go to a mainstream language, I always miss those features. So since 2018 we have been doing a new language and one of them will be publicly launched this or next year so I can at least use that for day to day programming without being annoyed by missing features. Note that I already have that using Racket with a bunch of macros but in my business it is easier to introduce your own language than use Racket...

> Note that I already have that using Racket with a bunch of macros but in my business it is easier to introduce your own language than use Racket...

Why is it easier?

Most people are allergic for lisp likes. Not sure why but it has since always been blocked. I even did a lispy but with <> instead 20 years ago and that was OK (it was the xml for everything hype) while with () it was rejected. I had a talk with the cto of one of our bigger infra structure partners and he had exactly the same issue, so he replaced the () with [] and suddenly it was fine. So he has had scheme in their products for over 10 years but with [] because people are allergic to ().

I can obviously do the same with racket but if no () then I rather have another syntax all together.

Ah, it's sad to hear that. People can be so emotional, just because of a bit of syntax.

But since you have full control, you could introduce some extra syntactic sugar as well and desugar it into regular lisp/racket syntax before parsing, no?

As an alternative with a completely different syntax, I found Scala to be extremely nice for building DSLs. Probably the best typesafe language for DSLs out there. It's only really good on the JVM though.

Out of interest, what are the features you miss?

> I get annoyed because I have to work around C's warts to do what I want, and that is only happening because I think in my language.

What's worse is that PL authors are usually students of PL history, and the history of PLs is littered with "We did things this way out of necessity. We wouldn't have done this if we had more time/resources." Which would be fine but then we are all stuck using those tools with all their arbitrary limitations and quirks for 50 years. If you ever thought "I could write something to make this so much easier", the impulse is 100x worse as a PL designer, because you realize how many things we do are done for no reason at all beyond history and happenstance.

On the bright side, it probably better equips you to actually argue about where C (or any language) has faults from a language design perspective, which is a relatively rare point of view.

> I've been designing mine since 2011, and I'm only now writing an interpreter after two failed attempts to bootstrap a compiler.

You are lucky (or unlucky) that you have reached that stage. I'm trying since 2004 and had at least 6 failed attempts on design and 3 different implementations that never finished. Fortunately for me, since I had a lot of failed designs (as opposed to implementations) I better appreciate existing designs even with their warts.

> I get annoyed because I have to work around C's warts to do what I want, and that is only happening because I think in my language

You "just" have to get to the point where your compiler is written in your own language. This may take a while. Go got there in V1.5:

https://go.dev/doc/go1.5

It's funny/interesting that an 1kloc implementation of minimal self hosting Go exist, or C/pascal/oberon compilers ; perfect hindsight view etc. You theoretically could (well if nobody does, no you can't) create a nice language and its implementation quickly.

> It's funny/interesting that an 1kloc implementation of minimal self hosting Go exist

Does it? That's not the technique Go introduced, they started by rebuilding Go from earlier versions written in C - but in fact the bootstrapping process may change soon, see https://github.com/golang/go/issues/44505

Sure, go itself didnt build it from scratch - rewriting your implementation each time you change your language might grow tiresome fast, but I was referring that toy/minimal implementations exist : https://benhoyt.com/writings/mugo/

Wirth was even more drastic in what concerns writing bootstraped compilers.

I don't recall in what paper from him I have read this, so take the story with a grain of salt, also open to corrections.

He actually wrote the initial version of the compiler directly in Pascal.

How did he perform such thing, one would ask.

By writing it on paper using a Pascal subset good enough as stage 0, and then manually compiling the source code into corresponding Assembly instructions that he would then actually type into the cards.

So when he finally got the compiler done, it was already bootstrapped from the get go.

Additionally, P-Code originally wasn't designed to be an interpreter, rather to repeat the above process in an easier way across computer systems.

He was initially surprised that others took it to write Pascal interpreters instead of a bootstrapping tool.

I've never been megalomaniac enough to think I could design a new language. But I did once write a Pascal source-level debugger; I think the compiler was Intel Pascal (long time ago). It taught me a lot about how the compiler worked, and how the language worked.

I've used to suffer quite badly from Impostor Syndrome, and that project did a lot to alleviate my symptoms.

I never shared the project with anyone else; it was never completely finished.

Nice story, thanks for sharing.

My hard drive is full of unfinished projects, started to learn about programming language, or try out new design approaches, quickly abandoned after the initial goal was achieved.

Regarding imposter syndrome, two guidelines that have helped me in such situations, are "only repent for paths not taken", "failure is better that not knowing at all".

Obviously those quotes aren't from me.

> be marked and scarred

If not, your language will be marked and swept.

Reply on news.ycombinator.com