On Thu, 10 Feb 2005 13:00:08 -0500, Daniel Jarboe
<daniel.jarboe@gmail.com> wrote:
> > Python exists as an alternative, for the aforemention Web Creatures,
> > who found PERL too difficult to comprehend as a language to parse
> > their text and strings. Thus they use it, possibly unknowingly, as an
> > alternative to PERL. Now they have Zope to use as a CGI.
>
> Ahh Logan. Such nonsense makes fine fodder for flamewars! Oddly,
> something about this one leaves me compelled to not let it just slide
> by. I fear a tirade.
>
> Just to clarify some misconceptions... the whole perl too difficult so
> learn python thing is way off base. And I'm confused by your "Now
> they have Zope to use as a CGI." Zope is an application server
> written in python, and provides an everything plus the kitchen sink
> framework for application server environments. CGI scripts written in
> python don't need Zope. Python's cgi library has been around since
> python 1.0.whatever.
>
> > If you have enough programming experience they all do the same thing,
> > and look a little different. Personally having learned all three, I
> > like PHP best for web dev. Python for application dev. And Perl for
> > glue apps.
>
> I think this one from Christopher is more on the level. PHP was
> largely designed for the web, and it does the web well. Sure it can
> do other things too, but when it comes down to it, PHP was designed to
> be embeddable in HTML. Python and Perl do the web well too, but they
> were designed with broader goals and those languages exude an air of
> flexibility over PHP. If you are interested in web-only, PHP is a
> fine choice; that is what it was designed for and it does a good job.
> For projects with broader needs, like tight integration with existing
> applications, or even particularly large standalone projects, I
> personally would shy away from exclusive PHP.
>
> Perl was largely designed for text processing. Python and PHP can do
> that too, but in those languages there is just more baggage associated
> with text processing. Perl's greatest strength, IMO, is its ubiquity
> and the size of its user-base. It works well. It's been around for
> longer than python and php. CPAN is wonderful. It is a shame python
> lacks a true equivalent to CPAN, but it is fair to make distinctions
> between the strengths of the communities vs. the strengths of the
> languages.
>
> Python too, has its strengths. IMO python makes better glue. Perl
> makes fine duct-tape, but IMO, Python stands out above the others here
> when it comes to real integration. I'm not talking about the stdout
> to stdin type glue. I'm talking object level, calling c/c++/java
> functions to and from your python script, but more importantly, python
> objects to use those "foreign" datatypes or whatever structs you can
> cook up feel well thought-out and work.
I like python, except the syntax. However, I feel the need
to mention that you can embed any language you want in perl, including python:
http://search.cpan.org/search?query=Inline%3A%3A&mode=module
However, it should be noted that Python has a much cleaner API. :)
It's not fun embedding perl in a C program. It isn't that hard, but it
is rather icky nonetheless.
I just can't wait 'til parrot is ready for production. Having a single
runtime that is designed for dynamic languages like perl, ruby,
python, php, scheme, etc, will be very nice. In theory it should allow
you to use CPAN modules from Python, and python objects in perl, and
ruby objects in python, etc.
-----------------------------------------------------------------------
This list is provided as an unmoderated internet service by Networked
Knowledge Systems (NKS). Views and opinions expressed in messages
posted are those of the author and do not necessarily reflect the
official policy or position of NKS or any of its employees.
This archive was generated by hypermail 2.1.3 : Fri Aug 01 2014 - 18:58:19 EDT