What's New in C# 6.0 [video] • Hacker News Board

Re: What's New in C# 6.0 [video]

#121

Post by coldtea » Sat, Nov 15, 2014, 12:52 PM UTC

Someone1234 wrote: post #69

JamesBarney wrote: post #11

Still hoping they add the !(non-nullable) operator. I know its hard http://blog.coverity.com/2013/11/20/c-non-nullable-reference... But dang I would appreciate it. So much code is cluttered with null checks that increases the robustness of the code at the cost of correctness, readability, and poorly defined behavior.

Aren't you just shifting the problem rather than solving it? For example, let's say I am calling a function which returns an object: var myStuff = new GiveMeStuff().GenerateStuff(1337); The return of this value can be valid "stuff," an exception, or null. If we remove null as an option, what happens when internally an exception is thrown within GenerateStuff()? Does it re-throw that exception? Or do we now need a pro…

You might want to read this:

http://www.infoq.com/presentations/Null-References-The-Billi...

Re: What's New in C# 6.0 [video]

#122

Post by coldtea » Sat, Nov 15, 2014, 12:54 PM UTC

wbond wrote: post #18

While all of the changes look nice in terms of writing less code, they are the kind of syntactic sugar I learned to hate in CoffeeScript. Mostly because the code was so much denser and harder to read. Especially when reading other people's code. As I write more and more code, the more I want simplicity and ease of understanding over typing a few less characters or having more elegant code.

>While all of the changes look nice in terms of writing less code, they are the kind of syntactic sugar I learned to hate in CoffeeScript. Mostly because the code was so much denser and harder to read. Especially when reading other people's code.

Syntactic sugar can be that, but not THIS syntactic sugar they propose here.

Here it makes the code easier to read and the intent more clear.

Re: What's New in C# 6.0 [video]

#123

Post by coldtea » Sat, Nov 15, 2014, 12:55 PM UTC

JackMorgan wrote: post #102

wbond wrote: post #18

While all of the changes look nice in terms of writing less code, they are the kind of syntactic sugar I learned to hate in CoffeeScript. Mostly because the code was so much denser and harder to read. Especially when reading other people's code. As I write more and more code, the more I want simplicity and ease of understanding over typing a few less characters or having more elegant code.

That's fascinating, because Steve Yegge suggests that density tolerance is a factor of skill. http://steve-yegge.blogspot.com/2008/02/portrait-of-n00b.htm...

On the other hand, Steve Yegge and people like him (ESR for one) always suggest that whetever they like is "a factor of skill".

Re: What's New in C# 6.0 [video]

#124

Post by dmiladinov » Sat, Nov 15, 2014, 1:19 PM UTC

macromaniac wrote: post #63

wbond wrote: post #18

While all of the changes look nice in terms of writing less code, they are the kind of syntactic sugar I learned to hate in CoffeeScript. Mostly because the code was so much denser and harder to read. Especially when reading other people's code. As I write more and more code, the more I want simplicity and ease of understanding over typing a few less characters or having more elegant code.

There is an optimal level of complexity per line of code that you should try to keep constant throughout your project. It's like a meal, I'd rather have something light like a salad and some soup over eating a 1 lb bar of chocolate for dinner. Reading code should be like reading a nice book.

Manager: "Why isn't the project done yet? Why are you still coding?"

macromaniac: "Patience, I'm still working on salad..."

Re: What's New in C# 6.0 [video]

#125

Post by louthy » Sat, Nov 15, 2014, 1:44 PM UTC

Arnavion wrote: post #96

louthy wrote: post #87

Earlier quoted context omitted.

> public int X { get; } is more consistent with how properties are declared. Consistency is important. As mentioned in my other reply. If that were the case, why have they just changed the method declaration syntax? It's inconsistent and therefore unacceptable right? If everything has to be consistent we wouldn't have LINQ, lambdas, generics, etc. The braces are for scope in C# and all C derivative languages. There i…

>As mentioned in my other reply. If that were the case, why have they just changed the method declaration syntax? They did change the property declaration syntax too. public int X => 5; is the same as public int X { get { return 5; } } This is exactly the same change they made to the method declaration syntax, so I'm not sure what you're complaining about. Of course it isn't identical to public int X { get; } because…

