Live data from Hacker News

What you learn by making a new programming language

ntietz.com

121–130 of 137 posts

Re: What you learn by making a new programming language

#121
post #70

> It will be a bad language, and that's okay This same advice could be applied to most hobbies. It doesn't have to be good, and it certainly doesn't have to make money. It just has to be fun and rewarding. If you learn something, even better. > Go Forth , make something fun *golfclap*

I also came across FORTH through hacker news. I ended up developing a compiler that can translate FORTH into C.

For the interested reader:

https://github.com/loscoala/goforth

It was a great experience and I can only recommend trying to develop a programming language yourself.

Re: What you learn by making a new programming language

#122
post #47

I think many people underestimate how easy it is to get started writing a language. It is a bit like improvising music: it's just one note followed by another note followed by another. Almost any intermediate level programmer can write a program that parses a hello, world program and translates it into the language they already know. Once you have hello, world, you add features. Eventually you realize you made mistak…

Very true. Working on a proglang is more like running a marathon than a 100 meters. Another thing that would surprise people is that how few complex data structures or subtil algorithms are required. For example in styx-lang, my little retard baby language, there is literaly no binary searches, no sorting, no hash map, no hash sets, yet it is still fast because actually a compiler most of the time only has to deal with very small vectors (5 parameters, 10 enum members, 15 statements in a body, etc.)

Re: What you learn by making a new programming language

#123

Seems the future of programming language is natural language

Good news, you can make new natural languages too!

Well, it would be a constructed language if you did it intentionally, but your point stands in that you can make a new language.

Re: What you learn by making a new programming language

#124
post #105

Earlier quoted context omitted.

> Besides, config languages never have the level of polish (re: tab completion and static analysis) that the main language does. They don't have to! > Why deny your users the niceties that you set up for yourself? Don't do this, of course. :) For instance, Nickel gained[1] an LSP implementation years before it hit version 1.0. When editing Nickel configs,byou get all the stuff you'd expect for a programming language:…

> there's no reason that a configuration language can't have first-rate tooling! Perhaps I shouldn't have made it about the configuration language's maturity. What I mean is that however mature it is, it's still yet another thing. At least from what I've been seeing lately, fewer tools > better tools. Suppose that on first run you generate a config file like this: from configtypes import Strategy def strategy() -> St…

> What I mean is that however mature it is, it's still yet another thing.

That's definitely true. And I didn't have scientific applications in mind as I wrote, either. I was thinking of domains where external DSLs for configuration are already predominant, and also of DSLs that I've enjoyed working with and their particular advantages. But everything you're saying makes perfect sense to me.

> And maybe the user is curious: "how is this used?". There are editor actions like "go to definition" or "find references" which they can use to find more information. Those will be interrupted if the language is different.

Right, the validation errors your config lang hands you might tell you what's wrong, but they won't be Python or R or $PROGLANG errors. It would be extra and special work to somehow get an editor to know how to jump between those two worlds, and I'm not even immediately sure how I'd try to do it if I wanted to.

> For now I'm focused on how to help users who aren't accustomed to navigating a project with files in more than one language (scientists mostly), and I just don't think the juice is worth the squeeze re: creating more than one world, one for them and one for "proper" devs.

I have to admit that I think you might be right, partial as I am to some fancy new config langs. But on some level it's already the case that those two separate worlds exist, right? Polyglot projects and companies are super common in software.

> that "learn scheme" item on my todo list.

I'm doing this right now in a real casual way with some friends! We're reading a chunk of The Little Schemer every other week. The book is easy, and that pace is gentle. If you're interested in joining or following along, feel free to DM me on NixOS Discourse.

Re: What you learn by making a new programming language

#125
post #124

Earlier quoted context omitted.

> there's no reason that a configuration language can't have first-rate tooling! Perhaps I shouldn't have made it about the configuration language's maturity. What I mean is that however mature it is, it's still yet another thing. At least from what I've been seeing lately, fewer tools > better tools. Suppose that on first run you generate a config file like this: from configtypes import Strategy def strategy() -> St…

> What I mean is that however mature it is, it's still yet another thing. That's definitely true. And I didn't have scientific applications in mind as I wrote, either. I was thinking of domains where external DSLs for configuration are already predominant, and also of DSLs that I've enjoyed working with and their particular advantages. But everything you're saying makes perfect sense to me. > And maybe the user is cu…

I think that we're each focusing on the right thing for the domains that we're thinking of, they're just different domains. When I first heard about Nickel I was like "wow, I'm gonna use this everywhere"--because I too get excited about fancy new languages--and I think that was premature. I'm looking forward to when the opportunity arises, but I don't think it'll become everywhere.

Config languages are definitely the way to go for system config and polyglot projects and maybe also places where the config/project divide is natural in some way such that users reasonably can spend their whole life without writing only config code (kubernetes comes to mind). I just tend to lean somewhat radically away from those things... to such an extreme that I've been thinking about making the code editor (and all its various configs) a project-level dependency instead of a system config.

