Hacker News Reader

Comment by jmnicolas | Hacker News Reader

This might be better titled "changing things for the sake of changing things and appealing to the programming language geeks".

The new syntax is not intuitive, not more readable, just a bit more terse.

View on HN

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, might as well drop it for the new syntax.

I find this completely reasonable, and I think it's very readable, especially compared to the closest equivalents: putting a single switch in a function and calling that, or using nested tertiary operators:

    const sqlOp = op switch {
                    "&&" => "AND",
                    "||" => "OR",
                    _ => throw new NotSupportedException()
                  }

    function getSqlOp(string op) {
      switch op {
        case "&&": return "AND";
        case "||": return "OR";
        default: throw new NotSupportedException();
      }
    }
    
    // ... far away
    const sqlOp = getSqlOp(op);

    const sqlOp = op=="&&" ? "AND" : op=="||" ? "OR" : throw new NotSupportedException();

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?)

the break keyword in switch statements also allows fallthrough, allowing for a terser way to write state machines, at the cost of making the whole construct less intuitive and readable.

In a switch expression of course that is moot since break is a statement, and statements can't appear in expressions.

The thrust of my above comment is largely about how the idea "enabling fallthrough" demonstrates how poorly the switch statement is usually taught: most people have an intuitive grasp of it as an alternative to if/else if, when in truth it's sugar for a jump table. Break exists to prevent fallthrough rather than enable it! And indeed fallthrough isn't useless, though decades of long experience has demonstrated that it is the wrong default, and newer languages like Go do better by making break the default and having a dedicated fallthrough keyword for when you want it.

Ofc, C# doesn't actually support non-trivial fall-through. You can have

x: y: DoX()

but you can't have

x: DoX() y: DoY()

at all.

But one can do

    case x:
        DoX(); goto case y;
    case y:
        DoY(); break;

C# doesn't allow fallthrough. Every branch in a case clause must exit the case clause. Fallthrough can only be aachieved with a goto at the end of the case clause. The `break;` requirement is completely superficial; there's no reason why it couldn't be a classical block/statement choice:

    case "foo" { /* ... */ }
    case "bar" /* ... */;

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

Actually, I think it is rather intuitive and readable - but then again I programmed in lisp for years.

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 (Linq), a metaobject system (dynamic + DLR), a limited form of call/cc (aysnc/await), first-class metaprogramming (Roslyn -- albeit more in the style of Smalltalk rather than Lisp), and a REPL.

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.

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.

AFAICT, this is kind of true for a lot of F#: F# is where they do the experimentation, C# is where they do the more heavily engineered "fast" version.

That seems to be true at least to some extent. However, there are some noteworthy parts of the two languages that seem to be intentionally different. For example, F# optimizes tail recursion while C# doesn't.

LINQ actually came from Haskell.

"Confessions of a Used Programming Language Salesman, Getting the Masses Hooked on Haskell"

http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.72....

This actually seems to be somewhat of a trend in C# as of late. Ever since they introduced lambdas, really.

While I use them every day, my favorite is still “replacing” String.Format with string literals. Shorter, sure, but less intuitive particularly for people coming from another language. You can do roughly the same thing in PHP with backticks, but most people avoid them for the same reasons.

I’m not sure how I feel about the trend as a whole. As long as I can continue using the old methods as well I suppose I don’t have much room to complain, but sometimes it does feel like we’re just changing for the sake of change and that’s usually a bad indicator.

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.

Local functions can be a serious win over the alternatives of far away functions with no closure semantics or huge lambdas.

Very true.

String interpolation is more intuitive than trying to match a placeholder in the string with a list outside of the string.

I suppose that depends upon where you’re coming from. Many, many languages have an sprintf-style construct of one form or another, so I think it’s actually much more familiar to most people to have a placeholder with an optional formatter. To each their own, though.

> Many, many languages have an sprintf-style construct of one form or another, so I think it’s actually much more familiar to most people to have a placeholder with an optional formatter

Many languages also have format strings with interpolation: JavaScript, Python, Ruby, Swift, PHP, etc.

Sprintf is very error prone. Maybe people are used to it but string interpolation is clearly superior because it removes a lot of potential errors. With the trend towards safer languages sprintf and similar techniques need to go away.

Well, let's take the TIOBE index as a rough indicator of popularity: https://www.tiobe.com/tiobe-index/

Java, C/C++/Objective-C/Go (I'm lumping them up because they're basically C + C NextGens), Matlab, SQL, ASM don't have them.

Everything else, has them.

On the list of languages that don't have it, Java is planning to add it, I don't see the C family to change because it's very conservative, and the others are domain specific and don't care that much about string operations.

C++ has string streams which actually work more like string interpolation than like sprintf just without adding custom syntax.

I have a hard time believing any programmer with more than a couple of months experience would have a moment of difficult figuring out what an interpolated string is doing.

string interpolation isn't simply a wrapper around String.Format(); it also offers compile time checking which solved a real limitation of String.Format() while offering better performance than concatenation.

For example:

     var h = "Hello ";  
     var w = "world";     
     var output = String.Format("{1} {2}", h, w);    
     output = $"{h} {w}";

Would compile fine but throw on the String.Format() line due to the typo.

I wasn’t necessarily saying it doesn’t offer any benefit, more that it’s not really a benefit that seems to benefit a lot of people. Between code intelligence tools and actually running the code you write (not even in an actual QA process, but simply executing each line) that just doesn’t seem like a big deal to me.

There are also instances where, such as with Console.Write you are now formatting a string in order to pass it into... a method that formats strings. Yes, the same benefit is still provided, but with a fairly obvious decrease in clarity and increase in redundancy.

> fairly obvious decrease in clarity

You feel that "{0} {1} {2}" provides better clarity than $"{FirstName} {MiddleInitial} {LastName}"?

>a fairly obvious decrease in clarity

In what's ways specifically? Using String.Format you have to keep your indices correct and 'compiling' the string in your head requires jumping back and forth between the format string and the args.

Interpolation wins on every account as far as I'm concerned.

String.Format("Is {0} to read {2} {1} of the {3} out of place", "harder", "half", "because", "string is").

Ironically that’s actually also one of the key advantages of it. If you have a long string with many placeholders in it and need to add a new one in the middle... you just add it and don’t have to figure out where in the list of params to insert the new arg.

Not so nice for the next guy, though.

This is not much of an advantage with respect to string interpolation as you could just as easily put your new value in a (nicely named) variable and insert it wherever.

Yes, God forbid the variable appear more than once.

> but less intuitive particularly for people coming from another language

Maybe for people coming from C++, but string interpolation is a feature in Python, JavaScript, PHP, etc. It's not exactly an unusal concept (like it was back when PHP started doing it)

It's not simply a matter of "uncomfortable" syntactic sugar. It's a fundamental change from a statement to an expression.

Also, there is an elegance to the functional style of pattern matching. And C# has been incorporating a lot of functional paradigms for more than a decade now which may initially feel "out of place" but ultimately benefited the language greatly.

More like the trend of “bolting everything they’ve ever heard on to the language spec”.

This is a half-assed, syntactically ugly implementation of case statements in functional languages like Elm or Haskell - the point of which is to cover all possible executions of a branch explicitly, to prevent runtime errors.

Reply on news.ycombinator.com