I think you're quoting me out of context here. I am debating the consistency angle. My argument is that if there is such a drive for consistency (and therefore that's a good reason to keep the braces) then the method syntax wouldn't have changed to drop the braces. So I feel that argument is moot when discussing the reason for keeping the (what I believe to be) ugly syntax of X { get; } = 5;

Your example of the computed properties is not the same. I like the computed properties syntax, but unless the properties can be computed from the constructor parameters then you will still need to either use the ugly property syntax, or readonly fields to get the same immutable guarantees.

Personally I am fine with using readonly fields, I was only commenting on how the C# team have (in my opinion) missed the opportunity to get rid of some of the unnecessary clutter. I know however many people don't like using readonly fields for various reasons: serialisation, data-binding, interface declarations, etc.

Re: What's New in C# 6.0 [video]

#126

Post by petercooper » Sat, Nov 15, 2014, 1:49 PM UTC

zaroth wrote: post #111

So these lines are now equivalent: public override string ToString() { return String.Format("({0}, {1})", X, Y); } public override string ToString() => "(\{X}, \{Y})" Could it go even further? This isn't paper after all, on screen why shouldn't it look like; public override string ToString() => "(X, Y)" where the X and Y are either slight italics or underlined or colored to indicate they mean X and Y the variable not…

where the X and Y are either slight italics or underlined or colored

You might find this interesting if you're thinking along those lines: http://joshondesign.com/2014/08/22/typopl

Re: What's New in C# 6.0 [video]

#127

Post by dfkf » Sat, Nov 15, 2014, 2:09 PM UTC

wbond wrote: post #18

While all of the changes look nice in terms of writing less code, they are the kind of syntactic sugar I learned to hate in CoffeeScript. Mostly because the code was so much denser and harder to read. Especially when reading other people's code. As I write more and more code, the more I want simplicity and ease of understanding over typing a few less characters or having more elegant code.

Most of the features make the language more consistent and reduce syntactic noise, making it easier to read. The only feature that puts additional mental burden is the elvis operator.

Re: What's New in C# 6.0 [video]

#128

Post by eogas » Sat, Nov 15, 2014, 3:32 PM UTC

Someone1234 wrote: post #59

ColinDabritz wrote: post #56

Earlier quoted context omitted.

IsNullOrWhiteSpace() was added in dot net 4: http://msdn.microsoft.com/en-us/library/system.string.isnull... I agree that Truncate would be a nice one to include in the core.

> IsNullOrWhiteSpace() was added in dot net 4: Look at what the helper actually does. I already addressed this in my comment. string hello = magic(); if(hello.IsNullOrWhiteSpace()) { ... } Is significantly more intuitive than: string hello = magic(); if(string.IsNullOrWhiteSpace(hello)) { ... } Plus it is consistent with things like Contains("XYZ") (e.g. hello.Contains("something")). Truncate is useful just because S…

That defeats half the purpose though, because if the string is null, you won't be able to call the method without throwing an exception. Or is that not the case for extension methods?

Re: What's New in C# 6.0 [video]

#129

Post by towelguy » Sat, Nov 15, 2014, 3:58 PM UTC

zaroth wrote: post #111

So these lines are now equivalent: public override string ToString() { return String.Format("({0}, {1})", X, Y); } public override string ToString() => "(\{X}, \{Y})" Could it go even further? This isn't paper after all, on screen why shouldn't it look like; public override string ToString() => "(X, Y)" where the X and Y are either slight italics or underlined or colored to indicate they mean X and Y the variable not…

>where the X and Y are either slight italics or underlined or colored to indicate they mean X and Y the variable not X and Y the letters

So what happens if you open the file in a different editor?

Re: What's New in C# 6.0 [video]

#130

Post by towelguy » Sat, Nov 15, 2014, 4:08 PM UTC

louthy wrote: post #75

I think they missed a trick if the goal was to reduce boilerplate; which I'm all for, I'm very much moving away from C# to F# for this reason (and a few others). Why this: public int X { get; } public int Y { get; } = 5; And not this: public int X get; public int Y get = 5; The braces serve absolutely no purpose anymore, the semi-colon doesn't serve as a separator between statements. So why leave them?

For the second one you can write this:

    public int Y => 5;