By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
429,313 Members | 2,798 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 429,313 IT Pros & Developers. It's quick & easy.

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

P: n/a
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
Jul 18 '05 #1
Share this Question
Share on Google+
15 Replies


P: n/a
>>>>> "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
Jul 18 '05 #2

P: n/a
Ville Vainio <vi***@spammers.com> 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/
Jul 18 '05 #3

P: n/a
>>>>> "Jacek" == Jacek Generowicz <ja**************@cern.ch> 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
Jul 18 '05 #4

P: n/a
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...

...


Jul 18 '05 #5

P: n/a
>>>>> "Phil" == Phil Frost <in****@bitglue.com> 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
Jul 18 '05 #6

P: n/a
mjt
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

Jul 18 '05 #7

P: n/a
>>>>> "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
Jul 18 '05 #8

P: n/a
has
Ville Vainio <vi***@spammers.com> wrote in message news:<du*************@mozart.cc.tut.fi>...
Pythonic Nirvana - towards a true Object Oriented Environment


Try Squeak for ideas: http://www.squeak.org/
Jul 18 '05 #9

P: n/a
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 <vi***@spammers.com> wrote in message news:<du*************@mozart.cc.tut.fi>...
>> "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.

Jul 18 '05 #10

P: n/a
>>>>> "Corey" == Corey Coughlin <co************@attbi.com> 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
Jul 18 '05 #11

P: n/a
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 <vi***@spammers.com> wrote in message news:<du*************@mozart.cc.tut.fi>...
>> "Corey" == Corey Coughlin <co************@attbi.com> 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.

Jul 18 '05 #12

P: n/a
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
Jul 18 '05 #13

P: n/a
>>>>> "Steve" == Steve <di****@yahoo.com.au> 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
Jul 18 '05 #14

P: n/a
In article <du*************@mozart.cc.tut.fi>,
Ville Vainio <vi***@spammers.com> 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 (aa**@pythoncraft.com) <*> http://www.pythoncraft.com/

"Typing is cheap. Thinking is expensive." --Roy Smith, c.l.py
Jul 18 '05 #15

P: n/a
>>>>> "Aahz" == Aahz <aa**@pythoncraft.com> 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
Jul 18 '05 #16

This discussion thread is closed

Replies have been disabled for this discussion.