What would take to use for example image editor like mspaint to write programs instead of text editor? We would still need to write text for interfaces with users i guess
Of course text would still be highly involved in the process. But the unit of a program will not be lines in files stored on a file-system.
The program will be a data structure and what the editor presents to you is just a editable projection of that structure.
And that doesn't mean some clunky tree editor GUI with drag and drop either. A sufficiently capable editor could present itself to you almost like a text editor but under the hood it would be operating on rich data objects that form the program not on lines of text.
This opens up a lot of opportunities, for example in project navigation. You could label an entire section of the program as something (example: "Create user") then the editor could give you nice fold/unfold features you could incrementally dig down and navigate the program that way.
You could tag objects in the program with stuff (example: tag a set of functions with the business topic that they deal with).
Because the editor accurately tracks meta-data related to program objects, for example it could be always aware of documentation related to a particular section or function in the program.
So that editor could give you a shortcut to instantly switch to a "documentation view" or "test case view".
I know some of this stuff is already sort-of possible with smart IDEs but they are still quite fragile and inaccurate and easily tricked as they rely on fragile tricks and heuristics to associate things with each other or they rely on conventions that pile up on top of each other and conflict with each other (file naming conventions to indicate something is a test case, etc...).
Treating programs as data objects gives us a strong foundation upon which we can make these fancy features with ease and high accuracy so that you can let your guards down and trust the editor to always be correct.
If you were going to take a new try at building a system like this, do you think something like Datomic's codeq[1] would be useful? It allows for navigating code semantics across multiple projects using a database query language as the interface. I've never actually used it but maybe it could help for data storage of an intentional programming system?
Thanks for the links, this was the first time I've heard of intentional programming. Neat idea!
Data storage for a demo of something like that is not really hard. Something as simple as a json object would work fine.
One hard part is to make it tolerant of incomplete/invalid objects.
If it's sufficiently tolerant you could make it look very similar to a normal text editor but it would have magical powers under the hood.
You could do all sorts of cool text-editor-like features but because you have a much richer object under the hood you could be much more magical.
The concept of "file" stops having any significance. You'd think in terms of your domain logic and program objects.
So your sidebar project tree could be organised arbitrarily (not dictated by the file system).
You could do fancy keyboard shortcuts. Imagine with key up/down you navigate around a list of objects that are highlighted (like functions). While the function is selected you'd press "d" and bam out pops the function documentation (because documentation would be an attribute of that function and tightly attached to it).
You'd type "h" and see the entire history of that function from day 1, who created it who worked on it, etc...
"r" and it asks you for a new name (name could be a phrase like "login the user into the system" because no text-parsing).
When you enter an entry is added to the history of that object (it has a unique id) "[timestamp] greenyouse renamed this function to 'login the user into the system'".
Then imagine the possibilities for CI/CD.
You could have constraint-based deployment and integration.
For example if any objects in the program tagged with 'security' have been created/modified/deleted you could require stronger code review sign-off etc...
You could "query" the diff of a software revision and do stuff based on that. For example all your "SQL query" nodes would have a pre-determined type.
So when a new revision is pushed you could tell if new SQL queries have been introduced in the system you could notify the database team "Revision #458 has introduced the following 3 SQL queries (click to view)".
Of course text would still be highly involved in the process. But the unit of a program will not be lines in files stored on a file-system.
The program will be a data structure and what the editor presents to you is just a editable projection of that structure.
And that doesn't mean some clunky tree editor GUI with drag and drop either. A sufficiently capable editor could present itself to you almost like a text editor but under the hood it would be operating on rich data objects that form the program not on lines of text.
This opens up a lot of opportunities, for example in project navigation. You could label an entire section of the program as something (example: "Create user") then the editor could give you nice fold/unfold features you could incrementally dig down and navigate the program that way.
You could tag objects in the program with stuff (example: tag a set of functions with the business topic that they deal with).
Because the editor accurately tracks meta-data related to program objects, for example it could be always aware of documentation related to a particular section or function in the program.
So that editor could give you a shortcut to instantly switch to a "documentation view" or "test case view".
I know some of this stuff is already sort-of possible with smart IDEs but they are still quite fragile and inaccurate and easily tricked as they rely on fragile tricks and heuristics to associate things with each other or they rely on conventions that pile up on top of each other and conflict with each other (file naming conventions to indicate something is a test case, etc...).
Treating programs as data objects gives us a strong foundation upon which we can make these fancy features with ease and high accuracy so that you can let your guards down and trust the editor to always be correct.