Skip site navigation (1) Skip section navigation (2)

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

From: Shachar Shemesh <psql(at)shemesh(dot)biz>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Stephan Szabo <sszabo(at)megazone(dot)bigpanda(dot)com>,Robert Treat <xzilla(at)users(dot)sourceforge(dot)net>,Dennis Bjorklund <db(at)zigo(dot)dhs(dot)org>,Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>,PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>,PostgreSQL advocacy <pgsql-advocacy(at)postgresql(dot)org>
Subject: Do we prefer software that works or software that looks good?
Date: 2004-04-24 05:23:57
Message-ID: 4089F9ED.6000108@shemesh.biz (view raw or flat)
Thread:
Lists: pgsql-advocacypgsql-hackerspgsql-www
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/


In response to

Responses

pgsql-www by date

Next:From: Tom LaneDate: 2004-04-24 05:47:07
Subject: Re: [HACKERS] What can we learn from MySQL?
Previous:From: Dennis BjorklundDate: 2004-04-24 04:38:58
Subject: Re: [HACKERS] What can we learn from MySQL?

pgsql-hackers by date

Next:From: Tom LaneDate: 2004-04-24 05:47:07
Subject: Re: [HACKERS] What can we learn from MySQL?
Previous:From: Tom LaneDate: 2004-04-24 04:56:51
Subject: Re: Current CVS tip segfaulting

pgsql-advocacy by date

Next:From: Tom LaneDate: 2004-04-24 05:47:07
Subject: Re: [HACKERS] What can we learn from MySQL?
Previous:From: Dennis BjorklundDate: 2004-04-24 04:38:58
Subject: Re: [HACKERS] What can we learn from MySQL?

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group