I've been playing around with the Godot game engine as a sort of modern successor to Delphi / Lazarus. I'm currently messing around with trying to create some database server management software using it.
GDScript is pretty similar in feel to Python, and you can also use C# if you want to. It has some level of GUI controls in the framework (not sure how many yet, but all of the GUI controls used to build the editor are available for use).
I want to believe the 3d capabilities might be useful for some kind of UI stuff, but I don't really have a real idea how to make that work - just a "wouldn't it be neat if..." question about it right now.
With the caveat that you probably shouldn't listen to me (or anyone else on here) since you are the only one who knows how much pain each choice will be ...
I think that given that you are not really dealing with structured data - you've said that different sites have different structures, and I assume even with processing, you may not be able to generate identical metadata structures from each entry.
I think I would go for one column of XML, plus maybe another column that holds a parsed data structure that represents the result of your processing (basically a cache holding the post-processed version of each site). Hopefully that could be re-evaluated by whatever language (Python?) you are using for your application. That way you don't have to do the full parsing each time you want to examine the entry, but you have access to something that can quickly give you whatever metadata is associated with it, but which doesn't tie you to the rigid structure of a table based database.
Once you know what you are really doing with the data, then you could add additional metadata columns that are more rigid, and which can be queried directly in SQL as you identify patterns that are useful for performance.
It's not listed as cdecl and (therefore?) not findable in the index, but in chapter 5 - Pointers and Arrays - the book presents the programs dcl and undcl that translate between C declarations and English renderings of them.
Tcl/Tk is still the easiest way I have found to make small gui apps and the language and standard library is small enough to keep in your head easily.
Pico 8 is my recent love. It's a great way to make small retro style games. There's a free educational edition or you can pay $15 for the full version which has some extra export options. I've been playing with it for the past couple months and my kids from 6-11 have started to get involved.
It's programmed in Lua and I and my kids prefer it at the moment to our previous attempts at Scratch.
o I believe this manual is downloadable as a literate org file that contains both the full documentation of the system, and the code of the system itself
o This system produces C++ code that can be compiled down to binaries.
o I am curious how this compares to Jank - another Clojure (ish?) dialect that also targets compilation via C++.
There were a number of really mind-blowing programmers that hung out in the Tcl ecosystem back around this time.
antirez, Richard Succhenwirth, Jean Claude Whippler, more.
So much of my early programming education was just wandering around the Tcler's wiki and messing around with the amazing random toy projects they came up with.
And then dipping down into the C code for Tcl was always really cool - the Tcl C style has always really impressed me. And it seems like that style was carried on in related projects like SQLite.
Sorry for responding late, but I don't think Termux includes SBCL - at least it doesn't on my android devices. But it does include ECL (Embeddable Common Lisp).
Apparently, you can compile SBCL using ECL, so if you really want SBCL itself instead of just a Common Lisp implementation, that might be a path to it.
I've played around with a similar idea with a less attractive UI, using Vim or Emacs.
With sufficient adjustments, you can reduce the GUI versions of Vim or Emacs to a single line of text. That way you can just write, but can't see what you've written one it's left that line, until you expand the window to see the full document.
It gives a good sense of flow, although I find that if I'm just forcing myself to write and push forward, it's easy to get into a situation where I'm just pushing text, and not really enforcing any kind of structure on my thoughts.
It's useful to get me into a mode where I'm thinking about new stuff, but I have to be ok with producing a lot of noise that I have to sift back though. Eventually that sifting starts to wear me out.
If 90% percent of everything I write is crap, sorting back through to find the 10% that's good and useful, is more effort than I can make myself keep doing on a regular basis.
One thing I like about Vi vs other editors even for non full fledged development experiences like editing config files, is that Vi allows very surgical edits to change only what you want and nothing else.
You can easily control exactly what portion of the line or file you are making the edit to, and Vi will not allow you to change beyond that area without a further intentional command.
Honestly I don't usually have anything super impressive. It's just that they are so seamless to define and use.
Lately I've used them a lot to deal with buffer to repl interactions where there wasn't a working mode to load the buffer into the repl.
It's trivial to run a repl in a shell buffer and then create a macro and keybindings that will save the file, switch to the repl buffer, and then insert the command to reload the file (and/or restart the repl if necessary).
Probably now that Vim and NeoVim have useful integrated terminals I imagine they can probably be automated similarly, but I mostly use vim as my failsafe editor and try to keep my interactions with it pretty stock, so I don't really explore automating it heavily.
I've used Emacs keyboard macros frequently to automate org mode to make certain kinds of entries immediate (almost like using a snippet solution).
Keyboard macros are not the be all and end all. But they are really useful for chinking around the cracks between other tools. They are a quick tool for prototyping and scripting automation.
Sometime last year I was experimenting with my own plain text note system outside of org mode (I wanted something that was a little more robust for dealing with arbitrary copy and pasted text without it potentially triggering semantic interpretation of the buffer). Using keyboard macros allowed me to quickly work up commands to deal with the various parts of the file in an interactive development style - it made it very easy to experiment with what was effectively a new file format without any real parsing or coding. I would guess it wouldn't be robust for release, but for figuring out what made sense or what I wanted, it was super helpful to have that ability to define new text interactions quickly.
At the risk of gushing a bit about Emacs, I'm going to share just a few things that I have gotten out of Emacs that I don't believe I have gotten out of Vim or VS Code.
A minor thing, that perhaps betrays my lack of commitment to really devoting myself to Vim, but I find the keyboard macros in Emacs clicked for me, far more than the equivalent functionality in Vim. I've read arguments that the Vim functionality can actually be superior because it can be applied after the fact, but Emacs keyboard macros are what clicked for me.
And given easy keyboard macros, that can cross buffers (and therefore even embedded shell invocations) you can construct your own text based workflows that are more flexible and streamlined than anything you are going to find in another editor or IDE environment. And that is without even having to deal with Emacs Lisp.
I find the Emacs keyboard macros also get supercharged when you combine them with Evil (Vim emulation) mode. That ability to record and play back complicated multi-state evil commands is awesome.
I also credit Emacs for exposing my son to his first experience with hacking / looking at source code. I showed him the Adventure game (yes, Emacs ships with an embedded text adventure game). And then I showed him how to find the data structure that describes the maze in the game, and he used that graph to figure out how to navigate through the maze.
I could go on, but that's probably enough random thoughts for now.
I've spent a lot of time with Vim and Emacs (with both the default Emacs keybindings and using Evil).
I haven't made it through all of vim adventures, but based on what I have done, I think that a significant portion of what you would get out of vim adventures would transfer to Emacs using Evil mode (or derivatives like spacemacs or doom Emacs).
I'm happily messing around with Racket, trying to do LeetCode and Project Euler problems in it and trying to figure out how to translate the programs from The Big Book of Small Python Projects into it. I'm trying to get comfortable enough with it that I can use it as a viable replacement for what I would do in Python - with the end goal that I can write my website and a hopefully useful web app in it.
This book Artificial Intelligence through Prolog [0] was really interesting to me several years ago and I remember the author [1] had a number of papers on search engine / information retrieval on his research page.
Probably not super popular, but last I checked (a couple months ago), Oracle Cloud will give you up to 2 free Oracle Autonomous (managed) SQL databases and I think if you work the free storage / virtual CPUs right, up to 4 virtual servers that you can put other unmanaged dbs on with their free tier.
I found the following quote from the article really interesting when it comes to thinking about managing open source projects.
---
Torvalds still considers that one of the building blocks of the Linux community; “just for fun,” he said, is part of what he still strives for.
It comes up when people talk about the possibility of writing some Linux kernel modules using Rust. “From a technical angle, does that make sense?” Torvalds asked. “Who knows. That’s not the point. The point is for a project to stay interesting — and to stay fun — you have to play with it.”'
Emacs includes a book, or maybe it's in the list of installable packages called An Introduction to Programming in Emacs Lisp (I think the package is called 'eintr') that does a pretty good job as an introductory lisp programing text and then gets deeper into the internal functions of Emacs.
By the later part of it I felt like I had a decent handle on Emacs Lisp and could read the code for packages I was interested in reasonably well.
GDScript is pretty similar in feel to Python, and you can also use C# if you want to. It has some level of GUI controls in the framework (not sure how many yet, but all of the GUI controls used to build the editor are available for use).
I want to believe the 3d capabilities might be useful for some kind of UI stuff, but I don't really have a real idea how to make that work - just a "wouldn't it be neat if..." question about it right now.