Python IRC dictatorship

[Timothy Rue]

On 23-Nov-02 17:05:04 John Hunter <jdhunter at ace.bsd.uchicago.edu> wrote:
>>>>>> "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'.

In other words you were not a graduate student of electronics.

>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.

Not in this case, for I cannot do that. It'd simply take to long for me to
give all the infinte examples of possibilities. Therefore that only leaves
what?

Imagine a client telling a coder that they need a compiler for a language,
before the concept of a compiler existed. Coder asks, what do you want to
do, give me an example. Client gives an example and coder says "Oh what
you need is......" the end result is something that can only optimise the
example given, nothing more.

So this idea of telling what you need to do doesn't always work. And in
this case it does not work.

>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...).

Lets' test that theory!

>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?

Major comprehension failure beginning here, on your part.

>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.

getting deeper in failure.

>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.

Supplement?????? I know more about programming that many clients would,
and you want me to know more???? Or how else Am I to supplement?

this is like a cassade failure, the more that is failing the faster it
gets at failing.

>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


And all of this complexity over a friggin list of human readable/editable
variables/values recorded and accesses thru files.

Oh, yeah... It most certainly is a tower of babel.

GUI? where did you get the idea that a GUI was involved? From the Tower
of Babel?

Database handeling? For a simple lists of variables, python has plenty of
builtin cross platform compatable functionality... anydbm, shelves,
pickle, etc. probably all being more than is really needed, so what's the
point of going to external complexity to further complicate the matter?
The more complex a system gets, the higher the probability of error and
resulting costs.

Concurrency is the key issue, but for python to be running concurrently in
a cross platform coded manner... it is likely to be using threads. But
here it's not really parrallel processing, but rather time slicing via the
Global Interpreter Lock. Though fcntl.flock is not cross platform
available, even where it is available it's only internal in use to the
python program that is using it. It has no control over other programs
accessing such a file. It fact there is no hard cross platform method of
such file access control, even outside of python.

As a matter of making soft cross platform internal python program file
access control available, the locking controls in the cross platform
threading module would have to be used. Though not directly controlling of
file locks, they can be used indirectly to control the code that reads and
writes to the files.

Human readability..... what ever happened to plain damn english (or in
this case - whatevr character set the user is using)? XML is just adding
pointless complexity, or at least extra, that leads to greater probability
of error, in this case.

The more pointless complexity that is added in, the greater the tower of
babel will fail, will fall.


If you can't bedazzel them with brilliance, baffel them with bull shit.
Just so long as you are ...... nice and smile.... it's supposed to be ok.

Isn't that right John?

Oh yeah...

>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:

"using only free, open source technology"?????

Exactly what is it that you are trying to insinuate here, in this tower of
babel you have tried to create?


In any event, I suppose you have been helpful John, though it may not have
been intentional but rather indirectly. For the solution direction is that
of using threading locks to control the code that provides access to files
for read and write operations. While anything outside of the python coded
application would need to either not access it for writes or go thru the
python coded application to make updates to the file, where the threading
locks would again be applied.

Another possible direction is that of using thread locks to control a
stream/pipe that is read by a file writer. As "variable ; tag ; value"
exist on a single line and such stream control locks is a common simple
example given in such things as the O'Reilly python books. Where in
updating the file the method of preventing external program conflict in
reading the file, while it is being written/updated by the python program,
a matter of using two files. A temp file the internal python program
writes then renames to the correct name, letting the os manage the
conflict avoidance during the rename (where if the OS fails.... It's an
OS problem that in any decent OS should have already dealt with.)

Oh wait... the os may be proprietary..... ;) meaning... it doesn't really
matter.

Having a WALL to bounce off of..... seems to be helpful in figuring out
the solution direction. Though it does not spell the specific coded
details out, it does help to remove the communication barrier between
client and coder.... Or so I hope..... shrug (there is no solution to the
human choice factor.... it has to be a choice to understand, ultimately
and apparently.)

Thanks John the wall.


---
*3 S.E.A.S - Virtual Interaction Configuration (VIC) - VISION OF VISIONS!*
   *~ ~ ~      Advancing How we Perceive and Use the Tool of Computers!*
Timothy Rue      What's *DONE* in all we do?  *AI PK OI IP OP SF IQ ID KE*
Email @ mailto:timrue at mindspring.com      >INPUT->(Processing)->OUTPUT>v
Web @ http://www.mindspring.com/~timrue/  ^<--------<----9----<--------<