On storage discipline- UNIX derived systems deliberately don't enforce file formats. In the UNIX philosophy Everything is a file. Inter program portability can be achieved in a multitude of ways. Pure ascii format with either defined field widths or the more common "special character" delimited fields. Ie pipe delimited or comma or : delimited. xml formatted. There are several conversion programs available as well as write your own. On Sun, Apr 4, 2021, 9:36 PM Bakul Shah wrote: > On Apr 4, 2021, at 4:33 PM, Clem Cole wrote: > > > > On Sun, Apr 4, 2021 at 7:01 PM Bakul Shah wrote: > >> >> >> On Apr 4, 2021, at 3:25 PM, David Arnold wrote: >> >> For us UNIX historians, we need to be careful and learn from our own >> history here -- the Cell Phone/Mobile target is the engine for the next >> Christenian style disruption. It is by far the #1 target for people >> writing new programs (which I find a little sad personally - but I >> understand and accept -- time has marched on). In the end, a small mobile >> target will be the tech on top, and available will be driven by market >> behavior and those suppliers will be "who has the gold.” >> >> >> I feel I should point out that both the dominant mobile operating systems >> are Unix-hased. The UI is necessarily new, but astonishingly the 50 year >> old basic abstractions are the same. >> >> >> Except Unix is kind of hard to see. It wasn't just the hierarchical file >> system but the idea of composability. Even now we whip up a shell >> "one-liners" to perform some task we just thought of. All that is lost. And >> not just on mobile devices. For example search through email messages for >> something in an email "app". And no UI composability. We have to use >> extremely heavyweight IDEs such as X-Code weighing at 15GB (even "du -s >> /Application/X-code" takes tens of seconds!) to painstakingly construct a >> UI. We can't just whip up a dashboard to measure & display some realtime >> changing process/entity. There may be equally heavyweight third party tools >> but there has been no Bell Labs like research crew to distill it down to >> the essence of composable UI and ship it with every copy. The idea that >> users too can learn to "program" if given the right tools. >> > > Exactly my point. The only difference I suspect is I just don't bother > with the IDE (Xcode or VS). Frankly, vi/emacs, or as we discussed a few > days ago, ed is still way more preferable when I'm programming. > > > Many things are easier to convey visually. It would be neat if unix > paradigms can be extended to visual design as well. And you certainly can't > do visual design easily in vi/emacs. Just like in Autocad you need both > interactivity and programmability for creating visual elements. > > I mentioned in another email Intel's new development suite - OneAPI. > Absolutely speaking for myself here, I am a bit at odds with management WRT > to much of it, as I feel the direction is a bit miss guided. But I do > understand why Intel is doing it/trying. Everyone in the industry seems > to be saying "use my Framework, my language, my solution and I will solve > your problem." "You will sell more copies of the program if you use my > portal, *etc*." Intel to compete, needs to do the same things. To > me, it seems a bit like fairy dust - a promise that will work for a set of > people, and of course, some firms like my own employer will keep making > money (or in the words of the Dr. Sueuss Lorax character: "Biggering and > Biggering." As I said in the previous message, it is driven by the other > golden rule. > > > IMHO a bigger need is some discipline on storage. As things stand, it is > hard to extract data from applications for legitimate uses but not so hard > to extract for illegitimate uses. If app A for some specific domain dies, > there is no guarantee that app B for the same domain can use A's data. > > What I always felt made UNIX powerful was that it did not seem like the > BTL folks were trying to sell anything. They were trying to solve real > problems they and the folks at AT&T had when it came to realistically > building and deploying systems. Yes, there were hidden from the profit > motive at the time because of the unique rules of the 1956 consent degree > and we all were winners because of it because they say -- sure here you can > use it too. > > > Similar conditions existed and exist to a certain extent in research orgs > of some companies but I think that is a necessary condition, not > sufficient. The right research crew can bring in another kind of > interactivity -- in creativity, in trying out and critiquing each others' > ideas and building on them. And you still need the right key people. > > Now that we are back to a winner take all market, (OSVM/360 *vs.* VMS > *vs.* winders ...) I think we have traded away designing for the sake of > getting the job done properly, for designing to sell as many as possible ( > *i.e.* be sexy and capture a market, not be simple and do the job well). > > >