Anders Hejlsberg and Chris McConnell: Reflections on LINQ, Desktop Search, WinFS, Functional and Int

I haven't watched the video yet, but I cheered out loud when I saw Anders. He's just cool.






Yeah, that might have been kind of creepy. I'm done now.

Interesting..

questions to Andres, when is it going to be harder for MSIL to be decompiled into rich code? Can C# compiler (managed compilers) have obfuscation natively in them so I dont have to worry about my assemblies being decompiled on the fly?

Also, when will drivers be written in Managed code?



With linq, from a performance perspective, is using Linq to query sql more efficient or using sql stored procedures more efficient?


Lastly, what is going to be in C# 4.0? (C# transactional programming model for multi-core processing?).

Can't wait to see this film!

Ion Todirel wrote:



SecretSoftware wrote: questions to Andres, when is it going to be harder for MSIL to be decompiled into rich code? Can C# compiler (managed compilers) have obfuscation natively in them so I dont have to worry about my assemblies being decompiled on the fly?

i dont understand why this is a problem for you?

Well, maybe it's bad if users can leaf through your source code looking for vulnerabilities?

kettch wrote:

I haven't watched the video yet, but I cheered out loud when I saw Anders. He's just cool.


Yeah, that might have been kind of creepy. I'm done now.

I did the same and laughed out loud when I read your post. Way to go Anders!

It was really interesting to hear Anders talk about intentional programming and what he thinks the core problems are. I think the 'common building blocks / baseline' that are missing between domain-specific expression is what might be the biggest issue. A friend of mine also made an interesting notion on how there is no exact notion of what 'debugging' would mean in an environment like this. Would you debug on the concrete level? Would you try to debug on the abstracted, problem-class solving level? I'm not even sure what that would mean.

It will be really interesting to see where this goes.

and re: functional languages, just take a look at python, ruby, boo, F# getting into the .NET ecosystem. The common building blocks are all in place and it will be really cool to be able to not just choose between general purpose, imperative languages for problem solving but between classes os languages, such as functional languages and combine those with existing and well-known methodologies.

It's a fun time to be a developer / engineer

"Also, when will drivers be written in Managed code? "

IIRC, there is a managed driver framework in Vista already.

"With linq, from a performance perspective, is using Linq to query sql more efficient or using sql stored procedures more efficient?"

Linq can query either.  After linq creates the sql string, the perf is the same as if you created the sql string yourself.  Naturally there is some overhead in linq to process the results.  But that is probably a wash as you would need to do it anyway.

Yes you do take a perf hit from not using Store procedures. (SQL Server is not given a chance to prechoose the execution plan)

Whats compelling about linq is the composibility. Doing Custom Where clauses on the fly is not something you can do with store procedures without a considerable time investment. Your other option is you can write a store proc for every case. You end up with a lot of stored procs. The second part of composibility is result set to object translation. My jaw dropped when they showed Linq ability to auto gen partial classes.

My suggestion would be to write basic CRUD with store procs. (Get 1 by ID, Get All, Update, Delete, Insert) Use LINQ for everything else. AFTER seriously bench marking the difference between a store proc and using equivelant LINQ syntax in time and resources.

I think at the point you you start hitting scalability or perf issues is where you probably have the money to shell out for an ORM mapper. Or just use Blinq.

I was searching for searching with desktop search via OLE DB, and I found this page. Interesting stuff!  

On another note, can LINQ query objects that do not implemet iQueryable?  This could be usefull for finding features in add-ins... or maybe not. 

I hope down there road there is some serious performance gains over using stored procedures.

Think about what is happening. LINQ is building decision trees, translating to SQL - sending it across the wire. SQL server takes the SQL builds decision trees and executes it. 

It doesnt take much imagination to elliminate a lot of overhead. Not to mention the performance advantage against competing products.

Stored procedures are tools of the dinosaur age. The sooner we get rid of them the better.

spiked wrote:

