I've begun to notice that as computing power grows, the expectations of the customers also grow. In fact, they are wanting more and more things to "just work". Having word processors that suggest alternate spellings and video cameras that automatically steady an image for them are things that people are beginning to demand, if not assume. There are various ways to accomplish these things, but I do find it interesting that in actual code, these algorithms that "just work" are often rewritten from scratch.
This is not good.
If I have a need to fetch documents from resources, it might be very convenient to just say document = fetch(resource) and have the computer figure out the gnarly bits itself. If we were to reimplement the code for every type of resource, it could get annoying. Instead, it would be nice to do this:
open my $doc, '<', 'http://www.somesite.com' or die ... open my $doc, '<', 'ftp://www.somesite.com' or die ... open my $doc, '<', '/some/local/file' or die ...
In fact, I've seen proposals for this in Perl 6 (I can't recall if it's going to be followed up on) and that would be a Good Thing, yet we still wind up going through the "open, read/write, close" cycle for every document. That's grunt work that should go away if we can figure out a clean way of doing this. However, while we recognize this in the small, for general problems, we don't. For example, at my work we are constantly resolving the problem "Given X, infer Y". There is a strong correlation between X and Y, but there is never a simple algorithm that will generate Y. We keep recrafting things by hand and, as a result, have a bunch of hard-coded, inflexible solutions. That's why I am doing my neural net research.
Unfortunately, I'm coming into AI rather late in the game and I'm doing this on the side so I can't claim to be particularly good at this, but I see the potential. With AI, we can start looking at general solutions to problems. Instead of generalizing specific tasks, we can start generalizing vague tasks. To a certain extent, many AI algorithms can be though of as Design Patterns for vague problems.
These things are quite possibly the future of computing. Even though many people will continue to brute force custom solutions, as we gain a better understanding of AI, I think more tools will be available to help people find cleaner solutions to these vague problems. I also think that programmers who start learning these tools and applying them to real-world problems will make themselves more valuable.
In 5.8 I'm sure can you do something like: open my $fh, \get($url)?
Re:leaky abstractions
Ovid on 2003-09-29T18:28:41
We've had this discussion before and I definitely see your point. However, what you bring up is the sort of problem that I'm talking about. Ultimately, these document fetching mechanisms all boil down to "open, read/write and close". There are a few fiddly bits in there, but I don't want to deal with them. I want to simply "fetch a document from a resource". To put this in perspective, consider the JCL (job control language) used by mainframe programmers in the 60s to work with a file (and this type of stuff is still used today).
//NEWFILE DD DSN=B7707O.DDA50010.APDATA,
// DISP=(NEW,CATLG,DELETE),
// UNIT=DASD,
// SPACE=(CYL,(150,150),RLSE),
// DCB=(RECFM=FB,LRECL=80,BLKSIZE=6400)Basically, we say where the file is (DSN). That's great. Then we say whether or not we're using a new file or an old one and what to do with the file upon success or failure of the JCL (DISP). Then we specify how we're storing it (UNIT), how much memory it can use (SPACE), how the records are laid out (DCB), etc. Those were the fiddly bits of the sixties and I suspect that most programmers back then would have had the same type of objections to open my $fh, $file or die $! as you do about "leaky abstractions".
It's not that what you're pointing out is irrelevant, it's that designing smarter abstractions and better protocols will necessarily stem from someone saying "hey, this is grunt work!"
Re:leaky abstractions
chromatic on 2003-09-29T19:11:44
PHP has this "feature". It's lead to quite a few security holes. Granted, trusting user input is a worse decision, but abstractions can occasionally hide things that shouldn't be hidden.
