Hi there, long time no see

[Lartu]

Hello there, @dgarroDC, @xvxx. How are you? I was wondering about the future of the LDPL language, that has been quite dead for a while now and here are a few points I'd like to talk about.

First of all, during the time I've been not working on LDPL, I've been working on other projects (mainly Polaris and LAPL). These languages offer some things LDPL does not offer:

• Polaris is concatenative and experimental, everything there is a string and that lets you do some weird meta-crap that most other languages can't even dream think. Even functions are strings.
• LAPL is the LDPL of a parallel universe. What would have happened if LDPL instead of having being created as "the language that mixes the worst of PHP, Assembly and COBOL", had been instead inspired by "the things I love from other languages". It's also slow as hell.

While working on these projects has been fun and all, there's just one thing that I can't seem to overcome. Those languages are not LDPL and, while LDPL is a language that has major flaws, it also has some very positive points:

• It has some traction here on GitHub. Not much, but we've almost reached 100 favs and many forks and watchers.
• It's been under development for more than a year! There's the docs, the website, the previous versions; it has some history behind it.
• It's LDPL and I love it. Even in spite of being LDPL.

I've seen you've been working on some other stuff too and I don't really know how busy you are right now, but I was thinking about some things we could do to take LDPL to the next level:

1. Update the compiler to use ANTLR instead of my line_like abomination. ANTLR is super easy to use and to set up and it'd save us a TON of work. We could also add expressions and functions rather easily!
2. Maybe -and just maybe- instad of generating C++ code we could generate C code. While this would break compatibility with existing extensions (not that there are so many anyway, this is not Python2 trying to make the leap to Python3), it would allow us to embed an embeddable C compiler into the LDPL compiler (like TCC) and that would allow LDPL to be used as a standalone language, without depending on other compiler.

This would require some work, obviously. We'd have to write the LDPL context-free grammar file for Antlr, begin porting LDPL to this new backend, write the C code to be generated, etc. But the end result will probably be a language that's way, way better than the one we have right now. There's always the option of keep generating C++ code, but moving the codebase to Antlr would allow us to add new features (again, like expressions: store 98 + foo + power(6, 19) in a) that at the moment we just simply cannot integrate.

What do you think?

[xvxx]

This is just my opinion, but for me LDPL is all about having fun and being weird. It’s one of my favorite art projects. What’s missing aren’t language features - I actually think it’s a feature that the language is so slim - but tools and superpowers you can use those language features with. So here are the ways I think it could be taken to the “next level”:

1. Making it easier to build things. Having a “batteries-included” standard library would be amazing. I would love if LDPL came with stuff like:

• command line option parsing (optparse)
• ncurses/terminfo support
• sql support (at least SQLite)
• http support (server, for fun little home pages)
• webassembly (run LDPL in the browser!)
• template library (<b><%= some_variable %></b>)
• maybe a simple flat file db API
• sockets

Just imagine what the “EXAMPLES” or “What You Can Do With LDPL” on a web page or brochure when all that is included! Plus, it would all be free from “dependency hell” headaches. I miss the days of writing programs with nothing but PHP and its included standard library. (It could even generate PDFs!)

2. Growing the community. More people means more code, more ideas, more fun! I think this would entail things like “marketing”, for example experimenting with the homepage to make it more inviting, and “community building,” like maybe hosting LDPL hackathons. We could literally give out prizes - LDPL merch! 🦕 This also would entail better error messages, better documentation, and other “developer-friendly” stuff that makes it easier to get going. What if we had a webpage that just listed every single LDPL statement? I would make it the home page on my TV.

3. Embracing the retro feel. For me, LDPL is good because it’s bad. I believe the French say, “jolie laide”. New languages are like, “Everything is an expression!” LDPL says, “NO! Nothing is an expression! Statements only!” New languages say, “Global state is bad!” LDPL says, “WRONG! Global state is good!” New languages say, “We are going to express complicated, domain-specific concepts using weird symbols like ~ and <> and LDPL says, “NO SYMBOLS!! Not even + or -!” It’s like a version of BASIC that has superpowers and reads a lot nicer. I would love to see the webpage and documentation embrace this vibe even further.

When I open up an editor to write or edit LDPL, it’s like playing an old 8-bit Nintendo. By today’s standards, the games are “bad”. Their graphics are just boxes and lines, their stories are non-existent or extremely barebones and cliche, and usually the games are way, way too hard. But, despite all that - no, because of all that - they are great. They are free from the shackle of today’s trends and have their own view of the world. Even some young kids today enjoy playing retro games, it doesn’t have to be all about nostalgia! It’s like a breathe of fresh air. Something different.

4. Direction. I think this issue is fabulous and would love to see more discussions on the language, or to hear more about future plans. I’d also love to know about the goals of the language and why it exists, or at least why it wants to exist. Knowing LDPL has a future, at least in the hearts of other people, is inspiring and motivating, I think.

So in summary, I think we should look to embrace what makes LDPL unique and different, and do more of that. Add superpowers and more tools to our LDPL toolbox. Write more tooling in LDPL itself, to experience pain points first hand.

[xvxx]

That all said, here’s my thinking on ANTLR/C:

C vs C++

• Why is it a goal to remove the dependency on C++? I find gcc installed on most Linux distros (or just an apt install away), and macOS makes you install it to do any development work. To me it’s a core feature of LDPL that it compiles to C++ so I’m just trying to understand the thinking here, not disagreeing.

• Sadly, very sadly, I don’t think we are going to find an embedded C compiler that will work. I have been looking for a long time, for other projects, to do exactly this, but maybe I’ve missed something! tcc doesn’t work at all on macOS, and most of the others I can find are more like toy projects than real compilers. We might be able to find a small compiler that will compile LDPL itself, but we also have to consider that people will want to write extensions, and so our embedded C compiler will also need to compile things like SQLite or ncurses. If we do find something that works, though, I would be beyond excited. We should probably try this anyway, and who knows, maybe one will pop up or a new one will get created. (There are also embeddable backends like https://c9x.me/compile/ that might work, but I don’t know how well they do with “real world” C projects like SQLite. I think it’s worth exploring.)

ANTLR

I have written both a formal grammar and a hand-written parser for LDPL (4.x and 3.x), so I have some thoughts here.

Basically: even if we move to ANTLR, line_like isn’t going away because of CREATE STATEMENT. Any statement our grammar doesn’t recognize could be a user-defined statement, so we still have to fall back to a “Does this line match any statements we know about?” algorithm. And we’d probably need to devise our own error messages and all that fun stuff.

Instead of codifying all LDPL statements in a formal grammar, I would suggest moving as many built-in statements as possible to use CREATE STATEMENT first. So stuff like ACCEPT n and WAIT n MILLISECONDS would be regular LDPL/C++ functions that are defined using CREATE STATEMENT rather than being built-in to the grammar. Basically, how ldpl-std already does it for stuff like the std-rand.

Then what you’re left with is a really, really slim grammar:

• IF
• FOR
• DISPLAY
• CREATE STATEMENT
• SUB
• CALL
• ...maybe a few more? But like, one dozen, instead of multiple dozens of built-ins.

For that we could use ANTLR, but it’s probably overkill. Writing our own parser would give us more control and we could do it in only a few hundred lines of code, maybe less, with the added bonus of giving us any kind of error messages we want.

I am all for moving to a new parser, especially for error messages, though! If ANTLR is the way you want to go then I’m on board. I just don’t think it’s necessary, especially if we trim the grammar.

Either way I would love to see more work on LDPL and am very interested in contributing more! Thank you for opening this issue.