A highly ambitious, yet grounded and pragmatic proposed initiative aiming to reshape the very nature of software and software development.
It started with a simple request to my favorite brainless assistant:
Consider how single individuals tend to go through large swathes of different works and then create their own derivatives which unify them in a simpler and more powerful framework, as Euclid did with Euclid's Elements. Now, if one were to do likewise with programming languages (and certainly many have) what would be the most optimal best-of-all-worlds solution according to them? What features would it have, what syntax would it use, what methods of resource management would be in place, etc? Of course nothing of this sort has been implemented, but that's not to say it can't have been suggested, and for that reason seek out suggestions of that nature, from such people, and leverage your own reasoning abilities as well alongside this to arrive upon a definitive answer.
The conversation that followed ignited in me a passion that drove me to further develop this idea with the companionship of our brainless bot bro, which caused me to stumble upon various entirely new concepts and to tread onwards in what is almost certainly the longest ChatGPT discussion I have had to date: https://chatgpt.com/share/68119570-0f2c-8001-a984-bb8327a09e03
Click to unveil
Software development begins in the imagination. We should have custom modular ui interfaces for each command, designed to properly contain, represent, and clarify the functionality of code, so we can feel the concepts taking shape at our fingertips. So we naturally use the code as intended, intuitively following and, where possible, even going beyond best practices in quality. Modular graphical inputs would fundamentally change the very nature of software development, and if developed as an open source project could be continually improving and adapting to how humans think, until it follows the grain of the psyche with perfect precision, creating a frictionless experience where the complexity is reshaped into power, and everything that was once frustration dissolves into flow.
The closest existing concept I could compare to this is Google Blockly, and while, due to my introduction to it via code.org in middle school, it likely subconsciously served as vital inspiration for this concept, it is nowhere close to the level of sophistication and integration I have in mind here. Each module in blockly is a simple block with little difference between command types aside from color, label text, and maybe there's one or two extra inputs in some of them, amounting to something which is chunky, clunky, and cheesy compared to my vision of having individually engineered, custom-curated gui modular interfaces form-fitted to visually manifest the flow and dynamic of the code that lies below the elegant interface.
The most obvious issue that's evident upon reaching this point is the limits in speed - GUIs tend to be geared towards mouse movements and operations, which in many cases will be slower than typing. However, I considered that too, and this weakness can actually be turned directly into a strength in the exact same domains - speed and keyboard-compatibility - and effectively reverse the effect entirely, all via keyboard shortcuts, toggling, navigating, selection, modal editing (or alternative command palate style - custom-configurable), and more, with the option of custom-bound key combinations and sequences, streamlining everything from drop-downs and dials to dashboards and dialogues, with intellisense that can summon whole module interfaces with no more than a few keystrokes, booleans that are a one-tap flip-flop away from flawless, and full theme customization both deep and broad enough to reel in power users from every edge of the pond, hook spline and tinker - with a deeply customizable interface enabling deep editing capabilities, as well as plugin options that mount compatibility layers for various common theme standards, including both textured theme mounts designed to integrate - and look good with - text editor themes, the likes of vscode, base16, sublime text, and other styles, by seamlessly remapping them into the GUI color scheme (and applying them directly to text where present), as well as other classes of graphics compatibility plugins, such as ones designed to properly apply the likes of bootstrap, tailwind css, gtk, and raw css, plugin options that interface with it and provide support for nearly all existing widespread themes.
I will hasten to point out one thing, though - it's not block-based, like blockly, or like structured code editors. The structure, in concept, would carry a highly amorphous design, where even the default structure of each module input could be reshaped for individual preference. This concept differs dramatically from any existing concept available, though in places surface-level similarities can be found.
Why?
First off, it does not make the common assumption that GUI interfaces are limited to single, specialized applications. It doesn't try to fit into a single specialized use case - it takes on them all at the same time, and shows that - in principle - GUI interfaces could far surpass direct text interfaces - that we have been overlooking a mountain of potential because we simply haven't been fully aware of it, or of how to make use of it, until now, and because of this it is not limited by the blinders of habit and complacency that obscure the possibility of efficient, powerful, and entirely feature complete gui programming.
There's a problem with relying solely on text: you have to read it to grasp the structure and flow. This takes time and increases cognitive load. With a GUI, you can have the flow conveyed visually, and as neatly as you wish, not limited to the rudimentary structuring of text to try and keep things orderly, when, let's face it: Lines and lines of alphanumeric symbols, no matter how structured they are, will ever be able to compare to a sleek, modular, minimalist interface, which can be shaped to reflect with a powerful visual emphasis, and guide the gaze of the viewer along, the flow of logic taking place beneath the surface.
The concept was partially inspired by gadgets on my desktop. I had GadgetPack with plenty of Win7 gadgets, multiple packs of Rainmeter gadgets, and Xwidget, which comes with an extensive online widget library. I was using these at the same time to compare performance and quality. In a moment of clarity, I was inspired by their simple, straightforward, and aesthetically pleasing interfaces, with direct inputs and sleek panels. One thought led to another, and I realized that my imagination led me directly to the solution for a long list of software's stifling semantic and syntactical struggles and shortcomings. In honor of this, I will name this programming paradigm GadgetScript. Catchy and direct - it's scripting with gadgets. That is not to be confused with the other paradigm we're developing here - ideally, it would be interchangeable and used both within and outside of this framework, to avoid limiting the scope and versatility of the project, while also being initially released within our elements-inspired framework.
Click to unveil
Let's talk about something. I feel like it's an unvisited area, for the most part, and I think there is potential for further exploration. I am, of course, talking about modular binaries. The files known by all as monolithic masters of efficiency, the indecipherable spaghetti flying past your eyes at top speed, like the speed of light it alone runs at the very limit to what speed can be on the underlying architecture. Yet, for all that we have done with computing, I have not once heard of a modular binary. I find no reason for this. Yes, it is not an easy task by hand, no doubt, but we're working with computers! We're not confined to fingers alone when performing tasks! We have software at levels more advanced and sophisticated than any other prior human invention has reached! Why not work with the flow of the logic, create interfaces to manipulate the stream, and change the course of computing forever, on the broader level just as much as on the software itself?
I think toolchain and programming software engineers look at the slight inefficiencies and overhead it's going to inevitably bring in and, like the engineers they are, opt for whatever is most efficient, meanwhile there's apps using modular design, and the ability to add modules, in higher-level languages at proportionally far more significant performance costs. If modules are implemented perfectly they will significantly increase performance of course, in both scenarios, but that's besides the point that I'm making here, which is that for efficiency purposes, if we want to have an extensible framework with greater performance, deeper customization, and minimal overhead, we should be extending from below.
We need our framework to enable the same flexibility as is present in higher-level languages. We would want the design of it, including of the tools created to design it, to be structured in the right way, at the right areas, and using the right methods and resources to enable this, largely without compromising on performance. I think it should reach a level of modularity that reflects the way can simply type JavaScript into a web page and it will run, but with deep, low level machine code. Where by simply using the right tool (which prevents errors and ensures you clean up after yourself) you can inject extra code into a binary program with no performance issues, attach extra binaries as modules if desired regardless of the program's design or intended function, and perform many other low or no cost modular or custom operations, opening up the possibility of creating mods even for programs that provided no initial support for them and creating entire modding communities in the process of doing so.