[Fwd: Re: [Uuu-devel] languages] <-- Why Python

Discussion in 'Python' started by Arich Chanachai, Feb 17, 2005.

  1. I consider this to be a good question. I just started to learn Python
    and I like it. I don't know about Lisp however...

    The problem, IMHO, in creating a new language is that we are losing code
    reusability... we will be able to port python applications very easily...

    I don't have a clear idea on this, but I'm sticking to Python until someone
    decides to replace it ;-)

    ----- Original Message -----
    From: "Richard Taytor" <>
    To: <>
    Sent: Thursday, February 17, 2005 4:28 PM
    Subject: [Uuu-devel] languages


    > First, thank you for Unununium. I first learned of the project years ago
    > and I'm happy to see it is alive and well.
    >
    > I'm curious: For the same reasons cited for using Python, why not use
    > Lisp? I understand that Python is more popular/pervasive, but if reducing
    > the cognitive load on the programmers, increasing the elegance and
    > efficiency between programmer and code, &c., is of primary concern, Lisp
    > (or as mentioned in the documentation, creating a new language) seems a
    > better choice (as it appears to me). What do you think?
    >
    > _______________________________________________
    > Uuu-devel mailing list
    >
    > http://unununium.org/cgi-bin/mailman/listinfo/uuu-devel



    _______________________________________________
    Uuu-devel mailing list

    http://unununium.org/cgi-bin/mailman/listinfo/uuu-devel
     
    Arich Chanachai, Feb 17, 2005
    #1
    1. Advertising

  2. Re: [Fwd: Re: [Uuu-devel] languages] <-- Why Python

    Some quick thoughts.

    1- Python is not new relatively speaking.

    2)- Python is a natural language for learning basic scripting, but can
    carry you through to object oriented program.

    3)- Knowing python, instantly gets you access to jython. I've found
    jython incredibly helpful in learning java. Finally, jython seems to
    be the defacto test scripting language for java.

    Cheers.
     
    pythonUser_07, Feb 17, 2005
    #2
    1. Advertising

  3. Re: [Fwd: Re: [Uuu-devel] languages] <-- Why Python

    pythonUser_07 wrote:

    >Some quick thoughts.
    >
    >1- Python is not new relatively speaking.
    >
    >

    Quite true, good point.

    >2)- Python is a natural language for learning basic scripting, but can
    >carry you through to object oriented program.
    >
    >3)- Knowing python, instantly gets you access to jython. I've found
    >jython incredibly helpful in learning java. Finally, jython seems to
    >be the defacto test scripting language for java.
    >
    >Cheers.
    >
    >
    >

    These last two points kind of diverge from the point, no? What I mean
    is that we want to present the argument of why Python is the best choice
    as THE built-in programming language for the revolutionary uuu operating
    system. Unless Java becomes built-in, the ability to transition from
    Python to Jython isn't pertinent info when talking about the uuu
    project. The idea is to have an easily maintainable (hence readable) OS
    core of functionality built with Python and to support advanced yet
    clean and simple modules which can run on the OS with support from the
    ground-up.

    On the other hand, are you suggesting against Python in favor of Java?

    - Arich
     
    Arich Chanachai, Feb 17, 2005
    #3
  4. Re: [Fwd: Re: [Uuu-devel] languages] <-- Why Python

    I see your point.

    Consider points 2 and 3 a nice side effect.

    The language I favor actually ties into the environment I am working
    in: Python for rapid prototyping, java for larger projects where the
    eclipse IDE comes in very handy.
     
    pythonUser_07, Feb 17, 2005
    #4
  5. Arich Chanachai

    Mike Meyer Guest

    Re: [Fwd: Re: [Uuu-devel] languages] <-- Why Python

    Arich Chanachai <> writes:

    > These last two points kind of diverge from the point, no? What I mean
    > is that we want to present the argument of why Python is the best
    > choice as THE built-in programming language for the revolutionary uuu
    > operating system.


    A new operating system shouldn't be picking "THE" built-in programming
    language. It should instead be providing mechanisms to allow arbitrary
    programming languages to be used wherever they are required. Tying the
    users of the OS - or of some application - down to a specific language
    is a disservice to the developers and users of that OS or application.

    While Python is an excellent language, and has a nice implementation
    for embedding/extending applications, it's not necessarily the best
    choice for all problems. You're be doing much better for your users to
    allow them to choose the right language for the problem than to
    dictate the language that has to be used.

    <mike
    --
    Mike Meyer <> http://www.mired.org/home/mwm/
    Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.
     
    Mike Meyer, Feb 18, 2005
    #5
  6. Re: [Fwd: Re: [Uuu-devel] languages] <-- Why Python

    Mike Meyer wrote:

    >Arich Chanachai <> writes:
    >
    >
    >
    >>These last two points kind of diverge from the point, no? What I mean
    >>is that we want to present the argument of why Python is the best
    >>choice as THE built-in programming language for the revolutionary uuu
    >>operating system.
    >>
    >>

    >
    >A new operating system shouldn't be picking "THE" built-in programming
    >language. It should instead be providing mechanisms to allow arbitrary
    >programming languages to be used wherever they are required. Tying the
    >users of the OS - or of some application - down to a specific language
    >is a disservice to the developers and users of that OS or application.
    >
    >While Python is an excellent language, and has a nice implementation
    >for embedding/extending applications, it's not necessarily the best
    >choice for all problems. You're be doing much better for your users to
    >allow them to choose the right language for the problem than to
    >dictate the language that has to be used.
    >
    > <mike
    >
    >

    There is no intention to dictate, but instead to provide out-of-the-box,
    built-into-the-architecture support for a single language or a wide
    array of languages. For now, this will begin with a single language and
    the question is merely which one. Python has been chosen, but some
    would argue that others are a better choice, such as Lisp. In the
    future, or whenever someone steps up to the plate, support for the CLR
    will be implemented, thus broadening the array of integrally supported
    programming languages (i.e IronPython, Boo, and so forth).
     
    Arich Chanachai, Feb 18, 2005
    #6
  7. Arich Chanachai

    Mike Meyer Guest

    Re: [Fwd: Re: [Uuu-devel] languages] <-- Why Python

    Arich Chanachai <> writes:
    > Mike Meyer wrote:
    >>Arich Chanachai <> writes:
    >>>These last two points kind of diverge from the point, no? What I mean
    >>>is that we want to present the argument of why Python is the best
    >>>choice as THE built-in programming language for the revolutionary uuu
    >>>operating system.

    >>
    >>A new operating system shouldn't be picking "THE" built-in programming
    >>language. It should instead be providing mechanisms to allow arbitrary
    >>programming languages to be used wherever they are required. Tying the
    >>users of the OS - or of some application - down to a specific language
    >>is a disservice to the developers and users of that OS or application.
    >>
    >>While Python is an excellent language, and has a nice implementation
    >>for embedding/extending applications, it's not necessarily the best
    >>choice for all problems. You're be doing much better for your users to
    >>allow them to choose the right language for the problem than to
    >>dictate the language that has to be used.
    >>

    > There is no intention to dictate, but instead to provide
    > out-of-the-box, built-into-the-architecture support for a single
    > language or a wide array of languages. For now, this will begin with
    > a single language and the question is merely which one.


    Whatever the intentions may be, the *act* is one of dictation. Since
    the point of the underlying OS is to increase the interconnections
    between applications (assuming I've found the correct web page and
    interpreted it correctly), the underlying architecture should be
    language-neutral. That allows as many applications as possible to play
    in the environment.

    I did this with CORBA (see http://www.mired.org/home/mwm/scripting/ )
    just to show that Unix can play in this arena as well as various
    desktop OS's. Plan 9 provides a much better mechanism that allows any
    programming language that can do file I/O to be used for building
    interconnections.

    <mike
    --
    Mike Meyer <> http://www.mired.org/home/mwm/
    Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.
     
    Mike Meyer, Feb 18, 2005
    #7
  8. Re: [Fwd: Re: [Uuu-devel] languages] <-- Why Python

    Mike Meyer wrote:

    >Arich Chanachai <> writes:
    >
    >
    >>Mike Meyer wrote:
    >>
    >>
    >>>Arich Chanachai <> writes:
    >>>
    >>>
    >>>>These last two points kind of diverge from the point, no? What I mean
    >>>>is that we want to present the argument of why Python is the best
    >>>>choice as THE built-in programming language for the revolutionary uuu
    >>>>operating system.
    >>>>
    >>>>
    >>>A new operating system shouldn't be picking "THE" built-in programming
    >>>language. It should instead be providing mechanisms to allow arbitrary
    >>>programming languages to be used wherever they are required. Tying the
    >>>users of the OS - or of some application - down to a specific language
    >>>is a disservice to the developers and users of that OS or application.
    >>>
    >>>While Python is an excellent language, and has a nice implementation
    >>>for embedding/extending applications, it's not necessarily the best
    >>>choice for all problems. You're be doing much better for your users to
    >>>allow them to choose the right language for the problem than to
    >>>dictate the language that has to be used.
    >>>
    >>>
    >>>

    >>There is no intention to dictate, but instead to provide
    >>out-of-the-box, built-into-the-architecture support for a single
    >>language or a wide array of languages. For now, this will begin with
    >>a single language and the question is merely which one.
    >>
    >>

    >
    >Whatever the intentions may be, the *act* is one of dictation. Since
    >the point of the underlying OS is to increase the interconnections
    >between applications (assuming I've found the correct web page and
    >interpreted it correctly), the underlying architecture should be
    >language-neutral. That allows as many applications as possible to play
    >in the environment.
    >
    >I did this with CORBA (see http://www.mired.org/home/mwm/scripting/ )
    >just to show that Unix can play in this arena as well as various
    >desktop OS's. Plan 9 provides a much better mechanism that allows any
    >programming language that can do file I/O to be used for building
    >interconnections.
    >
    > <mike
    >
    >

    When the CLR is integrated, it will allow a wide array of problem
    solving choices for uuu users.
     
    Arich Chanachai, Feb 18, 2005
    #8
  9. Arich Chanachai

    Ville Vainio Guest

    >>>>> "Arich" == Arich Chanachai <> writes:

    Arich> From: "Richard Taytor" <>
    Arich> To: <>
    Arich> Sent: Thursday, February 17, 2005 4:28 PM
    Arich> Subject: [Uuu-devel] languages


    >> First, thank you for Unununium. I first learned of the project
    >> years ago and I'm happy to see it is alive and well.
    >>
    >> I'm curious: For the same reasons cited for using Python, why
    >> not use Lisp? I understand that Python is more
    >> popular/pervasive, but if reducing the cognitive load on the
    >> programmers, increasing the elegance and efficiency between
    >> programmer and code, &c., is of primary concern, Lisp (or as
    >> mentioned in the documentation, creating a new language) seems
    >> a better choice (as it appears to me). What do you think?


    Essentially this seems like advocacy material for Lisp (doesn't seem
    to address any UUU-specific issues, just claims that Lisp is "better"
    than Python), and should be treated as such. Go googling for heaps of
    Python vs. Lisp material.

    Go ahead and learn Lisp - I guess you'll quickly realize that
    perfectly rational people may well choose Python for reasons other
    than "not knowing Lisp".

    --
    Ville Vainio http://tinyurl.com/2prnb
     
    Ville Vainio, Feb 18, 2005
    #9
  10. Arich Chanachai

    Mike Meyer Guest

    Re: [Fwd: Re: [Uuu-devel] languages] <-- Why Python

    Arich Chanachai <> writes:

    > Mike Meyer wrote:
    >>Whatever the intentions may be, the *act* is one of dictation. Since
    >>the point of the underlying OS is to increase the interconnections
    >>between applications (assuming I've found the correct web page and
    >>interpreted it correctly), the underlying architecture should be
    >>language-neutral. That allows as many applications as possible to play
    >>in the environment.
    >>

    > When the CLR is integrated, it will allow a wide array of problem
    > solving choices for uuu users.


    You've missed the point. Allowing a wide array of problem solving
    choices is a goal, not a means. Instead of concentrating on adding
    langauges, you should be provding an infrastructure that makes adding
    langauges simple. The Plan 9 example does this best, as any language
    that can do file I/O is supported.

    It may be that CLR is just such an infrastructure (I'm not familiar
    with it). In that case, instead of pushing Python, you should be
    pushing CLR with IronPython as an option.

    <mike
    --
    Mike Meyer <> http://www.mired.org/home/mwm/
    Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.
     
    Mike Meyer, Feb 18, 2005
    #10
  11. Arich Chanachai

    Nick Coghlan Guest

    Re: [Fwd: Re: [Uuu-devel] languages] <-- Why Python

    Mike Meyer wrote:
    > Arich Chanachai <> writes:
    >
    >
    >>Mike Meyer wrote:
    >>
    >>>Whatever the intentions may be, the *act* is one of dictation. Since
    >>>the point of the underlying OS is to increase the interconnections
    >>>between applications (assuming I've found the correct web page and
    >>>interpreted it correctly), the underlying architecture should be
    >>>language-neutral. That allows as many applications as possible to play
    >>>in the environment.


    *Allowing* other languages is one thing, but that shouldn't preclude having a
    'default' language. On other OS's, the default language is some form of shell
    scripting (i.e. Unix shell scripts, or Windows batch files). It would be good to
    have a real language to fill that role.

    > You've missed the point. Allowing a wide array of problem solving
    > choices is a goal, not a means. Instead of concentrating on adding
    > langauges, you should be provding an infrastructure that makes adding
    > langauges simple. The Plan 9 example does this best, as any language
    > that can do file I/O is supported.


    Still, the builtin shell is going to need *some* form of scripting support. And
    if that looks like IPython's shell mode, so much the better.

    Anyway, the reason to prefer Python to LISP for something like this, is that
    Python reads much more naturally for most people, whereas LISP requires that you
    write things 'out of order'.

    Compare out-of-the-box Python:
    a = 1 + 2 + 3 + 4

    And out-of-the-box Lisp:
    (setq a (+ 1 2 3 4))

    Which language has the lower barrier for entry? That should be a fairly
    important consideration for a language that is going to sit at the heart of an OS.

    Cheers,
    Nick.

    --
    Nick Coghlan | | Brisbane, Australia
    ---------------------------------------------------------------
    http://boredomandlaziness.skystorm.net
     
    Nick Coghlan, Feb 20, 2005
    #11
  12. Arich Chanachai

    Paul Rubin Guest

    Re: [Fwd: Re: [Uuu-devel] languages] <-- Why Python

    Nick Coghlan <> writes:
    > Compare out-of-the-box Python:
    > a = 1 + 2 + 3 + 4
    >
    > And out-of-the-box Lisp:
    > (setq a (+ 1 2 3 4))
    >
    > Which language has the lower barrier for entry? That should be a
    > fairly important consideration for a language that is going to sit at
    > the heart of an OS.


    Huh? Why does mucking about in the heart of an OS need a low barrier
    of entry?
     
    Paul Rubin, Feb 20, 2005
    #12
  13. Arich Chanachai

    Nick Coghlan Guest

    Re: [Fwd: Re: [Uuu-devel] languages] <-- Why Python

    Paul Rubin wrote:
    > Nick Coghlan <> writes:
    >
    >>Compare out-of-the-box Python:
    >> a = 1 + 2 + 3 + 4
    >>
    >>And out-of-the-box Lisp:
    >> (setq a (+ 1 2 3 4))
    >>
    >>Which language has the lower barrier for entry? That should be a
    >>fairly important consideration for a language that is going to sit at
    >>the heart of an OS.

    >
    >
    > Huh? Why does mucking about in the heart of an OS need a low barrier
    > of entry?


    It doesn't. I was looking at it from the point of view of *scripting* the OS -
    which *should* have a low barrier for entry :)

    Cheers,
    Nick.

    --
    Nick Coghlan | | Brisbane, Australia
    ---------------------------------------------------------------
    http://boredomandlaziness.skystorm.net
     
    Nick Coghlan, Feb 20, 2005
    #13
  14. Arich Chanachai

    Donn Cave Guest

    Re: [Fwd: Re: [Uuu-devel] languages] <-- Why Python

    Quoth Nick Coghlan <>:
    [... re Python OS interface vs. language-generic model ]

    | *Allowing* other languages is one thing, but that shouldn't preclude having a
    | 'default' language. On other OS's, the default language is some form of shell
    | scripting (i.e. Unix shell scripts, or Windows batch files). It would be good to
    | have a real language to fill that role.

    I don't know what the Windows version is like, but for all the UNIX
    shell's weaknesses, it's very well suited to its role. The Plan 9
    shell (rc) is similar with much improved syntax, and has a distant
    relative "es" that I think is the closest thing I've ever seen to
    a 1st class language that works as a shell (though the implementation
    was only at the proof of concept level.) (I'm not forgetting REXX,
    it's a fairly respectable effort but not 1st class.)

    ....
    | Still, the builtin shell is going to need *some* form of scripting support. An
    | if that looks like IPython's shell mode, so much the better.
    |
    | Anyway, the reason to prefer Python to LISP for something like this, is that
    | Python reads much more naturally for most people, whereas LISP requires that y
    | write things 'out of order'.
    |
    | Compare out-of-the-box Python:
    | a = 1 + 2 + 3 + 4
    |
    | And out-of-the-box Lisp:
    | (setq a (+ 1 2 3 4))
    |
    | Which language has the lower barrier for entry? That should be a fairly
    | important consideration for a language that is going to sit at the heart of an OS.

    Well, honestly I think that's stretching it. Your order issue here
    seems to apply only to operators, and they don't really figure that
    heavily in the kinds of things we normally do with the OS. The only
    operator I can think of in "rc" is ^, an odd sort of string multiplication
    thing, and I can't think of any in the original Bourne shell.

    Meanwhile, the idea that barriers to entry are built out of things like
    "+ 1 2 3 4" vs. "1 + 2 + 3 + 4" is really quite open to question.

    10 years ago when BeOS was a little hotter than it is today, there were
    a couple enthusiasts pushing Python as an official language. A few of
    the people following BeOS at that point had come from a strong Amiga
    background, and I remember one of them arguing vehemently against Python
    because its arcane, complicated syntax was totally unsuited to casual use.
    Compared to, say, REXX.

    Now, we Python users know very well that's not true, Python's as clear
    as could be. But theoretically, if you wanted to talk about order
    issues, for example ... is it really easier to understand when a language
    sometimes expresses a function f over x and y this way
    f(x, y)
    sometimes this way (+ is a function, really)
    x f y
    and sometimes this way
    x.f(y)
    ?

    I don't know, I'm just thinking that while Python's notation might
    be just fine for people who've gotten here the way most of us have,
    it's not obvious from this that it's just fine 4 everyone.

    Donn Cave,
     
    Donn Cave, Feb 20, 2005
    #14
  15. Arich Chanachai

    Paul Boddie Guest

    Re: [Fwd: Re: [Uuu-devel] languages] <-- Why Python

    Mike Meyer <> wrote in message news:<>...
    > Arich Chanachai <> writes:
    >
    > > When the CLR is integrated, it will allow a wide array of problem
    > > solving choices for uuu users.

    >
    > You've missed the point. Allowing a wide array of problem solving
    > choices is a goal, not a means. Instead of concentrating on adding
    > langauges, you should be provding an infrastructure that makes adding
    > langauges simple. The Plan 9 example does this best, as any language
    > that can do file I/O is supported.


    This discussion collides quite nicely with two of the more quoted
    articles on software development:

    http://primates.ximian.com/~miguel/bongo-bong.html
    http://www.jwz.org/doc/groupware.html

    The first of which eventually addresses the issue of how programs
    communicate with the operating system services and each other,
    although I'm sure I've seen a more succinct overview from Mr De Icaza
    on that subject. The second brings up the topic of making things
    "enterprise-ready" - probably one of the more popular motivations for
    introducing something like the CLR into a project which doesn't
    necessarily need it and isn't yet familiar with it.

    From what I've seen of Unununium, the motivation for using Python
    seems to stem from the way Python's runtime system provides services
    which overlap with those of an operating system; programs can
    dynamically import code, inspect the properties of such code, and
    invoke such code reasonably safely (as opposed to the "jump to this
    memory address" model of lower-level runtime systems), although these
    features are not unique to Python - the Erlang runtime system is
    apparently designed for use at this level, and the Java environment
    (and presumably the CLR) provides introspection and dynamic loading
    capabilities. I would also imagine that the development of Lisp
    operating systems and environments was similarly motivated.

    In contrast, the standard UNIX model of interprocess communication and
    introspection, extended substantially by Plan 9 and more
    conservatively by modern UNIX variants, is said to leave something to
    be desired, and those wishing more informative details about the
    interfaces exposed by programs and services usually end up putting
    something more complicated on top - see the emergence of Bonobo, DCOP
    and D-BUS.

    Paul
     
    Paul Boddie, Feb 20, 2005
    #15
  16. Arich Chanachai

    Ville Vainio Guest

    Re: [Fwd: Re: [Uuu-devel] languages] <-- Why Python

    >>>>> "Donn" == Donn Cave <> writes:

    Donn> I don't know what the Windows version is like, but for all
    Donn> the UNIX shell's weaknesses, it's very well suited to its
    Donn> role. The Plan 9

    I don't know about that - I don't see anything in shell that couldn't
    be done better in Python (well, launching subshells perhaps, and the
    smaller size == faster launch). The Windows incarnation is obviously
    so horrible that it hardly deserves mention, but the scripts done with
    unix shell also always have this "hackish" flavour.

    (I'm aware that this is an unpopular opinion that is likely to collect
    some flames, but some people never learn ;-).


    Donn> shell (rc) is similar with much improved syntax, and has a
    Donn> distant relative "es" that I think is the closest thing I've
    Donn> ever seen to a 1st class language that works as a shell

    I assume you've tried IPython ('ipython -p pysh')? I just apt-getted
    es and it seems to be like ipython, only for scheme.

    Donn> Well, honestly I think that's stretching it. Your order
    Donn> issue here seems to apply only to operators, and they don't
    Donn> really figure that heavily in the kinds of things we
    Donn> normally do with the OS. The only

    I think they do - summing sets of files, adding extensions to
    filenames, etc.

    Donn> Now, we Python users know very well that's not true, Python's as clear
    Donn> as could be. But theoretically, if you wanted to talk about order
    Donn> issues, for example ... is it really easier to understand when a language
    Donn> sometimes expresses a function f over x and y this way
    Donn> f(x, y)
    Donn> sometimes this way (+ is a function, really)
    Donn> x f y
    Donn> and sometimes this way
    Donn> x.f(y)
    Donn> ?

    Yes - operators like + and - are very intuitive to everybody. Having
    only one way to call functions is more orthogonal and "cleaner" in a
    theoretical sense, but noi in practical sense.

    Donn> I don't know, I'm just thinking that while Python's notation
    Donn> might be just fine for people who've gotten here the way
    Donn> most of us have, it's not obvious from this that it's just
    Donn> fine 4 everyone.

    Perhaps not for everyone but for the majority I guess the python
    notation would be more suitable.

    --
    Ville Vainio http://tinyurl.com/2prnb
     
    Ville Vainio, Feb 20, 2005
    #16
  17. Arich Chanachai

    Mike Meyer Guest

    Re: [Fwd: Re: [Uuu-devel] languages] <-- Why Python

    Nick Coghlan <> writes:

    > Mike Meyer wrote:
    >> Arich Chanachai <> writes:
    >>
    >>>Mike Meyer wrote:
    >>>
    >>>>Whatever the intentions may be, the *act* is one of dictation. Since
    >>>>the point of the underlying OS is to increase the interconnections
    >>>>between applications (assuming I've found the correct web page and
    >>>>interpreted it correctly), the underlying architecture should be
    >>>>language-neutral. That allows as many applications as possible to play
    >>>>in the environment.

    >
    > *Allowing* other languages is one thing, but that shouldn't preclude
    > having a 'default' language. On other OS's, the default language is
    > some form of shell scripting (i.e. Unix shell scripts, or Windows
    > batch files). It would be good to have a real language to fill that
    > role.


    Um - I'd say Unix has no default language. Traditional Eunices come
    with a nice selection of languages (sh, awk, sed, C), and modern ones
    include more (C++, Perl, Python, Ruby, Lua). Tagging one as the
    "default" does a disservice to the other languages, and to the OS as a
    whole.

    For that matter, I'd say that these days the default on Windows is VB,
    unless there are hooks to talk to COM from batch files, since COM is
    the standard scripting mechanism on Windows. Note that by providing a
    scripting mechanism instead of a scripting language, you can script
    applications with Python as or more easily than you can script them
    with the MS provided solution of VB.

    >> You've missed the point. Allowing a wide array of problem solving
    >> choices is a goal, not a means. Instead of concentrating on adding
    >> langauges, you should be provding an infrastructure that makes adding
    >> langauges simple. The Plan 9 example does this best, as any language
    >> that can do file I/O is supported.

    > Still, the builtin shell is going to need *some* form of scripting
    > support. And if that looks like IPython's shell mode, so much the
    > better.


    Scripting support shouldn't "look like" a language, it should look
    like a mechanism for hooking languages up to the system being
    scripted. Shells are a particularly easy hookup, as they have only
    three types of objects to deal with - commands, command results, and
    text streams. Any language which lets you invoke commands and
    manipulate the results of those commands and text streams is
    sufficient for shell scripting.

    IPython's pysh seems a little clumsy for interactive use, as it
    requires special characters to distinguish between commands to be
    passed to the shell and commands to be passed to the scripting
    language. This should be contrasted with languages designed for
    working in a command environment, like Rexx, sh and rc.

    > Anyway, the reason to prefer Python to LISP for something like this,
    > is that Python reads much more naturally for most people, whereas LISP
    > requires that you write things 'out of order'.


    I'll say it again - if you're arguing about which language to use,
    you're arguing about the wrong thing.

    <mike
    --
    Mike Meyer <> http://www.mired.org/home/mwm/
    Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.
     
    Mike Meyer, Feb 21, 2005
    #17
  18. Arich Chanachai

    Mike Meyer Guest

    Re: [Fwd: Re: [Uuu-devel] languages] <-- Why Python

    (Paul Boddie) writes:

    > Mike Meyer <> wrote in message news:<>...
    >> Arich Chanachai <> writes:
    >>
    >> > When the CLR is integrated, it will allow a wide array of problem
    >> > solving choices for uuu users.

    >>
    >> You've missed the point. Allowing a wide array of problem solving
    >> choices is a goal, not a means. Instead of concentrating on adding
    >> langauges, you should be provding an infrastructure that makes adding
    >> langauges simple. The Plan 9 example does this best, as any language
    >> that can do file I/O is supported.

    >
    > This discussion collides quite nicely with two of the more quoted
    > articles on software development:
    >
    > http://primates.ximian.com/~miguel/bongo-bong.html


    I've actually done some work on using CORBA as a COM for Unix (or, as
    I think of it, an ARexx for Unix). After being exposed to Plan 9, I've
    decided that's a better solution. CORBA has the advantage that you can
    work on it without getting buy-in from kernel vendors.

    > In contrast, the standard UNIX model of interprocess communication and
    > introspection, extended substantially by Plan 9 and more
    > conservatively by modern UNIX variants, is said to leave something to
    > be desired, and those wishing more informative details about the
    > interfaces exposed by programs and services usually end up putting
    > something more complicated on top - see the emergence of Bonobo, DCOP
    > and D-BUS.


    The crucial question isn't whether the underlying mechanism is
    complete, but whether it's sufficient. The underlying Unix facilities
    provide byte streams - because that's what Unix does. What that leaves
    to be desired is a standard high-level way for applications to
    interact with each other, passing back and forth things that are more
    complicated than byte streams. Having standars for these high-level
    objects allows for code reuse and data sharing. This is a good thing,
    and there's nothing inherently wrong with doing things this way.

    <mike
    --
    Mike Meyer <> http://www.mired.org/home/mwm/
    Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.
     
    Mike Meyer, Feb 21, 2005
    #18
  19. Arich Chanachai

    Ville Vainio Guest

    Re: [Fwd: Re: [Uuu-devel] languages] <-- Why Python

    >>>>> "Mike" == Mike Meyer <> writes:

    Mike> IPython's pysh seems a little clumsy for interactive use, as
    Mike> it requires special characters to distinguish between
    Mike> commands to be passed to the shell and commands to be passed
    Mike> to the scripting language. This should be contrasted with

    What do you mean by "the commands to be passed to the shell"? Commands
    on the path (the normal situation in Unix) can be executed directly
    just like in bash et al. Ditto for "magic" functions if "automagic" is
    on.

    I only use ! for calling commands that are in the current directory. A
    *real* deficiency with ipython/pysh under Linux is the lack of job
    control (in the sense that ^z suspends the whole ipython). I don't see
    why pysh would not be able to match and exceed the capabilities of
    shell in job control as well. It's not a priority for fperez himself
    ATM, but we'll see how easy it is to add shellish job control in the
    future after the refactoring...

    Mike> I'll say it again - if you're arguing about which language
    Mike> to use, you're arguing about the wrong thing.

    In a sense C is the native language of Unix and Windows (system calls
    are in C). It might make sense to expose the OS as Python objects.

    I work w/ Symbian OS in my day job, with the OS API in C++. I'm not
    sure whether it's a good idea or not, but at least some people are
    doing it :).

    --
    Ville Vainio http://tinyurl.com/2prnb
     
    Ville Vainio, Feb 21, 2005
    #19
  20. Arich Chanachai

    Ville Vainio Guest

    Re: [Fwd: Re: [Uuu-devel] languages] <-- Why Python

    >>>>> "Mike" == Mike Meyer <> writes:

    Mike> I've actually done some work on using CORBA as a COM for
    Mike> Unix (or, as I think of it, an ARexx for Unix). After being
    Mike> exposed to Plan 9, I've decided that's a better
    Mike> solution. CORBA has the advantage that you can work on it
    Mike> without getting buy-in from kernel vendors.

    The problem w/ CORBA is the alleged lack of speed. ISTR there was lots
    of controversy w/ the way Gnome used CORBA (Bonobo) and how it was too
    slow for Desktop apps. I don't know what the current status is - CORBA
    has always seemed more than fast enough for me.

    --
    Ville Vainio http://tinyurl.com/2prnb
     
    Ville Vainio, Feb 21, 2005
    #20
    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. Davide Carboni
    Replies:
    0
    Views:
    369
    Davide Carboni
    Dec 18, 2003
  2. Tristan Miller
    Replies:
    1
    Views:
    664
    Tristan Miller
    Jul 23, 2004
  3. Replies:
    2
    Views:
    373
    Michele Simionato
    Apr 4, 2005
  4. Mr. SweatyFinger
    Replies:
    2
    Views:
    2,078
    Smokey Grindel
    Dec 2, 2006
  5. goldtech
    Replies:
    2
    Views:
    632
    Stefan Behnel
    Nov 11, 2012
Loading...

Share This Page