Do we prefer software that works or software that looks good?

Tom Lane wrote:

>Personally I don't think that this is a "transitional issue" and we will
>someday all be happy in upper-case-only-land. Upper-case-only sucks,
>by every known measure of readability, and I don't want to have to put up
>with a database that forces that 1960s-vintage-hardware mindset on me.
>
>
And I was feeling apologetic that I was accusing without a base the good
(and I'm not cynical about that last adjective) people of the PostgreSQL
of making life more difficult for programmers just because they don't
like the asthetics of something which an external standard dictates.

I mean, sure, I understand the sentiment. I don't like seeing all-caps
either. But allow me to give an allegory from another free software
project, one where I am an actual active code contributer.

Imagine that Alexandre Juliard, the benevolent dictator for the Wine
project, would have had the same attitude. Each time someone would come
around saying "today function X calls function Y, and this breaks
program Z. We need to reverse X and Y", he would reply with "But it
makes more asthetic/program design/whatever sense to do it the way we do
it today". The result would be that Wine would never come to the point
where it can run Word, IE and other prominant Windows only applications.

The reality of things is that Wine, just like Postgres, work by an
external standard. Wine's standard is more strict, less documented, and
more broad. However, like it or not, the more you deviate from the
standard, the more you require people who want to use your technology to
adapt to whatever it is that you do.

This doesn't make sense on any level.

>So what I'm holding out for is a design that lets me continue to see the
>current behavior if I set a GUC variable that says that's what I want.
>
>
>This seems possible (not easy, but possible) if we are willing to
>require the choice to be made at compile time ... but that sounds too
>restrictive to satisfy anybody ... what we need is a design that
>supports such a choice per-session, and I dunno how to do that.
>
>
In other words, you are going to reject the simpler solutions that treat
this as a transition problem, because of asthetic issue? Not even
program design issue, mind you. Sounds strange to me, and also pretty
much guarentees that this will never happen. That would be a shame.

The reason this would be a shame is because postgres is the same reason
this thread was CCed to advocacy to begin with. Databases form a pretty
saturated field. If Postgres is to break forward, it needs a niche. The
fully-featured databases role is taken (Oracle), and the free database
role is taken (MySQL). Postgres CAN take the fuly featured free database
niche, but that will need help.

The time is ripe, however. The company we're doing my current OLE DB
work for has contacted me about this, and they dictated Postgres (MySQL
was not nearly enough). They still want to see proof of concept working,
but that's my job. However, I'm afraid they might give up if things
become too complicated to port. Under such circumstances, every little
help Postgres can give may mean the difference between "breaking
through" and "staying behind". I really wouldn't like to see such an
important help break merely because "Tom Lane doesn't like to see
uppercase on his database tables list".

Now, I'm intending to do the best I can on my end. This does have a
pretty heavy cost. It means that the OLE DB driver will parse in details
each query, and perform replacements on the query text. This is bug
prone, difficult, hurts performance, and just plain wrong from a
software design perspective. The current drift of wind, however, means
that the PostgreSQL steering commite seems to prefer having a lesser
quality driver to seeing ugly uppercase.

> regards, tom lane
>
>PS: I resisted the temptation to SET THIS MESSAGE IN ALL UPPER CASE
>to make the point about readability. But if you want to argue the
>point with me, I'll be happy to do that for the rest of the thread.
>
>
Yes, it's a well known rhetoric technique. Take whatever argument your
opponent say, and exagerate it to an absurd.

Shachar

--
Shachar Shemesh
Lingnu Open Source Consulting
http://www.lingnu.com/