5 ms·

I always had the dream of building a language, then I did it and found what an extraordinary undertaking it is, and abandoned it. The issue is not getting somet

I always had the dream of building a language, then I did it and found what an extraordinary undertaking it is, and abandoned it. The issue is not getting something working early on or lack of supporting tooling. The issue (as I see it) is that most well known languages are extraordinarily sophisticated not just in their syntax but also things like debugging, profiling & analysis. Once you start conceptualising an entire system to get actual work done, you realise it really isn’t feasible as a lone endeavour. While not impossible, it’s very hard to be an expert in all these fields. You are therefore presented a choice: somehow fund your language (maybe you’re rich), or make it open source. Just open sourcing something isn’t a silver bullet either, successful projects often have a charismatic leader. I generally prefer to program alone when working on vanity projects, so I figure I’d just wait until someone invents something that most aligns to my tastes (SerenityOS/Jakt is close).

antipurist 3y ago
There is a third option: make your language shine where it matters (to you), and accept subpar experience in areas that matter less. Specific things you mentioned — debugging, profiling & analysis — could be treated as a solved problem if you transpile your language into some other language that already has these nice-to-haves. JS is a wonderful target, as long as you generate something remotely readable you already have a way to debug it, no need to reinvent it. Instead, it's much more fun and beneficial to focus on the reason you want to create the language, on the features that make it stand out.
- chrismsimpson 3y ago
  Firstly, JS is a horrendous target. Second, breakpointing in another language is about as great (possibly worse) as debugging via printf.
  - pmoriarty 3y ago
    printf debugging is infinitely better
    - chrismsimpson 3y ago
      Agreed
  - auggierose 3y ago
    Depends on your needs. In terms of functionality, JS has everything you might want, even the ability to execute itself. Viewed as a platform, not just a language, it offers WebAssembly, soon WebGPU. I don't see anything else that comes even close as a target platform!
  - JonChesterfield 3y ago
    The usual choice is C. I'm currently liking luajit as the tracing cuts through some of the DSL. The JavaScript compilers probably manage the same thing.
  - viraptor 3y ago
    Unless you write a basic interpreter or code in plain binary, you're breakpointing in another language. It's really not a big deal as long as you preserve the mapping to the original code. When you breakpoint in C, you breakpoint in assembly and find your C location from the debug information for example.
  - hu3 3y ago
    > Second, breakpointing in another language is about as great (possibly worse) as debugging via printf. You don't have to. Just generate sourcemaps and you'll be able to set breakpoints in your own language even when targeting JS. If anything that makes JS an even better target since you can leverage tooling.
- Warwolt 3y ago
  I think this is an important point. Comparing an initial implementation of a language with that of mature projects doesn't make sense. Every cool language started off in a rough initial state I'd wager, and many were initially developed by a single person, so why not give it a shot if it's compelling?
- matijash 3y ago
  This is how we went with https://wasp-lang.dev/ https://wasp-lang.dev/ (a DSL for building full-stack web apps). It is a very declarative language (config pretty much) and there is still plenty of work around tooling, but also enabled to cut down on a lot of boilerplate. Another route to consider when implementing a DSL, is to make an embedded one (e.g. like Terraform or Pulumi have, even both at the same time). That doesn't resolve all the tooling problems since there is still a compile step, but might provide a more integrated experience, although at the cost of brevity.
kstenerud 3y ago
Yup, I found out how hard it is just writing a simple language that doesn't even need computer tooling: https://dogma-lang.org/ https://dogma-lang.org/ And even with a language as simple as this, it still took 6 months. The biggest problem is keeping the patterns simple and coherent, while avoiding unnecessary features. It pains me to think of the weeks spent developing parts that were ultimately ruthlessly slashed away. Hours spent agonizing over a usage pattern that was mostly the same but different enough that (I thought at the time) it required special constructs... and then not as I thought about it in the shower days or weeks later. It's one hell of an eye opener. And then there's the type system... UGH.
- packetlost 3y ago
  There are languages out there that are more or less designed for rapid prototyping of PLs. Lisps, and in particular, Schemes such as Gerbil and Racket, are particularly well-suited to building languages. Yes, you have to get used to the prefix notation and (((((((, but ultimately it lets you have a lot of flexibility in testing out language constructs and usage-patterns before you build the parser, lexer, etc. that are time consuming.
  - sitkack 3y ago
    I think you meant, ))))))))
    - MisterTea 3y ago
      I think you just couldn't stand seeing all those unclosed braces ;-))))))))
