There is already reverse-debug

@@Bokto1 I meant for jai. I know they exist in general.

look at kira, timeless debugger

Who's the other developer Jonathon Blow is talking to?

@@slair_i Casey Muratori

I'll be praying for you.

I’ve just done the same… 😔

I feel like the web ought to run on some kind of lisp. All the markup could have a lisp syntax (or not) and a common interface for DOM manipulation.

​@@adammontgomery7980 Is this an irony?

To be fair, almost every data structure is readily translatable into S-expressions. XML is what you could call "gradually typed S-expressions" I suppose.

@@adammontgomery7980Web thrives on backwards compatibility, I don't imagine anyone will be rewriting HTML to S-expressions. But in good news, WebAssembly is basically S-expressions :)

@@adammontgomery7980 It almost did. The first prototype for what would become Javascript was "Mocha" - essentially "Scheme for the web" (dialect of Lisp), but the leadership wanted something that smelled like Java, which was gaining popularity back then.

so you know how a function was called? trying to imagine how that could be useful. Seems like an interesting idea though.

@@HairyPixels not just how a function was called, you could also get values from previous stack frames (maybe there is some access specifier for that) I guess you would have to figure out where exactly the variables were somehow

@@HairyPixels if it wasn't useful, C++ wouldn't have decided it was important enough to add it before reflections or any of the many other features that we've been waiting 20 years for.

@@tiranito2834 what's this feature called in C++? I never knew about this.

Jai doesn't really aim at being a general-purpose systems language. Have a look at Zig or Odin for a similar vibe but goals closer to that of C++. Also Rust is there but it's very different in design goals from Jai.

I'm interested too 😢

"Poorly documented" means that either no documentation exists (on what some library function / some API call does), or the dev just doing some bare minimum (like by listing its parameters and nothing more). A proper documentation would include some useful use-cases (example code how to call / use that functionality) and possible value range for each parameter, expected return-type, how to interpret results, how to troubleshoot errors. As for engine problems, this could also mean that somebody once identified errors but never bothered properly writing about them or explaining them in details, so these problems could be taken care of in the future.

@ only listing the parameters and nothing more is the exact problem I have with the Unreal documentation. Screw that noise, I'd much rather implement my own engine than having to figure out how someone else's mess works. I've already spent enough years actually producing on Unreal to know for sure how to use it, but imagine with all the new functionalities coming up, I can't imagine newbies wrapping their heads around it, thus, they end up using the ugly blueprints... whose documentation also suffers the exact same problem LMAO. But hey, what can we expect from Epic? they are just a poor, little, tiny itty bitty small multi million company... we can't expect them to do that all of that documentation work on their own, now can we?!

@@tiranito2834 At this point you probably wrote "some documentation" for yourself. I also saw Unity struggle with that issue in some places and some use-cases tell you nothing new or useful, but at least you can find some good tutorials on KZfaq most of the time. Still, ideally you'd expect from such products to make you put less work into using them, than pointlessly trying different argument combinations or ending up writing a new engine from scratch. Not to mention most open-source programs have better documentation than the paid (or not to mention subscription-based) ones...

Not all. There is C projects that are like 50k+ lines long that I used, and they use an amalgamated build where the whole thing is in a single C file. And all you have to do to build it is `cc project.c` and that's it. It's unfortunate that most projects insist on overcomplicating it with very annoying build systems.

the issue is mainly build systems and linking libraries for c/c++ (cmake is more confusing/unintuitive than automake imo). Anyways I bet open source projects are easier to build over a variety of environments than closed-source projects. As for java I find it pretty simple to compile since everything compiles to the same bytecode and if you use something like maven everything has the exact same dependencies (if the versions are pinned).

This is one of the things I loved about starting to learn Rust - cargo just takes care of it all and it's so easy to just clone a repo, `cargo build`, and it just works :) Having said that, I've seen some very cool build systems for C, including a header library that lets you configure your own build in C itself. You build one file using cc, then that executable builds the rest of the code for you - I thought it was an interesting approach.

@@michaelzomsuv3631 Oh but this complexity is unforgivable (prepare yourself): We have to use a library cc project.c glfw3.lib So complex!! (in reality this is obviously simple and some people seem to think they have to use dumb things like cmake; it really is easy if you make it easy)

​@@sub-harmonik I've heard some great things about maven, but nobody ever seems to use it. The vast majority of open source java projects I've seen depend on gradle and/or eclipse with 20+ environment variables instead of a config file and it just makes for a terrible build experience.

Only those programmers who repeat what others do and call it industry standard. Like parrots and sheep.