Wrapper vs. full language

I glanced at [link|http://snaga.org/pgsql/cvsweb.cgi/~checkout~/pgsql/src/pl/plperl/plperl.c?rev=1.1.1.1&content-type=text/plain|http://snaga.org/pgs...t-type=text/plain] and [link|http://snaga.org/pgsql/cvsweb.cgi/~checkout~/pgsql/src/pl/plpython/plpython.c?rev=1.1.1.2&content-type=text/plain|http://snaga.org/pgs...t-type=text/plain] to see what you are talking about. What leapt out at me is that the Python source did a lot of explicit declaring and manipulating of Python stuff. What I next noticed is that the Perl version used some big macros from the Perl source.

Take a look at and compare PLy_procedure_create to plperl_create_sub. See things like ENTER, SAVETMPS, PUSHMARK(SP), XPUSHs(sv_2mortal(newSVpv(s, 0))) and so on? Those are all macros which are commonly used within the Perl source. Those macros do a lot of stuff, and expanded out would be many more lines. It doesn't surprise me that the Python version of that function is over twice the length of the Perl version - the Perl version is going to be bigger than the Python version after you run the preprocessor over it.

Whether or not the number of macros that you have in Perl sourcecode is a good or bad thing is open to debate. (There is a reason that they did that, there are also lots of complaints about it from anyone who has to work with them.) But they certainly do leave you with less code and more confidence that certain kinds of checks have been done reliably.

Cheers,
Ben

Post #140,707 by drewk 2/9/04 11:11:29 AM Reply	Wrapper vs. full language Perl and Python are just APIs to call the other language, which must also be installed. pl/pgsql is a full language that has to be installed. === Implicitly condoning stupidity since 2001.
Post #140,799 by deSitter 2/9/04 8:19:34 PM Reply	Well right I was thinking Python vs. Perl. It's like 7 to 1. -drl
Post #140,821 by ben_tilly 2/9/04 9:28:09 PM Reply	At a glance, big macros I glanced at [link\|http://snaga.org/pgsql/cvsweb.cgi/~checkout~/pgsql/src/pl/plperl/plperl.c?rev=1.1.1.1&content-type=text/plain\|http://snaga.org/pgs...t-type=text/plain] and [link\|http://snaga.org/pgsql/cvsweb.cgi/~checkout~/pgsql/src/pl/plpython/plpython.c?rev=1.1.1.2&content-type=text/plain\|http://snaga.org/pgs...t-type=text/plain] to see what you are talking about. What leapt out at me is that the Python source did a lot of explicit declaring and manipulating of Python stuff. What I next noticed is that the Perl version used some big macros from the Perl source. Take a look at and compare PLy_procedure_create to plperl_create_sub. See things like ENTER, SAVETMPS, PUSHMARK(SP), XPUSHs(sv_2mortal(newSVpv(s, 0))) and so on? Those are all macros which are commonly used within the Perl source. Those macros do a lot of stuff, and expanded out would be many more lines. It doesn't surprise me that the Python version of that function is over twice the length of the Perl version - the Perl version is going to be bigger than the Python version after you run the preprocessor over it. Whether or not the number of macros that you have in Perl sourcecode is a good or bad thing is open to debate. (There is a reason that they did that, there are also lots of complaints about it from anyone who has to work with them.) But they certainly do leave you with less code and more confidence that certain kinds of checks have been done reliably. Cheers, Ben "good ideas and bad code build communities, the other three combinations do not" - [link\|http://archives.real-time.com/pipermail/cocoon-devel/2000-October/003023.html\|Stefano Mazzocchi]
Post #140,833 by admin 2/9/04 10:06:48 PM Reply	Physicists can't do math. Try 2.5 to 1 for the main .c file. The Python stuff has unit tests as well. The main difference is functionality: the Python version does that much more. 1) Python stored procs have a global and session level data area that is preserved across calls. 2) Perl functions cannot be used as triggers; Python functions can, and they have a trigger-related data area as well. 3) You can create and use execution plans. and unrelated to code size: 4) The documentation is a helluva lot better for the Python version. :-) Regards, -scott anderson "Welcome to Rivendell, Mr. Anderson..."

Welcome to IWETHEY!