I hope down there road there is some serious performance gains over using stored procedures.

Think about what is happening. LINQ is building decision trees, translating to SQL - sending it across the wire. SQL server takes the SQL builds decision trees and executes it. 

It doesnt take much imagination to elliminate a lot of overhead. Not to mention the performance advantage against competing products.

Stored procedures are tools of the dinosaur age. The sooner we get rid of them the better.

I agree.  It would seem their could be a way to eliminate that round-trip to/from a sql string. Especially if linq already "knows" the schema it should be able to gen some hints already on the client side and transmit to server with some new internal query format - so in effect, linq becomes the native query language.  Makes even more sense inside the server (i.e. sqlclr).  Also, we can think of c# not only as a language, but as a markup.  So like sqlmetal, we can describe tables, but they work both ways.  They can both build the table and define it for query.:

[Security(Everyone=ReadOnly)]
public class MyTable
{
      public string Name;
      public int Age;

      public void Clear(); // One type of intrinsic method on tables.
      public static string[] GetNames(string name) // new sproc
      {
           return MyTable.Where(x => x.Name == name);
      }
}

Change your class, recompile, and the db is changed to match (with care).  Properties, fields, public, private, and internal could all be used.  I guess this would then become .NetdB.

I guess you could also allow extention methods on tables.

Interesting video, as always Anders is enlightening, but Chris McConnell is a WinFS hater

Just because a schema doesn't satisfy everybody, doesn't mean schemas are a bad idea! You might not be able to create a schema that satisfies everyone, but it is an order of magnitude simplier to create a schema that satisfies one organization or describes how a particular common application is modelled!

And the performance argument about WinFS not being able to perform? Because it is rigid and normalized? Sounds like FUD to me...

Round one to the desktop search guys, bring on round two!

Improving Full Text Search in Documents (see my Blog article)

Traditionally all text in a document is treated equally in the search ranking ..
But let us assume a typical document with following content :
 Document Name
 Document Title
 Section Headers
 Paragraphs
 foot notes
 etc...

If one is searching with a naked eye , surely the bolder and bigger the text the higher relevance it would be given ..
So if a searched phrase or word occurs in a section heading in one document and occurs in a foot note in another document .. The  search engine should rank the former document higher than the latter ..

This would lead to Search engines that should understand the formatting and structure of the document and would result in a more intelligent ranking algorithms ..
So perhaps in the future we will have a "Text-Format-aware"  search engines .. Maybe you should get started creating Word DOC, PDF, XLS ..etc .." filters that can understand the formatting of the documents and that would result in a more realistic ranking ...

OK .. I think this is a new IDEA so I'will be applying for a patent ..

Blinq's just a web page generator.  It uses LINQ to SQL underneath.

I would recommend taking a pythonic approach to perf:

1) write in the clearest, safest manner (ie, LINQ)
2) *measure* the perf
3) rewrite the bottlenecks in something more arcane
4) re-measure to see if it was actually worth the effort.  If not, for god's sake revert.

and, of course

5) learn how to do multi-threaded programming, correctly.  Absolute speed is often less important than perceived responsiveness.

The bottom line is to be lazy, and make use of what the framework provides.  But know what you're doing and don't just assume that the rules for performance in one environment automatically apply to another environment.

There are a few things not quite in the system, but IronPython, etc will drive those changes.  Part of Hugunin's mandate when he was hired by Microsoft was to make the CLR friendlier to dynamic languages.

And, of course, that often translates to enabling things in static languages...

IQueryable is intended for use with LINQ implementations that handle expression trees.  LINQ -- the basic, to-object, implementation -- just deals with things you can do with IEnumerable<T>.

Nothing in theory (to my knowledge) prevents you from creating a server that accepts expression trees, except that expression trees are not, in the general case, serializeable.  However, if you're willing to restrict cases, you could do so.

SecretSoftware wrote:


Also, when will drivers be written in Managed code?

http://research.microsoft.com/os/singularity/