I only took a peek for a few seconds at this video and could make this code: static public Predicate CreatePredicateFromLambdaExpression(Expression theLambdaExpresssion) work in matter of seconds! Minutes ago I was at loss what to do with it. Some good teaching there sir!
Why we can apply lambda to Delegate and can apply lambda to Expression, but can't apply Delegate to Expresion? We can conver Expression to Delegate, but can't convert Delegate to Expression???? Two different behaviors: When we apply lambda to Delegate, compiler convert lambta to a method, but when we apply lambda to Expression, compiler convert lambda to a Expression. Why compiler can't convert Delegate to Expression?
That is generally not true. Even way back, UCSD Pascal used P-code, decades ago, and all of the languages in the Java family compile to JVM byte code, which almost no real processors can execute without a virtual machine running it, and of course all .Net languages compile to what I think is no longer supposed to be called MSIL (Microsoft Intermediate Language) but now I think we just call IL to be less partisan. At some points, some people might have said "then they aren't real compilers!" but if you said that now everyone would think you were silly. There have been some languages that were just "front ends" to something else, so if the output was say, human readable C that you would still need to put thru a C compilation phase, then you could say that isn't a compiler. So you could say "compilers translate our code from human readable form into something more runnable and less readable" yes, but all the way to executable x86/amd64/ARM code -- no, we don't strictly limit the term that way in modern discussions, but would specify "a compiler generating native code" if we meant only those.
Everything I wrote in the other reply is true and correct, but in this case, since you made that comment on this particular video, I presume you were confused by something else going on. In earlier languages, there was normally a very direct translation by the compiler from what you wrote to native code (or sometimes an intermediate code). C# over its history, has increasingly contained lots of things that looked like magic, for example, yield return, delegates and events, async/await and many other things covered in different playlists on this channel. Spoiler alert -- none of it is really magic, in all of those cases, the compiler is invisibly writing a bunch more code for you that you don't normally see, but if you stepped thru it in the disassembly mode in the debugger you would see that it is all just boring normal code like you would write yourself, but didn't have to. We use the term "syntactic sugar" for things like that, because what you type and read is simple and easy and magical-looking, but what it actually becomes behind the scenes is bigger and more boring, when you look at it. This video in particular, and this channel but not many others in general, will show you what the compiler is doing for you, for those that care. That all still happens at the C# level. Some of these things are directly reflected in the intermediate code with special instructions or features, others just look almost the same as if you had written all those extra pieces yourself. That intermediate code is what is finally output by the compiler, and then the JIT-compiler goes the rest of the way at run time and turns all the Intermediate Language into native code. The playlists on this channel mostly don't talk about the last part, but do quite often show you the non-obvious things that the C# compiler does for you to make your relatively simple C# code loaded with magic into the larger amount of non-magical, you-can-see-how-it-all-works Intermediate Language. Not everyone needs or wants that, but those that do love this channel with a passion. Also, this channel has snarky humor and a lot of cows, so some people like it for those reasons, and accidentally learn the stuff described above.
@Jamie King that laugh @5.12 🤣🤣🤣 I have never seen or heard anyone more excited about a lambda expression
i am working with Linq for a year at work and i entered to learn about dynamic linq, your explanations are great!!
I only took a peek for a few seconds at this video and could make this code:
static public Predicate CreatePredicateFromLambdaExpression(Expression theLambdaExpresssion)
work in matter of seconds! Minutes ago I was at loss what to do with it. Some good teaching there sir!
wonderful video
Great video!
this is amazing. I see you did not post anything for a while, hope you are doing well. thank you sir.
How to solve eqution with hidden x variable by C#. Do you know ?
you are my hero.
where can i get the compiler batch file that you have used there ???
So if I want to use
select(x => x.foo);
it will be the same if I use:
Expression i = i.foo;
select(exp)
?
Wonderful explanation... Thank you!!
Is the compiler batch file available ?
It's super simple to write:
csc mainclass.cs
reflector mainclass.exe
Great job explain a tough subject
Why we can apply lambda to Delegate and can apply lambda to Expression, but can't apply Delegate to Expresion?
We can conver Expression to Delegate, but can't convert Delegate to Expression????
Two different behaviors:
When we apply lambda to Delegate, compiler convert lambta to a method,
but when we apply lambda to Expression, compiler convert lambda to a Expression.
Why compiler can't convert Delegate to Expression?
this dude is funny
Nice
i always thought compilers turn all our code into binary
That is generally not true. Even way back, UCSD Pascal used P-code, decades ago, and all of the languages in the Java family compile to JVM byte code, which almost no real processors can execute without a virtual machine running it, and of course all .Net languages compile to what I think is no longer supposed to be called MSIL (Microsoft Intermediate Language) but now I think we just call IL to be less partisan. At some points, some people might have said "then they aren't real compilers!" but if you said that now everyone would think you were silly. There have been some languages that were just "front ends" to something else, so if the output was say, human readable C that you would still need to put thru a C compilation phase, then you could say that isn't a compiler. So you could say "compilers translate our code from human readable form into something more runnable and less readable" yes, but all the way to executable x86/amd64/ARM code -- no, we don't strictly limit the term that way in modern discussions, but would specify "a compiler generating native code" if we meant only those.
Everything I wrote in the other reply is true and correct, but in this case, since you made that comment on this particular video, I presume you were confused by something else going on. In earlier languages, there was normally a very direct translation by the compiler from what you wrote to native code (or sometimes an intermediate code). C# over its history, has increasingly contained lots of things that looked like magic, for example, yield return, delegates and events, async/await and many other things covered in different playlists on this channel. Spoiler alert -- none of it is really magic, in all of those cases, the compiler is invisibly writing a bunch more code for you that you don't normally see, but if you stepped thru it in the disassembly mode in the debugger you would see that it is all just boring normal code like you would write yourself, but didn't have to. We use the term "syntactic sugar" for things like that, because what you type and read is simple and easy and magical-looking, but what it actually becomes behind the scenes is bigger and more boring, when you look at it. This video in particular, and this channel but not many others in general, will show you what the compiler is doing for you, for those that care. That all still happens at the C# level. Some of these things are directly reflected in the intermediate code with special instructions or features, others just look almost the same as if you had written all those extra pieces yourself. That intermediate code is what is finally output by the compiler, and then the JIT-compiler goes the rest of the way at run time and turns all the Intermediate Language into native code. The playlists on this channel mostly don't talk about the last part, but do quite often show you the non-obvious things that the C# compiler does for you to make your relatively simple C# code loaded with magic into the larger amount of non-magical, you-can-see-how-it-all-works Intermediate Language. Not everyone needs or wants that, but those that do love this channel with a passion. Also, this channel has snarky humor and a lot of cows, so some people like it for those reasons, and accidentally learn the stuff described above.