public inbox for [email protected]  
help / color / mirror / Atom feed
From: Shachar Shemesh <[email protected]>
To: Tom Lane <[email protected]>
Cc: Stephan Szabo <[email protected]>
Cc: Robert Treat <[email protected]>
Cc: Dennis Bjorklund <[email protected]>
Cc: Bruce Momjian <[email protected]>
Cc: PostgreSQL-development <[email protected]>
Cc: PostgreSQL advocacy <[email protected]>
Subject: Do we prefer software that works or software that looks good?
Date: Sat, 24 Apr 2004 08:23:57 +0300
Message-ID: <[email protected]> (raw)
In-Reply-To: <[email protected]>
References: <[email protected]>
	<1082735128.22969.1106.camel@camel>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>

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/




view thread (144+ messages)  latest in thread

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: [email protected]
  Cc: [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected]
  Subject: Re: Do we prefer software that works or software that looks good?
  In-Reply-To: <[email protected]>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox