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 <bakul(a)iitbombay.org> wrote:
On Apr 4, 2021, at 4:33 PM, Clem Cole
<clemc(a)ccc.com> wrote:
On Sun, Apr 4, 2021 at 7:01 PM Bakul Shah <bakul(a)iitbombay.org> wrote:
On Apr 4, 2021, at 3:25 PM, David Arnold <davida(a)pobox.com> 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).