We Keep Coding

Objects in functional programming - Immutability

Recently I have been learning to program in Erlang as a long time C and C# developer. I am fairly new to functional programming. Now, I am trying to understand how do objects in languages like Scala work. I have been taught that OOP is all about changing state of given object using its public methods. Those methods change state of public properties and private members. But now I hear that in functional programming all objects should be immutable. Well, I agree that once assigned variable (in given function) should remain pointing to the same object. But does this "immutability" mean that I cannot change the internals (properties, private members) of given objects using their public methods? This makes objects just like simple data containers. It extracts all of the functionality outside of them. This makes objects act more like structures in C. It is something that is strange to me. Maybe I am missing something? Is it possible to use objects the old-fashioned-way and still consider it as functional programming?

You are mixing up three different concepts. Functional programming, mutability, and OOP are three different things.
I have been taught that OOP is all about changing state of given object using its public methods.
Yes and no. The important thing in OOP is that you have objects, which can simultaneously carry around data and code (their member methods), and that you talk to the objects using their interface, so that the object can then
dispatch to the concrete implementation of the called method
supply additional information that is stored in the data that the object carries (accessing this in the method implementation)
execute the code of the method implementation
Nobody prescribes you what this method call does, or that it must modify some state.
It happens to be that OOP helps to restore some basic sanity when working with state. This is because the horrifyingly complex global state of the application can be cut up into smaller pieces and hidden inside mutable objects. Moreover, those mutable objects can additionally attempt to maintain at least some local invariants, by prohibiting direct access to their state, and providing only a restricted set of operations that can modify that state.
But now I hear that in functional programming all objects should be immutable.
They should respect referential transparency. If your objects have no mutable state and only methods without any side effects, then it is sufficient for referential transparency. Sufficient, but not necessary: the objects can have more complex inner structure, but appear completely immutable from the outside. Caching is a good example.
Furthermore, even pure functional programs are not restricted to working with immutable data structures only. There is such thing as pure mutable state. The idea is that your functional programs are used to construct something like complex action plans for dealing with mutable state. The plan itself is an immutable entity. This plan can be very complex, but thanks to the fact that it is built from pure functions, it can be still sufficiently easy to reason about. This plan, which is built using only pure functions, can then be given to a small and simple interpreter, which executes the plan on mutable memory. In this way, you reap the benefits of both worlds: you have conceptual simplicity of pure functions while you are building the plan, but you also have the performance of close-to-the-metal computations when you execute this plan on mutable data structures.
But does this "immutability" mean that I cannot change the internals (properties, private members) of given objects using their public methods?
In general, yes. However, in Scala, immutability is not enforced by default. You can decide what parts of your application are complicated enough to reason about, so that it might be worth it to restrict yourself to pure functions. Everything else can be implemented using ordinary mutable structures, if this is easier.
This makes objects just like simple data containers. It extracts all of the functionality outside of them.
No, because objects still carry their virtual dispatch table with them. You can then ask the object from the outside to invoke the method apply(integer i), and the object, depending on what kind of object it is, might then invoke completely different things, like
/** get i-th character */
String.apply(integer i)
or
/** get value for key `i` */
TreeMap.apply(integer i)
You cannot do this with C structs without essentially re-implementing subclass polymorphism as a design pattern.
Is it possible to use objects the old-fashioned-way and still consider it as functional programming?
It's not an all-or-nothing game. You can start with a classical oop-language (with mutable state and all that), which supports the functional programming paradigm to some degree. You can then look at your application, and isolate those aspects of it that require more precise control over the side effects. You have to decide which side effects matter, and which are less critical. Then you can express the really critical parts using the somewhat stricter approach with pure functions (pure in the sense: as pure as you need them to be, i.e. not performing any critical side-effects without declaring it explicitly in their signature). The result would be a mix of classical OOP and FP in one application.
Writing programs using pure functions can be thought of as a construction of a proof in a somewhat primitive logic. It's nice if you can do it when you need it (using a stricter approach with pure functions), but it can also be nice if you can omit it when you don't need it (using the usual approach with messy side-effecty functions).

