1. 15
  1. 10

    This is from 2006, not from 2016, if you check the comments. And C# has come a long way from what the author is describing here…modern C# code for #2 would look more like this:

    string.Join('\n', mylist.Select(x => x.Description()).Where(x => !string.IsNullOrEmpty(x)))

    which does not lose much at all in terms of readability from the Python or Haskell versions, and could be simplified further with appropriate use of helper methods.

    C# gained LINQ with 3.0, which added a bunch of extension methods to collections to write much more functional code with lazy evaluation. And since then, C# has continued to grow closer to feature parity with functional programming languages. I am particularly excited for the addition of tuples + record types + pattern matching in version 7, bringing in my favorite part of Haskell + Elm https://www.kenneth-truyers.net/2016/01/20/new-features-in-c-sharp-7/

    C# brings together an awesome mix of functional + imperative programming with an amazing set of tools built behind it, and I think it would be a shame to dismiss it based on this outdated blog post.

    1. 4

      I’m all for more features in C#, but the way they’ve decided to implement Pattern Matching irks me. C# Pattern Matching will be more like sugar around the switch statement; likely you’ll need to either provide a “default” case, or there won’t be any warnings/errors if you “forget” one of the cases, as opposed to languages with discriminated unions built in from the start. The lack of this feature means that you don’t really get any of the productivity benefits of using the compiler to direct where to fix things when the program changes (For example, when you add a new abstract method, you’re forced to update all of the subclasses"). the C# folks are considering an additional “match” keyword that might provide this, but it’s still up in the air.

      https://github.com/dotnet/roslyn/blob/features/patterns/docs/features/patterns.md https://github.com/dotnet/roslyn/blob/features/patterns/docs/features/patterns.work.md https://github.com/dotnet/roslyn/issues/8818

      This post also gets submitted every few years on hn https://hn.algolia.com/?query=why-learning-haskell-python-makes-you-a-worse-programmer&sort=byPopularity&prefix&page=0&dateRange=all&type=story

      1. 1

        C# Pattern Matching will be more like sugar around the switch statement; likely you’ll need to either provide a “default” case, or there won’t be any warnings/errors if you “forget” one of the cases

        Ah yeah, that’s a really good point, and a shame. I had forgotten that the switch statement didn’t throw a warning/error for “forgetting”.

    2. 6

      Title is misleading, author is simply more aware of their badness and the badness that surrounds them. It reminds me of the Alan Watts quote (paraphrased) “ We are only capable of goodness to the extent which we are aware of our inner darkness”.Author has seen the darkness, and assumes they are worse because of it, but really they’re just less ignorant now. Also I’m a bit disappointed that the Author still hasn’t found F# :(.

      1. 2

        Well, as noted by akbiggs, this article is from 2006. F# would have hardly been a viable option in 2006.

        1. 1

          Ah, good eye.

      2. 4

        Sadly, I agree with this. I think that it makes you a more knowledgeable programmer, to know more languages, but it also can make you unhappy and, therefore, less successful.

        Most people in the corporate world are just trying to protect their incomes and play politics. When someone comes along and says, “This project would be so much better if it were done in Haskell”, it just pisses everyone off. Most people want to avoid risk and work– not have more work come their way if the only thing achieved is a better-quality codebase (which they don’t see as relevant to their careers and personal finances and that, realistically, probably aren’t).

        1. 2

          Add the “satire” tag.

          1. 1

            Add the “satire” tag.