Desktop For Smart People




Recently quite a comtion has come over the direction of gnome, it's changes, and it's target audience.  I, personally, seem to average somewhere around 1/2 to 1 hour a day trying to get something to work in gnome that usually just isn't going to work anyway.  So my hour is basically spent as time "learning" the (lack of) system.

For those who care, this is a link to: a profile of my days with gnome which details a tipical day of me working with gnome and burning time, but it's not incredibly important to the current point, so don't let it distract you from the rest of the article :)

Now much has already been said on the subject, even before the gnome war.  In particular the distinction between systems that are easy to learn vs easy to use without learning has been very enlightening.

This issue also has a massive similarity to the ideas of Languages For Smart People vs Langagues For the Masses

I think when people say "I wish more people would use X" {where X = linux, or a programming language, etc}, that what many of them they really mean is "I wish more people would act like the people that I currenly see using X".  I discovered this for myself when after saying "I wish everyone would be on the internet" in the early 90's,  I found myself saying "I wish these people would *leave* the internet" {coinicdently, this was shortly after the windows drivers were written}.

I propose that what we need to do, is to similarly create the Desktop for Smart People, in which we do not assume the user is a idiot {i.e. incapable of learning}. So, we will have to understand that everyone in the world will not use it. 

Ok, that may sound neat, but what does it mean?  It means a desktop, that is easy to learn, but has no limit to how much there is to learn.  One that's based on a few, small components that can be learned quickly, and are re-usable in new combinations of which the consequences can be explored over a entire lifetime.  One that has a interface that is turing complete.  A few default options of what there is to do in a menu system don't cut it.  The menu system of programs should be a front end to a simple, interpeted language which has all the features, like scheme, which can in turn have a parser for whatever syntax the user needs for his current task.  A {sourcastic} discussion of language principles and features is over in The Languages Of Suffering.  The the principals of languages should come through in our desktop and programs, making once and for all the line between using and programming unidentifiable.

As a user, I should be able to stop using the menu system, and get a command prompt (of the programming language... not bash ;) Some might say that I'm reinventing emacs, and in some sence there right.  But emacs dosn't have quite the good visual graphical support that gnome has.  Also, emacs uses Common Lisp, which is a older dialect.  It would be better if we could update it with the simpler dialect of scheme.  someone is trying something like this now:

texmacs is a TeX based "word processor" with guile scheme scripting in it... a interesting project.  Think of it as a cross between lyx and emacs.

guilemacs was a guile based emacs that looks like development stopped on though.

emacs link...

siag


All this would be driving it to become the easiest system to develop in.  And think of how much code would be submitted in a system in which using and programming couldn't be distinguished...  It would mean that, in classical vocabulary, every "user" would be a "developer", and could just submit a copy of whatever they just did.  and there "programming expertice" would get better every day as they used their word processor, etc.

Really what were looking for is something like a cross between nextstep (OSX) and emacs.


*one namespace*

integration of filesystem and namespace (automatic filename->symbol conversion.  (spaces and wierd chars could be handled ok by a extra function of symbol->string thus:
(open (find-in (find-in (find-in root-directory-list  usr) local) (string->symbol "HoRiBLe  *name* by \"Meanie\"')
but that'd be just having access to the filesystem as a list.  we should integrate the filesystem hierarchy, with the module system.  and of course theres nothing preventing us from creating a reader macro to do automatic string->symbol via (gimmie-object ##/usr/local/bin/lyx)  (assuming the ## is the begining of our reader macro syntax) . in fact the macro could call the "gimmie-ojbect" and just return the object it'self with ##/usr/local/bin/lyx.


Integration of the development environment with the desktop, the IDE & file manager should be the same thing.

integrated "GUI builder".  by left clicking on anything I should be able to change it into "layout mode", without loading a seperate application.

//note: integration with "tex" or tex-like operations...

emblems - if the mime type system  is integrated with the native "type system" (or type standard), a user should be able to create new types on the fly, and use those types to sort his file list. 

(see example on next page)


mime types & "real types"

Our internal scheme type system should be extended to recognize mime types, so (number?  ##/usr/local/bin/hello.world.tx) would be #f, but (texmacs-data?  ##/usr/local/bin/hello.world.tx) would be #t.  Of course type systems are often coupled closely with object systems, so we might need to pick a standard object system (something like tinyclos, but bigger?)



So that's the idea.  Now how would we do it?  check out:

Page 2 - The Plan



Corey
corey.sweeney@gmail.com


That's the end, but you can always go back to



RSS feed