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

[Andrej Falout]

Warning : Off topic, probably...


> > (Warning: crude end-user logic ahead...)
>
> Sorry, I had no intention to start a flamewar here; I was just curious
> about your rationale.
>

Same here :-)


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


In a sense that Python is a much more universal, and capable tool, but at
the same time by design a much more complex one too (compared with Bash). As
a result, doing things in Bash is simpler and faster - as long as one does
not need advanced functionality Bash does not have.


> > That's why I dont like 3GLs; they do things like "cleaning up the
> > state",
>
> In general, programs do that, if so instructed.  Bash has some inbuilt
> state-cleanup, as does Python, but it's not the built-in stuff I worry
> about.


See, I am quite proficient with Bash, but I still did not know I can "clean
up the state" with it :-) The concept has no meaning for humans, try asking
your mother ... (Unless she is a programmer)

(Yes, I DO know, but I do not WANT to know. I resent machines trying to pull
me down on there level. I want machine to understand my way of thinking,
instead me having to think as a machine)

> 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?
>
> It means "restoring the invariants of the system."  For example, it
> might mean removing lock files, releasing resources, rolling back
> partially-completed operations, etc.


Yes, that I do ... Except releasing resources in Bash, that's called 'exit'
;-)

It's interesting that you make this objection, since as far as I can
> tell, "handle the error" essentially means "respond somehow" --- which
> could amount just about anything depending on the circumstances,


Correct. That I like :-)


> whereas "clean up state" actually has some specific meaning.


...which in my head amounts to "respond somehow". I guess I am trying to be
pragmatic in a human way... or maybe just my own way...


> > 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)
>
> I have no clue why you view "handle the error" to be less jargon-y than
> "clean up state."
>

Maybe I'm just too old. For me, there is little difference between 70's
"time share" concept and "Cloud computing" of today. Other that the Time
Share is a concept familiar to most people, and Cloud Computing is a 'catch
all' marketing buzz of the day that smells of salesmen and Technology
"Gurus"...

>>   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 guess I'm not one of those people who would benefit most, then.


If you can find your way in Python, I doubt you would have any issues with
Bash. Reverse is unlikely true for majority. Of end users, that is.


> > I'm sure Python is great, but it is just not needed in this case.
>
> Nor is bash, right?  One could do the same thing with any number of
> programming languages, from assembly language to Haskell.  If the fact
> is that you're just more comfortable programming in bash than in Python,
> please just say so.


Well absolutely! But even if I was, I would have a hard time seeing the
advantage in it for this task. I am reasonably good with Java and C, almost
as good with Perl, but can find no reason to use them here.


>  That's a good enough reason for me.  I happen to be
> the opposite, and I tend to assume everyone who can program knows python
> (which is probably true at some level even if they've never seen a line
> of it before).  So if that's not the case, my bad.


After I release the script, take a look, and name one function that would be
a) simpler to do and/or b) significantly functionally better from end-user
perspective - if done in another language.


> > 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.
>
> I'm both a Tahoe beginner and an end-user, for what it's worth to you.


Thats whats great about OpenSource - maybe you can pick up few ideas and
make them better by using tools of your own preference - or maybe even
rewrite it to appeal to folks with same preferences as you have.

I'm just happy to have parallel backups management, monitoring and progress
reporting of my backups in a easy to use tool that hides complexities of the
Tahoe and saves me of repetitive tasks...


Andrej Falout
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://tahoe-lafs.org/pipermail/tahoe-dev/attachments/20090619/8b6d4b60/attachment.html>