Posted by MaxLeiter 6 days ago
But I'll also mention that this pretty much already exists. You can have whitespace options for git. I also imagine there's some setup using hooks that uses one formatter locally, and another for remote.
Also, the common IR already exists - it's just the AST. It was "solved" back in the day when people were throwing whatever they could to the wall to see what sticks since it was all so new. With the benfit of hindsight, I think we can say that it's not that good of an idea.
There are most likely good reasons why Ada and DIANA are not in widespread use.
https://git-scm.com/book/pt-br/v2/Customizing-Git-Git-Attrib...
You have to get everyone set up to use it, whereas everyone is already, of necessity, set up to use plain text.
And we aren't all using the same programming language and the same hardware setup.
Thus, specifically:
* everyone has to agree on an IR standard; if it can't accommodate every programming language, then there needs to be coverage for all the programming languages, and a way for software systems to know which one to use
* everyone has to have local software that can convert back and forth (they can't just rely on something built in to the "development system", I assume burned into a ROM)
* everyone's version control setup has to invoke that software as a commit hook
* the IR has to be designed in a way that allows for meaningful diffs, and the version-control software needs to be aware of how to diff and patch (which potentially also means a new standard for diff files)
They don't have to agree on anything.
The poster child for this is Smalltalk. An untraditional environment despite being around 60 years. The source code is stored locally in an internal file tied directly to the runtime image. You can export/import code through "traditional" avenues, but not just anything, it needs to be structured source code. You can't readily move raw text in and out.
Despite this impedance mismatch with "the rest of the world", ST folks have been developing code and collaborating for decades. They even manage to get things accomplished.
Also, consider many of the modern logging platforms that are logging to databases rather than just raw files. While some grouse about that, others manage to make do. Letting the structured log managers handle the lower level details and provide a better UX.
The game is to make sure that your UX for your system is capable of the task, not worrying about interoperating with everyone else.
Okay, and what happens when you want to use version control?
And what happens when people want to use other text editors? Or are you proposing that each language should have its own complete Smalltalk-style "environment"?
> not worrying about interoperating with everyone else.
Many programming language ecosystems (notably Python's) would be severely hobbled without all the existing structure built for inter-operation (notably with C, and to a lesser extent Fortran). You can do a lot with pure Python code, but especially for performance reasons Python could never have drawn anywhere near the audience it has without libraries like NumPy.
"This allows Git/GitHub to diff versions, and merge branches."
https://drcuis.github.io/TheCuisBook/Daily-Workflow.html
Back-in-the-day long-long-time-ago
ENVY Developer
https://www.google.com/books/edition/Mastering_ENVY_Develope...
Product Revew, ENVY Developer
https://archive.esug.org/HistoricalDocuments/TheSmalltalkRep...
What about comments? Were they part of the IR?
(I agree with others that version control, grep etc. are also very important, and kind of a deal breaker).
Raw text is amazing at smaller scales. The ability to apply a bunch of intermediate incorrect transformations to reach a valid destination is invaluable (like doing a bunch of hacky find/replace).
Projectional editors like JetBrains MPS have tons of disadvantages vs text, and the few advantages don't make up for it.
Formatting is a silly problem to have, but far beyond that why are we manipulating text files directly rather than editing a live program (ala Smalltalk). Text can just be the on-disk serialization format you never look at.
(Raw text is still how you edit individual functions and methods in Smalltalk, there just isn't any actual text file on disk)
Code is flat out complicated, with lots and lots and lots of steps, each with perhaps even more detail.
And it's hard to do that efficiently with visual editors. Imagine a display with instead of thousands of lines of code, you have thousands of symbols.
Or, the visual editors break things down in to components that are so small they do not convey the "big picture" well.
It's a personal complaint with the way Smalltalk works. Lots of methods, small (ideally) snippets of code, all viewed in isolation.
It's common (at least for me) to put related code together in the source file. It's useful to scan the whole file to get a feel for the flow of the code, and the system. Looking at isolated code, out of context, has always been a struggle for me. There's a reason my code is not sorted alphabetically by function name.
Maybe if you organized code visually, that is, perhaps the upper left is the start up code, the lower right is some core math all collected together like beads in a pot. "All red ones go here, all the 1" ones go there".
Granted I have not worked on such a tool or such a project. But the linear presentation of code as structured text has worked well for me, even when I bounce around between modules in the IDE.
Though it too breaks down, because the relations between various bits of code may be so complex that there's no good way to "linearize" them.
And you should be documenting your code, but documentation comments take up space on the screen since they are linearly arranged in the same file, so you see less functions at a time.
Imagine as an alternative that the documentation was presented on a side view of the functions, like how you can open two files side by side in VSCode. Then you'd be able to see many more functions at the same time.
If you have any unit tests then it would be great if you could see them (and run them) while editing the function. In Rust you can put tests in the same file as the function (very nice) but usually on a submodule at the bottom of the file rather than near the function itself. Again, the problem of trying to linearize everything in a single file.
The issue with visual programming tools is that they don't put any thought into this. On how they could actually help get you the information you want to see. Instead they focus on letting you make cute drawings.
It's a UX problem, we should be able to do better than text files, even if what we end up editing is still text (because of all the advantages it has).
?
The issue with Moldable Development is that it adds a substantial additional cost in development time that is then hopefully paid back with much improved debugging and analytics.
That's a tough sell. The sort of tools you see in other engineering domains have tons of custom visualizations and such already built in, for all sorts of domains, even ultra niche ones (like battery design). That's why they can charge so much. Since all that stuff is just there ready to use, the cost is 0 (in effort, they cost a lot of money).
Because GT needs to adapt to all the insane sorts of existing use cases and programming languages, it can't possibly implement all visualizations itself (nor even know what those visualizations should be like).
What I'm thinking of is one level higher, where the entire development experience for a particular domain (which could be very broad) is entirely designed from the ground up with visualization in mind. Enso Analytics is a pretty good example.
GT could be used to build something like that, but is not itself that.
https://www.wirfs-brock.com/allen/files/digitalk/VSbrochure....
func main()
{
fmt.Println("HELLOWORLD")
}
However 'if (x) == (1) {}' is totally fine with the formatter. As is an assignment of '(x) = (y)'.
It's actively annoying too because like, extra parenthesis often have important meaning.
For example, consider the following code:
if (x.isFoo() || x.isBar()) /* && x.isBaz() */ { /* code */ }
I've hit that far more times than it's uhh... I dunno, I guess removed parenthesis I didn't want? I don't write them if I don't want them.
With modern tools it it is easy to add formatting on saving or on commit. So I don't understand what's the fuss about.
At the same time, for the most important tool in software engineering, Git, it matters which lines are changes. And it is better to only see actual logic changes, not swamped in tabs vs space or other parts that are just formatting.
That said, I would love to see more of this splitting between actual internal representation and view. Don't like anything in style guide (or even syntax alike curly brackets vs indentions) - just change view, alike folding.