- XML for config data storage and coordination 🧐 - Universally available stack trace 🧐🧐 I've worked with Common Lisp for years and enjoy checking on how the rest of software engineering is getting along. Those points caught my attention because 1. XML is essentially an ugly version of S-expressions. 2. Common Lisp put the idea of a fully integrated debugger back in the 80s, part of the ANSI standard since the 90s. Common Lisp has many rough edges, but I hope at least modern languages can learn from the example and include the positive features already demonstrated for decades.
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.
I think it's more like John is confirming that making a general tracing stuff is sort of a Swiss Army Knife and personally speaking I'm understanding this as something as a necessity for a personal debugging dark magic library but not to be synthesized into some PL feature.
it would be cool if more languages exposed the underlying stacks/frames. And allow implementation of wild stuff like dynamically scoped variables as well (or environment-wrapper functions). And obviously serializing a stack trace would be trivial at that point.
@@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.
Jonathan Blow makes me feel it's not me going crazy, it's kinda cathartic. I really hope his new language Jai (or any other good one) eventually replaces C++. ...And maybe Jaiscript? lol
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've been trying to find a talk of his he gave but haven't been able to find it. It's about an hour long and he's presenting to a crowd. At one point he shows video of a racing game where two cars are on a straight road to show how the game has dynamic difficulty adjustment. He also talks about 'self-sabotage' in game design. Anyone have a link? Edit: Found it, czcams.com/video/v_A3T-MLWJ8/video.html
How do you document code or problems in an engine? When I hear 'something isn't well documented,' I'm wondering what defines those parameters.
Před 2 měsíci+1
"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?!
Před 2 měsíci
@@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 CZcams 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.
Given Braid, seems like a timetravel debugger is a very obvious thing to do.
There is already reverse-debug
@@Bokto1 I meant for jai. I know they exist in general.
look at kira, timeless debugger
Is that the two most based gamedev programmers in a single video?! Sign me in.
Who's the other developer Jonathon Blow is talking to?
@@slair_i Casey Muratori
2020/03/29 - almost exactly 4 years ago. Thanks for sharing, hadn't heard this discussion.
Everything external to actual programming is killing my desire to write code. It's awful.
- XML for config data storage and coordination 🧐
- Universally available stack trace 🧐🧐
I've worked with Common Lisp for years and enjoy checking on how the rest of software engineering is getting along. Those points caught my attention because
1. XML is essentially an ugly version of S-expressions.
2. Common Lisp put the idea of a fully integrated debugger back in the 80s, part of the ANSI standard since the 90s.
Common Lisp has many rough edges, but I hope at least modern languages can learn from the example and include the positive features already demonstrated for decades.
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.
5:55 I feel personally attacked, there's no adult in the room when I code....
spent all day on debugging cmakelists
I'll be praying for you.
I’ve just done the same… 😔
Some say they are still on bathroom break to this day
I think it's more like John is confirming that making a general tracing stuff is sort of a Swiss Army Knife and personally speaking I'm understanding this as something as a necessity for a personal debugging dark magic library but not to be synthesized into some PL feature.
Log the stack trace on the mutator, good trick! I'll steal that one!
it would be cool if more languages exposed the underlying stacks/frames. And allow implementation of wild stuff like dynamically scoped variables as well (or environment-wrapper functions).
And obviously serializing a stack trace would be trivial at that point.
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.
Jonathan Blow makes me feel it's not me going crazy, it's kinda cathartic. I really hope his new language Jai (or any other good one) eventually replaces C++. ...And maybe Jaiscript? lol
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 love this so much - there is no adult in the room.
I've been trying to find a talk of his he gave but haven't been able to find it. It's about an hour long and he's presenting to a crowd. At one point he shows video of a racing game where two cars are on a straight road to show how the game has dynamic difficulty adjustment. He also talks about 'self-sabotage' in game design. Anyone have a link?
Edit: Found it, czcams.com/video/v_A3T-MLWJ8/video.html
I'm interested too 😢
How do you document code or problems in an engine? When I hear 'something isn't well documented,' I'm wondering what defines those parameters.
"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 CZcams 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...
Getting just about any C/C++/Java open source project to build sucks.
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.
Its ok people, AI will solve all those problems for us and replace all programmers 😂
Only those programmers who repeat what others do and call it industry standard. Like parrots and sheep.
Lol you look badass in that Thumbnail. You should consider a career in HollyWood!