Re: [fonc] Task management in a world without apps.
I guess as you build more and more capable systems it will be harder and harder to burn the disk packs. You will redo your work several times over to get virtually no further. But once you get so much ahead that your new system outpace all the previous it will start a life of it's own. It seems much of Smalltalk's advances have been distributed around, so many systems are of much the same capability now. But it's hard to see another system that are pushing far into the next level. Well, that is probably mostly because I'm pretty oblivious. But because the computer science field is also much more complex and the problems to solve orders of magnitude harder to solve. That said, Smalltalk 80 have a pretty nice readability and that counts for a lot in my book :-) Best regards, Karl On Sun, Nov 3, 2013 at 1:11 PM, Alan Kay wrote: > When I mention Smalltalk I always point to the 40 year ago past because it > was then that the language and its implementation were significant. It was > quite clear by the late 70s that many of the compromises (some of them > wonderfully clever) that were made in order to run on the tiny machines of > the day were not going to scale well. > > It's worth noting that both the "radical" desire to "burn the disk packs", > *and* the "sensible" desire to use "powers that are immediately available" > make sense in their respective contexts. But we shouldn't confuse the two > desires. I.e. if we were to attempt an ultra high level general purpose > language today, we wouldn't use Squeak or any other Smalltalk as a model or > a starting place. > > Cheers, > > Alan > > > -- > *From:* karl ramberg > *To:* Alan Kay ; Fundamentals of New Computing < > [email protected]> > *Sent:* Sunday, November 3, 2013 3:18 AM > > *Subject:* Re: [fonc] Task management in a world without apps. > > One issue with the instance development in Squeak is that it is quite > fragile. It is easy to pull the building blocks apart and it all falls down > like a house of cards. > > It's currently hard to work on different parts and individually version > them independent of the rest of the system. All parts are versioned by the > whole project. > > It is also quite hard to reuse separate parts and share is with others. > Now you must share a whole project and pull out the parts you want. > > I look forward to using more rugged tools for instance programming/ > creation :-) > > Karl > > > On Thu, Oct 31, 2013 at 5:31 PM, Alan Kay wrote: > > It's worth noting that this was the scheme at PARC and was used heavily > later in Etoys. > > This is why Smalltalk has unlimited numbers of "Projects". Each one is a > persistant environment that serves both as a place to make things and as a > "page" of "desktop media". > > There are no apps, only objects and any and all objects can be brought to > any project which will preserve them over time. This avoids the stovepiping > of apps. Dan Ingalls (in Fabrik) showed one UI and scheme to integrate the > objects, and George Bosworth's PARTS system showed a similar but slightly > different way. > > Also there is no "presentation app" in Etoys, just an object that allows > projects to be put in any order -- and there can many many such orderings > all preserved -- and there is an object that will move from one project to > the next as you give your talk. "Builds" etc are all done via Etoy scripts. > > This allows the full power of the system to be used for everything, > including presentations. You can imagine how appalled we were by the > appearance of Persuade and PowerPoint, etc. > > Etc. > > We thought we'd done away with both "operating systems" and with "apps" > but we'd used the wrong wood in our stakes -- the vampires came back in the > 80s. > > One of the interesting misunderstandings was that Apple and then MS didn't > really understand the universal viewing mechanism (MVC) so they thought > views with borders around them were "windows" and view without borders were > part of "desktop publishing", but in fact all were the same. The Xerox Star > confounded the problem by reverting to a single desktop and apps and missed > the real media possibilities. > > They divided a unified media world into two regimes, neither of which are > very good for end-users. > > Cheers, > > Alan > > > -- > *From:* David Barbour > *To:* Fundamentals of New Computing > *Sent:* Thursday, October 31, 2013 8:58 AM > *Subject:* Re: [fonc] Task management in a world wi
Re: [fonc] Task management in a world without apps.
On Fri, Nov 1, 2013 at 6:17 AM, Josh Grams wrote: > On 2013-11-01 10:37AM, Chris Warburton wrote: > >My dislike of canvas is that it arrogantly presumes that a user agent > >has a display to be formatted. > > > >I used to develop a CMS called ocPortal which got lots of praise from > >its blind users. > > OK, now I'm completely lost. Isn't canvas for primarily graphical > applications (videogames, drawing stuff, etc.) where it would be > impossible to make it usable for a blind person anyway? I mean, > sure, people will abuse it and use it for other things, but that's > true of any technology; there's no way around that, is there? > > What am I missing? > > --Josh > Take it from a game developer - you're not missing anything. Canvas is for realtime raster graphics, that's it. Bypassing the web's usual structure/layout is its whole purpose. -Tom ___ fonc mailing list [email protected] http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Task management in a world without apps.
When I mention Smalltalk I always point to the 40 year ago past because it was then that the language and its implementation were significant. It was quite clear by the late 70s that many of the compromises (some of them wonderfully clever) that were made in order to run on the tiny machines of the day were not going to scale well. It's worth noting that both the "radical" desire to "burn the disk packs", *and* the "sensible" desire to use "powers that are immediately available" make sense in their respective contexts. But we shouldn't confuse the two desires. I.e. if we were to attempt an ultra high level general purpose language today, we wouldn't use Squeak or any other Smalltalk as a model or a starting place. Cheers, Alan > > From: karl ramberg >To: Alan Kay ; Fundamentals of New Computing > >Sent: Sunday, November 3, 2013 3:18 AM >Subject: Re: [fonc] Task management in a world without apps. > > > >One issue with the instance development in Squeak is that it is quite fragile. >It is easy to pull the building blocks apart and it all falls down like a >house of cards. > > >It's currently hard to work on different parts and individually version them >independent of the rest of the system. All parts are versioned by the whole >project. > > >It is also quite hard to reuse separate parts and share is with others. Now >you must share a whole project and pull out the parts you want. > > >I look forward to using more rugged tools for instance programming/ creation >:-) > > >Karl > > > >On Thu, Oct 31, 2013 at 5:31 PM, Alan Kay wrote: > >It's worth noting that this was the scheme at PARC and was used heavily later >in Etoys. >> >>This is why Smalltalk has unlimited numbers of "Projects". Each one is a >>persistant environment that serves both as a place to make things and as a >>"page" of "desktop media". >> >>There are no apps, only objects and any and all objects can be brought to any >>project which will preserve them over time. This avoids the stovepiping of >>apps. Dan Ingalls (in Fabrik) showed one UI and scheme to integrate the >>objects, and George Bosworth's PARTS system showed a similar but slightly >>different way. >> >>Also there is no "presentation app" in Etoys, just an object that allows >>projects to be put in any order -- and there can many many such orderings all >>preserved -- and there is an object that will move from one project to the >>next as you give your talk. "Builds" etc are all done via Etoy scripts. >> >>This allows the full power of the system to be used for everything, including >>presentations. You can imagine how appalled we were by the appearance of >>Persuade and PowerPoint, etc. >> >>Etc. >> >>We thought we'd done away with both "operating systems" and with "apps" but >>we'd used the wrong wood in our stakes -- the vampires came back in the 80s. >> >>One of the interesting misunderstandings was that Apple and then MS didn't >>really understand the universal viewing mechanism (MVC) so they thought views >>with borders around them were "windows" and view without borders were part of >>"desktop publishing", but in fact all were the same. The Xerox Star >>confounded the problem by reverting to a single desktop and apps and missed >>the real media possibilities. >> >>They divided a unified media world into two regimes, neither of which are >>very good for end-users. >> >>Cheers, >> >>Alan >> >> >> >> >> >> >>> >>> From: David Barbour >>>To: Fundamentals of New Computing >>>Sent: Thursday, October 31, 2013 8:58 AM >>>Subject: Re: [fonc] Task management in a world without apps. >>> >>> >>> >>>Instead of 'applications', you have objects you can manipulate (compose, >>>decompose, rearrange, etc.) in a common environment. The state of the >>>system, the construction of the objects, determines not only how they appear >>>but how they behave - i.e. how they influence and observe the world. Task >>>management is then simply rearranging objects: if you want to turn an object >>>'off', you 'disconnect' part of the graph, or perhaps you flip a switch that >>>does the same thing under the hood. >>> >>> >>>This has very physical analogies. For exa
Re: [fonc] Task management in a world without apps.
One issue with the instance development in Squeak is that it is quite fragile. It is easy to pull the building blocks apart and it all falls down like a house of cards. It's currently hard to work on different parts and individually version them independent of the rest of the system. All parts are versioned by the whole project. It is also quite hard to reuse separate parts and share is with others. Now you must share a whole project and pull out the parts you want. I look forward to using more rugged tools for instance programming/ creation :-) Karl On Thu, Oct 31, 2013 at 5:31 PM, Alan Kay wrote: > It's worth noting that this was the scheme at PARC and was used heavily > later in Etoys. > > This is why Smalltalk has unlimited numbers of "Projects". Each one is a > persistant environment that serves both as a place to make things and as a > "page" of "desktop media". > > There are no apps, only objects and any and all objects can be brought to > any project which will preserve them over time. This avoids the stovepiping > of apps. Dan Ingalls (in Fabrik) showed one UI and scheme to integrate the > objects, and George Bosworth's PARTS system showed a similar but slightly > different way. > > Also there is no "presentation app" in Etoys, just an object that allows > projects to be put in any order -- and there can many many such orderings > all preserved -- and there is an object that will move from one project to > the next as you give your talk. "Builds" etc are all done via Etoy scripts. > > This allows the full power of the system to be used for everything, > including presentations. You can imagine how appalled we were by the > appearance of Persuade and PowerPoint, etc. > > Etc. > > We thought we'd done away with both "operating systems" and with "apps" > but we'd used the wrong wood in our stakes -- the vampires came back in the > 80s. > > One of the interesting misunderstandings was that Apple and then MS didn't > really understand the universal viewing mechanism (MVC) so they thought > views with borders around them were "windows" and view without borders were > part of "desktop publishing", but in fact all were the same. The Xerox Star > confounded the problem by reverting to a single desktop and apps and missed > the real media possibilities. > > They divided a unified media world into two regimes, neither of which are > very good for end-users. > > Cheers, > > Alan > > > -- > *From:* David Barbour > *To:* Fundamentals of New Computing > *Sent:* Thursday, October 31, 2013 8:58 AM > *Subject:* Re: [fonc] Task management in a world without apps. > > Instead of 'applications', you have objects you can manipulate (compose, > decompose, rearrange, etc.) in a common environment. The state of the > system, the construction of the objects, determines not only how they > appear but how they behave - i.e. how they influence and observe the world. > Task management is then simply rearranging objects: if you want to turn an > object 'off', you 'disconnect' part of the graph, or perhaps you flip a > switch that does the same thing under the hood. > > This has very physical analogies. For example, there are at least two ways > to "task manage" a light: you could disconnect your lightbulb from its > socket, or you could flip a lightswitch, which opens a circuit. > > There are a few interesting classes of objects, which might be described > as 'tools'. There are tools for your hand, like different paintbrushes in > Paint Shop. There are also tools for your eyes/senses, like a magnifying > glass, x-ray goggles, heads-up display, events notification, or language > translation. And there are tools that touch both aspects - like a > projectional editor, lenses. If we extend the user-model with concepts like > 'inventory', and programmable tools for both hand and eye, those can serve > as another form of task management. When you're done painting, put down the > paintbrush. > > This isn't really the same as switching between tasks. I.e. you can still > get event notifications on your heads-up-display while you're editing an > image. It's closer to controlling your computational environment by direct > manipulation of structure that is interpreted as code (aka live > programming). > > Best, > > Dave > > > > On Thu, Oct 31, 2013 at 10:29 AM, Casey Ransberger < > [email protected]> wrote: > > A fun, but maybe idealistic idea: an "application" of a computer should > just be what one decides to do wit
Re: [fonc] Task management in a world without apps.
On 2013-11-01 10:37AM, Chris Warburton wrote: >My dislike of canvas is that it arrogantly presumes that a user agent >has a display to be formatted. > >I used to develop a CMS called ocPortal which got lots of praise from >its blind users. OK, now I'm completely lost. Isn't canvas for primarily graphical applications (videogames, drawing stuff, etc.) where it would be impossible to make it usable for a blind person anyway? I mean, sure, people will abuse it and use it for other things, but that's true of any technology; there's no way around that, is there? What am I missing? --Josh ___ fonc mailing list [email protected] http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Task management in a world without apps.
David Barbour writes: > On Thu, Oct 31, 2013 at 12:37 PM, Chris Warburton > wrote: > >> In the case of an OS, providing a dumb box to draw on is much easier >> than a complete, complementary suite of MVC/Morphic/etc. components, >> even though developers are forced to implement their own incompatible >> integration layers, if they bother at all. >> > >> This is why I'm not a fan of HTML5 canvas, since it's a dumb box which >> strips away the precious-little semantics the Web has, and restrict >> mashups to little more than putting existing boxes next to each other. >> > > There is "worse is better", but there also is "less is more". From a > limited perspective, it may be difficult to tell the difference. We should > be careful to not mistake these. In this case, the other POV is that the > canvas is a humble box that doesn't arrogantly presume it knows better than > its users how to format a display. :) My dislike of canvas is that it arrogantly presumes that a user agent has a display to be formatted. I used to develop a CMS called ocPortal which got lots of praise from its blind users. Cheers, Chris ___ fonc mailing list [email protected] http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Task management in a world without apps.
David Leibs writes: > Hi Chris, > I get your point but I have really grown to dislike that phrase "Worse > is Better". Worse is never better. Worse is always worse and worse > never reduces to better under any set of natural rewrite rules. Yes > there are advantages in the short term to being first to market and > things that are worse can have more mindshare in the arena of public > opinion. > > "Worse is Better" sounds like some kind of apology to me. > > cheers, > -David Leibs I don't see it as an apology, I use it as an insult. To me, "worse is better" is the answer to questions like "If SomeLanguage is so much better than C, why is everyone still using C?". The reason so many people use C is because so many people use C (and the same goes for Windows, multithreading, HTML, x86, etc.); there's a feedback loop. To describe something as "Worse is Better" , we're basically saying that this loop is more powerful than others'. One acceptable reason for this is because it got there first, which may mean it's lacking subsequent improvements, but it's not the end of the world. That's how progress is made, after all. One (IMHO) unacceptable reason for this is because of incompatibility. "Embrace, Extend, Extinguish" is an example, where product A is open to compatibility but product B is not; B can offer compatibility with A, but A cannot offer compatibility with B, so everyone switches to B as the 'most compatible'. Another (IMHO) unacceptable reason is a deceptively low barrier to entry. As an example, in a course I took at university, multithreading in Java was introduced as 'just writing a class with a "run" method'. This is deceptive, since multithreading invalidates all kinds of assumptions which were safe to make in single-threaded Java code. This can make one technology look simpler and cheaper to invest in than another, when actually it has a large cost further down the line. By that point a project may be irrevocably invested in that technology. None of these are features, but they do explain why it's hard to replace incumbents. Hence if a technology's most compelling feature is 'Worse is Better', that's basically saying it has no compelling features. Cheers, Chris ___ fonc mailing list [email protected] http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Task management in a world without apps.
Essentially a problem oriented window is what you want. In something like Lively Kernel, this becomes a problem oriented widget. On Oct 31, 2013 10:30 AM, "Casey Ransberger" wrote: > 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. > > Out of curiosity, how does one change one's "mood" when interacting with > Frank? > > Casey > ___ > fonc mailing list > [email protected] > http://vpri.org/mailman/listinfo/fonc > ___ fonc mailing list [email protected] http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Task management in a world without apps.
On Thu, Oct 31, 2013 at 12:37 PM, Chris Warburton wrote: > In the case of an OS, providing a dumb box to draw on is much easier > than a complete, complementary suite of MVC/Morphic/etc. components, > even though developers are forced to implement their own incompatible > integration layers, if they bother at all. > > This is why I'm not a fan of HTML5 canvas, since it's a dumb box which > strips away the precious-little semantics the Web has, and restrict > mashups to little more than putting existing boxes next to each other. > There is "worse is better", but there also is "less is more". From a limited perspective, it may be difficult to tell the difference. We should be careful to not mistake these. In this case, the other POV is that the canvas is a humble box that doesn't arrogantly presume it knows better than its users how to format a display. :) ___ fonc mailing list [email protected] http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Task management in a world without apps.
It can be depressing, certainly, to look at the difference between "where we are" and "where we could be, if we weren't short-sighted and greedy". OTOH, if you look at "where we are" vs. "where we were", I think you can find a lot to be optimistic about. FP and types have slowly wormed their way into many PLs. Publish-subscribe is gaining mindshare. WebRTC, HTML Canvas, WebSockets, etc. have finally resulted in a widespread VMs people are actually willing to use (even if they could be better). On Thu, Oct 31, 2013 at 1:16 PM, David Leibs wrote: > In the spirit of equivocation when I look at the world we live in and and > note the trends then I feel worse, not better. > > -David Leibs > > On Oct 31, 2013, at 11:10 AM, David Barbour wrote: > > The phrase "Worse is better" involves an equivocation - the 'worse' and > 'better' properties are applied in completely different domains (technical > quality vs. market success). But, hate it or not, it is undeniable that > "worse is better" philosophy has been historically successful. > > > On Thu, Oct 31, 2013 at 12:50 PM, David Leibs wrote: > >> Hi Chris, >> I get your point but I have really grown to dislike that phrase "Worse is >> Better". Worse is never better. Worse is always worse and worse never >> reduces to better under any set of natural rewrite rules. Yes there are >> advantages in the short term to being first to market and things that are >> worse can have more mindshare in the arena of public opinion. >> >> "Worse is Better" sounds like some kind of apology to me. >> >> cheers, >> -David Leibs >> >> On Oct 31, 2013, at 10:37 AM, Chris Warburton >> wrote: >> >> Unfortunately, a big factor is also the first-to-market pressure, >> otherwise known as 'Worse Is Better': you can reduce the effort required >> to implement a system by increasing the effort required to use it. The >> classic example is C vs LISP, but a common one these days is >> multithreading vs actors, coroutines, etc. >> >> >> >> ___ >> fonc mailing list >> [email protected] >> http://vpri.org/mailman/listinfo/fonc >> >> > ___ > fonc mailing list > [email protected] > http://vpri.org/mailman/listinfo/fonc > > > > ___ > fonc mailing list > [email protected] > http://vpri.org/mailman/listinfo/fonc > > ___ fonc mailing list [email protected] http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Task management in a world without apps.
Alan,
I appreciate the peek into history! I had to look up Fabrik and PARTS. I
love the idea of running presentations as live coding; in fact, I shall
endeavor to do so for any talks I give regarding my own system.
Smalltalk has a lot of good ideas, but they're sometimes mixed with
not-so-great ideas and difficult to separate. Even today, the idea of
"applications as objects in the IDE" gives results in a knee-jerk rejection
response from many people who fear a tight coupling ("to share the app, I
need to share the whole IDE!") based largely on Smalltalk's example.
Language-layer security and an alternative state model could address this
issue, enabling easy decoupling of behavior from environment. Similarly,
MVC has several properties that I believe have been more harmful than
helpful. Models in MVC systems are neither compositional nor open, and
controls were decoupled from views, which hinders direct manipulation and
physical metaphors. More modern variations such as MVVM are improvements,
but they're still a long way from collaborative projectional editors or
spreadsheets.
But the good ideas should be preserved, separated from the chaff, reused in
new contexts. It's interesting to pick apart history and hypothesize why
various good ideas have failed to gain traction.
Best,
Dave
On Thu, Oct 31, 2013 at 11:31 AM, Alan Kay wrote:
> It's worth noting that this was the scheme at PARC and was used heavily
> later in Etoys.
>
> This is why Smalltalk has unlimited numbers of "Projects". Each one is a
> persistant environment that serves both as a place to make things and as a
> "page" of "desktop media".
>
> There are no apps, only objects and any and all objects can be brought to
> any project which will preserve them over time. This avoids the stovepiping
> of apps. Dan Ingalls (in Fabrik) showed one UI and scheme to integrate the
> objects, and George Bosworth's PARTS system showed a similar but slightly
> different way.
>
> Also there is no "presentation app" in Etoys, just an object that allows
> projects to be put in any order -- and there can many many such orderings
> all preserved -- and there is an object that will move from one project to
> the next as you give your talk. "Builds" etc are all done via Etoy scripts.
>
> This allows the full power of the system to be used for everything,
> including presentations. You can imagine how appalled we were by the
> appearance of Persuade and PowerPoint, etc.
>
> Etc.
>
> We thought we'd done away with both "operating systems" and with "apps"
> but we'd used the wrong wood in our stakes -- the vampires came back in the
> 80s.
>
> One of the interesting misunderstandings was that Apple and then MS didn't
> really understand the universal viewing mechanism (MVC) so they thought
> views with borders around them were "windows" and view without borders were
> part of "desktop publishing", but in fact all were the same. The Xerox Star
> confounded the problem by reverting to a single desktop and apps and missed
> the real media possibilities.
>
> They divided a unified media world into two regimes, neither of which are
> very good for end-users.
>
> Cheers,
>
> Alan
>
>
> --
> *From:* David Barbour
> *To:* Fundamentals of New Computing
> *Sent:* Thursday, October 31, 2013 8:58 AM
> *Subject:* Re: [fonc] Task management in a world without apps.
>
> Instead of 'applications', you have objects you can manipulate (compose,
> decompose, rearrange, etc.) in a common environment. The state of the
> system, the construction of the objects, determines not only how they
> appear but how they behave - i.e. how they influence and observe the world.
> Task management is then simply rearranging objects: if you want to turn an
> object 'off', you 'disconnect' part of the graph, or perhaps you flip a
> switch that does the same thing under the hood.
>
> This has very physical analogies. For example, there are at least two ways
> to "task manage" a light: you could disconnect your lightbulb from its
> socket, or you could flip a lightswitch, which opens a circuit.
>
> There are a few interesting classes of objects, which might be described
> as 'tools'. There are tools for your hand, like different paintbrushes in
> Paint Shop. There are also tools for your eyes/senses, like a magnifying
> glass, x-ray goggles, heads-up display, events notification, or language
> translation. And there are tools that touch both aspects - like a
> projectional editor, lenses. If we extend the user-model with concepts like
> 'inventory',
Re: [fonc] Task management in a world without apps.
In the spirit of equivocation when I look at the world we live in and and note the trends then I feel worse, not better. -David Leibs On Oct 31, 2013, at 11:10 AM, David Barbour wrote: > The phrase "Worse is better" involves an equivocation - the 'worse' and > 'better' properties are applied in completely different domains (technical > quality vs. market success). But, hate it or not, it is undeniable that > "worse is better" philosophy has been historically successful. > > > On Thu, Oct 31, 2013 at 12:50 PM, David Leibs wrote: > Hi Chris, > I get your point but I have really grown to dislike that phrase "Worse is > Better". Worse is never better. Worse is always worse and worse never > reduces to better under any set of natural rewrite rules. Yes there are > advantages in the short term to being first to market and things that are > worse can have more mindshare in the arena of public opinion. > > "Worse is Better" sounds like some kind of apology to me. > > cheers, > -David Leibs > > On Oct 31, 2013, at 10:37 AM, Chris Warburton > wrote: > >> Unfortunately, a big factor is also the first-to-market pressure, >> otherwise known as 'Worse Is Better': you can reduce the effort required >> to implement a system by increasing the effort required to use it. The >> classic example is C vs LISP, but a common one these days is >> multithreading vs actors, coroutines, etc. > > > ___ > fonc mailing list > [email protected] > http://vpri.org/mailman/listinfo/fonc > > > ___ > fonc mailing list > [email protected] > http://vpri.org/mailman/listinfo/fonc ___ fonc mailing list [email protected] http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Task management in a world without apps.
The phrase "Worse is better" involves an equivocation - the 'worse' and 'better' properties are applied in completely different domains (technical quality vs. market success). But, hate it or not, it is undeniable that "worse is better" philosophy has been historically successful. On Thu, Oct 31, 2013 at 12:50 PM, David Leibs wrote: > Hi Chris, > I get your point but I have really grown to dislike that phrase "Worse is > Better". Worse is never better. Worse is always worse and worse never > reduces to better under any set of natural rewrite rules. Yes there are > advantages in the short term to being first to market and things that are > worse can have more mindshare in the arena of public opinion. > > "Worse is Better" sounds like some kind of apology to me. > > cheers, > -David Leibs > > On Oct 31, 2013, at 10:37 AM, Chris Warburton > wrote: > > Unfortunately, a big factor is also the first-to-market pressure, > otherwise known as 'Worse Is Better': you can reduce the effort required > to implement a system by increasing the effort required to use it. The > classic example is C vs LISP, but a common one these days is > multithreading vs actors, coroutines, etc. > > > > ___ > fonc mailing list > [email protected] > http://vpri.org/mailman/listinfo/fonc > > ___ fonc mailing list [email protected] http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Task management in a world without apps.
Hi Chris, I get your point but I have really grown to dislike that phrase "Worse is Better". Worse is never better. Worse is always worse and worse never reduces to better under any set of natural rewrite rules. Yes there are advantages in the short term to being first to market and things that are worse can have more mindshare in the arena of public opinion. "Worse is Better" sounds like some kind of apology to me. cheers, -David Leibs On Oct 31, 2013, at 10:37 AM, Chris Warburton wrote: > Unfortunately, a big factor is also the first-to-market pressure, > otherwise known as 'Worse Is Better': you can reduce the effort required > to implement a system by increasing the effort required to use it. The > classic example is C vs LISP, but a common one these days is > multithreading vs actors, coroutines, etc. ___ fonc mailing list [email protected] http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Task management in a world without apps.
n 31 October 2013 17:37, Chris Warburton wrote: > > …many filesystems have provided metadata facilities > over the years, but these have all hit limits which end up being worked > around by storing metadata in files, making the FS unnecessarily > complex. ReiserFS, from at least version 3, implemented extended attributes (xattrs) as directories, meaning that there were no arbitrary limits. I never understood why other FSes didn't do the same, as it surely makes the code simpler than having a special fixed-size implementation. However, having thought about ResierFS, the idea of xattrs themselves seem pretty odd, because what is data and what is metadata can depend on context, plus of course you're never going to get all the metadata out of files and into FS attributes; and it seems odd to have two different fundamental APIs (regular file API and xattr API) to manipulate different instances of the same on-disk representation (files in directories). ___ fonc mailing list [email protected] http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Task management in a world without apps.
Alan Kay writes: > One of the interesting misunderstandings was that Apple and then MS > didn't really understand the universal viewing mechanism (MVC) so they > thought views with borders around them were "windows" and view without > borders were part of "desktop publishing", but in fact all were the > same. When we design an environment/framework, there are always tradeoffs to make when deciding what capabilities to include in the medium. A common problem is capabilities becoming obsolete and being worked around, for example many filesystems have provided metadata facilities over the years, but these have all hit limits which end up being worked around by storing metadata in files, making the FS unnecessarily complex. Another problem is restricting the technology which can be used by clients; for example browsers will only run Javascript, which made them 'toys' for many years in the eyes of C/C++/Java programmers. Unfortunately, a big factor is also the first-to-market pressure, otherwise known as 'Worse Is Better': you can reduce the effort required to implement a system by increasing the effort required to use it. The classic example is C vs LISP, but a common one these days is multithreading vs actors, coroutines, etc. In the case of an OS, providing a dumb box to draw on is much easier than a complete, complementary suite of MVC/Morphic/etc. components, even though developers are forced to implement their own incompatible integration layers, if they bother at all. This is why I'm not a fan of HTML5 canvas, since it's a dumb box which strips away the precious-little semantics the Web has, and restrict mashups to little more than putting existing boxes next to each other. Cheers, Chris PS: I spent one summer living in Etoys on my OLPC XO-1, creating physics simulations. It's a very nice system once it's gotten used to. It's one thing to drag and drop tiles to make a scribbled picture start spinning, it's quite another to make the tiles themselves start spinning :) PPS: I keep meaning to pull those those simulations off my XO and upload them to squeakland. Unfortunately I reached a point where they maxed out the RAM so I couldn't finish them :( ___ fonc mailing list [email protected] http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Task management in a world without apps.
It's worth noting that this was the scheme at PARC and was used heavily later in Etoys. This is why Smalltalk has unlimited numbers of "Projects". Each one is a persistant environment that serves both as a place to make things and as a "page" of "desktop media". There are no apps, only objects and any and all objects can be brought to any project which will preserve them over time. This avoids the stovepiping of apps. Dan Ingalls (in Fabrik) showed one UI and scheme to integrate the objects, and George Bosworth's PARTS system showed a similar but slightly different way. Also there is no "presentation app" in Etoys, just an object that allows projects to be put in any order -- and there can many many such orderings all preserved -- and there is an object that will move from one project to the next as you give your talk. "Builds" etc are all done via Etoy scripts. This allows the full power of the system to be used for everything, including presentations. You can imagine how appalled we were by the appearance of Persuade and PowerPoint, etc. Etc. We thought we'd done away with both "operating systems" and with "apps" but we'd used the wrong wood in our stakes -- the vampires came back in the 80s. One of the interesting misunderstandings was that Apple and then MS didn't really understand the universal viewing mechanism (MVC) so they thought views with borders around them were "windows" and view without borders were part of "desktop publishing", but in fact all were the same. The Xerox Star confounded the problem by reverting to a single desktop and apps and missed the real media possibilities. They divided a unified media world into two regimes, neither of which are very good for end-users. Cheers, Alan >________ > From: David Barbour >To: Fundamentals of New Computing >Sent: Thursday, October 31, 2013 8:58 AM >Subject: Re: [fonc] Task management in a world without apps. > > > >Instead of 'applications', you have objects you can manipulate (compose, >decompose, rearrange, etc.) in a common environment. The state of the system, >the construction of the objects, determines not only how they appear but how >they behave - i.e. how they influence and observe the world. Task management >is then simply rearranging objects: if you want to turn an object 'off', you >'disconnect' part of the graph, or perhaps you flip a switch that does the >same thing under the hood. > > >This has very physical analogies. For example, there are at least two ways to >"task manage" a light: you could disconnect your lightbulb from its socket, or >you could flip a lightswitch, which opens a circuit. > > >There are a few interesting classes of objects, which might be described as >'tools'. There are tools for your hand, like different paintbrushes in Paint >Shop. There are also tools for your eyes/senses, like a magnifying glass, >x-ray goggles, heads-up display, events notification, or language translation. >And there are tools that touch both aspects - like a projectional editor, >lenses. If we extend the user-model with concepts like 'inventory', and >programmable tools for both hand and eye, those can serve as another form of >task management. When you're done painting, put down the paintbrush. > > >This isn't really the same as switching between tasks. I.e. you can still get >event notifications on your heads-up-display while you're editing an image. >It's closer to controlling your computational environment by direct >manipulation of structure that is interpreted as code (aka live programming). > > >Best, > > >Dave > > > > > > >On Thu, Oct 31, 2013 at 10:29 AM, Casey Ransberger >wrote: > >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
Re: [fonc] Task management in a world without apps.
Instead of 'applications', you have objects you can manipulate (compose, decompose, rearrange, etc.) in a common environment. The state of the system, the construction of the objects, determines not only how they appear but how they behave - i.e. how they influence and observe the world. Task management is then simply rearranging objects: if you want to turn an object 'off', you 'disconnect' part of the graph, or perhaps you flip a switch that does the same thing under the hood. This has very physical analogies. For example, there are at least two ways to "task manage" a light: you could disconnect your lightbulb from its socket, or you could flip a lightswitch, which opens a circuit. There are a few interesting classes of objects, which might be described as 'tools'. There are tools for your hand, like different paintbrushes in Paint Shop. There are also tools for your eyes/senses, like a magnifying glass, x-ray goggles, heads-up display, events notification, or language translation. And there are tools that touch both aspects - like a projectional editor, lenses. If we extend the user-model with concepts like 'inventory', and programmable tools for both hand and eye, those can serve as another form of task management. When you're done painting, put down the paintbrush. This isn't really the same as switching between tasks. I.e. you can still get event notifications on your heads-up-display while you're editing an image. It's closer to controlling your computational environment by direct manipulation of structure that is interpreted as code (aka live programming). Best, Dave On Thu, Oct 31, 2013 at 10:29 AM, Casey Ransberger wrote: > 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. > > Out of curiosity, how does one change one's "mood" when interacting with > Frank? > > Casey > ___ > fonc mailing list > [email protected] > http://vpri.org/mailman/listinfo/fonc > ___ fonc mailing list [email protected] http://vpri.org/mailman/listinfo/fonc