OOP is all about changing state of given object using its public methods.
It's a lie!
in functional programming all objects should be immutable
It's a lie!
But does this "immutability" mean that I cannot change the internals (properties, private members) of given objects using their public methods?
There are strict immutability and "simulated" immutability. With "simulated" immutability you can change internals, but you shouldn't produce visible changes. For example, caching of heavy computations is still acceptable.
Is it possible to use objects the old-fashioned-way and still consider it as functional programming?
It depends on how exactly you are mutating objects and how you define FP. Actually, god damn it, you can mutate objects in FP.
Maybe I am missing something?
Yes, there a lot of things you should learn.
There are several things you don't understand about immutable objects:
Immutable object still can has computed properties. So it's more than structure in C. See Uniform access principle for details. Note: in C# structure can have computed properties
Immutable object still can have useful methods. So it's more than structure in C. You can have some logic in immutable object, but this logic can't mutate state. Note: in C# structure can have computed properties.
Also, there is a huge difference between objects and structures in memory-safe languages (like C#, Scala, Erlang): you can't work easily with structures. Generally, there are no pointers in safe code (except things like unsafe regions). So you can't just share same structure between different structures.
Immutable object still can encapsulate some data. Encapsulation is the key to make abstractions (either good or bad)
Here are things that you should know about OOP:
OOP doesn't requires to mutate state. OOP without mutations is still OOP.
OOP has nice useful thing: inheritance. There are no such thing in pure FP.
Here are things that you should know about FP:
FP doesn't requires you to use immutable data. But it's much easier to work with immutable data in FP.
If a tree falls in the woods, does it make a sound?
If a pure function mutates some local data in order to produce an immutable return value, is that ok?"
Good FP languages have a lot of ways to work with mutable data to meet performance needs. FP just loves to hide mutations.
Only pure-FP languages are forcing you to use immutable data.
FP has get it's name for functions as first-class citizens. See more on wiki. You can use & pass functions just like you use & pass objects.
Well, a lot of FP is not about functions.
You should also know how OOP and FP are related:
Encapsulation and polymorphism works differently in OOP and FP. It's very clear how encapsulation work in OOP: private/protected and another access modifiers. But in pure FP only way to encapsulate some data is to use closures.
Polymorphism works differently in OOP and FP. In OOP you are using subtype polymorphism. But in pure FP you should use thing like protocols (interfaces) or multimethods.
“Closures are poor man's objects and vice versa”. You can express same code with closures and with objects.
C# and Scala are multi-paradigm languages. They both supports OOP and FP. It's not bad to mix OOP and FP. Actually it's best way to produce readable code.
And now, I want to explain why there a lot of people whom thinks that some paradigms can't be combined:
OOP was born before immutability become useful. In old days programs was simpler & we worried a lot about memory.
OOP was born before our CPU become able to parallel code. So, immutability (which makes writing parallel code easier) wasn't helpful.
Before recent popularity of FP it was useful primarily only for academists. Academists aren't in love with uncontrolled mutations.
Potentially FP program can be reorganized in such crazy ways that we can't depend on time order of side-effects (and mutations as part of side-effects). No time ordering = useless mutations. But languages like C#, Scala aren't so much crazy. But see next point.
FP has lazy computations at nearly birth. Also they have monads or similar mechanism to replace direct control flow. And function can be executed at any moment, because it's can be stored anywhere. And this make side-effects (and mutations) a bit harder for controlling.
Just to make things clear: creators of FP-style aren't idiots. They want side-effects to be explicit & controlled. So there is a nice concept: pure function.
Summary:
OOP is oftenly used with mutations. But it's not required. OOP is focused on objects.
FP is oftenly used with immutability. But it's not required. FP is focused on functions.
You can mix OOP, FP, mutations and immutability - all of them.

But does this "immutability" mean that I cannot change the internals
(properties, private members) of given objects using their public
methods?
Yes.
This makes objects just like simple data containers. It extracts all
of the functionality outside of them.
No. Typically much of the functionality of immutable classes is provided by their constructors. A constructor is not neccessarily just assigning values passed to it as arguments to member variables. Another part of the functionality can be found in getter-like methods that not only return the values of member variables but perform more complex transformations on them.
This makes objects act more like structures in C.
No. Structs in C are completely mutable. Anyone can access and modify their elements.

Should ConditionalWeakTable<TKey, TValue> be used for non-compiler purposes?

I've recently come across the ConditionalWeakTable<TKey,TValue> class in my search for an IDictionary which uses weak references, as suggested in answers here and here.
There is a definitive MSDN article which introduced the class and which states:
You can find the class ... in the System.Runtime.CompilerServices namespace. It’s in CompilerServices because it’s not a general-purpose dictionary type: we intend for it to only be used by compiler writers.
and later again:
...the conditional weak table is not intended to be a general purpose collection... But if you’re writing a .NET language of your own and need to expose the ability to attach properties to objects you should definitely look into the Conditional Weak Table.
In line with this, the MSDN entry description of the class reads:
Enables compilers to dynamically attach object fields to managed objects.
So obviously it was originally created for a very specific purpose - to help the DLR, and the System.Runtime.CompilerServices namespace embodies this. But it seems to have found a much wider use than that - even within the CLR. If I search for references of ConditionalWeakTable in ILSpy, for example, I can see that is used in the MEF class CatalogExportProvider and in the internal WPF DataGridHelper class, amongst others.
My question is whether it is okay to use ConditionalWeakTable outside of compiler writing and language tools, and whether there is any risk in doing so in terms of incurring additional overhead or of the implementation changing significantly in future .NET versions. (Or should it be avoided and a custom implementation like this one be used instead).
There is also further reading here, here and here about how the ConditionalWeakTable makes use of a hidden CLR implementation of ephemerons (via System.Runtime.Compiler.Services. DependentHandle) to deal with the problem of cycles between keys and values, and how this cannot easily be accomplished in a custom manner.

I don't see anything wrong with using ConditionalWeakTable. If you need ephemerons, you pretty much have no other choice.
I don't think future .NET versions will be a problem - even if only compilers would use this class, Microsoft still couldn't change it without breaking compatibility with existing binaries.
As for overhead - there certainly will be overhead compared to a normal Dictionary. Having many DependentHandles probably will be expensive similarly to how many WeakReferences are more expensive than normal references (the GC has to do additional work to scan them to see if they need to be nulled out). But that's not a problem unless you have lots (several million) of entries.

C# classes - Why so many static methods?

I'm pretty new to C# so bear with me.
One of the first things I noticed about C# is that many of the classes are static method heavy. For example...
Why is it:
Array.ForEach(arr, proc)
instead of:
arr.ForEach(proc)
And why is it:
Array.Sort(arr)
instead of:
arr.Sort()
Feel free to point me to some FAQ on the net. If a detailed answer is in some book somewhere, I'd welcome a pointer to that as well. I'm looking for the definitive answer on this, but your speculation is welcome.

Because those are utility classes. The class construction is just a way to group them together, considering there are no free functions in C#.

Assuming this answer is correct, instance methods require additional space in a "method table." Making array methods static may have been an early space-saving decision.
This, along with avoiding the this pointer check that Amitd references, could provide significant performance gains for something as ubiquitous as arrays.

Also see this rule from FXCOP
CA1822: Mark members as static
Rule Description
Members that do not access instance data or call instance methods can
be marked as static (Shared in Visual Basic). After you mark the
methods as static, the compiler will emit nonvirtual call sites to
these members. Emitting nonvirtual call sites will prevent a check at
runtime for each call that makes sure that the current object pointer
is non-null. This can achieve a measurable performance gain for
performance-sensitive code. In some cases, the failure to access the
current object instance represents a correctness issue.

Perceived functionality.
"Utility" functions are unlike much of the functionality OO is meant to target.
Think about the case with collections, I/O, math and just about all utility.
With OO you generally model your domain. None of those things really fit in your domain--it's not like you are coding and go "Oh, we need to order a new hashtable, ours is getting full". Utility stuff often just doesn't fit.
We get pretty close, but it's still not very OO to pass around collections (where is your business logic? where do you put the methods that manipulate your collection and that other little piece or two of data you are always passing around with it?)
Same with numbers and math. It's kind of tough to have Integer.sqrt() and Long.sqrt() and Float.sqrt()--it just doesn't make sense, nor does "new Math().sqrt()". There are a lot of areas it just doesn't model well. If you are looking for mathematical modeling then OO may not be your best bet. (I made a pretty complete "Complex" and "Matrix" class in Java and made them fairly OO, but making them really taught me some of the limits of OO and Java--I ended up "Using" the classes from Groovy mostly)
I've never seen anything anywhere NEAR as good as OO for modeling your business logic, being able to demonstrate the connections between code and managing your relationship between data and code though.
So we fall back on a different model when it makes more sense to do so.

The classic motivations against static:
Hard to test
Not thread-safe
Increases code size in memory
1) C# has several tools available that make testing static methods relatively easy. A comparison of C# mocking tools, some of which support static mocking: https://stackoverflow.com/questions/64242/rhino-mocks-typemock-moq-or-nmock-which-one-do-you-use-and-why
2) There are well-known, performant ways to do static object creation/logic without losing thread safety in C#. For example implementing the Singleton pattern with a static class in C# (you can jump to the fifth method if the inadequate options bore you): http://www.yoda.arachsys.com/csharp/singleton.html
3) As #K-ballo mentions, every method contributes to code size in memory in C#, rather than instance methods getting special treatment.
That said, the 2 specific examples you pointed out are just a problem of legacy code support for the static Array class before generics and some other code sugar was introduced back in C# 1.0 days, as #Inerdia said. I tried to answer assuming you had more code you were referring to, possibly including outside libraries.

