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

Ion Todirel
buuu

cooool

kettch

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.

SecretSoftware
Code to live, but Live to code.

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?).

aghiondea2

Can't wait to see this film!

Ion Todirel
buuu

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? do you have some genial code and dont what to share with us? Tongue Out

You can always use a 3rd party obfuscator, also obfuscation just make code decompiled code harder to read, whatever you do, even writting code in a compiler that compiles to native there always will be crackers that will break your code and find all secrets.

SecretSoftware wrote:
Also, when will drivers be written in Managed code?

not too soon IMO, btw check this.

aaron.axvig

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?

RGabo

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 Smiley

staceyw
Before C# there was darkness...

"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.

odujosh
Need Microsoft SUX now!

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.