shanebellone 3y ago
I have the same fanciful desires. I've decided to focus on extending Python with C instead. I can keep the benefits of Python and increase its speed as needed. This concept scratches that same itch.
otikik 3y ago
I believe that's why the article is saying "little" languages. Not all languages need a package repository and a language server
mattgreenrocks 3y ago
What kills it for me is the amount of middlebrow dismissals new PLs get, especially here. Tons of work and some rando comes in complaining you didn't advance type theory to help avoid annotating a type in one location. Arguably worse are the people who advocate against the new PL because no one is using it, strengthening the Matthew Effect, collecting Internet Points for cosplaying as a "responsible engineer" that argues solely for the status quo.
- AnimalMuppet 3y ago
  > Tons of work and some rando comes in complaining you didn't advance type theory to help avoid annotating a type in one location. If your language gets any traction, then you're going to get a number of randos saying things like that. Worse, some may not be randos. Some may be people with a connection to other languages. > Arguably worse are the people who advocate against the new PL because no one is using it, strengthening the Matthew Effect, collecting Internet Points for cosplaying as a "responsible engineer" that argues solely for the status quo. Well... one of the things a responsible engineer should in fact consider is maintenance, including the ability to find future workers who know that language. It's only one factor, not completely determinative, but it should be considered.
  - SaintSeiya84 3y ago
    found one of those randos
- deleted 3y ago
  [deleted]
- karmakaze 3y ago
  I don't like dismissals about adoption for anything new or under development as it's a given. I would complain if a posted language doesn't describe why it was created. What's the thing it does that others don't or do poorly. If just playing with syntax or scratching an itch that's ok too--simply make that clear.
LoganWhitwer 3y ago
[dead]
strangattractor 3y ago
Pretty sure Javascript is an example of why most of us shouldn't invent a language:)
fwip 3y ago
Another option is to use tooling that helps you write little languages with debugging, profiling, etc for free. An interesting article I saw the other day: https://news.mit.edu/2023/d2x-easier-way-get-bugs-out-programming-languages-0407 https://news.mit.edu/2023/d2x-easier-way-get-bugs-out-progra...
- quelltext 3y ago
  Isn't that article / researcher saying the same opinion the submission article is responding to? JetBrains about 9-10 years ago made those arguments and claimed to work on providing the tools to solve those challenges. I'm kind of curious what actually happened in that time. I've actually seen a few of these research projects over the years, i.e. providing tools to build languages with automated IDE and debugging support. Ultimately, I think (like the submission article's author) that it's something else holding adoption back. It may simply be lack of a convincing use case, e.g. industry adoption by one large company could make the overall approach (DSLs) more convincing. Now DSLs or DSL-like languages are of course in use in many orgs but they very often aren't more than configuration languages and often embedded in something else. Very rarely do they get complex enough to warrant debuggers. So I think we a) still lack good examples of DSLs being worth it, or b) a more convincing argument why today's methods would benefit from building a whole new language (incl. tooling).

antipurist 3y ago

There is a third option: make your language shine where it matters (to you), and accept subpar experience in areas that matter less. Specific things you mentioned — debugging, profiling & analysis — could be treated as a solved problem if you transpile your language into some other language that already has these nice-to-haves. JS is a wonderful target, as long as you generate something remotely readable you already have a way to debug it, no need to reinvent it. Instead, it's much more fun and beneficial to focus on the reason you want to create the language, on the features that make it stand out.

chrismsimpson 3y ago
Firstly, JS is a horrendous target. Second, breakpointing in another language is about as great (possibly worse) as debugging via printf.
- pmoriarty 3y ago
  printf debugging is infinitely better
  - chrismsimpson 3y ago
    Agreed
- auggierose 3y ago
  Depends on your needs. In terms of functionality, JS has everything you might want, even the ability to execute itself. Viewed as a platform, not just a language, it offers WebAssembly, soon WebGPU. I don't see anything else that comes even close as a target platform!
- JonChesterfield 3y ago
  The usual choice is C. I'm currently liking luajit as the tracing cuts through some of the DSL. The JavaScript compilers probably manage the same thing.
- viraptor 3y ago
  Unless you write a basic interpreter or code in plain binary, you're breakpointing in another language. It's really not a big deal as long as you preserve the mapping to the original code. When you breakpoint in C, you breakpoint in assembly and find your C location from the debug information for example.
- hu3 3y ago
  > Second, breakpointing in another language is about as great (possibly worse) as debugging via printf. You don't have to. Just generate sourcemaps and you'll be able to set breakpoints in your own language even when targeting JS. If anything that makes JS an even better target since you can leverage tooling.