The Array class isn't generic and can't be made fully generic because this would break backwards compatibility. There's some sort of magic going on where arrays implement IList<T>, but that's only for single-dimension arrays with a lower bound of 0 – "list-ish" arrays.
I'm guessing the static methods are the only way to add generic methods that work over any shape of array regardless of whether it qualifies for the above-mentioned compiler magic.

Advantages of compilers for functional languages over compilers for imperative languages

As a follow up to this question What are the advantages of built-in immutability of F# over C#?--am I correct in assuming that the F# compiler can make certain optimizations knowing that it's dealing with largely immutable code? I mean even if a developer writes "Functional C#" the compiler wouldn't know all of the immutability that the developer had tried to code in so that it couldn't make the same optimizations, right?
In general would the compiler of a functional language be able to make optimizations that would not be possible with an imperative language--even one written with as much immutability as possible?

Am I correct in assuming that the F# compiler can make certain
optimizations knowing that it's dealing with largely immutable code?
Unfortunately not. To a compiler writer, there's a huge difference between "largely immutable" and "immutable". Even guaranteed immutability is not that important to the optimizer; the main thing that it buys you is you can write a very aggressive inliner.
In general would the compiler of a functional language be able to make optimizations that would not be possible with an imperative language--even one written with as much immutability as possible?
Yes, but it's mostly a question of being able to apply the classic optimizations more easily, in more places. For example, immutability makes it much easier to apply common-subexpression elimination because immutability can guarantee you that contents of certain memory cells are not changed.
On the other hand, if your functional language is not just immutable but pure (no side effects like I/O), then you enable a new class of optimizations that involve rewriting source-level expressions to more efficient expressions. One of the most important and more interesting to read about is short-cut deforestation, which is a way to avoid allocating memory space for intermediate results. A good example to read about is stream fusion.
If you are compiling a statically typed, functional language for high performance, here are some of the main points of emphasis:
Use memory effectively. When you can, work with "unboxed" values, avoiding allocation and an extra level of indirection to the heap. Stream fusion in particular and other deforestation techniques are all very effective because they eliminate allocations.
Have a super-fast allocator, and amortize heap-exhaustion checks over multiple allocations.
Inline functions effectively. Especially, inline small functions across module boundaries.
Represent first-class functions efficiently, usually through closure conversion. Handle partially applied functions efficiently.
Don't overlook the classic scalar and loop optimizations. They made a huge difference to compilers like TIL and Objective Caml.
If you have a lazy functional language like Haskell or Clean, there are also a lot of specialized things to do with thunks.
Footnotes:
One interesting option you get with total immutability is more ability to execute very fine-grained parallelism. The end of this story has yet to be told.
Writing a good compiler for F# is harder than writing a typical compiler (if there is such a thing) because F# is so heavily constrained: it must do the functional things well, but it must also work effectively within the .NET framework, which was not designed with functional languages in mind. We owe a tip of the hat to Don Syme and his team for doing such a great job on a heavily constrained problem.

