If you had to explain Lambda expressions to a 5th grader (10/11 years old), how would you do it? And what examples might you give, or resources might you point them to? I may be finding myself in the position of having to teach this to 5th grade level developers and could use some assistance.
[EDIT]: The "5th Grader" reference was meant to relate to an American TV show which pits adults vs. 5th graders in a quiz type setting (I think). I meant to imply that the people who need to be taught this know nothing about Lambda's and I need to find a way to make things VERY simple. I'm sorry that I forgot this forum has a worldwide audience.
Thanks very much.
Just call it a function without a name. If she has not been exposed to much programming her mind not already have been calcified in thinking that all functions should have names.
Most of the complexity related to lambda expressions is caused by complicated naming and putting it on a marble pedestal.
Lot's of kids create great websites with lot's of Javascript stuff. Chances are they are using lambda expressions all the time without knowing it. They just call it a 'cool trick'.
I don't think you need to explain lambda expressions to kids aged 10-11. Just show them how lambda expressions look like, what you can do with them, and where you can use them. Kids in that age still have the capability to learn something new without relying on analogies to understand it.
Lambda expressions are what I consider higher order programming. Rigorous explanation will require extensive prerequisite learning. Certainly, this is not practical at the 5th grade level.
However, it might help to just cover some concepts by example in a way that mirrors real life physical situations.
For instance, a scale is a sort of a lambda expression. It tallies the mass of the objects placed on it. It is not a variable because it does not store the number anywhere. Instead, it generates the number at the time of use. When used again, it recalculates based on its inputs. You can take it places and use it somewhere else, but the underlying mechanics (expression) is the same.
if he already understands what "function" is that you can say that it is the function that you need only once and therefore it doesn't need a name.
Anyway, if you need to explain functional programming I would recommend to try to steal some ideas from http://learnyouahaskell.com/ - it's one of the best explanations of ideas behind functional programming I've ever read.
Lambda expressions in c# are basically just anonymous delegates so when explaining what they are to ANYONE they need to understand in this order:
What a delegate is and what they are used for.
What an anonymous delegate is and how it is just short hand way of creating a delegate.
Lambda expression syntax and how it is just really a even more short hand way of creating an anonymous delegate.
Probably not the best thing to start explaining to a fifth grader if a cutting edge OO language (C#) didn't get it for 10 years.
Pretty hard to come up with an analogy for a function with no name... Perhaps it's significant because it's a less verbose way specify a callback?
I'm assuming you're actually looking for a basic intro for programmers, not actual 5th graders. (For 5th graders, Python or JavaScript tend to be best). Anyways, two good introductions to C# lambda expressions:
Explaining C# lambda statements in one sentence (and LINQ in about 10)
LINQ in Action
The first (disclaimer - my blog) will give you a quick explanation of the fundamental concepts. The book provides complete coverage of all relevant topics.
Related
I am in a new team. I am shocked by their coding guidelines.
Example:
strName
iCount
structRectangle
listCustomers
retVal (for the return value... that is really biting me... how someone can do this)
They demand to write the datatype before the variable with the argument that this way the developer knows everytime what datatype the variable is without scrolling up to the declaration.
Well that is true, but my argument would be then a method should not be longer than 30 lines (else put code in another method) which fits into a common 24" screen...
But I am not totally convinced because there are things like Action<T>, Dynamic, Func<T> in .NET. which force me too to go the same way and do "actionCustomers" for a delegate holding a method gettings a list of customers.
What advice can you give me as an alternative to e.g. "actionCustomers" which should render the argument of the team useless?
I would suggest that you adopt the coding style of the team you are coding with. They have adopted their style to deal with their own systemic problems. Unless you are in a position to judge their code (which it seems you are not) or you can appeal to a higher authority on code style (seems unlikely from your post) then, if you want to keep your job and demonstrate that you're a team player, you need to conform to the rules you've been given.
Why is datatype in variables bad coding style?
It's not. A relatively ancient form of it called Systems Hungarian Notation that actually encoded the type has received a lot of criticism for a lot of reasons, including redundancy, inconsistency, and poor readability. But that's not what you're dealing with. I sometimes find it helpful to include datatypes in my object names when I haven't fully decided on which container I'm going to use (list, no, set, no, dict... and usually in that order.)
This coding style is very useful when you are not using an IDE.
I often open old code files with Notepad++ (just to read it and convert to newer code, no need to open huge project to read one single file) and without this coding style, every time I see a variable, I have to search for its name inside the document just to find out its type. And that hurt my time schedule A LOT.
Long story short: you may not like the old school methods but they existed because people needed them. You will never know if one day you wish for it.
Encoding the type of a function into the name (so-called Hungarian
notation) is brain damaged—the compiler knows the types anyway and can
check those, and it only confuses the programmer.
Linus Thorvalds, Linux Kernel Coding Styles
I really love that quote.
It is clear that there are lots of problems that look like a simple regex expression will solve, but which prove to be very hard to solve with regex.
So how does someone that is not an expert in regex, know if he/she should be learning regex to solve a given problem?
(See "Regex to parse C# source code to find all strings" for way I am asking this question.)
This seems to sums it up well:
Some people, when confronted with a problem, think “I know, I'll use
regular expressions.”
Now they have two problems...
(I have just changed the title of the question to make it more specific, as some of the problems with Regex in C# are solved in Perl and JScript, for example the fact that the two levels of quoting makes a Regex so unreadable.)
Don't try to use regex to parse hierarchical text like program source (or nested XML): they are proven to be not powerful enough for that, for example, they can't, for a string of parens, figure out whether they're balanced or not.
Use parser generators (or similar technologies) for that.
Also, I'd not recommend using regex to validate data with strict formal standards, like e-mail addresses.
They're harder than you want, and you'll either have unaccurate or a very long regex.
There are two aspects to consider:
Capability: is the language you are trying to recognize a Type-3 language (a regular one)? if so, then you might use regex, if not, you need a more powerful tool.
Maintainability: If it takes more time write, test and understand a regular expression than its programmatic counterpart, then it's not appropriate. How to check this is complicated, I'd recommend peer review with your fellows (if they say "what the ..." when they see it, then it's too complicated) or just leave it undocumented for a few days and then take a look by yourself and measure how long does it take to understand it.
I'm a beginner when it comes to regex, but IMHO it is worthwhile to spend some time learning basic regex, you'll realise that many, many problems you've solved differently could (and maybe should) be solved using regex.
For a particular problem, try to find a solution at a site like regexlib, and see if you can understand the solution.
As indicated above, regex might not be sufficient to solve a specific problem, but browsing a browsing a site like regexlib will certainly tell you if regex is the right solution to your problem.
You should always learn regular expressions - only this way you can judge when to use them. Normally they get problematic, when you need very good performance. But often it is a lot easier to use a regex than to write a big switch statement.
Have a look at this question - which shows you the elegance of a regex in contrast to the similar if() construct ...
Use regular expressions for recognizing (regular) patterns in text. Don't use it for parsing text into data structures. Don't use regular expressions when the expression becomes very large.
Often it's not clear when not to use a regular expression. For example, you shouldn't use regular expressions for proper email address verification. At first it may seem easy, but the specification for valid email addresses isn't as regular as you might think. You could use a regular expression to initial searching of email address candidates. But you need a parser to actually verify if the address candidate conforms to the given standard.
At the very least, I'd say learn regular expressions just so that you understand them fully and be able to apply them in situations where they would work. Off the top of my head I'd use regular expressions for:
Identifying parts of a string.
Checking whether a string conforms to a certain format or construction.
Finding substrings that match a certain pattern.
Transforming strings that fit a certain pattern into a different form (search-replace, capitalization, etc.).
Regular expressions at a theoretical level form the foundations of what a state machine is -- in computer science, you have Deterministic Finite Automata (DFA) and Non-deterministic Finite Automata (NFA). You can use regular expressions to enforce some kind of validation on inputs -- regular expression engines simply interpret or convert regular expression patterns/strings into actual runtime operations.
Once you know whether the string (or data) you want to determine to be valid could be tested by a DFA, you have a choice of whether to implement that DFA yourself using your own code or using a regular expression engine. You'll find that knowing about regular expressions will actually enhance your toolbox and your understanding of how string processing can actually get complex.
Based on simple regular expressions you can then look into learning about parsers and how parsers work. At the lowest level you're looking at lexical analysis (where regular expressions work) and at a higher level a grammar and semantic actions. These are the bases upon which compilers and interpreters work, as well as protocol parser implementations, and document rendering/transformation applications rely on.
The main concern here is maintainability.
It is obvious to me, that any programmer worth his salt must know regular expressions. Not knowing them is like, say, not knowing what abstraction and encapsulation is, only, probably, worse. So this is out of the question.
On the other hand, one should consider, that maintiaining regex-driven code (written in any language) can be a nightmare even for someone who is really good at them. So, in my opinion, the correct approach here is to only use them when it is inevitable and when the code using regex' will be more readable than its non-regex variant. And, of course, as has been already indicated, do not use them for something, that they are not meant to do (like xml). And no email address validation either (one of my pet peeves :P)!
But seriously, doesn't it feel wrong when you use all those substrs for something, that can be solved with a handful of characters, looking like line noise? I know it did for me.
Today I found out about an interface I'd never heard of before: IGrouping
IEnumerable<IGrouping<YourCategory, YourDataItem>>
I am fortunate to have access to some of the best programming books available, but seldom do I come across these kinds of gems in those books. Blogs and podcasts work, but that approach is somewhat scattershot. Is there a better way to learn these things, or do I need to sift through the entire MSDN library to discover them?
Eric Lippert's blog. The real guts of C# - why there are some limitations which might seem arbitrary at first sight, how design decisions are made, etc.
Alternatively, for more variety, look at the Visual C# Developer Center - there's a whole range of blogs and articles there.
Oh, and read the C# spec. No, I mean it - some bits can be hard to wade through (I'm looking at you, generic type inference!) but there's some very interesting stuff in there.
The best place to start is Jon Skeet's C# Coding blog: http://msmvps.com/blogs/jon_skeet/
He regularly covers stuff you won't see anywhere else.
How about the Hidden Features series of questions?
Hidden Features of C#
Hidden Features of ASP.NET
And many more...
I personally like the way of discovering hidden features on my own while solving a specific problem. In the end, a hidden feature that you never needed to get something done is of questionable value. It just adds clutter to the brain.
The way to do it is to use the MSDN library to look things up. Then take a little time to look around what you found.
That's especially important with the pure API documentation. For instance, I just browsed to http://msdn.microsoft.com/en-us/library/system.xml.xmlreader.aspx (note how that URL is formed). When I look in the Contents pane on the left, I see everything from XmlDocument (and XmlDocumentFragment) all the way down to XmlReader. In the middle are some things I rarely or never use, like XmlNamespaceScope and XmlNodeOrder.
From time to time, spend a little time on "abstract knowledge". Sometimes, it's good to look up from the trees to learn your way around the forest. You never know when you'll need something you've learned to get you out of the woods.
For the people who don't know IGrouping:
http://msdn.microsoft.com/en-us/library/bb344977.aspx
I often read useful stuff on the Viual Studio Startup page and start clicking around to other keywords/areas. Not too promote StackOverflow too much, but you'll find some hidden gems here as well, simply by looking at how other people write code.
For example:
Hidden Features of C#?
I am trying to find information (and hopefully c# source code) about trying to create a basic AI tool that can understand english words, grammar and context.
The Idea is to train the AI by using as many written documents as possible and then based on these documents, for the AI to create its own creative writitng in proper english that makes sense to a human.
While the idea is simple, I do realise that the hurdles are huge, any starting points or good resoueces will be appriacted.
A basic AI tool that you can use to do something like this is a Markov Chain. It's actually not too tricky to write!
See: http://pscode.com/vb/scripts/ShowCode.asp?txtCodeId=2031&lngWId=10
If that's not enough, you might be able to store WordNet synsets in your Markov chain instead of just words. This gives you some sense of the meaning of the words.
To be able to recompose a document you are going to have to have away to filter through the bad results.
Which means:
You are going to have to write a program that can evaluate if the output is valid (grammatically and syntactically is the best you can do reliablily) (This would would NLP)
You would need lots of training data and test data
You would need to watch out for overtraining (take a look at ROC curves)
Instead of writing a tool you could:
Manually score the output (will take a long time to properly train the algorigthm)
With this using the Amazon Mechanical Turk might be a good idea
The irony of this: The computer would have a difficult time "Creatively" composing something new. All of its worth will be based on its previous experiences [training data]
Some good references and reading at this Natural Language article.
As others said, Markov chain seems to be most suitable for such a task. Nice description of implementing Markov chain can be found in Kernighan & Pike, The Practice of Programming, section 3.1. Nice description of text-generating is also present in Programming Pearls.
One thing, though not quite what you need, would be a Markov chain of words. Here's a link I found by a quick search: http://blog.figmentengine.com/2008/10/markov-chain-code.html, but you can find much more information by searching for it.
Take a look at http://www.nltk.org/ (Natural Language Toolkit), lots of powerful tools there. They use Python (not C#) but Python is easy enough to pick up. Much easier to pick up than the breadth and depth of natural language processing, at least.
I agree, that you will have troubles in creating something creative. You could possibly also use a keyword spinner on certain words. You might also want to implement a stop word filter to remove anything colloquial.
As a fairly junior developer, I'm running into a problem that highlights my lack of experience and the holes in my knowledge. Please excuse me if the preamble here is too long.
I find myself on a project that involves my needing to learn a number of new (to me) technologies, including LINQ (to OBJECTS and to XML for purposes of this project) among others. Everything I've read to this point suggests that to utilize LINQ I'll need to fully understand the following (Delegates, Anonymous Methods and Lambda Expressions).
OK, so now comes the fun. I've CONSUMED delegates in the past as I have worked with the .NET event model, but the majority of the details have been hidden from me (thanks Microsoft!). I understand that on a basic level, delegate instances are pointers to methods (a gross over-simplification, I know).
I understand that an anonymous method is essentially an in-line unnamed method generally (if not exclusively) created as a target for a delegate.
I also understand that lambdas are used in varying ways to simplfy syntax and can be used to point a simple anonymous method to a delegate.
Pardon me if my any of my descriptions are WAY off here, this is the basic level to which I understand these topics.
So, the challenge:
Can anyone tell me if at least on a basic level if my understanding of these items is even close? I'm not looking for complex esoteric minutiae, just the basics (for now).
To what degree do I need to truly understand these concepts before applying LINQ in a project to reasonable effect? I want to understand it fully and am willing to spend the time. I simply may not HAVE the time to fully grok all of this stuff before I need to produce some work.
Can anyone point me to some good articles that explain these subjects and apply them to "real world" examples so that I can get my head around the basics of the topics and application of them? What I mean by real world, is how might I use this in the context of "Customers and Invoices" rather than abstract "Vectors and Shapes" or "Animals and Cows". The scenario can be somewhat contrived for demonstration purposes, but hopefully not strictly academic. I have found a number of examples on-line and in books, but few seem to be "Plain English" explanations.
Thank you all in advance for your patience, time and expertise.
Where can i find a good in depth guide to C# 3?
1) Your knowledge so far seems ok. Lambda expressions are turned into anonymous methods or System.Linq.Expressions.Expression's, depending on context. Since you aren't using a database technology, you don't need to understand expressions (all lambdas will be anonymous methods). You didn't list Extension methods, but those are very important (and easy) to understand. Make sure you see how to apply an extension method to an interface - as all the functionality in linq comes from System.Linq.Enumerable - a collection of extention methods against IEnumerable(Of T).
2) You don't need a deep understanding of lambdas.
The arrow syntax ( => ) was the biggest hurdle for me. The arrow separates the signature and the body of the lambda expression.
Always remember : Linq methods are not executed until enumerated.
Watch out for using loop variables in a lambda. This is a side effect from deferred execution that is particularly tricky to track down.
3) Sure, Here are some of my answers that show linq method calls - some with xml.
List splitting
Simple Xml existence search
Xml projection - shape change
1) Those descriptions sound pretty accurate to me. Sometimes anonymous methods and lambda expressions will need to create a new type to put the target of the delegate in, so they can act as closures.
2/3) I would read up a bit until you're happy with delegates, anonymous methods and lambda expressions. I dedicate a chapter to the delegate-related changes in each of C# 2.0 and C# 3.0 in C# in Depth, although of course other books go into detail too. I have an article as well, if that helps.
As for examples - delegates are used for many different purposes. They're all different ways of looking at the same functionality, but they can feel very different:
Providing the code to call when you start a new thread
Reacting to UI events
Providing the filter, selection, ordering etc for a LINQ query
Providing a callback for when an asynchronous operation has finished
If you have any specific situations you'd like an example of, that would be easier to answer.
EDIT: I should point out that it's good news that you're only working with LINQ to Objects and LINQ to XML at the moment, as that means you don't need to understand expression trees yet. (They're cool, but one step at a time...) LINQ to XML is really just an XML API which works nicely with LINQ - from what I remember, the only times you'll use delegates with LINQ to XML are when you're actually calling into LINQ to Objects. (That's very nice to do, admittedly - but it means you can reuse what you've already learned.)
As you've already got C# in Depth, chapters 10 and 11 provide quite a few examples of using lambda expressions (and query expressions which are translated into lambda expressions) in LINQ. Chapter 5 has a few different examples of delegate use.
Read this...
http://linqinaction.net/
..and all you're question will be answered!!!