Re: pl/Ruby, deprecating plPython and Core - Mailing list pgsql-hackers

From Joshua D. Drake
Subject Re: pl/Ruby, deprecating plPython and Core
Date
Msg-id 430271BD.1080703@commandprompt.com
Whole thread Raw
In response to Re: pl/Ruby, deprecating plPython and Core  (Christopher Petrilli <petrilli@gmail.com>)
List pgsql-hackers
> There are two questions, I perceive, critical to making decisions
> about what goes into the core. While I'm not a contributing developer,
> I've worked with PostgreSQL since it was still Stonebraker's child and
> still use Postquel, and have rolled it inot a lot of production
> situations, so I'm going to speak from that perspective.
> 
> 1) More isn't better.

Actually it can be, if more equates to more choice of quality product
that allows programmers to use the environment they are most comfortable 
with.

> 
> 2) What the *MARKET* cares about is PL/PGSQL and PL/Java.  

Who's Market? The Oracle market? O.k.... The PostgreSQL Market?
Not likely. Yes plJava is a big player, but I doubt nearly as
many people use it as say plPerlNG.

Is plJava important? You bet. It makes all those sweaty types
that yell "Developers, Developers, Developers" while running
around on stage like a monkey... oh wait that is .Net. Is there a 
difference?

Sorry I digress, the point is, Ruby has a HUGE following in Asia
and is growing very, very quickly in the US.

If it wasn't, Oreilly wouldn't be annoyed that several other
publishers had beat them to the punch in publishing books on it.


> I have the utmost detestful view of Java, but that's what it is.  I
> don't write my stored-procedures in Java, I write them in PL/PGSQL
> because it is familiar to those who have to maintain the database,

No it is familiar to those who maintain or have maintained Oracle. I 
personally detest plPgsql and will only use it because a lot of times
it is faster than the other langes.

> Personally, I think pulling PL/Java in, and throwing the rest out, is
> a great idea. Let them mature seperately, and keep the perenial
> language wars out of the core.  What is in the core is a decision made
> on a couple of points:

I don't think you would get anyone to vote for that.

1. It is extreme
2. There are a lot of developers, I would say most with PostgreSQL
that don't use or want to use Java.

> 1) What helps Postgresql in the "market," such that it is. 

Choice, to allow developers to use the tools they want and know how to
use. That includes plJava and plRuby, and plPHP etc...

> 
> 2) What would the core team be willing to take ownership of because of
> #1, even if the existing supports disappeared.

Well I think there is a minimal chance of that.

> 
> As someone who has been writing in Python since 1994, I like the
> language, and we could have all sorts of discussions about language
> idioms and safety, and the perception of each, but neither have
> anything to do with the decision at hand.

Actually they do, directly because Python can't be trusted from the 
PostgreSQL point of view.

> Axes should be put away, and people should decide what is critical to
> the market perception of the database, and as much as I hate to admit
> it, Java is 1000x more important than Ruby, Perl, Python and Tcl

Really? Give me numbers. Where are your sources? What statistics show this?

Again I am not suggestion that pljava isn't important but your arguments
seem more based on what was on the cover of Java magazine than actual
reality of what people are using to code.

Do you realize the number of Perl, Python and Ruby programmers and 
programs there are out there? Now include PHP and just a touch of C
and Java is a drop in the bucket.

Sincerely,

Joshua D. Drake


-- 
Your PostgreSQL solutions company - Command Prompt, Inc. 1.800.492.2240
PostgreSQL Replication, Consulting, Custom Programming, 24x7 support
Managed Services, Shared and Dedicated Hosting
Co-Authors: plPHP, plPerlNG - http://www.commandprompt.com/


pgsql-hackers by date:

Previous
From: Mark Wong
Date:
Subject: Re: data on devel code perf dip
Next
From: Mary Edie Meredith
Date:
Subject: Re: data on devel code perf dip