No.
The F# compiler makes no attempt to analyze the referential transparency of a method or lambda. The .NET BCL is simply not designed for this.
The F# language specification does reserve the keyword 'pure', so manually marking a method as pure may be possible in vNext, allowing more aggressive graph reduction of lambda-expressions.
However, if you use the either record or algebraic types, F# will create default comparison and equality operators, and provide copy semantics. Amongst many other benefits (pattern-matching, closed-world assumption) this reduces a significant burden!

Yes, if you don't consider F#, but consider Haskell for instance. The fact that there are no side effects really opens up a lot of possibilities for optimization.
For instance consider in a C like language:
int factorial(int n) {
if (n <= 0) return 1;
return n* factorial(n-1);
}
int factorialuser(int m) {
return factorial(m) * factorial(m);
}
If a corresponding method was written in Haskell, there would be no second call to factorial when you call factorialuser. It might be possible to do this in C#, but I doubt the current compilers do it, even for a simple example as this. As things get more complicated, it would be hard for C# compilers to optimize to the level Haskell can do.
Note, F# is not really a "pure" functional language, currently. So, I brought in Haskell (which is great!).

Unfortunately, because F# is only mostly pure there aren't really that many opportunities for aggressive optimization. In fact, there are some places where F# "pessimizes" code compared to C# (e.g. making defensive copies of structs to prevent observable mutation). On the bright side, the compiler does a good job overall despite this, providing comparable performace to C# in most places nonetheless while simultaneously making programs easier to reason about.

