Live data from Hacker News

C# 8: Switch expressions

alexatnet.com

51–60 of 124 posts

Re: C# 8: Switch expressions

#51
post #45

Earlier quoted context omitted.

For some time, I've thought that the direction of C#'s evolution makes a lot of sense if you look at as the designers' effort to cope with Haskell envy (pattern matching, type inference (which is really just class inference), and monad comprehensions). But, it makes almost complete sense if you instead look at it as coping with Lisp envy. I'm still amazed that they managed to sneak in function literals and FEXPRs (Li…

I don't think it's Lisp envy. They're porting stuff from F#, which as far as I know is from the ML family.

Well, to be clear, I was being tongue-in-cheek when calling it "envy".

I just mean that C# looks messy from the point-of-view of an ML-wannabe, but pretty elegant as an aspiring Lisp. And I say this as someone that is fluent in F# and prefers functional programming in the style of ML rather than that of Lisp.

Re: C# 8: Switch expressions

#53
I am not sure I like the path c# is going down.

For years the language has been trying to evolve from being aesthetic and easy to understand and read.

With the functional implementations and patterns I believe the language is trying to embrace too much.

This is not specific to the swith expression in this context but in general.

You can write C# in too many forms and I don't believe that's really good.

Re: C# 8: Switch expressions

#55
post #48
post #12

Earlier quoted context omitted.

I think string interpolation is one of the best things they did to C#. String.Format is pretty error prone.

I'm on your side. I've found very little use for most improvements since C# 4, but I always use literals now. Things like value tuples and string literals are huge improvements to my code's readability and flow.

Value tuples are good too. Somehow I don't seem to get too friendly with the syntax but they are very useful.

Re: C# 8: Switch expressions

#56
post #45

Earlier quoted context omitted.

For some time, I've thought that the direction of C#'s evolution makes a lot of sense if you look at as the designers' effort to cope with Haskell envy (pattern matching, type inference (which is really just class inference), and monad comprehensions). But, it makes almost complete sense if you instead look at it as coping with Lisp envy. I'm still amazed that they managed to sneak in function literals and FEXPRs (Li…

I don't think it's Lisp envy. They're porting stuff from F#, which as far as I know is from the ML family.

This change was definitely inspired by F# (or ML ultimately). It's far from the first feature to be brought over. Look at async/await, usable tuples, lambda functions, range syntax, etc.

Re: C# 8: Switch expressions

#57

I am not sure I like the path c# is going down. For years the language has been trying to evolve from being aesthetic and easy to understand and read. With the functional implementations and patterns I believe the language is trying to embrace too much. This is not specific to the swith expression in this context but in general. You can write C# in too many forms and I don't believe that's really good.

> You can write C# in too many forms and I don't believe that's really good.

Why not? And what, exactly, defines "too many"?

Re: C# 8: Switch expressions

#58

I am not sure I like the path c# is going down. For years the language has been trying to evolve from being aesthetic and easy to understand and read. With the functional implementations and patterns I believe the language is trying to embrace too much. This is not specific to the swith expression in this context but in general. You can write C# in too many forms and I don't believe that's really good.

> You can write C# in too many forms and I don't believe that's really good. Why not? And what, exactly, defines "too many"?

Perhaps he means something like Python's motto of "There should be one--and preferably only one--obvious way to do it."

https://www.python.org/dev/peps/pep-0020/

Re: C# 8: Switch expressions

#59

I am not sure I like the path c# is going down. For years the language has been trying to evolve from being aesthetic and easy to understand and read. With the functional implementations and patterns I believe the language is trying to embrace too much. This is not specific to the swith expression in this context but in general. You can write C# in too many forms and I don't believe that's really good.

> You can write C# in too many forms and I don't believe that's really good. Why not? And what, exactly, defines "too many"?

I know people meme a lot about Go and "not having generics," but I really feel that a lot of the things left out of Go have benefitted it. I've never really been able to jump into a project without a lot of mental overhead. With Go, most code everywhere is written pretty idiomatically, making it easy to approach and read. I've heard similar things about C#, but my experience hasn't been as great.

This is a big problem in the JavaScript world in my opinion. So many different ways to solve common problems that it's difficult to approach. OP might be worried this could be happening to C#.

Re: C# 8: Switch expressions

#60
post #31

Earlier quoted context omitted.

Using switch as an expression makes sense, just like using if as an expression (often written as a?b:c) does. It makes it obvious that all you are doing is changing one variable, and it makes initialising constants a lot cleaner. Once you start making switch expressions, the break keyword makes no sense. And with pattern matching the case keyword technically wouldn't be nessesary for normal switch statements already,…

The break keyword in switch statements makes sense only if the programmer considers switch as a syntax sugar for goto, which are the semantics in C. Once you have a language that doesn't use goto but that still requires breaking each switch case, the only rationale is inertia for people familiar with C. (That said, C# does have goto, right?)

Yes, C# does have goto. Ayende made a blog post [1] about some interesting uses of goto for performance reasons. Also likely for performance reasons, async/await state machines in .NET essentially use goto (br.s in CIL). VB.NET has GoTo as well.

1: https://ayende.com/blog/183553-A/using-goto-in-c

Post reply on HN