We then find out that there are times we want something that is a lot like, but not quite, a native Perl data structure. The fact that there is no obvious way to do that is a self-inflicted injury, and magic is the band-aid that Perl applies.

But users often what behaviour that it a lot like something that Perl does. tie is a wrapper around the magic band-aid to give users a band-aid for that problem.

But people often want something that is a lot like something that Perl does, but not exactly! Which introduces tied - Perl's way to lift the band-aid and scratch the raw wound left beneath.

At some point I wonder whether it wouldn't be easier to just not injure ourselves in the first place?

So Perl intertwines expectations about behaviour with syntax.

Quick, what does $bar = $foo{bar} mean? What does it do? How do you know, you've just seen syntax?

Perl lets you tie a behaviour to a particular syntax, because people relate syntax with behaviour. Using the right combination, this makes things easier because you raise the level of abstraction and reuse a familiar conceptual model including its syntax. It makes it appear that there is a special builtin type that eg. knows that you want the lines of a file as an array and lets you work with that array (conceptually and notationaly) just like any other array. How cool is that? :-)

tied is the way to get past tie's illusion and the only thing you'll find is that you were tricked, but you should have known that all along. That you need tied to remind you just goes to show how effective tie can be in creating the illusion in the first place.

— Arien

You miss the point.

Suppose that you want to create an interface to a dbm. Making it look like a hash is an obvious way to do it. (If you try to do it with nested data structures you have trouble, but let's ignore that.)

Now suppose that your dbm offers some useful features that hashes don't - like granular locking for cooperation between processes. How do you expose that naturally? You can't extend the tie solution to do it. The available behaviour for a hash is fixed by Perl's syntax - to get something with extensible behaviour you have to make it obviously extensible from the start. The native datatypes aren't. So you either tell people to peek using tied (wrecking the illusion) or else (more efficiently) you don't pretend to be a hash from the start.

With this example in mind, here is my criticism. Perl's syntax creates a strong image of what a built-in datatype should look like. Built-ins are not extensible. tie allows a pretty effective illusion of a built-in. But if you have something that is a lot like a built-in, but its behaviour needs to be extended in some direction, Perl simply doesn't have a clean solution. Those two notions simply do not conceptually go together in Perl, looks native means isn't extensible and vice versa.

It doesn't have to be that way. For instance in Ruby the native datatypes can trivially be extended, and if you need a different implementation, then the MetaRuby package makes it easy to write new datatypes that behave like a built-in. This is the equivalent of tie except that no new concept needed for it, and there is no conflict between using it and extending the behaviour of your new thing in some interesting way that looks nothing like what the native datatypes do.

Of course you give up autovivification because the syntax no longer gives hints for the datatype. But then again you can swap between hashes and arrays more easily. And, of course, by not making it look hard you give up the appearance of being a genius for figuring it out...