His item 4 is to some extent a result of the limited immutable support (he mentions "a lightweight way of building immutable list/collection expression"). Fix that support and 1,4 out of his list are not much of a problem anymore or at least ameliorated.

2) I would be glad to never need hear of IComparer or IEqualityComparer again, which I only need due to the stdlib leftovers... Admittedly not much, but enough to be annoying. His solution is more general, but your idea is very nice. Why didn't I think of that?

5) Dynamic is there for the Dynamic Language Runtime and for dynamic code far more general than your example. It should be kept in that silo, but it does do its job there.

IMHO, the author tries to write C# with the current trend of functional+immutable, and that's why he ended up hitting these issues. It's true that the OOP way isn't bad (at least with those examples), but it's also true C# could offer better support for doing things the other way without much effort.

Tho, your own example of immutable collections is actually a good one. Rather specific, but still good. Immutable collections really could profit from compuiler-level warnings or even errors. It would be an easy enough fix for the language/compiler team: have some attribute that you/the immutable library authors would decorate functions with, something like [NoDiscardReturn] and the compiler would check that and emit warnings/errors.

(2) Implementing something like IComparer<> is something you rarely do, and more or less never the way the author does.

   var enumerator = array.OrderBy(e => e.Foo).ThenBy(e => something.CheckProperty(e.Bar)).ThenByDescending(e => e.Name, StringComparer.OridinalIgnoreCase);
   array = enumerator.ToArray();
   // Tho you often do not need to call .ToArray() if you're only gonna traverse the enumerator once

Now, this was specific to the comparer stuff, but in general a sane API these days would use Func<> or Action<> instead of single-method interfaces. There are still some leftovers in the C# stdlib (and probably more in third party libraries) but again, you can write a wrapper once - not the horrible mess the author proposed either, but an interface implementation that would use single Func<> parameter in the constructor and then call that in the method implementation.

    internal class Foo
    {
      public string Bar;
      public int Baz;

      public override string ToString() => $"{Bar}: {Baz}";
    }

    internal class DontAnnoyMeComparer<T> : IComparer<T>
    {
      private readonly Func<T, T, int> cmpFunc;

      internal DontAnnoyMeComparer(Func<T, T, int> cmpFunc)
      {
        this.cmpFunc = cmpFunc;
      }

      public int Compare(T x, T y) => cmpFunc(x, y);
    }

    static void Main(string[] args)
    {
      var foos = new[] {
         new Foo { Bar = "World", Baz = 1 },
         new Foo { Bar = "Hello", Baz = 2 },
         new Foo { Bar = "Hello", Baz = 1 },
       };

      // First with some ideomatic Linq
      Console.WriteLine(string.Join(", ", foos.OrderBy(f => f.Bar).ThenBy(f => f.Baz)));

      // Then with our helper interface implementation
      Array.Sort(foos, new DontAnnoyMeComparer<Foo>((x, y) => {
        var res = x.Bar.CompareTo(y.Bar);
        return res != 0 ? res : x.Baz.CompareTo(y.Baz);
      }));
      Console.WriteLine(string.Join(", ", (object[])foos));
    }

    // Output
    // Hello: 1, Hello: 2, World: 1
    // Hello: 1, Hello: 2, World: 1

(4) Sure, something like that would be nice sometimes. But the lack of it is hardly the end of the world. Tho on the flipside, in my opinion languages that offer such pseudo-DSLs or even real embdeddable DSLs quite often suffer from people writing DSLs for every freaking thing, thus reducing readability of their code.

(5) dynamic is hell for robust code, that's why you avoid it. I only ever used it when I was too lazy to do the extra typing to create proper types in run-once code dealing with JSON. And even then I should have probably just:

    class MyType {
      [DataMemeber]
      public int Foo;
      
      [DataMemeber(Name="baz")]
      public int Baz;
    }

