Adding LINQ to Visual Studio: Does this change everything?
Merging JOIN and UNION into a procedural language
SCOTT FULTON: Well, forgive me for saying this, but as ugly as doing certain things in ODBC used to be, it did have a kind of discrete bridge to it: the fact that, at the tail end, when you were converting the data to a format that was used by the rest of the program, it was done one item at a time, sequentially. Sometimes you had to create a for-next loop, and you took the string -- and hopefully you made sure it was a string -- and you assigned it to the string variable, and you parsed it with the val() function and you checked it for correctness...but at least it had that discrete rigidity to it. If you kept doing it the same way over and over again, you're bound to do it right. At least it had that going for it.
With LINQ, you actually are taking the Dr. E. F. Codd playbook here and handing it to people and telling them about unions and joins and recordsets, and mandating that they think of the data as recordsets and unions and joins, the way a SQL Server programmer might do. And for a lot of people, that's a stretch.
JASON ZANDER: I think what it'll come down to is, what problem are you trying to solve? You can still use LINQ in a singleton fashion, you can use libraries to match between the two. That's what you would have done without LINQ. You could have written some code for the XML, shredded it, and stuck it in a dictionary class, for example. Then I would take that data and go to ADO.NET, and I would go write up some kind of a SQL statement, and I would merge the two together and go write the code for that...As you say, once you develop a pattern, and if you're willing to follow that pattern and debug it and you're happy with it, well, certainly it's going to continue working. There's no issue with that whatsoever.
So the question is, if you have the opportunity to use something that eliminates a lot of that boilerplate code and use that as your new pattern, is that concept easy for you to understand, and can you now actually be much more productive writing that code?
I suspect that some of the statements, if it gets to be too complicated, people won't use them and will merge the old-fashioned way. I think a lot of people will look at it and go, "Wow, if it's really as simple as sticking a JOIN keyword between two clauses and matching up two variables, and I can do that whole thing in one line of code...I might want to try that."
SCOTT FULTON: I think it was 24 years ago, I published a treatise on some of the things I thought a next-generation operating system should really have, and one of the things was, we need a dynamically executable SQL-based query language for data on the command line. This was back when we just barely premiered DOS 3.0. Ever since, I was told it would never happen. LINQ is the closest thing to that 1984 thing I wrote.
JASON ZANDER: One of the things I love about this industry is, every so often, we have perhaps good concepts -- what you describe is intuitive and it makes sense, and lord knows I wish we had had that back then. But then, what'll happen is, eventually we'll figure out -- either the hardware will come along or the technology closes the gap where we make a leap on the concepts that eliminates complexity. Web services is another good example of that, I think XML is a good example. Even the CLR and dynamic languages have been around since LISP, which is 40-some years.