I would say largely 'no'.
The main 'optimization' advantages you get from immutability or referential transparency are things like the ability to do 'common subexpression elimination' when you see code like ...f(x)...f(x).... But such analysis is hard to do without very precise information, and since F# runs on the .Net runtime and .Net has no way to mark methods as pure (effect-free), it requires a ton of built-in information and analysis to even try to do any of this.
On the other hand, in a language like Haskell (which mostly means 'Haskell', as there are few languages 'like Haskell' that anyone has heard of or uses :)) that is lazy and pure, the analysis is simpler (everything is pure, go nuts).
That said, such 'optimizations' can often interact badly with other useful aspects of the system (performance predictability, debugging, ...).
There are often stories of "a sufficiently smart compiler could do X", but my opinion is that the "sufficiently smart compiler" is, and always will be, a myth. If you want fast code, then write fast code; the compiler is not going to save you. If you want common subexpression elimination, then create a local variable (do it yourself).
This is mostly my opinion, and you're welcome to downvote or disagree (indeed I've heard 'multicore' suggested as a rising reason that potentially 'optimization may get sexy again', which sounds plausible on the face of it). But if you're ever hopeful about any compiler doing any non-trivial optimization (that is not supported by annotations in the source code), then be prepared to wait a long, long time for your hopes to be fulfilled.
Don't get me wrong - immutability is good, and is likely to help you write 'fast' code in many situations. But not because the compiler optimizes it - rather, because the code is easy to write, debug, get correct, parallelize, profile, and decide which are the most important bottlenecks to spend time on (possibly rewriting them mutably). If you want efficient code, use a development process that let you develop, test, and profile quickly.

