![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
Entry tags:
(no subject)
First week finished. Have environment *mostly* set up. Tired. Still sick, but rather better. Have been getting acceptable amounts of sleep.
Now that I'm coding in the Windows world, and it is a very different world, I have been paying more attention to what technologies MS is cooking up. One of the things that's been getting buzz recently is LINQ, the Language INtegrated Query system,* a reasonable discussion of which can be found here. In short, it's embedding a thing kind of like SQL into an imperative language, working on more or less arbitrary data. I had heard vaguely about this, and I thought it sounded fairly interesting. You know, for a Microsoft project. And, since it's syntactic sugar for more typical constructions, I wondered whether someone had done anything like that in Perl, and if not why not. However, when I started thinking about how I would implement SQL queries in Perl, I ran into a number of troublesome issues, mostly involved with handling selection from multiple sources without a lot of cumbersome overhead in disambiguation. In a DB environment the rigid table definitions allow you to do that in a fairly non-ugly way, and it's still hidden SQL magic, so how you deal with it for unpredictable arbitrary data. Well, of course, the guys who put together LINQ must have come up with some solution, I figured, so I went and looked into it a little more.
So, it turns out they seem to only let you select from one source, and although it's implied I haven't seen any examples yet that select more than one element from that source. And, you know, if we're looking at
*Which should be LIQ. People are so sloppy with acronyms. Then again, I'm in the acronyms-can't-be-compressed-in-other-acronyms camp, so from my perspective reform is rather a lost cause.
Now that I'm coding in the Windows world, and it is a very different world, I have been paying more attention to what technologies MS is cooking up. One of the things that's been getting buzz recently is LINQ, the Language INtegrated Query system,* a reasonable discussion of which can be found here. In short, it's embedding a thing kind of like SQL into an imperative language, working on more or less arbitrary data. I had heard vaguely about this, and I thought it sounded fairly interesting. You know, for a Microsoft project. And, since it's syntactic sugar for more typical constructions, I wondered whether someone had done anything like that in Perl, and if not why not. However, when I started thinking about how I would implement SQL queries in Perl, I ran into a number of troublesome issues, mostly involved with handling selection from multiple sources without a lot of cumbersome overhead in disambiguation. In a DB environment the rigid table definitions allow you to do that in a fairly non-ugly way, and it's still hidden SQL magic, so how you deal with it for unpredictable arbitrary data. Well, of course, the guys who put together LINQ must have come up with some solution, I figured, so I went and looked into it a little more.
So, it turns out they seem to only let you select from one source, and although it's implied I haven't seen any examples yet that select more than one element from that source. And, you know, if we're looking at
from x in FooCollection where x.size = 6 select x.namewhich at any rate is going to be converted into
FooCollection.where(x => x.length == 6).select(x => x.namethen I might as well stick with
map {$_->name} (grep {$_->length == 6} @foo_collection)I can't quite do the same thing in Java, but there's a well-established filtering pattern with iterators that comes to the same thing. I'm disappointed, but that's what I get for thinking Microsoft might have done something innovative.
*Which should be LIQ. People are so sloppy with acronyms. Then again, I'm in the acronyms-can't-be-compressed-in-other-acronyms camp, so from my perspective reform is rather a lost cause.
no subject
chop @lines;
etc.
no subject