Thread: Re: Triggers, Stored Procedures, PHP. was: Re: PostgreSQL

Re: Triggers, Stored Procedures, PHP. was: Re: PostgreSQL

From
"Jay O'Connor"
Date:
 > >If you need more power IMO Python is the way to go.

 > I am not that familiar with pything, not to get off topic here but
what you
 >can do in python that you can't do in PHP?

Well if they are both Turing complete, arguably not much :)

It's not the 'what' it's the 'how'  I'm equating Perl with PHP much in
this because what little I've seen of PHP it looks a lot like Perl to
me; more simularity between the two then between either and Python

Python has a much simpler and more elegant object-class infrastructure
than Perl. It's integrated better unto the natural feel of the
language.  It's easier to use (especially developing new classes) and
easier to read and that makes it easier to build large (compliacted,
large number of classes, etc..) programs in it.

Python also reads more obviously, in that it doesn't have a lot of
'default context' ($_) and 'scalar context versus array context' and
cute shortcuts and stuff floating around, which makes it easier to read,
and more importantly easier for teams to read.  This, again, affects the
ability to build large (complex) programs because it's easier for teams
of developers to work together on the same code base and understand what
each other is doing.

A nit of mine is languages that insist on using $ and @ and other
special symbols for variable names.  That's great for inline striing
substitution but really annoying in a couple thousand lines of code with
lots of variables

Personally, I would never use Perl for anything over about one hundred
lines and about one developer if I had any say in the matter.  Takeing
Perl and mixing Presentation (HTML) with Business Logic (embedded
scripts) wihich seems to be PHPs claim to fame just really sits wrong
with my software design mentatiliy


Re: Triggers, Stored Procedures, PHP. was: Re: PostgreSQL

From
Alvaro Herrera
Date:
On Mon, Dec 01, 2003 at 05:18:17PM -0700, Jay O'Connor wrote:

> Personally, I would never use Perl for anything over about one hundred
> lines and about one developer if I had any say in the matter.  Takeing
> Perl and mixing Presentation (HTML) with Business Logic (embedded
> scripts) wihich seems to be PHPs claim to fame just really sits wrong
> with my software design mentatiliy

Well, I have used Perl for a couple of thousand-lines-projects and while
I can't say it's wonderful, it's usable as far as one is strict (i.e.
code for strict and warnings), and use implicit things as less as
possible.  If you abstract things the right way it's not the nightmare
you think it is.  Agreed, the language grants you the power to do it
"the wrong way" (write-only language), but I distrust anything that
takes that power away (may I say Java?).

PHP on the other hand, while I don't quite like it, is not also the
nightmare you make of it.  You are of course not forced to embed HTML in
the logic -- in these days, doing so is folly.  Most [sane] people uses
templates.  Same with Perl.

Python may be better, but keep in mind that it _also_ grants you the
power to do thing the wrong way.  In fact, a colleague of mine is right
now ranting about a specific project, saying that he will have to write
it almost completely from scratch to be able to extract certains parts
of the functionality -- the author apparently did not abstract them
correctly.  I have yet to use Python much, but the little I have seen I
like.

--
Alvaro Herrera (<alvherre[a]dcc.uchile.cl>)
Al principio era UNIX, y UNIX habló y dijo: "Hello world\n".
No dijo "Hello New Jersey\n", ni "Hello USA\n".

Re: Triggers, Stored Procedures, PHP. was: Re: PostgreSQL

From
merlyn@stonehenge.com (Randal L. Schwartz)
Date:
>>>>> "Jay" == Jay O'Connor <joconnor@cybermesa.com> writes:

Jay> Python also reads more obviously, in that it doesn't have a lot of
Jay> 'default context' ($_) and 'scalar context versus array context' and
Jay> cute shortcuts and stuff floating around, which makes it easier to
Jay> read, and more importantly easier for teams to read.

It also has some things which are functions, and others which are
methods, with no rhyme or reason except for a historical basis.  And
that's just the beginning.  (Why are tuples read only?  Sorry, cheap
shot.)

Please don't paint Python as nice and regular.  It has nearly as many
odd things to know as Perl does.

--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!

language war

From
Jonathan Bartlett
Date:
> Well, I have used Perl for a couple of thousand-lines-projects and while
> I can't say it's wonderful, it's usable as far as one is strict (i.e.
> code for strict and warnings), and use implicit things as less as
> possible.  If you abstract things the right way it's not the nightmare

Actually, Perl is wonderful for several classes of programs.  I wrote a
web-based application in Perl that probably would have been many times as
long in any other language.  On top of that, I got a full SOAP API with
just a 100-line wrapper script.

Perl has really powerful OO features, and makes it really easy to do
things that you only wish you could do in other languages.  It is
especially useful when you need to come up with special-purpose templating
languages.

It's RegExp language is also excellent. While you can get PCRE in other
languages, Perl having it built-in to the language makes them much easier
to use.

Jon

> you think it is.  Agreed, the language grants you the power to do it
> "the wrong way" (write-only language), but I distrust anything that
> takes that power away (may I say Java?).
>
> PHP on the other hand, while I don't quite like it, is not also the
> nightmare you make of it.  You are of course not forced to embed HTML in
> the logic -- in these days, doing so is folly.  Most [sane] people uses
> templates.  Same with Perl.
>
> Python may be better, but keep in mind that it _also_ grants you the
> power to do thing the wrong way.  In fact, a colleague of mine is right
> now ranting about a specific project, saying that he will have to write
> it almost completely from scratch to be able to extract certains parts
> of the functionality -- the author apparently did not abstract them
> correctly.  I have yet to use Python much, but the little I have seen I
> like.
>
> --
> Alvaro Herrera (<alvherre[a]dcc.uchile.cl>)
> Al principio era UNIX, y UNIX habl� y dijo: "Hello world\n".
> No dijo "Hello New Jersey\n", ni "Hello USA\n".
>
> ---------------------------(end of broadcast)---------------------------
> TIP 9: the planner will ignore your desire to choose an index scan if your
>       joining column's datatypes do not match
>


Re: Triggers, Stored Procedures, PHP. was: Re: PostgreSQL

From
"Joshua D. Drake"
Date:
>It also has some things which are functions, and others which are
>methods, with no rhyme or reason except for a historical basis.  And
>that's just the beginning.  (Why are tuples read only?  Sorry, cheap
>shot.)
>
>Please don't paint Python as nice and regular.  It has nearly as many
>odd things to know as Perl does.
>
>
>
I think the last thing we need is a language war. Every language has its
cruft and problems.  Use
the language that suits you best. Perl, Python, PHP are all good
languages in their own right.
Currently Python has the best server side (pl) support for PostgreSQL of
the three but that
will change after the new year.

Sincerely,

Joshua D. Drake


--
Command Prompt, Inc., home of Mammoth PostgreSQL - S/ODBC and S/JDBC
Postgresql support, programming shared hosting and dedicated hosting.
+1-503-222-2783 - jd@commandprompt.com - http://www.commandprompt.com




Re: language war

From
"Chris Travers"
Date:
First-- my main programming languages at the moment are Perl, PHP, and
Python.  I don't do multithreaded programming, though when I need to, I will
use sockets, pipes, fork(), SYSV IPC etc.  Needless to say, I do very little
Windows programming.

First, every language allows you to do things any of several right ways, and
any of many many wrong ways.  I am not convinced that the choice of language
will make a sloppy program magically become readable.

Most of my web programming is done using PHP.  For stateless architectures,
I have yet to find a language that is as extensible, powerful, and easily
modular as PHP.  My favorite feature is the fact that I can include
arbitrary files, using a line of code:
include "$next_file.php";
Then whichever file shares the name (minus the .php extension) with the
$next_file variable will be included.  This enables me to write engines that
allow for event-driven programming in stateless web environments.  I have
not been able to find an elegent solution to this problem either in Perl or
PHP.  Note: this is only used for UI modules due to obvious security
concerns, and the variables should be subject to some additional sanity
checks.

I find that Perl is the best program for UNIX system programming, as long as
performance is less expensive than programmer time.  Many of my applications
for automated, scheduled file transfers, log reporting, etc. as well as
installers for other UNIX programs are written in Perl.