Except now that I look at it more specifically, it looks like a bound on the class's generic parameter rather than a condition on the interface implementation?

As in you're defining a SortedList class which implements ICollection and IEnumerable but requires T:IComparable, not defining a SortedList class which implements IEnumerable if T is IComparable.

And if that reading is correct, Java can do it just fine:

    class SortedList<T extends Comparable<T>> implements Collection<T>, Iterable<T>

But it certainly works with others, e.g. something like this:

    public class SortedList<T> : ICollection<T>,IEnumerable<T> where T : IComparable<T>

    db.Orders.Sort(o => o.StartDate)

Anyway, generics. Without having to muck around with funky designs for your classes.

C# also sort of implements type classes. For your example, there's IComparable in C#; implement it and a List<SomeObject> can be directly sorted.

For pure functions, there's the [Pure] attribute, but it isn't enforced by the compiler, it's just a contract, a promise.

- IComparable

- IComparable(Of T)

- IEquatable(Of T)

- IStructuralEquatable

- IStructuralComparable

- IEqualityComparer

- IEqualityComparer(Of T)

- IComparer(Of T)

- overriding Object.Equals

- overriding operators <,>, <=, >=, =, <>

...it's time to find a new language.

edit: Just imagine you encounter a new collection BozBag(Of T) which has to test your objects for equality. Without looking at documentation could you as a coder possibly know if BozBag uses x.Equals(y), x = y, x.CompareTo(y) = 0? Heck it could even use x.Equals(DirectCast(y,Object)) or x.CompareTo(DirectCast(y,Object)). The only way to really know is to dig through documentation.

.NET has:

- Several basic ways doing comparisons: the == operator, the object.Equals() method, and the object.ReferenceEquals() method. == is intended to be for referential equality, and object.Equals() can optionally be overridden to implement value equality. == can be overridden (though it's not generally recommended), which is why there's the separate ReferenceEquals() method for when you absolutely must compare references.

- An IEqualityComparer interface for implementing custom equality. Collection classes that rely on determining if objects are equal (e.g., hash sets and dictionaries) let you supply one of these so that you can do purpose-specific equality.

- IComparable interface for when you want to implement a default ordering on a type.

- IComparer interface for when you want to use custom ordering rules.

  Collections.sort(list, (Comparator) #(String a, String b) {
    return a.compareToIgnoreCase(b);
  });

I remember writing extension methods in C# for IEnumerable<T>, which would of course take in an IEnumerable<T>, but saw if the actual input was a ICollection<T>, IList<T> etc to optimize the operations.

https://github.com/morelinq/MoreLINQ

Edit: `collections.namedtuple` is Python, mixed that up.

[1] https://news.ycombinator.com/item?id=12954790

[1]: https://docs.microsoft.com/en-us/dotnet/api/system.collectio...

[2]: https://docs.microsoft.com/en-us/dotnet/api/system.collectio...

The requirement was to add a method that works for all collections, whether platform or language specific, while preserving type. The code I gave is an approximation of a solution - to use a rough analogy: topologically speaking the code matches but loses the geometry. The code I gave works on basically all .NET collections, whether C# or F#, string or tree - as long as they implement the interface - they are matched. That it leverages the existing organization should not count against it. The failing is that although types are preserved it is under a new geometry or structure.

We try to use ICollection in our APIs instead of IEnumerable, since the latter can have surprising semantics like being a wrapper for some operation which may not be valid anymore, or might be slower than you expect to do things like .Count(). IMO it's really not best for transporting across interface boundries in the most common case; only when you're specifically trying to avoid having the whole collection in memory or something like that.

Another thing that can help is this wonderful May<T> library[1]. It a great option type[2] for .NET. It helps make operations more composable.

[1] https://github.com/Strilanc/May

[2] http://en.wikipedia.org/wiki/Option_type

  cars.Where(x => x.Horsepower > 300).OrderBy(x => x.Price / x.Horsepower).Take(20);