u/ythl

Right, but my main thesis is that you need access to the source code in order to know what a proxy does. It's not possible to figure it out at runtime with a REPL like the console or otherwise. The console alone does not provide the source code so you cannot infer what the Proxy does; however, the console may provide a reference to the source for examination.

> I've already got 20 questions like why didn't you just use a native library that already does exactly that?

The short answer is that we used to use Mathjax + Node.js, and we have hundreds of knowledge articles with math equations a few of which depend on some of the eccentricities of Mathjax, so Mathjax + goja allowed us to remove the Node dependency without needing to check hundreds of KAs for rendering regressions.

> That said I'm deeply skeptical of the benefits and criteria you claim -- I doubt goja is more "secure" than a battle-tested runtime like V8 or JSC, how anyone in a regulatory space has even heard of goja let alone rubber stamped it is beyond me.

I agree with you - goja is almost certainly less secure than V8. However, note that the JS it executes is trusted (not user supplied), so it's fairly low risk. The bigger thing for us was the CVE surface area and SOUP (software of unknown provenance) surface area which is what regulatory bodies like the FDA care about when dealing with medical device software or medical device adjacent software. With a "from scratch" golang binary docker image, the surface area is the go stdlib and go dependencies. That's it. OTOH it's exceedingly difficult to do a "from scratch" Node.js docker image. Which means suddenly your surface area has already exploded into whatever your base distro is (alpine, ubuntu, debian, etc). There's now a torrent of distro-specific CVEs you have to regularly justify as "false positive" or "won't fix" such as libxml2 and all the other c libraries included in your base image. And that's not even mentioning npm also having a tendency of causing causing explosions in SOUP/CVE surface area due to the micro-package dependency web (a problem much less pronounced with go packages). Those are a few of the pressures that led us to move to a 100% golang application. Someday we would like to replace mathjax + goja with a native go solution like https://codeberg.org/go-latex/latex but so far the native go ones aren't mature enough yet (though with LLMs now we could probably fork and get up to snuff pretty quickly).

> The thing doesn't have a debugger, you are right. I'm sorry but proxy objects are the least of your problems here.

Yes, you are right. And actually I haven't ever used Proxy objects at work! I wrote the article because I discovered them when developing a video game and found their behavior surprising and fascinating so I wanted to do an "FYI"/"PSA" type piece. My specific use case for using Proxy was obscuring object APIs in a JavaScript puzzle adventure game I developed, and in my game, you can write and run JS, but you don't have access to a full debugger!

At my work we use goja (https://github.com/dop251/goja) to run mathjax in JS VMs in order to render math equations as SVGs. This is so we can avoid a NodeJS runtime dependency and keep our docker images "from scratch" (containing a single statically compiled go binary) which has huge regulatory and cybersecurity benefits.

Pragma Twice (https://store.steampowered.com/app/3528840/Pragma\_Twice)

Inspired by another excellent programming game Untrusted (https://untrustedgame.com/)

Indeed, though you may not always have access to a debugger/breakpoints depending on where the JS is executing!

Yes, it is a little tricky balancing user requests with the spirit of the game! Even things like level balancing is a little tricky. Some users are getting stuck on levels and I have to decide whether to tweak the level to make the intended solution more obvious or stand my ground (or something else altogether). Ultimately I want the levels to feel challenging but fair, and I know a few of the levels might have slightly steep and sudden spikes in difficulty at the moment.

For the JS engine it's using full V8, so it should be able to do anything that you could do in a Chromium-based browser!

I always love to hear players' thoughts, so thanks for the feedback!

Currently the best place to share feedback is the [community discussions] or the [Discord], though not as many people are using the Discord yet.

For #1, I agree it would be nice to be able to organize kernels into multiple files somehow. Still mulling over what the best way to support something like that would be. Your workaround is very clever though! With such an approach you could do increasingly sophisticated things like writing kernels in TypeScript and having build.sh auto-strip out types!

For #2, improved in-game docs have been requested [here] - we are actively developing a "manual" tab that can can be used as a permanent reference for documentation you've discovered (and we'll probably write out a manual.txt for those that want to search the manual with external editors like vim). And we could certainly beef up some of the man pages (such as robot.reprogram) to have more examples.

There's also a related feature request you may be interested in [here] which is to basically capture closures when passing a function to `reprogram()`. I think this should possible with an AST generator/analyzer like [Acorn] and I'm still prototyping this. Your current approach (injecting some startup context before self.getKernel() to guide how it executes) also works and is probably the most creative meta-programming solution I've seen so far!

Thanks for the feedback!

One possible workaround - it's not exactly Vim mode, but with the full game you can edit your kernel with any editor (including vim) so if you have 2 monitors you can alt+tab between vim and the game and the game automatically detects changes you've made and loads them without mouse input.

Possibly, I'll take a look at cli-games!

Watch other people play your game (and resist temptation to help them; just silently observe and take notes)

Glad you are enjoying it! Sorry there's not an easy way to transfer save file from web version to steam (yet). I can give you autonomous solutions to levels 1-6 if you want to quickly get back to where you were before, just let me know.

> I will say though, needing to brute force some of these passwords feels like a bit more than needing "a little JavaScript" lol.

Just think, you'll be able to put "beat Pragma Twice" on your resume in the future and employers will know you have serious programming chops ;)!

Thanks for the feedback and kind words! I'll have to take a look at the start button again because I do remember disabling it on startup for some reason, but it's not supposed to stay in that state.

Thank you for the kind words!

If you are enjoying it enough that you think it's worthy of a positive review, please leave one because currently it has zero reviews!

Thanks!

Thanks!

Update:

Track game progress here: https://store.steampowered.com/app/3528840/Pragma_Twice/

Just another "me too", running Debian 12 + XFCE and xfwm4 by itself was over 20GB RAM usage and grinding my PC to a halt because of swapping. `xfwm4 --replace &` is an ok workaround.