encloser
The problem corporate IT/Dev folks face isn't that an idea started as a low-code tool, but rather that the low-code solution is often dumped on them with no budget or desire to improve it to be more reliable and maintainable.
At least until something fails... and usually in dramatic fashion that then wakes leadership up to the idea that maybe we should invest more into this critical business process. If the company didn't go under in the meantime.
This is how I remember it also. Doing CGI "well" was significantly harder. And new ways of making dynamic web content was rapidly coming out.
There were no HTTP server libraries in any languages. All web servers were large codebases. Most of the web sites ran on Apache in multiuser environments. Configuring (and compiling) Apache correctly and securely took a bit of voodoo in those environments.
The security issues with CGI wasn't just injection attacks. How should admins setup safeguards when every user could write a binary/script that remote people could execute? By the time best practices evolved PHP was taking off. And PHP offered a little bit more of a sandbox.
And then... ColdFusion. Java Servlets. JSP. ASP. And many more ways of creating dynamic websites that were often easier, had better libraries tailored to webdev, and included better sandboxing.
Web servers started to become proxies to long running processes and stateful web apps became a thing. For better or worse. (for worse IMHO. :D)
CGI with Go or Rust could be pretty interesting and significantly easier than my first C-based CGI binaries. Mostly because of their extensive web-dev library options and dependency management tools.
Which, to me, sounds very different from voicing concerns or identifying problems.
TL;DL: Feeding pets the animal byproducts of our own food production is not only a good symbiotic relationship, but also contains more of the nutrients the pets need (as opposed to grain-free or other specialty diets). But, the specifics for your pet will vary based on their own needs and allergies.
I'd add that mid-sized and up companies are usually not homogeneous. There are usually good and bad leaders, managers, and developers to be found within them. You can have a great experience in one part of a company and a horrible one in another part.
Another thing that I've found is that there is no "one true way" for a team to operate. I have found that what works best is to lean into a methodology that meets your business partners wants/needs and hire people that work well in that environment in that mode. Be it highly formalized and layer ITIL, super agile kanban+devops, or somewhere in between.
There are a few factors that make bridges very reliable (but not perfect) in the US. A real engineer can probably describe this far better than I can.
1) Physics and material science are pretty well known quantities. There is innovation and new materials come to market, but by the time they are approved to be used in real bridges their qualities are fairly well known and tested. They have solid evidence of the capabilities of a material or part. (Tensile strength of an item under various environmental conditions, for example).
2) Standards & Very Firm Requirements (Where waterfall works!) They have a set of strict approved industry standards to rely upon. Not the "industry standard by convention" kind that you see around IT a lot, but the "tested, reviewed, approved, published by a standards body" kind. When a civil engineer is assigned to build a specific bridge they reference these standards that tell them "given this type of ground do this", "given this length of span do that". They know the lengths and widths, they check the traffic patterns, they know the desired weight limits. Challenges do come up, yet they have fewer unknown unknowns. Something changed from their expectations, maybe the ground is different than expected, but they still have standards that guide them in what to do in those cases.
3) Reviews, reviews, reviews. Other Professional Engineers have to sign off on the work of the initial designer(s). Deep reviews. Not what typically passes for software architecture and code reviews I've seen.
4) Legal responsibility. Professional Engineers have an amount of personal accountability at stake because real lives are at stake if something fails.
5) "User" common sense and intuition Nobody builds a 100,000 ton vehicle and then tries to drive it over a bridge. Most any human that thought about doing this can probably reason that doing so would break the bridge. In my experience software users have no idea that trying to push a 1TB file into a system that was designed to only handle 1MB files will cause it to fail. They often have no idea when their data volume increases. "I'm doing the same thing I did last month!"
All that and more, yet bridges still go over budget and over time and fail and people die.
From a teaching perspective it is probably best to start with the long-form.
The same with the parent commenter's thoughts, "Sure, developers can screw up [business transformation projects], but they cannot make them succeed."
Many people use the JPA libraries like Hibernate and EclipseLink. Another popular ORM is (my|i)batis. JDBI also seems to have a decent following.
After years of using ORMs, I vastly prefer interfaces like HugSQL unless I'm building a dead simple CRUD app. (I'm never building simple CRUD apps.)
I primarily am using Pandora and it really depends how much time I spend thumbing music up or down. Once I zero in a station it doesn't seem like I hear new artists or songs very often.
I'll also add that in my personal case, pandora led me to finding and buying more music. Spotify and smartphones over iPods (and buying a house) are why I don't by albums very often anymore.
With persistent data structures you don't have a whole copy of the entire system. The two views of your system share memory where information didn't change. Sort of like how Git works.
There are a whole lot of people in the world who's jobs are not "9-5" office jobs. Also on any given day there are a bunch of people who took the day off. And then there are the elderly, medical leave, etc.
I still think solutions like this are putting your build process at great risk. You will have build issues that are no fault of your own and completely out of your control. Unless you clone the github repository and then use that as your source. And cloning will have issues and risks of its own.
EDIT: See pron's reply for describing the risks: https://news.ycombinator.com/item?id=9029870
Go ask the Erlang community about the issues they have with using GitHub repos as "packages". Here is a discussion about packaging: http://mostlyerlang.com/2015/01/27/054-packages/
When you get into examples using tables it would be nice if you provided the table definitions and some sample data.
PS: psoug's connect by page (http://psoug.org/reference/connectby.html) is my favorite reference.
Is some form of hypermedia supported or built in? If not, is it planned?
These may be answered in the presentation. I hope to watch it soon.