I know it sounds crazy, but If you bundle the tools needed to work on a project into that project, then wherever it ends up, the user has what they need to work on it, even if the internet is down: Little dev-focused operating systems bundled with each package so that the actual operating system needs to be interacted with hardly at all. Something something right to repair...

---

Re: The Little Schemer, I actually have a copy of that on my desk, I have spent less than 5 minutes on it. I'll find you on NixOS Discourse :)

Re: What you learn by making a new programming language

#126
post #44

Anyone wanting to work on a new language is most welcome to help out on mine: jank. It's a native Clojure dialect on LLVM with C++ interop and all the JIT goodies one expects from a lisp. jank is currently part of a mentorship program, too, so you can join (for sree) and get mentored by me on C++, compiler dev, and Clojure runtime internals. 1. https://jank-lang.org/ 2. https://clojureverse.org/t/announcing-the-scicl…

Were you able to implement transducers at the core of Jank? Or did you end up sticking to the existing Java implementation as much as possible?

Re: What you learn by making a new programming language

#127
post #124

Earlier quoted context omitted.

> What I mean is that however mature it is, it's still yet another thing. That's definitely true. And I didn't have scientific applications in mind as I wrote, either. I was thinking of domains where external DSLs for configuration are already predominant, and also of DSLs that I've enjoyed working with and their particular advantages. But everything you're saying makes perfect sense to me. > And maybe the user is cu…

I think that we're each focusing on the right thing for the domains that we're thinking of, they're just different domains. When I first heard about Nickel I was like "wow, I'm gonna use this everywhere"--because I too get excited about fancy new languages--and I think that was premature. I'm looking forward to when the opportunity arises, but I don't think it'll become everywhere. Config languages are definitely the…

> I've been thinking about making the code editor (and all its various configs) a project-level dependency instead of a system config.

> I know it sounds crazy, but If you bundle the tools needed to work on a project into that project, then wherever it ends up, the user has what they need to work on it, even if the internet is down: Little dev-focused operating systems bundled with each package so that the actual operating system needs to be interacted with hardly at all.

I think it's totally sensible. Presumably some people will always like to bring their own editor, and for that, having direnv supply an language server, compiler or interpreter, etc., plus including a generic editorconfig file is nice. But why not go all the way and provide ready-to-use, pre-configured VSCodium and Neovim?

I'm planning on putting together something like that for my roommate who is a non-programmer but interested in learning to code. Right now he's working through Learn Enough Developer Tools to Be Dangerous to get some Linux and CLI basics down, then we're gonna do Linux From Scratch together and some programming (starting with The Little Schemer and hopefully ending with SICP). I'm making Nix environments for all the programming books I'm currently reading, and the Scheme one will bundle Emacs and DrRacket.

Re: What you learn by making a new programming language

#128
post #126
post #44

Anyone wanting to work on a new language is most welcome to help out on mine: jank. It's a native Clojure dialect on LLVM with C++ interop and all the JIT goodies one expects from a lisp. jank is currently part of a mentorship program, too, so you can join (for sree) and get mentored by me on C++, compiler dev, and Clojure runtime internals. 1. https://jank-lang.org/ 2. https://clojureverse.org/t/announcing-the-scicl…

Were you able to implement transducers at the core of Jank? Or did you end up sticking to the existing Java implementation as much as possible?

Transducers, in Clojure, are implemented in Clojure, rather than in Java. In jank, the Clojure source for transducers is exactly the same. For example: https://github.com/jank-lang/jank/blob/a14f4d7c7e8097d5ab588...

Re: What you learn by making a new programming language

#129
post #127

Earlier quoted context omitted.

I think that we're each focusing on the right thing for the domains that we're thinking of, they're just different domains. When I first heard about Nickel I was like "wow, I'm gonna use this everywhere"--because I too get excited about fancy new languages--and I think that was premature. I'm looking forward to when the opportunity arises, but I don't think it'll become everywhere. Config languages are definitely the…

> I've been thinking about making the code editor (and all its various configs) a project-level dependency instead of a system config. > I know it sounds crazy, but If you bundle the tools needed to work on a project into that project, then wherever it ends up, the user has what they need to work on it, even if the internet is down: Little dev-focused operating systems bundled with each package so that the actual ope…

I was also motivated in this direction by some friends I want to teach to code. There's so much for a newbie to overcome that has nothing to do with code.

What I'm struggling with right now is:

How do you make supplying your own vim, say, versus the one that's default for this project... How do you make that feel like supplying a nondefault "Editor" type argument to a function? I'm aware that flake inputs support that sort of trickery via input overrides from the CLI, but there's nothing about that (besides perhaps the name of the input) which ensures that you only put editors in that slot. And then correspondingly, editors are a bit too varied to be interchangable like that. If a project defaults to VSCodium and I want to inject helix... that's like gonna take some hackery which prevents it from feeling like dependency-injected magic.

Re: What you learn by making a new programming language

#130
Similar to woodworkers making their own tools, as programmers, we have the ability to create everything from operating systems to tools. This privilege is rare in other fields, allowing us to get closer to the tools we use. This autonomy enables us to have a deeper understanding and mastery of the tools and technologies we rely on.
Post reply on HN