| Re: getting perl and php to talk to each other [message #180603 is a reply to message #180601] |
Wed, 06 March 2013 01:08   |
Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma:
|
Senior Member |
|
|
On 3/5/2013 6:59 PM, Ben Morrow wrote:
>
> Quoth Thomas 'PointedEars' Lahn <php(at)PointedEars(dot)de>:
>> [X-Post & F'up2 comp.lang.php; please do not X-Post without F'up2]
>
> OK. As such I won't see any replies.
>
Don't worry about Pointed Head. He's a well known troll in several
newsgroups.
<snip>
>>> Why on Earth would you want to do that? Seriously, I can't think of any
>>> situation where mixing PHP and Perl is easier than just writing in Perl
>>> in the first place.
>>
>> Other people would say the same about writing PHP instead of a mix.
>
> Yes, of course.
>
A long shot - maybe you have a package in one language you need to feed
input to. But that input must first be processed by a package in the
other language. Rather than rewrite everything, merge them together.
Or, perhaps you need to build the data preprocessor, and aren't familiar
with the language the package is written in.
I agree it would be quite rare, but it's about the only reason I could
think of people would need both languages. I'm sure there are more, though.
>> However, there can be value in two programming languages in the same
>> program. Just consider what kinds of data you can pass via the command
>> line and what kinds you cannot pass that way (yes, there are text files,
>> named pipes, and other equally ugly workarounds).
>
> The methods used by PHP::Interpreter are not really any less ugly. Until
> you get to the point of being able to run the two languages on the same
> VM with properly interworking data structures (such as Parrot is trying
> to achieve, for instance) I don't see much point stuffing the two
> languages into the same process and then just passing strings to eval
> back and forth.
>
I doubt that they'll ever have internetworking data structures, though.
Just not a need for it.
>>> Note that the Perl in that article (or at least, the first page, which
>>> was all I read) is pretty bad:
>>>
>>> […]
>>> - using PHP to talk to a database, when Perl's DBI module is
>>> considerably better than PHP's rather random database functions.
>>>
>>> I don't know PHP well enough to comment on it,
>>
>> Yet you did, which shows that you have never used PHP Data Objects (PDO).
>> “*Random* database functions”? IBTD.
>
> I have not. The database functions used in the article referenced were
> mssql_connect and so on, which last time I used PHP (a long time ago)
> was all there was. I don't think you can deny that *those* functions
> (and the equivalent set for other databases) are a nasty mess. I tried
> to make it clear that I understand the state of the PHP art has improved
> since then.
>
> My major point was that I don't see any good reason to call into PHP
> just to connect to a database, when Perl already has perfectly good
> database code. Had the example been written the other way around the
> equivalent point could of course have been made about calling into Perl.
>
I agree with both of your points. Both languages have reasonable means
of accessing data. I don't think there are any databases one language
can access but not the other.
However, I wouldn't call those functions a "nasty mess". But then I was
writing C code > 25 years ago, and these are just wrappers around C
functions. And while there are other ways such as PDO, they also
typically add an extra layer of overhead. In a busy system, this may or
may not be important. However, if the system is that busy, I wouldn't
be switching back and forth between languages, either.
>>> but I wouldn't be surprised if the PHP code was just as bad (for instance,
>>> I understand PHP has a saner database interface these days; I don't know
>>> if it existed in 2007, though).
>>
>> It did; for example, “PDO [shipped] with PHP 5.1”, “[r]eleased: 24 Nov
>> 2005”, which is not that hard to find out:
>
> Not that hard had I been interested, which I'm not, and had I known
> 'PDO' was the term to look for, which I didn't. (I was actually thinking
> of the PEAR DB module, which I've observed is a thing that exists.
> Again, I've no idea if this is the currently-recommended database
> interface, or how it compares with the Perl DBI.)
>
> Ben
>
I wouldn't have bothered looking up when a Perl module was shipped, either.
BTW - comp.lang.perl.misc added back since this is about both languages.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex(at)attglobal(dot)net
==================
|
|
|
|
Calendar
Search
Help
Members
Register
Login
Home
]