4 ms·
Amen. I have been thinking about this a lot as well. In fact I was thinking of writing a blog post about it along the lines of "The plain-text tragedy". A pro
by borplk 9y ago
Amen. I have been thinking about this a lot as well.
In fact I was thinking of writing a blog post about it along the lines of "The plain-text tragedy".
A program is so much more than a flat collection of lines of text stored on a filesystem.
Our tools force us to "reduce" a program and dumb it down to a bunch of flat files.
This in turn increases the cost of representing information (syntax clutter).
It also adds cognitive overhead for naming things and so on.
As a result we get ourselves into a fight with the compiler. On one hand we want to give it as much information as possible so it can help us solve the problem.
On the other hand we don't want to overwhelm ourselves so we awkwardly compromise somewhere in between (terse syntax, short weird variable names, "def" for define "fn" for function, symbols and so on).
As a result, and believe me I could write a book of rants about this, what we call "IDE" is anything but integrated.
Imagine an editor that allowed you to easily view and modify "objects" in your programs.
Instead of the project tree representing the files on a filesystem it would be representing components of your project.
You could view a function, select it in the editor and right click on its name and click "Write documentation", or "View entities calling this function", "View tests involving this function", "View authors".
In a way similar to, for example, how stored procedures are stored as objects in a database that you can fiddle around with.
And you could have custom attributes attached to these objects. You could tag them with domain-specific stuff.
Imagine the possibilities for version control. If the units of our programs where tracked and edited as first-class-citizen objects in a smart database you would automatically get "git on steroids".
We already "have" some of this stuff but they are not integrated. We first throw away information then come up with parsers that try to make sense of it again like fancy auto-complete intellisense stuff. As a result they become expensive to write and maintain and they become fragile and unreliable. You can't trust them blindly because their accuracy varies wildly. Good luck getting intelligent intellisense in a large project with dynamic languages and transpilers and so on.
We need a development environment that is not hostile towards the humans. It should actively encourage the programmer to provide and specify things about the domain.
We need programming languages that allow and encourage the programmer to provide information. The flat-file ASCII syntax that we are so used to punishes that.
In the "real world" there's so much meta-data associated to each object/entity/unit of the program.
Consider a simple function that adds two numbers together.
While from a mathematical standpoint it's nice to be able to write "function add(a, b) { return a + b; }". From a industrial real-world team-effort software engineering point of view that is incomplete.
Ideally we would want documentation (purpose, arguments, return value, etc), tests, history/version-control and some more context-specific things such as logging that can be turned on-off depending on the context.
We need languages that recognise these concepts and editors that allow us to keep these things in a way that doesn't get reduced down to meaningless text (like documentation crammed in comments that later needs to be pulled out and parsed awkwardly).
If we don't "throw away" the information suddenly so much of the stuff that we work so hard to do today becomes available for free (such as much more accurate documentation that stays up to date with the project, version control that operates at the program level not lines of text).
You could "tag" the components of your program with various attributes.
Then your IDE could auto-generate a report that says "Hey 57.2% of your functions related to authentication currently do not have a test case associated with them. Would you like to create a test case for checkUserLogin function now? click here".
As I said right now we have a lot of this stuff but they are not integrated and fall apart easily, they rely on fragile mechanisms to keep them accurate so you can never let your guard down and trust what you see on the screen you have to actively fight to keep things in sync with each other and so on.
- contras1970 9y ago> A program is so much more than a flat collection of lines of text stored on a filesystem. > Our tools force us to "reduce" a program and dumb it down to a bunch of flat files. Agreed with a reservation: text sucks, but we have nothing better, and your post does not suggest an improvement. If you have something more concrete on your mind, I have some specific questions here I think we'll need good answers before we jump the text-based ship. > It also adds cognitive overhead for naming things and so on. I take this you advocate going without textual names. Presumably, if we didn't name things in our programs, programming (both "writing" and "reading" them) would be easier. If this is actually your point: * How are our tools going to present "source code" to us? * How are we going to refer to pieces of our programs, in spoken and written communication? These things have great impact, right now I can get into a discussion of execle(), execl(), execlp(), execve(), execv() and execvp() (these are pretty average regarding mutilation in the interest of brevity, at least they're pronouncable[1]). > Imagine an editor that allowed you to [...] view a function, select it in > the editor and right click on its name and click "Write documentation", or > "View entities calling this function", "View tests involving this function", > "View authors". * What would "view a function" mean in a nontextual programming language mean? * "Write documentation" implies more text. Doesn't the argument against text in programming languages apply to documentation as well, just more forcefully? What is your proposed solution to keep documentation in sync with the code? * What does "View entities calling this function" mean in a universe without names? [1] cf. wcsnrtombs(), wcspbrk(), wcsrchr(), wcsrtombs().
- borplk 9y agoA better alternative is theoretically possible we just haven't devoted significant time and resources to it. It is possible to create an "editor" that edits the objects of the application but not as text. It can look almost identical to a text editor but under the hood it knows more about each "node" that you are interacting with. One challenge is that sometimes these applications are not flexible enough to deal with "temporarily invalid" programs. So they become rigid and feel less flexible than a normal text editor. But those challenges can be overcome. This suddenly opens the door to so many wonderful possibilities. I know because I have worked on an experimental prototype for such a thing. For example text-based version control will be automatically obsolete. Your IDE will have the history of every single piece of your program (program is stored as a rich object in the database). Your IDE can suddenly present different "layers" of information to you in a clean way. For example you can "hide" an entire block of code and just label it with "Check if user has sufficient privileges". Then the IDE can allow you to expand and explore that section of the program if you wish. But otherwise you can collapse it and just scan over it with your eyes. The one-dimensional flat nature of a text-based system discourages us from attaching additional information to the pieces of the program. We need a way to be able to "navigate" through multiple dimensions of information in relation to the obejcts in the program. For keeping documentation in sync, the IDE allows you to view/create/modify the documentation for a given object of the program therefore it can guarantee certain things. Your environment is fully aware of the relationship between an object and its corresponding documentation. It's not just a piece of string that gets ignored. So when you change the body of a function it can pop up a warning and say "Hey you have modified this function since revision #48452 but the documentation has not been changed. Click here to update the documentation.". Your environment will be aware of, for example, the relationship between tests and obejcts (such as functions). So it can tell you in a 100% reliable way, not based on file name conventions and error-prone parsing, that hey across your project the following functions have no tests associated with them. There's enormous inertia against an initiative like this because of our dependence on existing technologies. But we cannot advance software engineering to the next stage unless we move beyond the "a program is a bunch of files that we view and edit like a book" mentality. We need environments that are much more aware and in-sync with the broader context of a program/project as a whole and in a reliably-structured manner. Check this out as a basic example: https://isomorf.io/#!/demos https://isomorf.io/#!/demos (I'm not affiliated with them)