Hello everybody, author here. I hope you enjoy my tiny project.
Regarding language, I chose Javascript for three reasons:
- the (ab)use of `eval` lets you do all sorts of sorcery, like instant evaluation
- the JS Redux library makes it easy to work with state, and I couldn't have implemented SCRIPT-8's time-traveling debugger without it
- I dream in Javascript
I love Lua's small footprint, and very early on I considered writing SCRIPT-8 in MoonScript, which compiles to Lua and has gorgeous syntax. Maybe some day.
And yes, my fantasy computer is definitely not the only open source project, there's several out there, and probably all of them are more stable than mine. Go check them out.
> very early on I considered writing SCRIPT-8 in MoonScript, which compiles to Lua and has gorgeous syntax. Maybe some day.
I know it's no longer considered hip these days, but why not support CoffeeScript?
It's easy to compile to JS on the client-side, so support should be much simpler than Lua or MoonScript. You could steal the trick TIC-80 uses to support MoonScript and say that starting a cassette with the string "use CoffeeScript" marks it as a CS file. Then it's "just" a matter of an if(String.startsWith("use CoffeeScript\n"))-check followed by an intermediate string-to-string compilation step, right?
Apart from https://github.com/usefulthink/coffeescript-from-hell/blob/m..., it takes the worst approach to spaces as syntax, because it doesn't enforce consistency, so with many devs you can end up with a file with two, four spaces, tabs all compiling but easily breaking. It has features their own syntax checker recommend not using, like defining objects without curly braces (which I think shouldn't even be a feature, but it was once so backwards compatibility)
Coffee Script tries to be beautiful without straying too far from Javascript and it ends up being an easily broken mess. I would then recommend either typescript or purescript.
Honest question: pointing out programming design warts that allow for WAT-level code[0] is perfectly valid, and I obviously prefer elegantly designed languages. Having said that, how realistic are the odds of being bitten by these issues when using CoffeeScript?
Also, if our point of comparison is Lua and MoonScript, how do those compare?
EDIT: regarding TypeScript and PureScript, can those be compiled in the browser? By which I mean, I'm sure they can technically but do not-too-heavy implementations of such exist?
> how realistic are the odds of being bitten by these issues when using CoffeeScript?
In my experience, minimal if you know the language well and can work around its quirks. Having said that, I prefer working with a language that doesn't require much time to tame and let me do concrete work, at the same time holding my hand when necessary (because of time schedule and pressure and so on). This is less of an issue with private projects, but still there are no downsides in learning a tool that is great for both lone and team work, so there is no real benefit in using coffeescript when there are much more solid languages that compiles to Javascript out there. Hell even heard you can change Glasgow backend compiler to make haskell output Javascript haha
I can't answer about lua and moonscript, I'm completely unfamiliar with them.
About typescript and purescript being compiled in browser, I have never even looked into such approach, they feel unrealistic, because from the top of my head it would require a compilation tool written in JS, which is not particularly efficient for this kind of task that benefits from parallelization, specially if you are not doing deep checks, just translating code. Then there is the matter of what to do with the resulting code. Can we dump it into a file and load it programatticaly? I would be surprised if we could. Eval() the output? Not without some serious security checks that would further compromise performance.
So I believe there is no motivation in not pre-compiling and distributing the result dist code
> About typescript and purescript being compiled in browser, I have never even looked into such approach, they feel unrealistic, because from the top of my head it would require a compilation tool written in JS
Eh, not really: you could write the compiler in any language that compiles to JS, then use the compiled output as your compiler. In the case of TypeScript or PureScript you could basically write a self-hosting compiler this way.
Walt is a compiles-to-WASM language that has partialy done so[0]. Its compiler written in JavaScript, and the generated compiler is also JavaScript. While not self-hosting, the guy developing it has rewritten parts of it in WASM to figure out what the best language design for strings and related JavaScript interop would be.
> which is not particularly efficient for this kind of task that benefits from parallelization
First of all, isn't WebPack written in JavaScript? Seems to do just fine.
Also, if we are talking about a somewhat modern browser that supports Web Workers parallelization is perfectly viable, no? Add Web Assembly and TextEncoder/TextDecoder in the mix and things could get even faster[1][2][3].
(The main performance issue I see is that due to SharedArrayBuffers being disabled (for now), each worker would need its own Uint8Array copy of the source input[4])
> Can we dump it into a file and load it programatticaly? I would be surprised if we could.
Saving a file is easy these days, just use a Blob[5].
> Eval() the output? Not without some serious security checks that would further compromise performance.
Creating Function object works. It just requires a string as input. I also don't see why this would be more insecure than compiling the same source string ahead of time - you end up running the same code. This isn't the typical user-context in which eval is dangerous.
> So I believe there is no motivation in not pre-compiling and distributing the result dist code.
You are arguing this from a technical point of view, which misses the entire point. Namely, that client-side compilation allows for browser-based apps, demos, and sharing. It greatly lowers the threshold to trying things out.
You may dislike CoffeeScript, but being able to try it out in the browser is quite a good sales pitch[6].
For a more ambitious example: Observable is a notebook environment similar to IPython, but for JavaScript, and with one of IPython's biggest quirks removed: cells track dependencies on other cells and re-evaluate as necessary[7]. The server is there for cloud storage and remote collaboration, allowing you to instantly share the notebook. However, I think it does most, if not all of its compilation client-side, since it still works when you are temporarily off-line (also, Jeremy Ashkenas is part of the developer team).
The aforementioned compiler for Walt can easily run in the browser, so last year I tried combining the two. It took me only a couple of hours to get it working[8].
Of course, you lose the benefit of a developer environment made for the language (but IIRC supporting compiles-to-JS languages is on the long-term Observable roadmap), but still: being able to quickly try out some simple WASM code without needing anything except a modern browser is quite powerful.
They don't now, but that is coming. The "SHOW CASSETTE SIZE" button under the live-preview screen shows you the current size / compressed size. But it doesn't prevent you from making a huge cassette - not yet.
This looks fun! Would be great to have something that catches runtime errors and highlights them in the source code. Then, of course, code completion etc to make it easy to find stuff.
I started working on a bit similar project some years ago (I unfortunately abandonded it...) but I got one thing right: the ability to highlight the erroneous line. See http://write-a-game.herokuapp.com/ and try to call a non-existent function.
Very creative project! Did you experience any issues doing pseudo-low-level programming with Javascript's lack of typing system or definite integer/float data-types?
Thank you, and no issues, because I didn't implement any low-level programming. I use React/Redux and Canvas 2D, with some custom shape drawing to avoid antialiasing (e.g. Bresenham's algorithm).
I find kind of disingenuous that the page does not mention PICO-8 at all, which is the obvious inspiration for this project, starting from the name. Many people who are in the scene, as it were, do know PICO-8 and know to draw the parallels, but it'd still be nice to link back to https://www.lexaloffle.com/pico-8.php somewhere...
I'm an avid Pico-8/fantasy computer fan, and this is a really nice project. There have been quite a number of fantasy consoles coming out within the past few years, so it's nice to see one that offers features that the others don't, rather than simply "Pico-8, but with a twist". The live coding window and sliders in particular are simple things that increase QoL.
Others have noted that the use of JS is somewhat of a turn off, but even as a big Lua fan myself, it doesn't really bother me, I already have one (probably more than one) Lua fantasy console that covers my wishes. However, the author's comment here did mention adding MoonScript support, which would be something I would be very interested in.
This looks incredible ! Real time editing, time travel
... and integrated sprite, map, and music editors are a real plus. Only thing is the default color palette that is great but I wonder if we can change it ?
For people complaining about JS vs Lua : go have a look at Amulet. This is not a fantasy console but also has an online editor and is perfectly suited for retro games. Just have a look at "Defender of the Weeping Quasar" in the example section :
http://www.amulet.xyz/editor.html
Interesting how different people arrive at similar ideas. Many years ago I created a retro-like "virtual computer" in Java, called simpleJ, to let teenagers learn how to program by creating simple arcade games. It also had an IDE like environment, with a step by step debugger that could draw a diagram of run time data-structures (arrays, linked lists, trees, etc.), a tile editor, a sprite editor, and a even a book teaching you how to program a video game. You can take a look at it at http://simplej.com/ (in Spanish).
This is exceptional - an online IDE with tutorials, sprite and tune editor, interesting code examples and little games to hack on, even an upload to share feature.
It only looks a bit ~dusty due to the sepia pallet, should be good to have other choices like a neon hue, and even free custom selection. But hats off here, this is a great resource !
No it's not. TIC-80 is open source and there are other open source fantasy consoles. The killer feature here is the Bret Victor inspired live coding support.
Not to mention JS vs Lua (an unfortunate direction in my view). That said, open source is good. There are a few other open source versions. TIC-80 is another open source option. LIKO-12 as well.
My main minus to this is not that it's JS(I'm building a JS fantasy computer too) but that it's a node/react piece, which inspires zero confidence that it will have anything resembling foundational stability in the future.
The typical performance requirements of these fantasy consoles are well below the need for WASM. Having said this, since this one is JS-based there shouldn't be anything stopping your from compiling your own WASM module in the code
Unlike most, I don't see a problem with it being Lua or JavaScript. I'm just curious why people pick such high-level languages in the first place. I'm planning to make a fantasy computer myself (basing it off the z80), and would never think to make it scriptable in something other than machine code.
But BASIC on those computers was interpreted, and thus far too slow. Even the C compilers weren't that great. Every real game, AFAIK, was written in 6502 assembly.
The point is that it's not "javascript interpreted in machine code", which in my opinion would make these computers far more fun, otherwise they're just fancy game frameworks.
> I'm planning to make a fantasy computer myself (basing it off the z80)
This is so much fun, I did this last year, although initially it only ran inside Unreal Engine. Later on I did a "native" port to Linux. It can run CP/M 2.x and Wordstar (https://i.imgur.com/rIY1he8.png), it had a telnet+VT100+zmodem client for accessing BBS's (https://i.imgur.com/VszSPkB.png), and I even added a graphics mode later on (https://i.imgur.com/t3kreQM.png).
I'm working on a 68000 based one now as well. It's a really great learning experience.
+1. I wish they used Lua instead of Javascript -- maybe using Lua.vm.js[1], although the VM in a VM thing may be a challenge to integrate with the rest of IDE, sprite editor, etc.
I think Lua is a wodnerful langauge, highly embedable, great feature set/style, quite fast, really lightweight. Pico-8 had it right in everything but the license.
>Everything compiles to JS these days, so it is an easy lowest common denominator.
That's not even remotely true. JS is only a common denominator for running code in a browser, but the lowest common denominator is still C/C++ and Java, even with native applications vs. Electron.
You keep using that word. I do not think it means what you think it means.
Javascript has no 8-bit types, nor does it have memory limits that 8-bit machines had. Pixelated graphics are cool and all, but it does not place you in the same league with people who made games fit in 128 bytes of ram and 2K of ROM, sorry!
Regarding language, I chose Javascript for three reasons:
- the (ab)use of `eval` lets you do all sorts of sorcery, like instant evaluation
- the JS Redux library makes it easy to work with state, and I couldn't have implemented SCRIPT-8's time-traveling debugger without it
- I dream in Javascript
I love Lua's small footprint, and very early on I considered writing SCRIPT-8 in MoonScript, which compiles to Lua and has gorgeous syntax. Maybe some day.
And yes, my fantasy computer is definitely not the only open source project, there's several out there, and probably all of them are more stable than mine. Go check them out.