Finally, I usually use Python for GUI apps, either with TKinter or WXPython.
I find its support for many graphical environments to be excellent, and I
can easily and rapidly prototype any application with it.

There are two points to bear in mind with this language war:
1:  Every language lets you program in any number of right ways, but also in
many many wrong ways.
2:  Using any language effectively takes some period of acclimation-- what
works in one language often doesn't in another.

Trying to bring this closer to the topic of the list--
what do PL/PHP and PL/Python allow you to do easier than with PL/Perl or
PLPGSQL?
What other PGSQL languages would people recommend I look into?

Best WIshes,
Chris Travers



Re: language war

From
Jan Wieck
Date:
Chris Travers wrote:

> I have yet to find a language that is as extensible, powerful, and easily
> modular as PHP.  My favorite feature is the fact that I can include
> arbitrary files, using a line of code:
> include "$next_file.php";
> Then whichever file shares the name (minus the .php extension) with the
> $next_file variable will be included.  This enables me to write engines that
> allow for event-driven programming in stateless web environments.  I have
> not been able to find an elegent solution to this problem either in Perl or
> PHP.  Note: this is only used for UI modules due to obvious security
> concerns, and the variables should be subject to some additional sanity
> checks.

You would like Tcl ... there include is named source ... but you can
redefine it so that the command instead does something completely
different (like using the filename as a key for a DB lookup?).

Or look at the PL/Tcl unknown support. If a PL/Tcl function contains a
call to an undefined proc but a proc "unknown" exists, the latter is
called with some extra information. In the PL/Tcl case it looks into
some tables if the proc is defined there, loads it and does the
initially failed call ... an auto-include totally transparent to you script.


Jan

--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me.                                  #
#================================================== JanWieck@Yahoo.com #


Re: language war

From
Ian Harding
Date:
pltcl, of course!

Chris Travers wrote:

>First-- my main programming languages at the moment are Perl, PHP, and
>Python.  I don't do multithreaded programming, though when I need to, I will
>use sockets, pipes, fork(), SYSV IPC etc.  Needless to say, I do very little
>Windows programming.
>
>First, every language allows you to do things any of several right ways, and
>any of many many wrong ways.  I am not convinced that the choice of language
>will make a sloppy program magically become readable.
>
>Most of my web programming is done using PHP.  For stateless architectures,
>I have yet to find a language that is as extensible, powerful, and easily
>modular as PHP.  My favorite feature is the fact that I can include
>arbitrary files, using a line of code:
>include "$next_file.php";
>Then whichever file shares the name (minus the .php extension) with the
>$next_file variable will be included.  This enables me to write engines that
>allow for event-driven programming in stateless web environments.  I have
>not been able to find an elegent solution to this problem either in Perl or
>PHP.  Note: this is only used for UI modules due to obvious security
>concerns, and the variables should be subject to some additional sanity
>checks.
>
>I find that Perl is the best program for UNIX system programming, as long as
>performance is less expensive than programmer time.  Many of my applications
>for automated, scheduled file transfers, log reporting, etc. as well as
>installers for other UNIX programs are written in Perl.
>
>Finally, I usually use Python for GUI apps, either with TKinter or WXPython.
>I find its support for many graphical environments to be excellent, and I
>can easily and rapidly prototype any application with it.
>
>There are two points to bear in mind with this language war:
>1:  Every language lets you program in any number of right ways, but also in
>many many wrong ways.
>2:  Using any language effectively takes some period of acclimation-- what
>works in one language often doesn't in another.
>
>Trying to bring this closer to the topic of the list--
>what do PL/PHP and PL/Python allow you to do easier than with PL/Perl or
>PLPGSQL?
>What other PGSQL languages would people recommend I look into?
>
>Best WIshes,
>Chris Travers
>
>
>
>---------------------------(end of broadcast)---------------------------
>TIP 8: explain analyze is your friend
>
>------------------------------------------------------------------------
>
>SPAM: BAYES_00             (-5.2 points)  Bayesian classifier says spam probability is 0 to 1%
>Score Total: -5.2
>