[tahoe-dev] v1.5 here we come!

[Andrej Falout]

(Warning: crude end-user logic ahead...)


> why not Python?


why not Bash? :-)

Anyhow, I am a big fan of the right tool for the job & KISS approach. Python
would be a complete overkill.


>  You're probably way better than I am at shell scripting,
> but I find that once a shell script gets that big, it's really easy to
> end up with something that fails to report errors or clean up state
> properly.


That's why I dont like 3GLs; they do things like "cleaning up the state",
and my head just wants to "handle the error". Even my grandmodher will
understand what I'm doing when I handle the error.... what the hell does
"cleaning up the state" mean? I find this kind of jargon highly anoying, but
more importantly, very unproductive and a great obsticle to wider adoption,
understanding and therefore sharing. Of not only Python... (Hint: try
reading this list with jargon detector on)

  The only reason not to use Python in those cases is a desire
> to avoid dependencies... but tahoe already depends on Python.


For people that would benefit the most from my script, I suspect it is far
greater likelihood of knowing (or being able to adapt a line or two for
there need) Bash, then Python. I'm sure Python is great, but it is just not
needed in this case.

The fact that nobody from the Python experts pool congregating here found
the need to write similar front-end, also shows that they probably dont even
need one - this is going to be of greatest use to beginners and end-users,
like me.

Andrej

PS. I am the end-user by choice. It is a state of mind. In some other
projects, I am the developer. And yes, l that's a state of mind too :-) If
curious, see Aubit4gl project on SF
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://allmydata.org/pipermail/tahoe-dev/attachments/20090618/37cc2fd4/attachment.htm