Having once been poor I understand you, but this is missing the bigger picture. If you're going to improve at mathematics you need to put serious time into it.
Instead of an hour of extra work every day, you're doing math instead. At minimum wage that's around two grand lost over a year. Even if MathAcademy was free.
Also, I recall seeing MathAcademy being free if you can demonstrate financial need.
Janet uses a bytecode VM that's faster than many dynamic languages but won't match SBCL's native compilation performance; it has optional type annotations for documentation but not for optimization.
It's a lightweight embeddable interpreter and runtime, similar to Lua. Dynamically and strongly typed, but no native compilation. Easy to call C libraries, or embed into C projects. In my testing, it's roughly twice as fast as Python for similar tasks. You can "compile" a project by embedding scripts and resources with the runtime into a bundled executable.
> My favorite feature of Janet, though, is something that sounds really dumb when I say it out loud: you can actually distribute Janet programs to other people. You can compile Janet programs into statically-linked native binaries and give them to people who have never even heard of Janet before. And they can run them without having to install any gems or set up any virtual environments or download any runtimes or anything else like that.
They're not super tiny, though. A hello world I just did is about 727K.
No, gp is correct, the 'real executables' are a VM image with the interpreter baked in. The only native code in the binary is the interpreter. Janet code does not compile to machine code.
I understand your point, but by similar logic I can argue any language is interpreted because nothing compiles down to microcode. The point is you don't need janet-specific external dependencies in the environment. I don't differentiate between this and an inefficient compiler.
> I can argue any language is interpreted because nothing compiles down to microcode
Not every processor architecture uses microcode, so this doesn't hold up.
> The point is you don't need janet-specific external dependencies in the environment
Sure.
> I don't differentiate between this and an inefficient compiler
A compiler is the general term here, but the target is not. Targeting the native architecture for a CPU vs targeting a bytecode VM are quite different and have pretty important implications for performance, portability, memory usage, etc.
I think the distinction (from the OP’s perspective) is that it’s “just an app” to the end user.
When I download the Slack desktop app, I might know it’s running on electron because I’m a programmer. But I didn’t have to download and install nodejs or anything else. As far as I’m concerned it’s a completely self contained application.
The end user needn’t download and install Janet or even know that Janet exists.
That can obviously be done with any interpreted language, but Janet makes it really simple out of the box.
Yeah, I see Janet as "what Guile intended itself to be", though it is quite a bit smaller (in some ways that's a postive). I find the choices it made to be more pragmatic and it's far more accessible in non-linux environments since Guile tied itself closely to guix.
That was just an excuse by Valve. The reality was that they were unable to finish numerous HL attempts due to the shortcomings of their organisational structure and somewhat absent/aloof/fickle top management.
Maybe they’ve finally recognized and fixed the real problem. Maybe not. We will see in future performance.
HL: Alex happened because "upper management" (aka the people with the actual power in their amorphous organizational structure) was engaged, and wanted a major title in VR. Major titles do not happen otherwise; excitement by the troops only goes so far, because there will always be setbacks and grind.
I want to second all recommendations of SwissMicros. I own DM15L (~$150), DM41X (~$220), and DM42 (~$250), and they are all absolutely excellent specimens. Not a single complaint. They are easily user serviceable, they have a very high build quality and feel like they will last decades (matching modelfkeyboards dot com build quality). The DM42 has a user-enabled N-stack so you can input algebraic expressions of any arbitrary length. The DM15L is an advanced calculator you (or at least I) can grok completely end-to-end, and packs it all into a compact form; I actually prefer to grab the DM15L before the DM42. The DM41X is also an excellent specimen. It includes the ability to {,un}load module files which are dumps of the old HP-41CX module cartridges. I love every single one of them, and cannot shill (for free) SwissMicros enough. You've beheld Swiss watches, now behold a Swiss calculator!
The hp-50g is pretty nice (I know I know, unpopular enter key location), its USB power and SD card make it quite convenient. Of course the screen is the same as before, but the CPU is faster afaik
And then of course there are many HP calculator emulators and others for android
The 50g screen has only slightly (131×80 vs 131×64) higher resolution than the 48G series, but it has vastly better contrast, and, thanks to improved fonts and other UI improvements, the built-in software on the 50g also makes significantly better use of the limited screen real estate.
N.B.: Meta Kernel[1] provides many of the 50g UI improvements on the 48GX — 49g/50g OS is based on Meta Kernel — but installing Meta Kernel in RAM requires a memory expansion card that, at current used prices, costs nearly as much as a used 50g (plus a steady [semi-yearly IIRC] supply of CR2016 coin cells to sustain the RAM card when the calculator is powered off).
While I also prefer the aesthetics and keyboard layout of the 48 series, the 50g with its bundled software suite stands as one of the most hacker-friendly handheld computing devices of all time: while documentation and development tools for the 48 series were widely available, it wasn't until the 49g that self-hosted versions of these tools (System RPL (de)?compiler, Saturn (dis)?assembler, library creation and extraction tools) were bundled with the base OS.
I'm guessing that you have newRPL. Have you tried putting DB48/DB50n firmware on it? That does have graphics (and RPL). I haven't had time to get familiar with mine, so I can't comment further on capability.
I used to think the same as you about 1-based indexing in Lua... until I tried using Lua in a game engine. I was constantly getting hit in the face with problems (e.g. coordinate systems and off-by-one errors), even after spending far too much time trying to abstract around this mismatch to make these problems go away.
In theory I was okay with the indexing. In practice it was an absolute PITA.
Plus there were other numerous papercuts; it felt like Lua was actively fighting me every step of the way. I went from liking Lua to absolutely despising it.
In the end I switched to C++11, which amazingly was much more productive. As in night-and-day difference.
One thing I've learned watching politicians the past few decades is that laws are guidelines. If the political will exists, politicians will find a way.
Instead of an hour of extra work every day, you're doing math instead. At minimum wage that's around two grand lost over a year. Even if MathAcademy was free.
Also, I recall seeing MathAcademy being free if you can demonstrate financial need.