Additional optimizations for functional languages are sometimes possible, but not necessarily because of immutability. Internally, many compilers will convert code into an SSA (single static assignment) form, where each local variable inside a function can only be assigned once. This can be done for both imperative and functional languages. For instance:
x := x + 1
y := x + 4
can become
x_1 := x_0 + 1
y := x_1 + 4
where x_0 and x_1 are different variable names. This vastly simplifies many transformations, since you can move bits of code around without worrying about what value they have at specific points in the program. This doesn't work for values stored in memory though (i.e., globals, heap values, arrays, etc). Again, this is done for both functional and imperative languages.
One benefit most functional languages provide is a strong type system. This allows the compiler to make assumptions that it wouldn't be able to otherwise. For instance, if you have two references of different types, the compiler knows that they cannot alias (point to the same thing). This is not an assumption a C compiler could ever make.

Do C# Generics Have a Performance Benefit?

I have a number of data classes representing various entities.
Which is better: writing a generic class (say, to print or output XML) using generics and interfaces, or writing a separate class to deal with each data class?
Is there a performance benefit or any other benefit (other than it saving me the time of writing separate classes)?

There's a significant performance benefit to using generics -- you do away with boxing and unboxing. Compared with developing your own classes, it's a coin toss (with one side of the coin weighted more than the other). Roll your own only if you think you can out-perform the authors of the framework.

Not only yes, but HECK YES. I didn't believe how big of a difference they could make. We did testing in VistaDB after a rewrite of a small percentage of core code that used ArrayLists and HashTables over to generics. 250% or more was the speed improvement.
Read my blog about the testing we did on generics vs weak type collections. The results blew our mind.
I have started rewriting lots of old code that used the weakly typed collections into strongly typed ones. One of my biggest grips with the ADO.NET interface is that they don't expose more strongly typed ways of getting data in and out. The casting time from an object and back is an absolute killer in high volume applications.
Another side effect of strongly typing is that you often will find weakly typed reference problems in your code. We found that through implementing structs in some cases to avoid putting pressure on the GC we could further speed up our code. Combine this with strongly typing for your best speed increase.
Sometimes you have to use weakly typed interfaces within the dot net runtime. Whenever possible though look for ways to stay strongly typed. It really does make a huge difference in performance for non trivial applications.

Generics in C# are truly generic types from the CLR perspective. There should not be any fundamental difference between the performance of a generic class and a specific class that does the exact same thing. This is different from Java Generics, which are more of an automated type cast where needed or C++ templates that expand at compile time.
Here's a good paper, somewhat old, that explains the basic design:
"Design and Implementation of Generics for the
.NET Common Language Runtime".
If you hand-write classes for specific tasks chances are you can optimize some aspects where you would need additional detours through an interface of a generic type.
In summary, there may be a performance benefit but I would recommend the generic solution first, then optimize if needed. This is especially true if you expect to instantiate the generic with many different types.

I did some simple benchmarking on ArrayList's vs Generic Lists for a different question: Generics vs. Array Lists, your mileage will vary, but the Generic List was 4.7 times faster than the ArrayList.
So yes, boxing / unboxing are critical if you are doing a lot of operations. If you are doing simple CRUD stuff, I wouldn't worry about it.

Generics are one of the way to parameterize code and avoid repetition. Looking at your program description and your thought of writing a separate class to deal with each and every data object, I would lean to generics. Having a single class taking care of many data objects, instead of many classes that do the same thing, increases your performance. And of course your performance, measured in the ability to change your code, is usually more important than the computer performance. :-)

According to Microsoft, Generics are faster than casting (boxing/unboxing primitives) which is true.
They also claim generics provide better performance than casting between reference types, which seems to be untrue (no one can quite prove it).
Tony Northrup - co-author of MCTS 70-536: Application Development Foundation - states in the same book the following:
I haven’t been able to reproduce the
performance benefits of generics;
however, according to Microsoft,
generics are faster than using
casting. In practice, casting proved
to be several times faster than using
a generic. However, you probably won’t
notice performance differences in your
applications. (My tests over 100,000
iterations took only a few seconds.)
So you should still use generics
because they are type-safe.
I haven't been able to reproduce such performance benefits with generics compared to casting between reference types - so I'd say the performance gain is "supposed" more than "significant".

