8,002 karma · joined August 8, 2008
And in my experience, apart from ease of use there's also a major trust issue here. If you're upgrading your app server framework/language, it's easy enough to do a rollback. With databases, people are worried that they might not notice errors right away and then you have to merge the data accumulated since the upgrade with the last backup in case of a rollback.
Not saying that this is entirely rational...
Also, new features on the SQL level are hard to sell if all you're doing is lowest common denominator ORM ("New window functions and faster lateral joins? But we're doing all that in our code!").
One problem that D&D and videogames have, is that weight in lbs is a pretty poor simulation of the burden involved. The sheer bulk or lack of proper carrying opportunities seems factored in a bit into several RPGs, even those where you can carry 111 spears in your backpack.
The (vastly underrated) tabletop RPG RuneQuest once ditched "lbs" and went with a more abstracted "encumbrance" (ENC) statistic. And of course lots of videogames plus several tabletop games go with a slot- or grid-based inventory as a main or secondary source of being overburdened.
Weapon weights and similar issues (too short rapiers, non-existant back scabbards) seem to be the "not every weapon is a AR-15/mind your trigger discipline" of the HEMA crowd.
Some day I might try my hand at a "full Jeremy Evans" stack backend, i.e. both Sequel and his web framework Roda, authentication with Rodauth etc.
Always glad to see software that still aims for some backwards compatibility. Sure, it might require a bit more testing and/or handling some customer complaints, but not everyone is one the latest version or able to do that.
(I do wonder whether a lot of that isn't just driven by either just accepting XCode defaults or some Swift stuff that has a very low range backwards)
Maybe I'll put RiscOS on a Raspberry Pi at the same time, which (IIRC) had one of the first antialiased font rendering engines ever.
(I do have some old Macs running currently, and weirdly enough still prefer some of the old "blurry" font renderings to a lot of modern ones, at least on regular displays)
How many language servers are we talking about here for the average dev? Three?
"These notes may be compiled into a pdf file through Quarto. As the result is rather large, we do not provide that file for download. For the interested reader, downloading the repository, instantiating the environment, and running quarto to render to pdf in the quarto subdirectory should produce that file (after some time)."
If more time is available, then a core of <favorite language> plus a view part in the native platform language and API.
Of course, now I wonder how to quickly express "change within 2nd text delimited by ..."
Don't remember anyone doing OO back then with it, either. Would be interested to know how that worked...
Not everything has to or can be be cross-platform, not everything has to be web-visible. And I'd argue that serving the same view to everyone is quite often a bad idea. (Heck, in the web-case, it's not even just the view)
A lot of the color fiddling etc. that web apps due is due to
1.) Graphic designers having no other way to go, now that print is dead
2.) Corporate Identity (which is of lower priority than platform identity)
3.) Selling stuff (not needed as much with desktop apps)
Granted, the LOTR of Lothlorien helped, too (I only saw the Sagrada Familia in 2022). To past generations, "Gothic" means something quite different, as we see it in our current context, with darkened fronts and comparisons to buildings that allow even more glass. But back then it was all light and organic. The SF seems to go in the same direction, but unhindered by medieval masonry and mathematics.
Then again, I also like brutalist churches...
Sometimes it's interesting to see how far you can go without going the "let's download the web in a JS blob" way.
One of these days, I'm going to see whether I can still build something reasonably modern with Seaside, the continuation-based framework from the olden days, where basically the whole UI state is stored in the server-side session and everything is a request. Worked quite alright, way back when not everything had a local CDN and the internet tubes were a bit narrower.
So I obviously can't say a lot about the style preferences, last presentations I held just used the company style.
But hooh, that font section couldn't get any more generic, even mentioning Calibri. No hints at what font characteristics you're looking for, or good examples of that (I'd say that you're better off with something that has a lot of weights, and if it isn't already condensed/compressed, at least one option for that)
1. The post is already about an alternative to the mainstream (Spring), so adding another alternative seems perfectly valid.
2. I know neither Spring nor this alternative, but want to add the one framework I know of. This gets increasingly popular after previous 1./2. responses.
3. My/my company's badly tested pet library, let me show you it.
(Back when Go came out, there were some Algol 68 comparisons, IIRC)
In general I notice a lot more resources used for terminal multiplexing, starting with GPU-focused terminal emulators (or even ones using Electron).
Maybe I missed something, I probably could run screen + xterm and barely notice any difference. Almost getting a bit of FOMO here, but have yet to see e.g. a screencast that would make me envious.
Meanwhile, XForms has been open-sourced, but FLTK being in a different language and having evolved a bit since its creation didn't suffer from the problems Lesstif had and is standing on its own rather well. And despite being C++, it pops up rather often when you're looking for GUIs with decent language bindings (e.g. for Lua or Rust). Probably because it's less a moving target than Qt or, heck, Gtk.
Although with FaaS, I don't see anything particularly new from a development perspective. It's, well, functions. Most of the time they aren't communicating in any kind of novel way, and often they're doing the decade-old stuff of reading files and slurping databases. The abstraction being more on the operational side of things this time.
Not that I'm complaining or doing the "it's just CGI" dance. Compared to other "cloudy" tech, there's actually potential for simplifying things and not just simulated VAX computers with more effort…
And boy, Kafka more and more seems like an early warning system for architecture astronautics. (Not necessarily bad by itself, but often part of hectoliters of manure poured in size 6 wellies)