We Keep Coding

Why do so many named collections in .NET not implement IEnumerable<T>?

Random example:
ConfigurationElementCollection
.Net has tons of these little WhateverCollection classes that don't implement IEnumerable<T>, which means I can't use Linq to objects with them out of the box.
Even before Linq, you'd think they would have wanted to make use of generics (which were introduced all the way back in C# 2 I believe)
It seems I run across these annoying little collection types all the time.
Is there some technical reason?

The answer is in the question title: "named collections". Which is the way you had to make collections type-safe before generics became available. There are a lot of them in code that dates back to .NET 1.x, especially Winforms. There was no reasonable way to rewrite them using generics, that would have broken too much existing code.
So the named collection type is type safe but the rub is System.Collections.IEnumerator.Current, a property of type Object. You can Linqify these collections by using OfType() or Cast().

As Adam Houldsworth said in a comment already, you simply need to use the Cast<> method.
Example:
var a = new DogCollection();
var allFidos = a.Cast<Dog>().Where(d => d.Name == "Fido");

Why is an Add method required for { } initialization?

To use initialization syntax like this:
var contacts = new ContactList
{
{ "Dan", "dan.tao#email.com" },
{ "Eric", "ceo#google.com" }
};
...my understanding is that my ContactList type would need to define an Add method that takes two string parameters:
public void Add(string name, string email);
What's a bit confusing to me about this is that the { } initializer syntax seems most useful when creating read-only or fixed-size collections. After all it is meant to mimic the initialization syntax for an array, right? (OK, so arrays are not read-only; but they are fixed size.) And naturally it can only be used when the collection's contents are known (at least the number of elements) at compile-time.
So it would almost seem that the main requirement for using this collection initializer syntax (having an Add method and therefore a mutable collection) is at odds with the typical case in which it would be most useful.
I'm sure I haven't put as much thought into this matter as the C# design team; it just seems that there could have been different rules for this syntax that would have meshed better with its typical usage scenarios.
Am I way off base here? Is the desire to use the { } syntax to initialize fixed-size collections not as common as I think? What other factors might have influenced the formulation of the requirements for this syntax that I'm simply not thinking of?

I'm sure I haven't put as much thought into this matter as the C# design team; it just seems that there could have been different rules for this syntax that would have meshed better with its typical usage scenarios.
Your analysis is very good; the key problem is the last three words in the statement above. What are the actual typical usage scenarios?
The by-design goal motivated by typical usage scenarios for collection initializers was to make initialization of existing collection types possible in an expression syntax so that collection initializers could be embedded in query comprehensions or converted to expression trees.
Every other scenario was lower priority; the feature exists at all because it helps make LINQ work.
The C# 3 compiler team was the "long pole" for that release of Visual Studio / .NET - we had the most days of work on the schedule of any team, which meant that every day we delayed, the product would be delayed. We wanted to ship a quality product on time for all of you guys, and the perfect is the enemy of the good. Yes, this feature is slightly clunky and doesn't do absolutely everything you might want it to, but it was more important to get it solid and tested for LINQ than to make it work for a bunch of immutable collection types that largely didn't even exist.
Had this feature been designed into the language from day one, while the frameworks types were still evolving, I'm sure that things would have gone differently. As we've discussed elsewhere on this site, I would dearly love to have a write-once-read-many fixed size array of values. It would be nice to define a common pattern for proffering up a bunch of state to initialize an arbitrary immutable collection. You are right that the collection initializer syntax would be ideal for such a thing.
Features like that are on the list for potential future hyptothetical language versions, but not real high on the list. In other words, let's get async/await right first before we think too hard about syntactic sugars for immutable collection initialization.

It's because the initialization statement is shorthand for the CLR. When it gets compiled into bytecode, it will call the Add method you've defined.
So you can make the case that this initialization statement is not really a "first class" feature, because it doesn't have a counterpart in IL. But that's the case for quite a lot of what we use, the "using" statement for example.

The reason for this is that it was retrofitted. I agree with you that using a constructor taking a collection would make vastly more sense, but not all of the existing collection classes implemented this and the change should (1) work with all existing collections, (2) not change the existing classes in any way.
It’s a compromise.

The main reason is Syntactic Sugar.
The initializer syntax only makes writing programing in C# a bit easier. It doesn't actually add any expressive power to the language.
If the initializer didn't require an Add() method, then it would be a much different feature than it is now. Basically, it's just not how C# works. There is no literal form for creating general collections.

