Python IRC dictatorship

[John Hunter]

>>>>> "Timothy" == Timothy Rue <threeseas at earthlink.net> writes:


    Timothy> In summary what you are saying is that there is a tower
    Timothy> of babel between not only client and coder but between
    Timothy> languages as well. The result of this is that anyone in
    Timothy> the position of a client really needs to learn the
    Timothy> details of whatever specific language, including any
    Timothy> other specifics of the use of a language, such as
    Timothy> platform dependant issues, before they consider hiring a
    Timothy> coder to produce, what the client designs. Otherwise how
    Timothy> the hell is the client to communicate to the coder what
    Timothy> the fuck they want?

When I was a graduate student trying to build some electronics, I
would frequently head up to the electronics shop where a super hard
core guru resided; he could build PET scanners by hand.  I would say I
needed capacitor A and switch B.  We'd search through all his drawers
looking for the part I needed and if we couldn't find it, he'd say,
will capacitor C do instead?  I'd say, hell, I don't know, you're the
expert.  And he'd say, well, what are you trying to do?  I'd tell him
what I was trying and he would say, 'No no no, you don't need any of
that.  What you need to do is this'.

This scenario was repeated many times, and it took me a long time to
learn that when you are the client, you need to tell them what you
need to do, not how to do it.

There is a lot of jargon and syntax and subtlety in the programming
world.  Most expert programmers know many languages and can easily map
concepts from one onto another.  Most technically savvy clients
cannot.  So the technically savvy client needs to stay focused on what
they want to do (as you do below when you spell out the need for
persistence across server reboots, concurrence, locking, platform
independence, human readable, etc...).

So I don't think the real problem is a tower of babel.  The real
problem is that the client and coder (intermediary) need to stay
focused on problem descriptions and solutions, not low level technical
implementations.

You have identified your problem fairly well below.  Some more
information would be helpful.  How many users?  Exactly which
platforms?  You probably don't need true independence, which doesn't
exist.  How big are the data chunks?  Is this mission critical data?

Then your coder can provide different alternative solutions with cost
estimates and spell out how well each of them meet your criteria.  If
the coder can't present them in problem description/solution
language, you should look for another coder.

I suspect if you supplement your problem description made in your
previous post with some additional quantitative information, you'll
get some answers to your questions here about how well python and
other technologies support them.

Off the cuff, for moderate to large projects using only free, open
source technologies, a combination of the following (which all play
very well together) meet many of your requirements:

-- Platform independence: python clients with platform independent
   graphical user interfaces (GUI).  If you want clients on Windows,
   Mac OS, linux and some major UNIXes UNIXs, your coder can choose
   between many GUI libraries (wxpython, tkinter, pygtk, ...).  If you
   want handheld support, your choices will be more limited.

-- Concurrency, locking and persistence: I've read that the database
   postgresql which is readily controllable by the python clients
   provides fairly good transactional support.  I've been told it
   doesn't scale well to very large numbers of concurrent
   transactions, so the size of your project may be important here.

-- Human readability.  Extensible Markup Language (XML) is widely
   regarded as the dominant standard for data storage that needs to be
   both machine and human readable.  You can combine this with
   databases by storing the XML in a database text field.  python has
   a number of built-in tools as well as powerful extensions for
   handling this data efficiently.


John Hunter