Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #22339 > unrolled thread

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

Back to article view | Back to comp.lang.python

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: Number of languages known [was Re: Python is readable] - somewhat OT Chris Angelico <rosuav@gmail.com> - 2012-03-30 01:03 +1100
    Re: Number of languages known [was Re: Python is readable] - somewhat OT Steve Howell <showell30@yahoo.com> - 2012-03-29 08:48 -0700
      Re: Number of languages known [was Re: Python is readable] - somewhat OT Chris Angelico <rosuav@gmail.com> - 2012-04-03 07:50 +1000
        Re: Number of languages known [was Re: Python is readable] - somewhat OT Steve Howell <showell30@yahoo.com> - 2012-04-02 17:25 -0700
          Re: Number of languages known [was Re: Python is readable] - somewhat OT Chris Angelico <rosuav@gmail.com> - 2012-04-03 17:12 +1000
      Re: Number of languages known [was Re: Python is readable] - somewhat OT Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2012-04-02 18:05 -0400

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

On Fri, Mar 30, 2012 at 12:44 AM, Nathan Rice
<nathan.alexander.rice@gmail.com> 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.

[toc] | [next] | [standalone]

#22493

On Mar 29, 7:03 am, Chris Angelico <ros...@gmail.com> wrote:
> On Fri, Mar 30, 2012 at 12:44 AM, Nathan Rice
>
> <nathan.alexander.r...@gmail.com> 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 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.

It's great to have languages like C and HTML that carve out their own
strong niches.  No argument there.

On the other hand, if you know Python, then having to contend with the
learning curves and idiosyncrasies of Perl and Ruby might feel more
frustrating than empowering.  Like REXX and PHP, Perl and Ruby
arguably have corners where they are more expressive than Python, but
I'd rather have a boring system written in 100% Python than a Ruby/
Python hybrid.

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.)

> 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.
>

Here I absolutely agree with you.  SQL, to me, is a perfect
illustration of a language that's optimal for a particular task.  Of
course, people still can't resist hiding it behind an ORM.

The web stack is notorious for requiring multilingual juggling.  HTML,
CSS, JS, Python, and SQL are easy enough to juggle, but then you might
also get template languages (with all the interpolation escaping),
config files (XML, YAML, etc.), regexes (possibly multiple dialects),
SQL, testing DSLs (ugh, Cucumber and friends), etc.


> 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.

I know you're just joking here, because you're obviously not
advocating for multiple hammers.  You're advocating for multiple tools
in the toolbox.  Which is good, of course.

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.

[toc] | [prev] | [next] | [standalone]

#22544

On Fri, Mar 30, 2012 at 2:48 AM, Steve Howell <showell30@yahoo.com> 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

[toc] | [prev] | [next] | [standalone]

#22560

On Apr 2, 2:50 pm, Chris Angelico <ros...@gmail.com> wrote:
> On Fri, Mar 30, 2012 at 2:48 AM, Steve Howell <showel...@yahoo.com> 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.

[toc] | [prev] | [next] | [standalone]

#22577

On Tue, Apr 3, 2012 at 8:05 AM, Dennis Lee Bieber <wlfraed@ix.netcom.com> wrote:
> On Thu, 29 Mar 2012 08:48:53 -0700 (PDT), Steve Howell
> <showell30@yahoo.com> 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 <showell30@yahoo.com> wrote:
> On Apr 2, 2:50 pm, Chris Angelico <ros...@gmail.com> 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

[toc] | [prev] | [next] | [standalone]

#22549

On Thu, 29 Mar 2012 08:48:53 -0700 (PDT), Steve Howell
<showell30@yahoo.com> 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
        wlfraed@ix.netcom.com    HTTP://wlfraed.home.netcom.com/

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.python

csiph-web