Live data from Hacker News

What you learn by making a new programming language

ntietz.com

51–60 of 137 posts

Re: What you learn by making a new programming language

#52

I think maybe a good middle ground is write an interpreter for an already spec'd esoteric language like brainfuck. [0] It's really fun. Brainfuck specifically is great because there's a lot to optimize with only 6 total operations. (An example, multiplication has to be done as repeated addition in a loop, make a multiply AST node! [1]) and you could knock out a (BF => AST => Anything you want) compiler in an afternoo…

Similarly, I’ve been thinking lately about forking Swift, because there’s a lot I love about the language, but also a lot of, IMO, unnecessary sugar and redundant surface area.

Re: What you learn by making a new programming language

#53
post #13

I've had two projects that end up being "oops, I made an interpreter". It starts innocently enough, you just have a JSON that has some basic functionality. Then you decide it would be cool to nest functionality because there's no reason not to, so you build a recursive parser. Then you think it'd be neat to be able to add some arguments to the recursive stuff, because then you can more easily parameterize the JSON. T…

Lots of people learn the same lesson at some price.

Data and execution are two separate things and should remain as separate as possible.

The reason is that once you mix data and execution, suddenly you don't know what your data is until you execute it. Then you can only deal with it in the context of whatever tools you write and you can never just look at it straight.

On the other hand now execution depends on lots of data and is no longer modular or general/generic and so becomes a one off solution somewhere.

At some point everyone has the "what if" idea and hopefully it only burns them instead of lots of other people through poor design.

Re: What you learn by making a new programming language

#54
In woodworking you make tools all the time, namely jigs. So much of woodworking, whether it is making cabinets, musical instruments, art, or whatever involves making your jigs, templates, and a bunch of other stuff. Hell, even larger projects like complex workbenches.

You rarely make actual tools, though. It's unheard of that a woodworking goes on to make their own router, band saw, planer, jointer, chisels, etc. - but you can learn a ton by starting with the absolute bare basics, before investing a ton in expensive tools.

Kind of makes me wonder where this analogy fits (if at all) in the world of software engineering: Some tools are probably either too complex, or don't really make sense making, if you're going to use it to actually build something.

I mean, it is a good intellectual exercised for the curious, and you pick up a bunch of things underway, but at some point it is probably good to ask yourself if your time is better spent on something else.

Re: What you learn by making a new programming language

#55
post #20

Earlier quoted context omitted.

> and life is pain So glad you finished with this. Right now I’m working with a guy who wants to write an interpreter…

Writing an interpreter for a project that isn't explicitly an interpreter is a code smell equivalent to microwaving fish. It is an incredibly fun side project though.

I think this really depends a lot on the task as well as how you frame it.

A whole lot of the "parse, don't validate" ethos is potentially about handling incoming data with complicated formats by writing a minimalist interpreter that reads the input and outputs either guaranteed-valid domain objects or error messages. Most the time you can get away with just a parser, but one occasionally runs into more complex formats that are easier to handle if you think of them as a declarative language that you handle using general-purpose interpreter implementation patterns. And it's just not a wheel worth reinventing.

The "very clever JSON" example the parent poster gives isn't particularly farfetched. The description reminds me of, for example, every Jetbrains REST API I've ever had to interact with. Also the data file formats for some commercial applications I've had to interact with. I don't like formats like this, but when I'm stuck with them, choosing the most maintainable option from the choices I've been left with is not a code smell; it's just sound engineering.

Re: What you learn by making a new programming language

#57
This is so true. I feel like I've learned more about programming in the last two years making Cassette[1] than in the past decade of professional software development.

Every developer should make a language at some point. I want to see everyone's weird, half-baked languages! I want to hear about what other people struggled with, and the tradeoffs they've made!

[1]: https://cassette-lang.com

Re: What you learn by making a new programming language

#59
post #13

I've had two projects that end up being "oops, I made an interpreter". It starts innocently enough, you just have a JSON that has some basic functionality. Then you decide it would be cool to nest functionality because there's no reason not to, so you build a recursive parser. Then you think it'd be neat to be able to add some arguments to the recursive stuff, because then you can more easily parameterize the JSON. T…

I'm pretty happy with "json scripting" for an implementation[0] of card game[1] with relatively low rules complexity. For a time it could evaluate arithmetic expressions, but I got rid of that because it was a bit unwieldy. The main pain point is that it runs slower than I'd like, so I may end up porting it all to actual Javascript functions or to Zig. [0]: https://github.com/sharpobject/yisim/blob/master/swogi.json…

The first time I did this, I ended up writing stuff that could use replace strings with regular expressions, do arithmetic, string concatenation, and a few other things. It was honestly kind of cool but it was horrible to maintain and I wish I had just kept the JSON as data.
Post reply on HN