Warwolt 3y ago
I think this is an important point. Comparing an initial implementation of a language with that of mature projects doesn't make sense. Every cool language started off in a rough initial state I'd wager, and many were initially developed by a single person, so why not give it a shot if it's compelling?
matijash 3y ago
This is how we went with https://wasp-lang.dev/ https://wasp-lang.dev/ (a DSL for building full-stack web apps). It is a very declarative language (config pretty much) and there is still plenty of work around tooling, but also enabled to cut down on a lot of boilerplate. Another route to consider when implementing a DSL, is to make an embedded one (e.g. like Terraform or Pulumi have, even both at the same time). That doesn't resolve all the tooling problems since there is still a compile step, but might provide a more integrated experience, although at the cost of brevity.

kstenerud 3y ago

Yup, I found out how hard it is just writing a simple language that doesn't even need computer tooling: https://dogma-lang.org/ https://dogma-lang.org/ And even with a language as simple as this, it still took 6 months. The biggest problem is keeping the patterns simple and coherent, while avoiding unnecessary features. It pains me to think of the weeks spent developing parts that were ultimately ruthlessly slashed away. Hours spent agonizing over a usage pattern that was mostly the same but different enough that (I thought at the time) it required special constructs... and then not as I thought about it in the shower days or weeks later. It's one hell of an eye opener. And then there's the type system... UGH.

packetlost 3y ago
There are languages out there that are more or less designed for rapid prototyping of PLs. Lisps, and in particular, Schemes such as Gerbil and Racket, are particularly well-suited to building languages. Yes, you have to get used to the prefix notation and (((((((, but ultimately it lets you have a lot of flexibility in testing out language constructs and usage-patterns before you build the parser, lexer, etc. that are time consuming.
- sitkack 3y ago
  I think you meant, ))))))))
  - MisterTea 3y ago
    I think you just couldn't stand seeing all those unclosed braces ;-))))))))

shanebellone 3y ago

I have the same fanciful desires. I've decided to focus on extending Python with C instead. I can keep the benefits of Python and increase its speed as needed. This concept scratches that same itch.

otikik 3y ago

I believe that's why the article is saying "little" languages. Not all languages need a package repository and a language server

mattgreenrocks 3y ago

What kills it for me is the amount of middlebrow dismissals new PLs get, especially here. Tons of work and some rando comes in complaining you didn't advance type theory to help avoid annotating a type in one location. Arguably worse are the people who advocate against the new PL because no one is using it, strengthening the Matthew Effect, collecting Internet Points for cosplaying as a "responsible engineer" that argues solely for the status quo.

AnimalMuppet 3y ago
> Tons of work and some rando comes in complaining you didn't advance type theory to help avoid annotating a type in one location. If your language gets any traction, then you're going to get a number of randos saying things like that. Worse, some may not be randos. Some may be people with a connection to other languages. > Arguably worse are the people who advocate against the new PL because no one is using it, strengthening the Matthew Effect, collecting Internet Points for cosplaying as a "responsible engineer" that argues solely for the status quo. Well... one of the things a responsible engineer should in fact consider is maintenance, including the ability to find future workers who know that language. It's only one factor, not completely determinative, but it should be considered.
- SaintSeiya84 3y ago
  found one of those randos
deleted 3y ago
[deleted]
karmakaze 3y ago
I don't like dismissals about adoption for anything new or under development as it's a given. I would complain if a posted language doesn't describe why it was created. What's the thing it does that others don't or do poorly. If just playing with syntax or scratching an itch that's ok too--simply make that clear.

LoganWhitwer 3y ago

[dead]

strangattractor 3y ago

Pretty sure Javascript is an example of why most of us shouldn't invent a language:)

fwip 3y ago

Another option is to use tooling that helps you write little languages with debugging, profiling, etc for free. An interesting article I saw the other day: https://news.mit.edu/2023/d2x-easier-way-get-bugs-out-programming-languages-0407 https://news.mit.edu/2023/d2x-easier-way-get-bugs-out-progra...

quelltext 3y ago
Isn't that article / researcher saying the same opinion the submission article is responding to? JetBrains about 9-10 years ago made those arguments and claimed to work on providing the tools to solve those challenges. I'm kind of curious what actually happened in that time. I've actually seen a few of these research projects over the years, i.e. providing tools to build languages with automated IDE and debugging support. Ultimately, I think (like the submission article's author) that it's something else holding adoption back. It may simply be lack of a convincing use case, e.g. industry adoption by one large company could make the overall approach (DSLs) more convincing. Now DSLs or DSL-like languages are of course in use in many orgs but they very often aren't more than configuration languages and often embedded in something else. Very rarely do they get complex enough to warrant debuggers. So I think we a) still lack good examples of DSLs being worth it, or b) a more convincing argument why today's methods would benefit from building a whole new language (incl. tooling).