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

[Steve Howell]

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