Re^3: A DWIM too far?

Here's something else you might find bizarre. There's a programming language many people greatly enjoy using that has very little stricture by default, lots of similar but slightly different ways to do the same thing, an object system that lets you use whatever type of datastructure you damn well please, and generally encourages a culture of "stay out of my living room because I ask, not because I have a shotgun." Perhaps you find it bizarre, but I find it downright refreshing.

I feel the same way about cooperative locking, non-exclusive opens, and -- to a far lesser extent -- the overwriting rename(). Do I wish there was a reasonable way to rename without clobbering-by-default? Yes, I do. That doesn't make me like the current behavior any less. Personally, I like a platform that lets me do what I want, even if what I want might be shooting myself in the foot. If this mentality is so strange to you, I wonder how exactly you've managed to stick with Perl as long as you have.

Comment on Re^3: A DWIM too far? Download Code

Replies are listed 'Best First'.
Re^4: A DWIM too far? by BrowserUk (Patriarch) on Jun 18, 2004 at 03:04 UTC
There is a difference. Most of those permissive behaviours that you describe,and which I mostly relish, are controlled entirely within the auspices of my program! The destructive behaviour of rename means that I may well be destroying someone else's data, or someone else accidentally or deliberatly destroying mine. I consider that a fundemental distinction. Examine what is said, not who speaks. "Efficiency is intelligent laziness." -David Dunham "Think for yourself!" - Abigail "Memory, processor, disk in that order on the hardware side. Algorithm, algoritm, algorithm on the code side." - tachyon	[reply]
Re^5: A DWIM too far? by revdiablo (Prior) on Jun 18, 2004 at 04:47 UTC
It doesn't seem like such a fundamental difference to me. Modifying the wrong hash element in an inhereted object can cause data loss. Changing a global sub (such as you do here) can cause serious problems if not done with care. All the behaviors "within the auspices of [your] program" are not necessarily as limited as you seem to imply. And besides, all the behaviors of an operating system are controlled entirely within the auspices of one computer. The difference I see is not fundamental, it is one of likelihood. The chances of problems caused by permissive behavior are less at the application level than the operating system level, but they are still there. As I said before, I like a platform that is as permissive as possible, and that goes for programming langauges as well as operating systems. After all, what is an operating system but another programming platform?	[reply]
Re^6: A DWIM too far? by BrowserUk (Patriarch) on Jun 18, 2004 at 05:26 UTC
It doesn't seem like such a fundamental difference to me. Then you either haven't taken the time to think before commiting to that opinion, or you simply haven't bothered to consider the possibility that a unix behaviour could possibly be flawed. Modifying the wrong hash element in an inhereted object can cause data loss. Modifying the wrong hash element is entirely within the control of my application. Overwriting or deleting a file created by a different application (or vice versa) is not. Changing a global sub (such as you do here) can cause serious problems if not done with care. I didn't "do it". I simply reminded someone else how Perl would let them do it, should they choose to. And besides, all the behaviors of an operating system are controlled entirely within the auspices of one computer. And if the files resides on a network drive or NFS mounted filesystem? The difference I see is not fundamental, it is one of likelihood. The chances of problems caused by permissive behavior are less at the application level than the operating system level, but they are still there. What makes the difference fundemental is that I can code my application to test for and avoid modifying the wrong hash element. To safely rename a file requires that the OS detect and inform me about potential collisions, as any test I code into my application opens a race condition on a multi-tasking system. My OS does this at the system API level. The thing that took me by surprise was that the Perl implementation chose to override this. Examine what is said, not who speaks. "Efficiency is intelligent laziness." -David Dunham "Think for yourself!" - Abigail "Memory, processor, disk in that order on the hardware side. Algorithm, algoritm, algorithm on the code side." - tachyon	[reply]