Pythonic Nirvana - towards a true Object Oriented Environment [visionary rambling, long]

Discussion in 'Python' started by Ville Vainio, Jun 29, 2004.

  1. Ville Vainio

    Ville Vainio Guest

    Pythonic Nirvana - towards a true Object Oriented Environment
    =============================================================

    IPython (by Francois Pinard) recently (next release - changes are
    still in CVS) got the basic abilities of a system shell (like
    bash). Actually, using it as a shell is rather comfortable. This all
    made me think...

    Why do we write simple scripts to do simple things? Why do we
    serialize data to flat text files in order to process them? Everything
    could be so much simpler and immensely more powerful if we operated on
    data *directly* - we should operate on objects, lists, dictionaries,
    functions, not files. We shouldn't write scripts to perform our
    routines - and way too often, we don't even try, because moving the
    data between scripts is too troublesome, involving file formats, argv
    parsing and other tedious stuff.

    If we use a shell with full Python capabilities, we can introduce new
    funtionality for integrating our environments very easily. Consider a
    project framework for managing a software project::

    >> import pf
    >> pf.projects


    --> [<project 'foo'>, <project 'bar'>]

    >> p = pf.projects[0] # we want to work with project 'foo'
    >> headers = Set([f for f in p.files() if f.endswith(".h")])
    >> srcs = p.files - headers
    >> found = Set([f for f in srcs if find_any(f, headers)])


    >> r = findradio("kazoo classics")[0] # some diversion needed
    >> music.play # manipulates our music player
    >> music.vol 100


    # back to work...
    >> notfound = srcs - found


    # who has made a header that is not used?
    >> jackasses = Set([p.author(file) for file in notfound])



    Now we have the names of our victims in 'jackasses' variable. We want
    to make that variable accessible to all in our project team, in a
    persistent store. We use tab completion to find the databases::

    >> export jackasses <TAB>


    Completions: "fooproject_db" "barproject_db" "private"

    Note how tab completions for "export" notices that we are trying to
    enter the second parameter. It knows that it is the database name, and
    the completion mechanism (written for export) dynamically queries the
    list of databases for which we are allowed to export data. After
    seeing the choices we choose one of them::

    >> export jackasses "fooproject_db" name="slackers"


    Now the list of guys is accessible to everybody. We also compose a
    volatile email to everybody::

    >> xemacs tmp


    >> for m in [Mail(to=name, bodyfile="tmp") for name in jackasses]: m.send


    And rat the guys to the management::

    >> xemacs tmp2


    # mail contents
    # The following guys have not been doing their jobs:
    # @("\n".join(jackasses))

    >> cont = open(tmp2).read().expand() # runs it through EmPy template expansion system.


    >> Mail(to=p.boss, body=cont).send


    Notice how jackasses variable was used inside the mail. We can also
    schedule some extra hours for the guys to check if their headers are
    needed, create a cron script to monitor that they have fixed the bugs,
    etc.

    The boss might want to fire them at once:

    >> l = import "slackers"
    >> [e.fire() for e in Employee(l)]


    Or the boss might want to do some more extensive firing to invigorate
    the company::

    >> ent = MyEnterprise()


    Auth needed!
    Password: ******

    >> st = stats(ent.allemployees())
    >> avgperf = st.average_performance



    >> def dead_weight(emp):

    .. if emp.performance() < avgperf: return True
    .. return False

    >> ent.fire_if(dead_weight)


    Typing all that might seem like a lot of work. However, a lot of it
    will probably be implemented as functions aggregating the
    functionality. Most of the lines here could be factored out to
    a function (note that I didn't say script)::

    def unused_headers(prj):
    """ returns the header files that are not used in the project """
    ... implementation ...


    With conventional scripting techniques, nobody would want to do all
    this. With the pythonic approach, creating this kind of business
    intelligence is a breeze, eliminating tons of tedious routine!

    Obviously this all can be done in specific scripts, which start doing
    the thing "from the start" - open database connections, ask the user
    to select the project, etc. However, writing such scripts is a lot of
    work. With the interactive, much more dynamic approach, pieces of
    functionality can be implemented one by one, and they become usable
    immediately.

    I can imagine that for power users and "knowledge workers", this type
    of system would yield immense power. The payback is also incremental -
    the whole system grows and gets refactored, streamlining the
    process. In the end most of it will probably be driven by a simple
    GUI. Especially the "fire below average employees" function, which
    should not be run in a yearly cron job - only when needed. Various GUI
    threads could be running in the same Python process, manipulating the
    same namespace

    What needs to be done
    ---------------------

    Not surprisingly, "we're not there yet".

    - IPython needs some refactoring (the codebase isn't quite scalable
    and extensible enough yet). Francois can use some help.

    - Flexible persistence system needs to be itengrated. ZODB, perhaps?

    - Domain specific modules (like project / "employee management"
    systems) need to be implemented. This luckily mostly writes itself.

    - Flexible, but easy to use protocols need to be specified for
    documenting the functions, argument expansion, gui interaction etc. A
    gui module should display the documentation for the "current" function
    and possible arguments, so there's no need to press tab at all times.

    Still, all in all, we're almost there. This has the perhaps same
    "feel" of tight integration that I imagine the Lisp Macine guys were
    experiencing, but Python is much more scripting-friendly, community
    driven and easier to learn.

    Ergo, world domination.

    --
    Ville Vainio http://tinyurl.com/2prnb
     
    Ville Vainio, Jun 29, 2004
    #1
    1. Advertising

  2. Ville Vainio

    Ville Vainio Guest

    >>>>> "Ville" == Ville Vainio (yes, that's me) writes:

    Ville> IPython (by Francois Pinard) recently (next release - changes are

    Minor correction - it's Fernando Perez, not Francois Pinard. I
    apologize.

    IPython web page is at http://ipython.scipy.org/, for the googlically
    challenged.

    --
    Ville Vainio http://tinyurl.com/2prnb
     
    Ville Vainio, Jun 29, 2004
    #2
    1. Advertising

  3. Ville Vainio <> writes:

    > Why do we write simple scripts to do simple things? Why do we
    > serialize data to flat text files in order to process them? Everything
    > could be so much simpler and immensely more powerful if we operated on
    > data *directly* - we should operate on objects, lists, dictionaries,
    > functions, not files. We shouldn't write scripts to perform our
    > routines - and way too often, we don't even try, because moving the
    > data between scripts is too troublesome, involving file formats, argv
    > parsing and other tedious stuff.


    http://www.scsh.net/
     
    Jacek Generowicz, Jun 29, 2004
    #3
  4. Ville Vainio

    Ville Vainio Guest

    >>>>> "Jacek" == Jacek Generowicz <> writes:

    Jacek> http://www.scsh.net/

    Yes, scsh appears to be doing the same thing as ipython now (though
    ipython doesn't yet do job control or other "lower level"
    stuff). However, it *is* in Scheme, which kinda muddens the
    integration / universality / user acceptance aspects ;-).

    Still, scsh appears is a good place to look for further development,
    especially as far as process control/redirection goes.

    --
    Ville Vainio http://tinyurl.com/2prnb
     
    Ville Vainio, Jun 29, 2004
    #4
  5. Ville Vainio

    Phil Frost Guest

    Re: Pythonic Nirvana - towards a true Object Oriented Environment[visionary rambling, long]

    I'm forwarding this to the Unununium <http://unununium.org/> mailing
    list. I think the two projects are solving the same problem from
    opposite ends.

    On Tue, Jun 29, 2004 at 05:03:18PM +0300, Ville Vainio wrote:
    > Pythonic Nirvana - towards a true Object Oriented Environment
    > =============================================================
    >
    > IPython (by Francois Pinard) recently (next release - changes are
    > still in CVS) got the basic abilities of a system shell (like
    > bash). Actually, using it as a shell is rather comfortable. This all
    > made me think...
    >
    > ...
     
    Phil Frost, Jun 29, 2004
    #5
  6. Ville Vainio

    Ville Vainio Guest

    >>>>> "Phil" == Phil Frost <> writes:

    Phil> I'm forwarding this to the Unununium <http://unununium.org/> mailing
    Phil> list. I think the two projects are solving the same problem from
    Phil> opposite ends.

    Very interesting link :).

    Actually, IPython is so far not actively solving the problem Ununium
    is solving, and I wasn't really talking on behalf of IPython the
    project, more like visions of what I might want it to be (and
    Fernando, the author, probably too, but his time resources are
    limited). If you Ununium guys have developer resources to throw at
    IPython's direction, I would bet Fernando wouldn't mind a little help
    at all - just join the ipython-dev mailing list, IPython is in need of
    refactoring :).

    And if you want to check ipython out, do a cvs checkout as instructed
    on the webpage and start ipython by "ipython -p pysh", which starts it
    in shell mode.

    --
    Ville Vainio http://tinyurl.com/2prnb
     
    Ville Vainio, Jun 29, 2004
    #6
  7. Ville Vainio

    mjt Guest

    Ville Vainio wrote:

    > Pythonic Nirvana - towards a true Object Oriented Environment


    .... with every new language/scripting language,
    we are supposed to discover nirvana

    as my 13 YO daughter would say: "what--*EVER*..."
    ..
    --
    << http://michaeljtobler.homelinux.com/ >>
    I don't need to compromise my principles, because they don't have the
    slightest bearing on what happens to me anyway. -- Calvin
     
    mjt, Jun 30, 2004
    #7
  8. Ville Vainio

    Ville Vainio Guest

    >>>>> "mjt" == mjt <mjtobler@removethis_mail.ru> writes:

    mjt> Ville Vainio wrote:
    >> Pythonic Nirvana - towards a true Object Oriented Environment


    mjt> ... with every new language/scripting language, we are
    mjt> supposed to discover nirvana

    Nirvana is not discovered - Nirvana just is ;-).

    The point was not liberation-through-Python, it was
    liberation-through-interactive-integration-at-deeper-level.

    --
    Ville Vainio http://tinyurl.com/2prnb
     
    Ville Vainio, Jun 30, 2004
    #8
  9. Ville Vainio

    has Guest

    Ville Vainio <> wrote in message news:<>...
    > Pythonic Nirvana - towards a true Object Oriented Environment


    Try Squeak for ideas: http://www.squeak.org/
     
    has, Jun 30, 2004
    #9
  10. Actually, the last time somebody propsed writing a python based OS, I
    had pretty much the same idea. The idea you have currently looks good
    for a pure text environment, but you may want to think about what
    enhancements would look like as people add things like GUIs in the mix
    and see how that works. I suppose it could wind up looking something
    like a Naked Object framework, but it could go a lot of different
    ways. But in general, putting together an interactive object based
    interface will probably lead you down the OS optimization path. As
    main memory gets cluttered with objects, you'll want to swap some back
    to disk, so you'll need some kind of virtual memory system, and some
    way to store those objects on disk, which implies an object file
    system, and once you start screwing with file systems, you may as well
    get right into the OS level. And that sounds like a vaguely good
    idea, although the top down approach seems like a different way of
    doing it, start with a basic linux kernel, then start modifying what
    you need to, rewriting parts in python as needed, until you get down
    to a core and the python object space.

    But to take another tack, you may also want to think about the user
    experience. Generally, if the system works on a text level, you'll
    definitely want to bring it into a gui framework, and when people see
    a gui, they'll want to start doing all the things they can do on other
    systems, like creating documents, spreadsheets, databases, listening
    to mp3s, looking at pictures and movies, and so on. So you may want
    to start thinking about more complicated standard types above list and
    dict, like Picture, Document, Sound, Table, and so on. Then make sure
    that creating these basic objects is fairly easy, then think about how
    scripting data flow in and around these objects can be done, object
    casting (for instance, casting a picture to a document would seem to
    require an OCR engine) and so on, and then you can begin to see how a
    whole framework could work, and act somewhat as expected in a normal
    setting.

    Of course, this has certain implications, for a system like this to
    interoperate with other normal file based systems, you'll need
    automatic conversion of incoming and outgoing files into your base
    object types, so it would probably help to pick current standards as
    the basis for your object models (like jpeg for pictures and so on) so
    that they can easily be cast as files to the outside world. So I
    wouldn't go too crazy coloring outside the lines with this. But it
    could be a great thing.

    And yes, I have thought about this before.





    Ville Vainio <> wrote in message news:<>...
    > >>>>> "mjt" == mjt <mjtobler@removethis_mail.ru> writes:

    >
    > mjt> Ville Vainio wrote:
    > >> Pythonic Nirvana - towards a true Object Oriented Environment

    >
    > mjt> ... with every new language/scripting language, we are
    > mjt> supposed to discover nirvana
    >
    > Nirvana is not discovered - Nirvana just is ;-).
    >
    > The point was not liberation-through-Python, it was
    > liberation-through-interactive-integration-at-deeper-level.
     
    Corey Coughlin, Jun 30, 2004
    #10
  11. Ville Vainio

    Ville Vainio Guest

    >>>>> "Corey" == Corey Coughlin <> writes:

    Corey> Actually, the last time somebody propsed writing a python
    Corey> based OS, I had pretty much the same idea. The idea you
    Corey> have currently looks good for a pure text environment, but
    Corey> you may want to think about what enhancements would look
    Corey> like as people add things like GUIs in the mix and see how
    Corey> that works. I suppose it could wind up looking something
    Corey> like a Naked Object framework, but it could go a lot of
    Corey> different

    Yes, the Naked Objects thing (now that I know about it ;-) looks quite
    similar to what I had in mind, but I get the feel that it's too
    "heavyweight" to be used as general purpose operating environment
    (a'la shell / file manager / bunch of scripts). It seems to be geared
    towards focused cathedral style development, as opposed to the user
    developing the system as he goes about using it (which is much more
    realistic w/ Python than Java).

    Corey> ways. But in general, putting together an interactive
    Corey> object based interface will probably lead you down the OS
    Corey> optimization path. As

    I tend to think that Linux / Windows is the base to build on, and that
    the software should work happily with the limitations of such systems
    (file system & all). Without integration with the platform people
    won't even try it, and it couldn't grow independent of the core
    developers.

    Corey> main memory gets cluttered with objects, you'll want to
    Corey> swap some back to disk, so you'll need some kind of virtual
    Corey> memory system, and some way to store those objects on disk,
    Corey> which implies an object file system, and once you start
    Corey> screwing with file systems, you may as well get right into
    Corey> the OS level. And that sounds like a vaguely good idea,

    Explicit persistence is IMO not a bad idea. If an object is in the
    main memory, it's in the main memory (until paged out normally by the
    OS). I'm not sure considering the object oriented nature of the data
    would yield significant payoffs compared to typical paged virtual
    memory implementations.

    Temporary data should be just that, temporary, so there would not be
    that much in-memory objects. Mostly the objects you are working with
    currently. Also, the actual valuable data should be stored in standard
    files in sensible places. a Music object, for example, is probably
    just an interface to manipulating an underlying .ogg file.

    Corey> experience. Generally, if the system works on a text
    Corey> level, you'll definitely want to bring it into a gui
    Corey> framework, and when people see a gui, they'll want to start

    Yes, GUI framework would definitely be cool. I'm thinking of a
    nautilus-like view of the python in-memory namespace, where the
    objects are shown in their natural representations. All the in-memory
    objects could be dragged to another window, representing a persistent
    object database, where they would be, well, persisted.

    Corey> to start thinking about more complicated standard types
    Corey> above list and dict, like Picture, Document, Sound, Table,
    Corey> and so on. Then make sure that creating these basic

    Things like Picture, Document etc. would be rather easy to implement -
    just make sure that Path objects work (file names should be Path objs,
    not strings), and create an object/system that autoconverts the path
    to an object via which the file can offer richer operations (play,
    print, etc).

    Corey> objects is fairly easy, then think about how scripting data
    Corey> flow in and around these objects can be done, object

    Well, since they are Python objects, using Python to script the data
    flow would seem optimal ;-).


    Corey> Of course, this has certain implications, for a system like
    Corey> this to interoperate with other normal file based systems,
    Corey> you'll need automatic conversion of incoming and outgoing
    Corey> files into your base

    As I said previously, I don't think files should be converted - all
    the valuable data (i.e. data that can't be trivially derived from
    other data) should still be as normal files.

    What is needed is

    1. Have a global python "system image", consisting of objects in
    memory and ones in persistent store.

    2. Implement a special file type for file managers (which will then
    act as object managers). Let's call it .object. Example contents of
    .object files follows:


    5236253625362512.object: # (the name need not make any sense, user never sees it)
    --------------------
    memobject at 0x2326561 core version 675 class = 3274892347.object
    --------------------

    3274892347.object: # this is the class object, in persistent store
    --------------------
    persistentobject #5612 database /srv/coredb1 version 34
    --------------------

    475847845.object
    --------------------
    instantiate myutils.OCREngine version 432 # or perhaps version HEAD?
    --------------------


    When the file manager starts to render the directory, it sees the
    ..object file and reads the contents, rendering the object as
    appropriate (reading it either from the memory or object
    database). Version numbers would guarantee that no objects in core
    which is dead (after reboot) would be rendered.

    This all would of course mean that Nautilus/whatever would be in the
    same address space as the python core.

    Corey> wouldn't go too crazy coloring outside the lines with this.
    Corey> But it could be a great thing.

    Yes, it would be absolutely brilliant. And entirely within the realm
    of doable. Less than a year of work, I'd estimate.

    Corey> And yes, I have thought about this before.

    The whole concept, esp. as far as object oriented desktop goes, has
    been rehashed several times over. All these projects tend to fail
    because programmability has not been there. You have always needed a
    professional to implement some of the objects for the desktop, and as
    a result there really hasn't been many of such objects around. With
    the programmability of python, it will be trivial for a 13-year old to
    do the following:

    class MyOggEncoder:
    def __init__(self):
    self.files = []
    self.encoded = []

    [accepts(WavFile)]
    def accept(self,wav):
    self.files.append(file)

    [tooltip("Starts encoding the files"),
    needthread]
    def go(self):
    for f in self.files:
    oggname = getuniquefilename()
    os.system("oggenc -o %s %s" % (oggname, f.filename()))
    self.encoded.append(OggFile(oggname))

    # show a pretty balloon on the object
    desktop.notify(self, "I've completed encoding!")



    Then the user can just drag the wav files to an instantiated
    MyOggEncoder, select "go" from popup menu, and the encoding will start
    in its own thread.

    After the encoding is done, you just double click the object, double
    click the "encoded" attribute, to see the contents of "encoded" list
    which is a bunch of ogg files. Then they are just dragged to the
    target folder, selecting an "move as normal files" option which copies
    the ogg files to the target folder, stripping all objectness.

    --
    Ville Vainio http://tinyurl.com/2prnb
     
    Ville Vainio, Jul 1, 2004
    #11
  12. Yeah, you bring up some good points, but at the very least, object
    browsing and hierarchy will be a key feature in the system, so that
    should be thought out pretty thoroughly. I suspect it could get kind
    of confusing for people switching between the object system and the
    file system. If all objects wind up becoming files in the back end,
    then people will start operating on the outside of the framework, and
    that probably wouldn't be good, and if they're all in a database (like
    ZODB), then people will complain about interoperability, so it makes
    sense to define that line pretty strictly before you get too far into
    it. It sounds like you're leaning towards making every
    file-to-object and back transition explicit, which might make sense,
    as long as you can keep the conversion overhead fairly low. I suppose
    you could set it up so that all data objects that get brought in from
    a file get saved back to a file, and all the extra objects created in
    the python shell get stored in the database, with explicit hooks for
    taking certain objects and transforming them into external files. I'd
    hate to see the system try to save every object out to a file
    somewhere (imagine every string in a typical program having it's own
    separate file, ugh) but it does seem like you'd want certain objects
    sent out to disk, without a lot of explicit object saving overhead, if
    you really want full interoperability. It's probably going to wind up
    even more confusing than this,
    but I guess there will be issues like this in any system that bridges
    the two worlds. That's why it's often easier to imagine a full os,
    where you don't have the interoperability issues to deal with. Ah
    well, it's a step in the right direction, anyway.

    Ville Vainio <> wrote in message news:<>...
    > >>>>> "Corey" == Corey Coughlin <> writes:

    >
    > Corey> Actually, the last time somebody propsed writing a python
    > Corey> based OS, I had pretty much the same idea. The idea you
    > Corey> have currently looks good for a pure text environment, but
    > Corey> you may want to think about what enhancements would look
    > Corey> like as people add things like GUIs in the mix and see how
    > Corey> that works. I suppose it could wind up looking something
    > Corey> like a Naked Object framework, but it could go a lot of
    > Corey> different
    >
    > Yes, the Naked Objects thing (now that I know about it ;-) looks quite
    > similar to what I had in mind, but I get the feel that it's too
    > "heavyweight" to be used as general purpose operating environment
    > (a'la shell / file manager / bunch of scripts). It seems to be geared
    > towards focused cathedral style development, as opposed to the user
    > developing the system as he goes about using it (which is much more
    > realistic w/ Python than Java).
    >
    > Corey> ways. But in general, putting together an interactive
    > Corey> object based interface will probably lead you down the OS
    > Corey> optimization path. As
    >
    > I tend to think that Linux / Windows is the base to build on, and that
    > the software should work happily with the limitations of such systems
    > (file system & all). Without integration with the platform people
    > won't even try it, and it couldn't grow independent of the core
    > developers.
    >
    > Corey> main memory gets cluttered with objects, you'll want to
    > Corey> swap some back to disk, so you'll need some kind of virtual
    > Corey> memory system, and some way to store those objects on disk,
    > Corey> which implies an object file system, and once you start
    > Corey> screwing with file systems, you may as well get right into
    > Corey> the OS level. And that sounds like a vaguely good idea,
    >
    > Explicit persistence is IMO not a bad idea. If an object is in the
    > main memory, it's in the main memory (until paged out normally by the
    > OS). I'm not sure considering the object oriented nature of the data
    > would yield significant payoffs compared to typical paged virtual
    > memory implementations.
    >
    > Temporary data should be just that, temporary, so there would not be
    > that much in-memory objects. Mostly the objects you are working with
    > currently. Also, the actual valuable data should be stored in standard
    > files in sensible places. a Music object, for example, is probably
    > just an interface to manipulating an underlying .ogg file.
    >
    > Corey> experience. Generally, if the system works on a text
    > Corey> level, you'll definitely want to bring it into a gui
    > Corey> framework, and when people see a gui, they'll want to start
    >
    > Yes, GUI framework would definitely be cool. I'm thinking of a
    > nautilus-like view of the python in-memory namespace, where the
    > objects are shown in their natural representations. All the in-memory
    > objects could be dragged to another window, representing a persistent
    > object database, where they would be, well, persisted.
    >
    > Corey> to start thinking about more complicated standard types
    > Corey> above list and dict, like Picture, Document, Sound, Table,
    > Corey> and so on. Then make sure that creating these basic
    >
    > Things like Picture, Document etc. would be rather easy to implement -
    > just make sure that Path objects work (file names should be Path objs,
    > not strings), and create an object/system that autoconverts the path
    > to an object via which the file can offer richer operations (play,
    > print, etc).
    >
    > Corey> objects is fairly easy, then think about how scripting data
    > Corey> flow in and around these objects can be done, object
    >
    > Well, since they are Python objects, using Python to script the data
    > flow would seem optimal ;-).
    >
    >
    > Corey> Of course, this has certain implications, for a system like
    > Corey> this to interoperate with other normal file based systems,
    > Corey> you'll need automatic conversion of incoming and outgoing
    > Corey> files into your base
    >
    > As I said previously, I don't think files should be converted - all
    > the valuable data (i.e. data that can't be trivially derived from
    > other data) should still be as normal files.
    >
    > What is needed is
    >
    > 1. Have a global python "system image", consisting of objects in
    > memory and ones in persistent store.
    >
    > 2. Implement a special file type for file managers (which will then
    > act as object managers). Let's call it .object. Example contents of
    > .object files follows:
    >
    >
    > 5236253625362512.object: # (the name need not make any sense, user never sees it)
    > --------------------
    > memobject at 0x2326561 core version 675 class = 3274892347.object
    > --------------------
    >
    > 3274892347.object: # this is the class object, in persistent store
    > --------------------
    > persistentobject #5612 database /srv/coredb1 version 34
    > --------------------
    >
    > 475847845.object
    > --------------------
    > instantiate myutils.OCREngine version 432 # or perhaps version HEAD?
    > --------------------
    >
    >
    > When the file manager starts to render the directory, it sees the
    > .object file and reads the contents, rendering the object as
    > appropriate (reading it either from the memory or object
    > database). Version numbers would guarantee that no objects in core
    > which is dead (after reboot) would be rendered.
    >
    > This all would of course mean that Nautilus/whatever would be in the
    > same address space as the python core.
    >
    > Corey> wouldn't go too crazy coloring outside the lines with this.
    > Corey> But it could be a great thing.
    >
    > Yes, it would be absolutely brilliant. And entirely within the realm
    > of doable. Less than a year of work, I'd estimate.
    >
    > Corey> And yes, I have thought about this before.
    >
    > The whole concept, esp. as far as object oriented desktop goes, has
    > been rehashed several times over. All these projects tend to fail
    > because programmability has not been there. You have always needed a
    > professional to implement some of the objects for the desktop, and as
    > a result there really hasn't been many of such objects around. With
    > the programmability of python, it will be trivial for a 13-year old to
    > do the following:
    >
    > class MyOggEncoder:
    > def __init__(self):
    > self.files = []
    > self.encoded = []
    >
    > [accepts(WavFile)]
    > def accept(self,wav):
    > self.files.append(file)
    >
    > [tooltip("Starts encoding the files"),
    > needthread]
    > def go(self):
    > for f in self.files:
    > oggname = getuniquefilename()
    > os.system("oggenc -o %s %s" % (oggname, f.filename()))
    > self.encoded.append(OggFile(oggname))
    >
    > # show a pretty balloon on the object
    > desktop.notify(self, "I've completed encoding!")
    >
    >
    >
    > Then the user can just drag the wav files to an instantiated
    > MyOggEncoder, select "go" from popup menu, and the encoding will start
    > in its own thread.
    >
    > After the encoding is done, you just double click the object, double
    > click the "encoded" attribute, to see the contents of "encoded" list
    > which is a bunch of ogg files. Then they are just dragged to the
    > target folder, selecting an "move as normal files" option which copies
    > the ogg files to the target folder, stripping all objectness.
     
    Corey Coughlin, Jul 1, 2004
    #12
  13. Ville Vainio

    Steve Guest

    Re: Pythonic Nirvana - towards a true Object Oriented Environment[visionary rambling, long]

    Ville Vainio wrote:

    > Why do we write simple scripts to do simple things?


    Because building complicated programs to do simple
    things is a bad idea?

    > Why do we serialize data to flat text files
    > in order to process them?


    Because it is a tried and tested method that works?

    Because flat text files are human readable, which is a
    huge advantage in the real world? (Just contrast the
    voodoo of the Registry in the Windows world with simple
    text-based config files under Linux.)

    > Everything
    > could be so much simpler and immensely more powerful


    More powerful, maybe. Simpler, no. A Python script
    might be simpler than the equivalent assembly code that
    does the same thing, but when you include the
    complexity of the Python framework vs the assembler, it
    is far more complex.

    Likewise, under your system, you are merely shifting
    the complexity from the script to the operating system.
    Overall, you should expect a great *increase* in
    complexity, not a decrease.

    Which *might* very well mean more OS bugs, hacks and
    cracks. Exploits in your script will only affect you;
    exploits in the OS will affect everyone. The comparison
    between Windows and Linux is so obvious that you should
    already be thinking it :)


    --
    Steven
     
    Steve, Jul 2, 2004
    #13
  14. Ville Vainio

    Ville Vainio Guest

    >>>>> "Steve" == Steve <> writes:

    Steve> Ville Vainio wrote:
    >> Why do we write simple scripts to do simple things?


    Steve> Because building complicated programs to do simple things
    Steve> is a bad idea?

    Of course, the idea is to write even simpler *functions* to do the
    things. Even a simple script is much more complex than a simple
    function that can access the data directly.


    >> Why do we serialize data to flat text files
    >> in order to process them?


    Steve> Because it is a tried and tested method that works?

    I guess so was using flintstone to set up a fire :).

    Steve> Because flat text files are human readable, which is a huge
    Steve> advantage in the real world? (Just contrast the voodoo of

    But so is a pretty-printed python data structure. Flat text file
    breaks up as a solution when the data is not flat anymore.

    Steve> More powerful, maybe. Simpler, no. A Python script might be
    Steve> simpler than the equivalent assembly code that does the
    Steve> same thing, but when you include the complexity of the
    Steve> Python framework vs the assembler, it is far more complex.

    Isn't the general idea to shift complexity away from users to the
    things written by "someone else"?

    Steve> Which *might* very well mean more OS bugs, hacks and
    Steve> cracks. Exploits in your script will only affect you;
    Steve> exploits in the OS will affect everyone. The comparison
    Steve> between Windows and Linux is so obvious that you should
    Steve> already be thinking it :)

    Needless replication of the code in the name of diversifying the
    system (and therefore improving the security through
    security-through-not-being-worthy-of-cracking) is really not the
    optimal path IMHO. Common frameworks and shared code are still
    fundamentally good things. Paranoid users just need to validate the
    data they are about to process, as always.

    I'll readily admit that highly integrated system would make it easy to
    implement some very sneaky trojans that log the data flow of other
    users (if they share the code). However, once you allow malicious code
    to be installed on your hard disk, you are screwed anyway.

    And as far the OS-ness goes - kernel and all the command line programs
    could (and should) stay. It's the user-interaction stuff like shell
    and GUIs that would benefit from the integration. Think of the
    functionality like am extra gear that you can switch to when you would
    otherwise implement non-trivial shell pipelines or a proper python
    script.

    --
    Ville Vainio http://tinyurl.com/2prnb
     
    Ville Vainio, Jul 2, 2004
    #14
  15. Ville Vainio

    Aahz Guest

    In article <>,
    Ville Vainio <> wrote:
    >
    >Why do we write simple scripts to do simple things? Why do we
    >serialize data to flat text files in order to process them?


    Read _The Pragmatic Programmer_ for a good explanation of why text
    files.
    --
    Aahz () <*> http://www.pythoncraft.com/

    "Typing is cheap. Thinking is expensive." --Roy Smith, c.l.py
     
    Aahz, Jul 3, 2004
    #15
  16. Ville Vainio

    Ville Vainio Guest

    >>>>> "Aahz" == Aahz <> writes:

    Aahz> Read _The Pragmatic Programmer_ for a good explanation of
    Aahz> why text files.

    I'm perfectly aware of the virtues of text files - transparency
    etc. The problem are flat text files when the data is not flat.

    --
    Ville Vainio http://tinyurl.com/2prnb
     
    Ville Vainio, Jul 4, 2004
    #16
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Peter Dunker

    check if char* is a ptr to mem or nirvana

    Peter Dunker, Apr 21, 2004, in forum: C Programming
    Replies:
    6
    Views:
    405
    Stephen Sprunk
    Apr 23, 2004
  2. Carl J. Van Arsdall
    Replies:
    4
    Views:
    502
    Bruno Desthuilliers
    Feb 7, 2006
  3. Replies:
    2
    Views:
    433
    Bruno Desthuilliers
    May 26, 2008
  4. bdb112
    Replies:
    45
    Views:
    1,349
    jazbees
    Apr 29, 2009
  5. rolo
    Replies:
    3
    Views:
    175
    Robert Klemme
    Apr 9, 2004
Loading...

Share This Page