I think we will need new standards here, because terminal emulators currently don't have any semantic information about what TUI programs are rendering. Browsers have the benefit of HTML to know this is a button, and that is a paragraph. A terminal is an unstructured grid of characters. The best we can hope for is for terminal emulators to use heuristics or AI to make sense of what TUI programs are rendering.
It doesn't detract from that at all, chief. What a weird thing to say. Particularly in the case of Nim -- it doesn't "throw away" C or C++, it compiles to them!
I believe cyclic imports are coming. And Nim does supports wasm...you can target it with `--cpu:wasm32`. You most likely want to pair that with emscripten as in https://github.com/treeform/nim_emscripten_tutorial
Yeah. checked out wasm part. But man. I am not going to go into Nim without cyclic imports.
I was writing a compiler I remember where I hit the 5k LOC mark in Nim. And then the errors and stuff. It was a terrible experience putting all the types into one file, the functions into others etc etc. The DevExp is bad that way.
Other than that, I don't see much issues with Nim to be fair. Its quite a good language that ticks all boxes
That's pretty sweet, I didn't know C++ could do this now!
Zig's still got it beat handily in simplicity though -- I think what's really cool about Zig's idea of comp-time evaluation is you get something like the power of C++ with something like the simplicity of C.
> the big tragedy it's that is focused on freight transport
I don't see the tragedy in that. Tracks in the US are privately owned and freight makes them more money than passenger rail. Don't think we'd gain anything by artifically changing that. Even in Europe planes are usually faster and cheaper than rail when traveling between countries.
I'm not sure why this would be considered a controversial statement. A lot of short to medium distance in Europe is very good/convenient by rail, e.g. Eurostar from London to Brussels or Paris--even if not necessarily cheaper than flying. But while I've taken night trains between countries, it was more for the experience and not to save either time or money.
The tragedy is that people who want to use the railways are put below freight in priority - whereas other countries such as Russia and India are capable of mixing both.
Reactive updates is the big one, in my opinion. DataScript is a triumph and arguably is the reason why so many note-taking tools (Roam, Athens, Logseq, etc) are written in Clojure. But there are so many cases where it would be nice to react when some set of entities is changed.
I think what we need is to figure out how to combine DataScript with a rules engine. I wrote a rules engine and made a writeup that compares the two together: "Using O'Doyle Rules as a poor man's DataScript" https://github.com/oakes/odoyle-rules/blob/master/bench-src/...
Subscribing to individual entities is nice but with a rules engine you have so much more fine-grained control over your reactions. And with the RETE algorithm this can be done efficiently. Most libraries in this space just ignore it and make their own ad-hoc solution -- an informally-specified, bug-ridden, slow implementation of half of a rules engine.
The rules engine direction is definitely an interesting one, hopefully there’s more exploration into that in the future.
For my needs now I actually wrote something pretty hacky[1] to get a 'reactive' version of DataScript’s Entity API.
As Nikita mentions in the article, I’ve found that most of the time I don’t really need queries in the UI, and so the entity API ends up fitting quite well – except that it’s non-reactive.
The `reactive-entity` library implements a reactive version of (most of?) the entity API, so you can pass entities in/through components, and then the components only re-render when the attributes accessed within those components change (including attributes accessed on other entities through refs).
Loads of room for improvement but I’ve used it successfully in a couple of projects.
That is the case with JavaFX as well. It's not part of the JRE anymore. Also there really isn't any such thing as the JRE anymore, only the JDK. If you want to distribute a desktop Java app you must embed the entire runtime via javapackager. They have correctly realized that end users cannot be expected to install and update a language runtime separately...
First, of course, all this depends on the audience.
JavaFX can still be installed in a JRE, so that the application does not need to bundle it. This is fine for internal distributions, or distributing to people willing to put up with the minor headaches of maintaining the JRE separate from the app.
But, consider, for example, NetBeans does not come with its own JRE. It's not a great leap, since it's a first most Java IDE, but if you wanted to use NetBeans for PHP, you'd still need to install a JDK separately just to run NetBeans. NetBeans doesn't use JavaFX, the point simply being that there are still large Java apps out there that require you to separately download the JRE/JDK. How much this is a hinderance to their adoption, I can't say.
The direction is towards all in one JRE/FX/App bundles, but that doesn't mean it's the only way.
If you can just deploy the app jar file, the apps can be quite tiny.
In the middle ground, https://jdeploy.com manages this. They host applications, but as I understand it you can deploy the infrastructure yourself and host it yourself.
You download the app, and their infrastructure will download the appropriate JRE (including JavaFX), and share it among all those apps that do, indeed, share it.
It has "up to date" systems for updating your app. When you download the app, you get an installer that does all the work.
This is great if you have a bunch of small apps you wish to distribute, as they're basically just the jar files. The first install is a kick, of course, and as you move through the JVM versions, they'll all incur an additional hit.
But if you distribute a dozen apps all on JDK 17, then the overall download should be quite small as the JRE is only downloaded once.
I have yet to use it, but it demos nice.
As for Fonts, they seem OK to me. I use macOS, but I've also looked at them casually on a Linux VM. However, there is one sticky bit with the fonts.
At least on macOS, the default font is terrible simply because, of all things, it doesn't support the different font faces. You can't do BOLD with the stock font. It's quite the nut until you figure that out.
So, I ended up embedding a font in my app. And it all worked. It rendered fine on my Mac, and the Linux VM, and it printed to the printer well as well.
I chose Source Sans Pro, which is one of the available Google fonts.
It's annoying that I had to go down that rabbit hole, but it is what it is.
There's some ramp up time with FX to be sure, but the combination of FX with the SceneBuilder to do layout works.
This is a recent screen shot of my app, I'm no UI guy (I majored in "Programmer Art" in college...), but it looks OK to me.
Nim supports wasm. You can target it with `--cpu:wasm32`. You most likely want to pair that with emscripten. Here's an example: https://github.com/paranim/parakeet
