Re: Number of languages known [was Re: Python is readable] - somewhatOT

Discussion in 'Python' started by Chris Angelico, Mar 29, 2012.

  1. On Fri, Mar 30, 2012 at 12:44 AM, Nathan Rice
    <> wrote:
    > We would be better off if all the time that was spent on learning
    > syntax, memorizing library organization and becoming proficient with
    > new tools was spent learning the mathematics, logic and engineering
    > sciences.  Those solve problems, languages are just representations.


    Different languages are good at different things. REXX is an efficient
    text parser and command executor. Pike allows live updates of running
    code. Python promotes rapid development and simplicity. PHP makes it
    easy to add small amounts of scripting to otherwise-static HTML pages.
    C gives you all the power of assembly language with all the
    readability of... assembly language. SQL describes a database request.

    You can't merge all of them without making a language that's
    suboptimal at most of those tasks - probably, one that's woeful at all
    of them. I mention SQL because, even if you were to unify all
    programming languages, you'd still need other non-application
    languages to get the job done.

    Keep the diversity and let each language focus on what it's best at.

    ChrisA
    who has lots and lots of hammers, so every problem looks like... lots
    and lots of nails.
     
    Chris Angelico, Mar 29, 2012
    #1
    1. Advertising

  2. On Fri, Mar 30, 2012 at 2:48 AM, Steve Howell <> wrote:
    > I agree with you on the overall point, but I think that Python
    > actually does a fine job of replacing REXX and PHP.  I've used both of
    > the latter (and, of course, Python).  REXX and PHP are great at what
    > they do, but I don't think their slight advantages over Python justify
    > all the weight they carry--incompatible syntax to Python, archaic
    > libraries, missing modern language features, etc.


    I think you're probably right about REXX, mainly because it's somewhat
    old now. It was an awesome language when I first met it back in the
    1990s; it tied in very nicely with OS/2, it was (and is) easy to
    extend and embed with C, it had excellent GUI facilities (as long as
    you don't need it to be cross-platform). But today, REXX is somewhat
    outclassed. I don't recommend it to people for most tasks, unless
    they're actually on OS/2 (in which case they probably know it
    already). Unicode support and cross-platform GUI toolkits would
    probably be REXX's two biggest lacks.

    As to PHP? I don't think it's "great at what [it] [does]", frankly. At
    least, it's not great at what it's often used for. PHP is adequate as
    a "variant of HTML that allows scripting", but it's usually used today
    as though it were a CGI script, and for that it's less than optimal.
    For instance, you can't have an include file without it also being an
    entry point of its own (eg someone could go to
    http://www.example.com/common_functions.php), so you need code to
    protect against that. Huge frameworks have such code peppered
    throughout.

    (As a side point, I don't believe that a web server's CGI scripts
    should be updated simply by writing to the disk. It's pretty easy to
    get non-atomicity problems when you have a page and its include file.
    There ARE other options, but I don't know of any efficient ways to do
    it in Python.)

    > Python should also be a perfectly good superset of Bash Scripting
    > language.  (To the extent that Python isn't, there's nothing intrinsic
    > about the language that prevents you from orchestrating processes.)


    Hmm... How do you pipe one command's output into another's input using
    Python? It's not nearly as clean as it is in bash.

    > I think the problem these days is that the programmer's brain is like
    > a small toolbox.  Maybe twenty tools fit in the toolbox.  Instead of
    > filling it up with 20 useful tools, a lot of us have it cluttered up
    > with ten hammers, when only one of the hammers is what we need for the
    > nails.


    Maybe. But you can also have a little catalogue in there that reminds
    you of the tools you have in your shed. If you keep that catalogue up
    to date and accurate, you can hunt down those tools you seldom use
    when you need them.

    ChrisA
     
    Chris Angelico, Apr 2, 2012
    #2
    1. Advertising

  3. On Thu, 29 Mar 2012 08:48:53 -0700 (PDT), Steve Howell
    <> declaimed the following in
    gmane.comp.python.general:


    > I agree with you on the overall point, but I think that Python
    > actually does a fine job of replacing REXX and PHP. I've used both of
    > the latter (and, of course, Python). REXX and PHP are great at what
    > they do, but I don't think their slight advantages over Python justify
    > all the weight they carry--incompatible syntax to Python, archaic
    > libraries, missing modern language features, etc.
    >

    REXX is inhibited by the architectures to which it has been ported
    -- limiting the ADDRESS targets to variations of Python's os.system() or
    popen() calls; even the subprocess module can't get beyond the all or
    nothing execution model.

    Much different from the original IBM environment (and, biased, the
    Amiga implementation may have gone beyond the IBM one in capabilities)
    wherein compliant programs become the "command shell" for REXX command
    processing -- actual bidirectional interactive interprocess
    communication. Window's COM system offers some of that capability, but
    buried in a cryptic object programming system -- nothing like having a
    script sending the /same/ command that one would use in a text interface
    to the target program.
    --
    Wulfraed Dennis Lee Bieber AF6VN
    HTTP://wlfraed.home.netcom.com/
     
    Dennis Lee Bieber, Apr 2, 2012
    #3
  4. Chris Angelico

    Steve Howell Guest

    Re: Number of languages known [was Re: Python is readable] - somewhat OT

    On Apr 2, 2:50 pm, Chris Angelico <> wrote:
    > On Fri, Mar 30, 2012 at 2:48 AM, Steve Howell <> wrote:
    > > I agree with you on the overall point, but I think that Python
    > > actually does a fine job of replacing REXX and PHP.  I've used both of
    > > the latter (and, of course, Python).  REXX and PHP are great at what
    > > they do, but I don't think their slight advantages over Python justify
    > > all the weight they carry--incompatible syntax to Python, archaic
    > > libraries, missing modern language features, etc.

    >
    > I think you're probably right about REXX, mainly because it's somewhat
    > old now. It was an awesome language when I first met it back in the
    > 1990s; it tied in very nicely with OS/2, it was (and is) easy to
    > extend and embed with C, it had excellent GUI facilities (as long as
    > you don't need it to be cross-platform). But today, REXX is somewhat
    > outclassed. I don't recommend it to people for most tasks, unless
    > they're actually on OS/2 (in which case they probably know it
    > already). Unicode support and cross-platform GUI toolkits would
    > probably be REXX's two biggest lacks.
    >
    > As to PHP? I don't think it's "great at what [it] [does]", frankly. At
    > least, it's not great at what it's often used for. PHP is adequate as
    > a "variant of HTML that allows scripting", but it's usually used today
    > as though it were a CGI script, and for that it's less than optimal.
    > For instance, you can't have an include file without it also being an
    > entry point of its own (eg someone could go tohttp://www.example.com/common_functions.php), so you need code to
    > protect against that. Huge frameworks have such code peppered
    > throughout.
    >
    > (As a side point, I don't believe that a web server's CGI scripts
    > should be updated simply by writing to the disk. It's pretty easy to
    > get non-atomicity problems when you have a page and its include file.
    > There ARE other options, but I don't know of any efficient ways to do
    > it in Python.)
    >
    > > Python should also be a perfectly good superset of Bash Scripting
    > > language.  (To the extent that Python isn't, there's nothing intrinsic
    > > about the language that prevents you from orchestrating processes.)

    >
    > Hmm... How do you pipe one command's output into another's input using
    > Python? It's not nearly as clean as it is in bash.
    >


    For pipes, I'd still call out to bash. I know that's cheating, but
    the idea is that Python can wrap all the good parts of bash while
    still allowing you to use Python's more modern syntax, standard
    library, etc.
     
    Steve Howell, Apr 3, 2012
    #4
  5. On Tue, Apr 3, 2012 at 8:05 AM, Dennis Lee Bieber <> wrote:
    > On Thu, 29 Mar 2012 08:48:53 -0700 (PDT), Steve Howell
    > <> declaimed the following in
    > gmane.comp.python.general:
    >
    >        REXX is inhibited by the architectures to which it has been ported
    > -- limiting the ADDRESS targets to variations of Python's os.system() or
    > popen() calls; even the subprocess module can't get beyond the all or
    > nothing execution model.
    >
    >        Much different from the original IBM environment (and, biased, the
    > Amiga implementation may have gone beyond the IBM one in capabilities)
    > wherein compliant programs become the "command shell" for REXX command
    > processing -- actual bidirectional interactive interprocess
    > communication. Window's COM system offers some of that capability, but
    > buried in a cryptic object programming system -- nothing like having a
    > script sending the /same/ command that one would use in a text interface
    > to the target program.


    Some years ago, I wrote a MUD that used REXX as its scripting
    language. (The server's still running, but not so much to be a MUD as
    to be my administrative interface to that particular box. I'm like
    that with MUDs.) I thought it was really cool to be able to simply put
    a bare string and have that get sent to the player - for instance:

    /* Command handler for some particular location in the MUD */
    if arg(1)="foo" then do
    "You begin to foo."
    /* do some stuff */
    "You finish fooing."
    end

    Having now built MUDs in Pike, I'm not so impressed with the syntax.
    But hey, it's a completely different use of the ADDRESS command! :)
    And of course, I can always use ADDRESS CMD "blah blah" to execute
    commands.

    On Tue, Apr 3, 2012 at 10:25 AM, Steve Howell <> wrote:
    > On Apr 2, 2:50 pm, Chris Angelico <> wrote:
    >> Hmm... How do you pipe one command's output into another's input using
    >> Python? It's not nearly as clean as it is in bash.

    >
    > For pipes, I'd still call out to bash.  I know that's cheating, but
    > the idea is that Python can wrap all the good parts of bash while
    > still allowing you to use Python's more modern syntax, standard
    > library, etc.


    So, it's not that Python is a superset of bash, but that Python+bash
    is a superset of bash. Well, that is certainly understandable. And
    needn't be too onerous syntactically either:

    from os import system as x

    x('do_stuff')

    ChrisA
     
    Chris Angelico, Apr 3, 2012
    #5
    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. PhilC
    Replies:
    4
    Views:
    363
    PhilC
    Oct 30, 2004
  2. Alex Willmer

    Human readable number formatting

    Alex Willmer, Sep 28, 2005, in forum: Python
    Replies:
    9
    Views:
    653
  3. John Friedland
    Replies:
    18
    Views:
    567
    Adam Warner
    Jul 12, 2006
  4. Chris Angelico
    Replies:
    15
    Views:
    286
    Dave Angel
    Mar 24, 2012
  5. Nathan Rice
    Replies:
    30
    Views:
    762
    Steve Howell
    Apr 4, 2012
Loading...

Share This Page