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
_______________________________________________ tahoe-dev mailing list [email protected] http://allmydata.org/cgi-bin/mailman/listinfo/tahoe-dev
