8 ms·

There’s a difference between building a toy language and designing something people would actually use. I think the article is more aimed at the latter, wherea

There’s a difference between building a toy language and designing something people would actually use. I think the article is more aimed at the latter, whereas if you just want to get something working and have fun, your approach makes more sense.

hardwaregeek 5y ago
Yeah you’re right. I guess I’m saying that you gotta build a few toy languages before the big one. I don’t think you can read all of the material in the blog, then go build a language that people would actually use. Ideally you should concurrently read the material, work on a toy language, and work on an existing language.
lolinder 5y ago
I think most people who are interested in programming languages would do well to start by making toy languages. There's a lot of pressure in trying to make something "useful", and you're almost certainly not going to succeed at that on your first attempt anyway. The list of prerequisites in the article is extensive, overwhelming, and largely unnecessary if you're just getting started. Most of the concepts that it lists as "prerequisites" are ones that I finally understood while implementing a toy language, not stuff that I studied ahead of time.
- eternityforest 5y ago
  Part of the usefulness of the guide might be to dissuade people from even trying, by showing them how hard language design is. I don't think I would ever want to do anything beyond a DSL or bytecode for tiny 128 byte ish embedded config or the like, and even then only if nothing else worked. The odds of usefulness are low even with pro backing. Understanding all this stuff puts you in a better position to decide it you actually want to try. With toy projects you can just keep iterating and iterating and never get anywhere, and not really fully realized why it's not successful.
  - lolinder 5y ago
    Yes, but if you approach it as a toy then "success" doesn't mean "wide usage" it means "I had fun and learned stuff". I love Crafting Interpreters in part because he's explicit about this being mostly about learning and about play. I love languages (spoken, written, programming) and it was a great introduction that really got me rolling. Articles like this consistently overwhelmed me, with the result being that I didn't really try it until years after I wanted to. Yeah, languages aren't for everyone, but specifically trying to scare people off of it seems harsh and unnecessary.
    - ModernMech 5y ago
      > Yeah, languages aren't for everyone, but specifically trying to scare people off of it seems harsh and unnecessary. That depends. It's really hard to articulate just how much work is involved in writing a programming language. It's one of the classic infinite time sinks that exists in the CS field; no matter how much work you put into it, there's more to be done. It's very hard to ever call it "finished". I've seen a lot of language projects start as "I was working on this other thing and then I thought to myself, gee, here's a great opportunity for a programming language to make this easier." 8 years later they're still working on that programming language, the original project a distant memory. Programming languages have a way of sucking in developers without them realizing it until it's too late. So while I wouldn't dissuade anyone from writing a PL per se, I would warn them that writing a PL is a *huge* undertaking in its own right, and should really never be undertaken to help you solve your own problems. If you want to go this route, then you need to abandon your problem and focus on the PL instead.
      - stevekemp 5y ago
        I'd almost agree, but at the same time such work can be a lot of fun. Personally I think an average programmer could knock out a BASIC, FORTH, or similar programming language - with extensions - in a few months of part-time work, if not less. The harder part, the part that I can see taking a lot of time, is trying to create a "batteries included" language which has a very complete and complex standard library. Sure there are cheats if you're able to use dlopen, and FFI, to access C-stuff, but it's still not easy to create client-libraries for MySQL, Postgres, Redis, HTTP, etc, etc. Those kind of extensions/support make your language very very useful for users though. So there's a trade-off. I've put together a couple of simple languages, with a standard-library of maybe 30 functions. I'd draw the line at anything more no matter how appealing it might seem because I can just imagine how much of a time-sink it might become.

hardwaregeek 5y ago

Yeah you’re right. I guess I’m saying that you gotta build a few toy languages before the big one. I don’t think you can read all of the material in the blog, then go build a language that people would actually use. Ideally you should concurrently read the material, work on a toy language, and work on an existing language.

lolinder 5y ago

I think most people who are interested in programming languages would do well to start by making toy languages. There's a lot of pressure in trying to make something "useful", and you're almost certainly not going to succeed at that on your first attempt anyway. The list of prerequisites in the article is extensive, overwhelming, and largely unnecessary if you're just getting started. Most of the concepts that it lists as "prerequisites" are ones that I finally understood while implementing a toy language, not stuff that I studied ahead of time.

eternityforest 5y ago
Part of the usefulness of the guide might be to dissuade people from even trying, by showing them how hard language design is. I don't think I would ever want to do anything beyond a DSL or bytecode for tiny 128 byte ish embedded config or the like, and even then only if nothing else worked. The odds of usefulness are low even with pro backing. Understanding all this stuff puts you in a better position to decide it you actually want to try. With toy projects you can just keep iterating and iterating and never get anywhere, and not really fully realized why it's not successful.
- lolinder 5y ago
  Yes, but if you approach it as a toy then "success" doesn't mean "wide usage" it means "I had fun and learned stuff". I love Crafting Interpreters in part because he's explicit about this being mostly about learning and about play. I love languages (spoken, written, programming) and it was a great introduction that really got me rolling. Articles like this consistently overwhelmed me, with the result being that I didn't really try it until years after I wanted to. Yeah, languages aren't for everyone, but specifically trying to scare people off of it seems harsh and unnecessary.
  - ModernMech 5y ago
    > Yeah, languages aren't for everyone, but specifically trying to scare people off of it seems harsh and unnecessary. That depends. It's really hard to articulate just how much work is involved in writing a programming language. It's one of the classic infinite time sinks that exists in the CS field; no matter how much work you put into it, there's more to be done. It's very hard to ever call it "finished". I've seen a lot of language projects start as "I was working on this other thing and then I thought to myself, gee, here's a great opportunity for a programming language to make this easier." 8 years later they're still working on that programming language, the original project a distant memory. Programming languages have a way of sucking in developers without them realizing it until it's too late. So while I wouldn't dissuade anyone from writing a PL per se, I would warn them that writing a PL is a *huge* undertaking in its own right, and should really never be undertaken to help you solve your own problems. If you want to go this route, then you need to abandon your problem and focus on the PL instead.
    - stevekemp 5y ago
      I'd almost agree, but at the same time such work can be a lot of fun. Personally I think an average programmer could knock out a BASIC, FORTH, or similar programming language - with extensions - in a few months of part-time work, if not less. The harder part, the part that I can see taking a lot of time, is trying to create a "batteries included" language which has a very complete and complex standard library. Sure there are cheats if you're able to use dlopen, and FFI, to access C-stuff, but it's still not easy to create client-libraries for MySQL, Postgres, Redis, HTTP, etc, etc. Those kind of extensions/support make your language very very useful for users though. So there's a trade-off. I've put together a couple of simple languages, with a standard-library of maybe 30 functions. I'd draw the line at anything more no matter how appealing it might seem because I can just imagine how much of a time-sink it might become.