Re^2: Paul Graham on Great Hackers

[jdporter]

that's exactly what Perl should do

should do?

That is absolutely absurd. You may as well say that an entire database (table space) should appear in perl as one big string. No? Then where do you draw the line?

It is possible (via modules such as Tie::File and Tie::MmapArray) to get behavior like what you're talking about; but it shouldn't be the only way to work with files. Sometimes a file is too large to load all at once. Sometimes a file is really a stream/pipe/socket. Sometimes a file is being written by another process at the same time. If you're a programmer, you need to know, and to handle these situations. Any proposal to require that files be abstracted as strings is naive at best.

[Jaap]

When i say one big string i mean that it would appear to be a scalar/string to the programmer, not that it is implemented as a big string. The same could indeed go for a socket for that matter.

edit: Not a database table, which has an inherent structure. Perhaps that'd be an array of arrays.

I'm talking only about the interface to the file/socket. You could concatenate something to a string which would write it to a socket.

[jdporter]

Why is that better? I think about the typical operations (methods) that are pertinent for strings, and I don't see how they fit on a database. So length gives me a count of the total bytes in the database. Why do I care? If I parse this database "string" on, say, ';', the chunks I get are meaningless. No, mapping a String abstraction onto a file or database is (in general, I'm saying) a complete failure.

[diotalevi]

A hash of arrays would be more appropriate assuming you mean a typical RDBMS-ish system. There is no order to the rows in a table and you'd violate that by providing an array. Maybe if we had an array with no order then you could say that.

[runrig]

And of course there's DB_File (and MLDBM) where you can tie a hash to a database (though not a RDBMS or SQL). How's that for abstraction?