if you compare a generic list (for example) to a specific list for exactly the type you use then the difference is minimal, the results from the JIT compiler are almost the same.
if you compare a generic list to a list of objects then there is significant benefits to the generic list - no boxing/unboxing for value types and no type checks for reference types.
also the generic collection classes in the .net library were heavily optimized and you are unlikely to do better yourself.

In the case of generic collections vs. boxing et al, with older collections like ArrayList, generics are a performance win. But in the vast majority of cases this is not the most important benefit of generics. I think there are two things that are of much greater benefit:
Type safety.
Self documenting aka more readable.
Generics promote type safety, forcing a more homogeneous collection. Imagine stumbling across a string when you expect an int. Ouch.
Generic collections are also more self documenting. Consider the two collections below:
ArrayList listOfNames = new ArrayList();
List<NameType> listOfNames = new List<NameType>();
Reading the first line you might think listOfNames is a list of strings. Wrong! It is actually storing objects of type NameType. The second example not only enforces that the type must be NameType (or a descendant), but the code is more readable. I know right away that I need to go find TypeName and learn how to use it just by looking at the code.
I have seen a lot of these "does x perform better than y" questions on StackOverflow. The question here was very fair, and as it turns out generics are a win any way you skin the cat. But at the end of the day the point is to provide the user with something useful. Sure your application needs to be able to perform, but it also needs to not crash, and you need to be able to quickly respond to bugs and feature requests. I think you can see how these last two points tie in with the type safety and code readability of generic collections. If it were the opposite case, if ArrayList outperformed List<>, I would probably still take the List<> implementation unless the performance difference was significant.
As far as performance goes (in general), I would be willing to bet that you will find the majority of your performance bottlenecks in these areas over the course of your career:
Poor design of database or database queries (including indexing, etc),
Poor memory management (forgetting to call dispose, deep stacks, holding onto objects too long, etc),
Improper thread management (too many threads, not calling IO on a background thread in desktop apps, etc),
Poor IO design.
None of these are fixed with single-line solutions. We as programmers, engineers and geeks want to know all the cool little performance tricks. But it is important that we keep our eyes on the ball. I believe focusing on good design and programming practices in the four areas I mentioned above will further that cause far more than worrying about small performance gains.

Generics are faster!
I also discovered that Tony Northrup wrote wrong things about performance of generics and non-generics in his book.
I wrote about this on my blog:
http://andriybuday.blogspot.com/2010/01/generics-performance-vs-non-generics.html
Here is great article where author compares performance of generics and non-generics:
nayyeri.net/use-generics-to-improve-performance

If you're thinking of a generic class that calls methods on some interface to do its work, that will be slower than specific classes using known types, because calling an interface method is slower than a (non-virtual) function call.
Of course, unless the code is the slow part of a performance-critical process, you should focus of clarity.

See Rico Mariani's Blog at MSDN too:
http://blogs.msdn.com/ricom/archive/2005/08/26/456879.aspx
Q1: Which is faster?
The Generics version is considerably
faster, see below.
The article is a little old, but gives the details.

Not only can you do away with boxing but the generic implementations are somewhat faster than the non generic counterparts with reference types due to a change in the underlying implementation.
The originals were designed with a particular extension model in mind. This model was never really used (and would have been a bad idea anyway) but the design decision forced a couple of methods to be virtual and thus uninlineable (based on the current and past JIT optimisations in this regard).
This decision was rectified in the newer classes but cannot be altered in the older ones without it being a potential binary breaking change.
In addition iteration via foreach on an List<> (rather than IList<>) is faster due to the ArrayList's Enumerator requiring a heap allocation. Admittedly this did lead to an obscure bug