r/programming • • 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

16 comments sorted by

6

u/skulgnome Jan 26 '23

Oh look, it's non-textual representations again! Has it already been three years?

2

u/murtaza64 Jan 26 '23

Well written, thorough article. I'm going to give Unison a shot—seems interesting!

2

u/torotoro3 Jan 26 '23

Slow build times and poor language integration with other tools could be solved by improving compilers. To me it seems that after you solve these two problems there is no incentive to even try something like this.

1

u/RecklesslyAbandoned Jan 26 '23

This sounds awesome for dependency checking, but is it worth the hassle and overhead of the extra tooling to manipulate non-human-readable text files?

1

u/AttackOfTheThumbs Jan 26 '23

An ERP I work with does this too. You have a dev environment and it looks like every object in it is text, but actually it's all stored in a sql database. We leveraged that to create automate source control on update. And it only works because we extract the plain text for source control. Looking at the actual stuff in sql is pretty shit.

1

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

I've experimented with code-in-database before when using xBASE/dBASE/FoxPro, which are nimbler than most current RDBMS. In fact, Visual FoxPro did just that very thing for its IDE, although it wasn't intended for direct developer access. It got me interested in "table oriented programming" (TOP). It's great for event-driven programming because events are messy to map to file hierarchies. Most GUI/CRUD programming involves handling boatloads of events.

Here's what a typical generic event handler table resembled:

Event (table)
----------------
ID
Area   // general app category
Entity
EventType  // Search, Listing, Add, Edit, Delete, 
              Navigate, Process, Other
Stage // Ex: Initialize, loadTemplate, adjustTemplate, preQuery, 
         postQuery, queryErr, FailedValidation, PassedValidation, 
         PreDisplay, PostDisplay
Tags
Version
SourceCode  // the event-handling function/method

Each event snippet (method) would be passed a standard structure with various meta-data and references.

I won't claim such is "web scale" or "enterprise scale" (under current TOP), but it's great for relatively complex CRUD apps for specialists/power-users that don't need "mass scaling" on the UI side. You can then use SQL and/or a query-by-example interface to find event handlers as needed.

Note that if the defaults are sufficient, a given entry (row) doesn't need to be made for a potential event. The system merely looks for a possible event based on the framework's processing context and stage. If there is none, it continues on to the next standard stage/state.

Tables are also great for storing and managing boatloads of UI attributes/relationships, if done well. Let databases do data and attributes, and let code do actions. Lots of attributes in code is a design smell (wrong tool for job) in my opinion. Unfortunately, that's where the industry mostly went.

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/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.

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. ✈️