On 11/5/2013 7:15 AM, Miles Fidelman wrote:
Casey Ransberger casey.obrien.r at gmail.comwrites
mailto:fonc%40vpri.org?Subject=Re%3A%20%5Bfonc%5D%20Task%20management%20in%20a%20world%20without%20apps.In-Reply-To=%3CDD90A941-C94A-4F01-A013-6D838B0B2524%40gmail.com%3E
A fun, but maybe idealistic idea: an application of a computer
should just be what one decides to do with it at the time.
I've been wondering how I might best switch between tasks (or
really things that aren't tasks too, like toys and documentaries and
symphonies) in a world that does away with most of the application
level modality that we got with the first Mac.
The dominant way of doing this with apps usually looks like either
the OS X dock or the Windows 95 taskbar. But if I wanted less shrink
wrap and more interoperability between the virtual things I'm
interacting with on a computer, without forcing me to multitask
(read: do more than one thing at once very badly,) what's my best
possible interaction language look like?
I would love to know if these tools came from some interesting
research once upon a time. I'd be grateful for any references that
can be shared. I'm also interested in hearing any wild ideas that
folks might have, or great ideas that fell by the wayside way back when.
For a short time, there was OpenDoc - which really would have turned
the application paradigm on its head. Everything you interacted with
was an object; with methods incorporated into it's container. E.g.,
if you were working on a document, there was no notion of a word
processor, just the document with embedded methods for interacting
with it.
a while ago, I had started, but didn't finish writing (or at least to a
level I would want to send it) about the relationship between
object-based and dataflow-based approaches to modular systems (where in
both cases, the application could be largely dissolved in favor of
interacting components and generic UIs).
but, the line gets kind of fuzzy, as what people often call OOP
actually covers several distinct sets of methodologies, and people so
much often focus on lower-level aspects (class vs not-a-class,
inheritance trees, ...), that there is a tendency to overlook
higher-level aspects, like whether the system is composed of objects
interacting via passing messages using certain interfaces, or whether it
is working with a data-stream where the objects don't really interact at
all and rather produce and consume data in a set of shared representations.
then, there is the bigger issue from an architectural POV, namely, can
App A access anything from within App B? short of both developers each
having access to and the ability to hack on each-others' source code
(or, often, get the thing rebuilt from source sometimes).
so, we have some problems:
lack of shared functionality (often short of what has explicitly been
made into shared libraries or similar);
frequent inability to add new functionality to existing apps (or UIs),
short of having access to and ability to modify their source-code to
ones uses;
lots of software that is a PITA to get to rebuild from source (*1);
...
*1: especially in GNU land, where they pride themselves of freely
available source, but the ever present GNU Autoconf system has a problem:
it very often has a tendency not to work;
it is often annoyingly painful to get it to work when it has decided it
doesn't want to;
very often developers set some rather arbitrary restrictions on projects
build-probing, like must have exactly this version of this library to
build, even when it will often still build and work with later (and
earlier) versions of the library;
...
it is sad, in premise, that hard-coded Visual Studio projects, and raw
Makefiles, are often easier to get to work when things don't go just
right. well, that and one time recently managing to apparently get on
the bad side of some developers for a FOSS GPL project, by going and
building part of it using MSVC (for plugging some functionality into the
app), but in this case, it was the path of least effort (the other code
I was using with it was already being built with MSVC, and I couldn't
get the main project to rebuild from source via the approved routes
anyways, ...).
weirder yet, some of the better development experiences I have had have
been in developing extensions for closed-source commercial projects
(without any ability to see their source-code, or for that matter, even
worthwhile API documentation), which should not be.
not that I don't think these problems are solvable, but maybe the
spaghetti string mess that is GNU-land at present isn't really an
ideal solution. like, there might be a need to address general
architectural issues (provide solid core APIs, ...), rather than just
daisy-chaining everything in a somewhat ad-hoc manner.
but, as an assertion:
with increasing modularity and ability to share functionality between
apps, and to extend
