Building a programming language in twenty-four hours | Hacker News Reader

Building a programming language in twenty-four hours

ersei.net

112 pointstodsacerdoti41 comments

Open articleView on HN

Hmmph. Try my build-no-programming language in 20 years instead:

- Be armchair-interested in programming languages

- Take some PL-whatever courses in college

- Read about PLs

- Read about progressively niche PL stuff…

- Get idealistic (get ideas)

- Read about the grueling design process of useful-in-the-real-world languages

- Eventually realize that There Are Always Tradeoffs

- Realize that the Tradeoffs are like two thousand parameters that might interact in super-weird and non-obvious ways

- Realize that a dozen super-competent PhD-wielders and multi-decade practitioners can easily spend a decade on developing the core of a language

- eh, why bother

- Me

I had to change the scope of my desires. I don't want to make the next Python. Not even the next Zig or Nim. I just like fiddling with compilers and interpreters. Someone else mentioned Crafting Interpreters and I'll bring it up, too. I've been following along in C# and occasionally come back to my C#Lox implementation and work through another chapter. It is quite a lot of fun.

I am on a similar path, I am super fascinated with type theory and I want to test / implement stuff.

Progress is always made by those with an optimal amount of ignorance :)

I came here to say "can we worry about building programming languages in twenty-four years instead, please?". Someone who has gone through your list is exactly who I want actually building the next generation programming languages. Of course your last question is the best one:

> eh, why bother

This is absolutely the question you need a deep answer for. You need a problem that is burning you up and whose only solution is a new programming language. This might never happen. If it ever does, you're the person to do it, exactly because of all the ups and downs and half-started ideas you've thrown away. But you're right: the "why bother" stage is not to be ignored. It's the most important one.

> - eh, why bother

Because you will learn a ton and become a better programmer for it.

- e̶h̶,̶ ̶w̶h̶y̶ ̶b̶o̶t̶h̶e̶r̶

- yolo

Some things do need PhDs but some smarts and a bit of vision can get you an extremely long way.

I implemented VBA in C# a few years ago for malware analysis, and my takeaway is...well, it's a hard project. Possibly as hard as I've ever done, but a big part of that was guaranteeing bug-for-bug and type conversion compatibility and obscure language features that nobody would include today. I can't even fathom how the old folks implemented BASIC in 256 bytes of 8-bit assembly back in the day.

try mal instead. all the fun and much less frustration

https://github.com/kanaka/mal

Wasnt javascript created in 10 days?

Seeing the interview with Chris Lattner on Lex Fridman podcast on developing Mojo, and how he's learnt from developing Swift, or LLVM is very interesting, and how the path they've taken with Mojo is different from Python. It also seems like a lot of languages especially the new ones are converging with the best features from past languages which also makes sense.

This is super ambitious, but a great project to work on to better your understanding. And I applaud you, especially as an undergrad student( I assume as you stated final exams in the post). I wish I'd done more projects like this back when I was starting out. You are way ahead of where I was lol, I barely did any projects outside classes. And you got some attention on HN. Good stuff!

An interesting read. Always been fascinated with compilers and lexers. I should really make a language at some point. I tried following that "make a lisp in c"* book but I didn't like that they used external libraries that I didn't know about.

[*] https://www.buildyourownlisp.com/

Check out https://craftinginterpreters.com/

Will do, thank you!

I think building a programming language (or DSL to be exact) for a problem is one the features of Racket [1].

At least, that was the idea I got from watching a presentation by Dr Felleisen [2].

[1]: https://racket-lang.org/

[2]: https://youtu.be/z8Pz4bJV3Tk

Before you start down this path, which will take longer than you imagine, you need to understand your underlying reasons for doing so.

What is your problem domain? What don't you like about the currently available languages? Why do you want to kill yourself doing so? Can you afford to do so? Is this something you consider fun?

Understand yourself first and be willing to spend the time learning and sure go ahead, knock yourself out.

Just keep in mind that there are a small number of language classifications and yours will fit into one of these:

COBOL style languages: COBOL, Common Lisp, C, C++, C# and Java are examples here.

Fortran style languages: Fortran and all its variations.

ALGOL style languages: ALGOL 60, ALGOl 68, Simula, Scheme, Pascal and others,

Functional style languages: ML, Haskell, Clean, OCAML, etc.

Forth style languages: FORTH, Postscript, Factor, etc

SNOBOL oriented languages: SNOBOL 4, Icon, Unicon, etc

and a couple of other more minor kinds.

Uhhhh, how is Common Lisp COBOL-style?