Not an answer, strictly speaking, but if you want to know what sort of things influenced the design of collection initialisers then you'll probably find this interesting:
What is a collection? [straight from the Horse's mouth Mads Torgersen]

What should the initialization syntax use, if not an Add method? The initialization syntax is 'run' after the constructor of the collection is run, and the collection fully created. There must be some way of adding items to the collection after it's been created.
If you want to initialize a read-only collection, do it in the constructor (taking a T[] items argument or similar)

As far as I understand it, the collection initializer syntax is just syntactic sugar with no special tricks in it. It was designed in part to support initializing collections inside Linq queries:
from a in somewhere
select new {
Something = a.Something
Collection = new List<object>() {
a.Item1,
a.Item2,
...
}
}
Before there was no way to do this inline and you'd have to do it after the case, which was annoying.

I'd love to have the initializer syntax for immutable types(both collections and normal types). I think this could be implemented with a special constructor overload using a syntax similar to params.
For example something like this:
MyClass(initializer KeyValuePair<K,V>[] initialValues)
But unfortunately the C# team didn't implement such a thing yet :(
So we need to use a workaround like
MyClass(new KeyValuePair<K,V>[]{...})
for now

Collection initializers are expressions, so they can be used where only expression are valid, such as a field initializer or LINQ query. This makes their existence very useful.
I also think the curly-bracketed { } kind of initialization, smells more like a fixed size collection, but it's just a syntax choice.

Can I get the same benefits of functional programming (F#) by using more static methods in C#?

I admit I haven't grokked F# yet. But in the 30,000 foot descriptions, they keep talking about easy to test code that doesn't have mutable state. Is that the same as static methods?
Could I get the benefit of F# by writing some of my code in classes with all static methods?
I'm just looking for the short answer, I know whole books exist on the topic.

You could certainly write C# code immutably, but that's nothing to do with static functions. Immutability are things like having a struct or object that only "changes state" by making a copy of itself and having the copy be different.

Absolutely no, immutability has nothing to do with methods being static or instance. String, being an immutable class, has plenty of instance methods, which, in a very functional manner, return a new instance of String class, rather than modifying anything.
You could try to emulate F# by using functional decomposition, but this will still be pretty imperative code.

Apart from static, functional modules versus objects, you can attempt to get some of the benefits of F# by using C# 3 and lambdas, LINQ, etc. However, that doesn't go very far. What I find nice in F# is:
Inference everywhere
Auto-generalization (adds in type parameters so I don't have to sort it out manually)
Easy immutability
Easy mix between module and classes
Types like discriminated unions
Pattern matching
Nested functions (lightweight)
First class functions (no, C#'s named delegates don't count)
Everything's an expression
Easy function composition
So, you can try to do some of this in C#. Some of it is simply not supported and won't work. The rest gets very ugly, very fast.
So, if you go much off the beaten path of LINQ and the Enumerable extensions, you'll probably end up in a world of pain.

I beg to differ with all the other answers to date. Immutability and static methods may not be strictly technically related, but I have found that using F# has encouraged me to make C# methods static whenever I can.
The thinking is analogue, in that it is easier to handle an immutable object because you don't have to worry about it changing state. In the same way, you don't have to worry about state when using a static method (unless you use a global singleton or something...).

No, it's not the same as static methods. You don't have mutable state if you don't assign anything (locals, function arguments, static fields, instance fields) after it was initialized. You can get some of the benefits by designing your classes to be immutable.

No, the two concepts are unrelated. Static methods in C# can still modify incoming objects as normal, and other variables using ref or out.

IT's true. You aren't going to get the benefits of functional programming just by using more static functions in C#. Howver, if you were to look under the hood (using Reflector, for example) I understand a simple let statement is a static function. In other words,
//F#
let a = 2
is like a function in C#
//C#
static int a()
{
return 2;
}
I can understand the confusion.
Explanation pulled from Leon Bambrick's "F# Eye for the C# Guy presentation."

C# - Syntactic sugar for out parameters?

Let us say for a moment that C# allowed multiple return values in the most pure sense, where we would expect to see something like:
string sender = message.GetSender();
string receiver = message.GetReceiver();
compacted to:
string sender, receiver = message.GetParticipants();
In that case, I do not have to understand the return values of the method until I actually make the method call. Perhaps I rely on Intellisense to tell me what return value(s) I'm dealing with, or perhaps I'm searching for a method that returns what I want from a class I am unfamiliar with.
Similarly, we have something like this, currently, in C#:
string receiver;
string sender = message.GetParticipants(out receiver);
where the argument to GetParticipants is an out string parameter. However, this is a bit different than the above because it means I have to preempt with, or at least go back and write, code that creates a variable to hold the result of the out parameter. This is a little counterintuitive.
My question is, is there any syntactic sugar in current C#, that allows a developer to make this declaration in the same line as the method call? I think it would make development a (tiny) bit more fluid, and also make the code more readable if I were doing something like:
string sender = message.GetParicipants(out string receiver);
to show that receiver was being declared and assigned on the spot.

No, there isn't currently any syntactic sugar around this. I haven't heard of any intention to introduce any either.
I can't say I use out parameters often enough for it really to be a significant concern for me (there are other features I'd rather the C# team spent their time on) but I agree it's a bit annoying.

.NET 4 will be adding a Tuple concept, which deals with this. Unfortunately, the C# language isn't going to provide any language support for "destructuring bind".

Personally, I like the inconvience introduced when using out parameters. It helps me to think about whether my method is really doing what it should be or if I've crammed too much functionality into it. That said, perhaps dynamic typing in C#4.0/.Net 4 will address some of your concerns.
dynamic participant = message.GetParticipants();
var sender = participant.Sender;
var recipient = participant.Recipient;
where
public object GetParticipants()
{
return new { Sender = ..., Recipient = ... };
}

You can also return a Tuple<T,U> or something similar. However, since you want to return two string, it might get confusing.
I use the Tuples structs of the BclExtras library which is very handy (found it on SO, thank you JaredPar!).

I don't think such functionality exists, but if it were implemented in a way similar to arrays in perl that could be useful actually.
In perl You can assign an array to a list of variables in parentheses. So you can for example do this
($user, $password) = split(/:/,$data);

Where this bugs me the most: since there's no overload of (say) DateTime.TryParse that doesn't take an out parameter, you can't write
if (DateTime.TryParse(s, out d))
{
return new ValidationError("{0} isn't a valid date", s);
}
without declaring d. I don't know if this is a problem with out parameters or just with how the TryParse method is implemented, but it's annoying.

This syntactic sugar is now is now available in the roslyn preview as seen here (called Declaration expressions).
int.TryParse(s, out var x);

At best you would have to use var rather than an explicit type, unless you want to restrict all multiple return values to be of the same type (not likely practical). You would also be limiting the scope of the variable; currently you can declare a variable at a higher scope and initialize it in an out parameter. With this approach, the variable would go out of scope in the same block as its assignment. Obviously this is usable in some cases, but I wouldn't want to enforce this as the general rule. Obviously you could leave the 'out' option in place, but chances are people are going to code for one approach or the other.

I think this is not what you want.
You may have come across a piece of code where you would have
liked that. But variables popping out of nowhere because
they have been introduced in the parameter list would be
a personal nightmare ( to me :) )
Multiple return values have grave downsides from the point
of portability/maintainability. If you make a function that returns two strings
and you now want it to return three, you will have to change all the code
that uses this function.
A returned record type however usually plays nice in such common scenarios.
you may be opening pandora's box ;-)
For line compacting:
string s1, s2; s1 = foo.bar(s2);
Lines can be any length, so you could pack some common stuff into one.
Just try to live with the semicolons.

Try the following code
Participants p = message.GetParticipants();
log(p.sender,p.receiver);

Programming language where you can refer to a array element by . (dot)

In C# language when you refer to an array element you can write:
myclass.my_array['element_name'] = new Point(1,1);
I think about refering to a element with name element_name by using dot in place of backets:
myclass.my_array.element_name = new Point(1,1);
Do you know any language where exists similar syntax to the example above?
What do you think about this example of refering to a array element? Is this good or is it as bad as my writing in english skills?
Kind regards

JavaScript does exactly what you describe. In JavaScript, every object is just a map of property names to values. The bracket operator just returns a property by name (or by value in the case of an integer index). You can refer to named properties by just using a dot, though you can't do that with integer indicies. This page describes the bracket operator and dot notation in detail.

You could almost certainly do this in any dynamic language, by handling property/variable access as an indexer if the specified property/variable didn't actually exist. I suspect that many dynamic languages already provide this functionality in some areas.
It's possible that in C# 4 you'll be able to make your objects behave like this if you really want to.
However, I would agree with the implicit judgement in Mohit's question - I see no reason to consider this more generally readable than using the more common indexer syntax, and it will confuse people who are used to indexers looking like indexers.
One area where I would quite possibly do something like this would be for an XML API, where a property would indicate "take the first element of the given name":
XElement author = doc.Root.Posts.Author;
That's quite neat - for the specific cases where it's what you want. Just don't try to apply it too generally...

REXX has the concept of stems, where you can say x.1, x.2 x.bob and these refer to array elements x[1], x[2] and x['bob'] respectively.
In addition LotusScript (in Notes) allows you to process the Notes databases in this fashion, where db.get("fieldname") is the same as db.fieldname.
I've used the REXX one a bit (as there's no choice) but when I've coded for Notes databases, I've preferred the get/put way of doing things.

Lua tables have a.x as syntactic sugar for a["x"]. Lua tables are associative arrays that could be used to represent arrays, hashes, and records of other languages. The sugar helps making code more readable by illustrating the intention (Record? Array? Hashtable?), though it makes no difference to the language.

What would be the advantage of such a syntax for you?
If you have fix names why not create a class with properties?

Maybe you are looking for a class or struct if you you want to use the element name as a field/property.