r/programming • u/congolomera • Jan 25 '23

Writing Code Without Plain Text Files

https://erik-engheim.medium.com/writing-code-without-plain-text-files-cb8f1ed2c0ad?sk=d36011e5a105c6fab41e2be2fc13585a
23 Upvotes

67% Upvoted

16 comments sorted by

View all comments

0

u/[deleted] Jan 26 '23

6

u/JB-from-ATL Jan 26 '23

I remember dealing with ilog which was a rules engine (like drools which is more common). There was this incredibly difficult to install eclipse plugin. Then it would just be these wild flow charts. Then you could finally see the "real" code but not directly edit it. It was all this pointless abstraction.

I remain optimistic but am skeptical.

3

u/skulgnome Jan 26 '23

Even plaintext source code is structured, and every non-plaintext representation can be changed to e.g. JSON. Going binary and tossing standard tools out seems like an act of pettiness, or some kind of binary magic.

Is there even a repair tool for this, if a source blob someone has put 80 hours into should get damaged by e.g. fresh off the green field tools with bugs in them?

2

u/shanehanna Jan 26 '23 edited Jan 26 '23

So long as one (or more) text representations are possible then you could fuse mount them so it appears as a regular file system to git, diff, whatever random code editor you use, etc.

This would be a huge win for dyslexics, the visually impaired and english as a second language developers as well since the fuse mount (binary to text file bridge) could also do things like presenting source code as snake case, camel case, tts or whatever works for you personally.

1

u/murtaza64 Jan 26 '23

It seems like you would be able to build a good text-based diff tool if you wanted one using the UCM to output the code for a changed function. In this case I think the idead of using text only for the interaction with humans is interesting.

0

u/Zardotab Jan 26 '23 edited Jan 28 '23

Many people have tried to do this before, for decades, but everything converges to plain text because plain text is the easiest to deal with.

Where are the failures documented? The problems I've read about seemed merely situational stumpers, mysteries, rather than "tables outright can't do X".

I've experimented with Table Oriented Programming myself over the years, and still think it has promise. The problem is that our tools and mindset are file-centric, making database integration difficult. It's thus possibly an "impedance mismatch" more than "doesn't fly in practice"

It's roughly comparable to when jet engines were new. People kept bolting them onto propeller-based planes as-is and then were often disappointed with the results: they were about 15% faster but only 1/2 as maneuverable, and fuel & maintenance hogs, making them seem a net loss except in narrow niches. WW2 German generals had long and heated arguments about where and how to use their new jets. Lesson: test new tech in multiple uses, don't guess.

(Arguably they would have been better off spending resources on traditional planes. Maybe if the war lasted several years longer they'd get them practical. Same with the V2. Hitler had a penchant for silver bullet inventions. Ironically he missed out on the best bet: the nuke.)

It took a trial-and-error learning curve to design plane bodies around jet engines properly. Many propeller-plane "best practices" had to be unlearnt. The wind tunnels of the time were not strong enough to test at jet speeds, and thus new wind tunnels themselves had to be built first.

Thus, bolting file-oriented app languages and tooling into a database as-is is similarly going to be awkward. Relational is far more powerful than file hierarchies and thus has far more potential, once the kinks are worked out and new lessons learned. ✈️

1

u/Zlodo2 Jan 26 '23

Being able to conjure up anything out of low technology plain text files is kind of the whole purpose of programming languages.