"Starts with a C, innit"

I don’t think your list is particularly well compiled. For starters, bar your “functional” group, you’ve not grouped them by paradigms. Which has meant you’ve left out some pretty significant classifications. And several languages haven’t even been grouped correctly using your own method (or at least the lack of established terminology makes it harder to understand the grouping context behind each category, since most languages exhibit multiple traits and influences).

This is really good advice. Writing a language you'd actually like to use is difficult. It's been a richer source of interesting subproblems than any other I've found. If it's for education or entertainment, all good. If it's something you're going to quit a day job to pursue in the hope it'll make you wealthy later, quite high risk.

Language classifications normally antagonise people and tagging Lisp as essentially COBOL is well chosen for that. You're missing the prolog family and proof languages (coq/isabelle/lean etc). Also smalltalk (from which one might draw self and javascript).

Knowing exactly what one has rejected about existing languages is useful as a guide.

The language classifications section was an attempt at humour.

I am currently trying to [understand] the quirky translation of ScratchPad to Common Lisp used within the Axiom/FriCAS systems.

You see the same sort of problems in Maxima to Common Lisp translations.

Oh dear, the language classifications above was supposed to be a somewhat obtuse sort of joke and it appears that I was way too obtuse with the grouping for [COBOL style languages] and the [a couple of other more minor kinds].

Way too many [Dad jokes] or in my case [Granddad Jokes].

My dream is to create a performant runtime which is similar to PHP in terms of deployment strategy but is multithreaded like Java, Go or Erlang.

I started writing a JIT compiler in C here: https://github.com/samsquire/compiler

It's a toy and incomplete but I've worked on compiling MOV and ADD instructions.

Eich supposedly did javascript in 10 days, so this seems reasonable, right? :)

https://thenewstack.io/brendan-eich-on-creating-javascript-i...

And it still shows.

People laugh at this, but isn't this exactly how we got Javascript?

Don't give fronyent people ideas.

this was how javascript was created

"the eich"

24 minutes is a better target, i have a few repos like this... and long before the internet made it easy, it was the kind of thing i would do in my lunchtime at an office job.

it was way more instructive than following the standard path.

interesting read though :)

I'm not sure what the intended utility of "I am better than the target audience of this article" is, but I assure you it does not paint you in a positive light to other readers.

I read it more like setting a low bar in terms of time, like a pomodoro in fact. So whatever you produce in 24 minutes is that language. Then try again later.

Some of us should start the meta-project of cleaning our house by just making our bed.

Maybe if that's all they'd said, but

> and long before the internet made it easy, it was the kind of thing i would do in my lunchtime at an office job.

This gives me vibes of "I think I'm really impressive and I want people to know it." Maybe that's uncharitable though... Talking to people online has made me too cynical haha. I appreciate the alternative perspective.

it's obviously humourous

We must have different definitions of "obvious" and/or "humorous". Neither fit the bill, in my opinion.

I had a lunch time project for a couple of months, where I would spend about 30 minutes a day (I had to limit myself) implementing a scheme-like in an assembly-like language called Teraterm. It was fun trying to work within the constraints of the language. I finally quit when I hit TTs built in recursion limits. I know the solution would be implementing a call stack in TT, but I couldn't bring myself to do it.

There wasn't a setjmp()/longjmp() type functionality? That's how I cheated implementing a Lisp in C. When tail recursing I'd let the stack grow a while, nuke it with longjmp(), and keep going.

That was a long time ago and I didn't know nearly as much about PL design and implementation as I do now, but it set me on the path. Funny thing was I started that project just to prove to myself that I could still write C since I'd been doing a ton of Perl.

Oooh, there's definitely a "goto" in the lexicon [0].

I suppose I could do something like that. This project is almost 3 years old now. I might have to pull it out and dust it off. :D

[0] https://ttssh2.osdn.jp/manual/4/en/macro/command/goto.html

If you discovered that trick yourself, you're very clever. It was documented by Henry Baker and is implemented in Chicken Scheme.

The basic ideas are:

1. All allocations (e.g. consing) take from the stack.

2. Tail calls are stack calls, so we keep consuming stack.

3. No function ever returns; all calls are tail calls. The Lisp code is CPS-transformed. (Since functions in the compiled code don't actually return even when appearing to, the stack-allocated objects remain nicely valid.)

4. When the stack reaches a certain limit, we rewind it. At that point, all the data which we consed on that stack which is still reachable is relocated to the heap, so they remain valid while we clobber the original stack.

Reply on news.ycombinator.com