Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

New in C# 10: Easier Lambda Expressions

dontcodetired.com

Post reply on HN
Print view View original

41–50 of 111 posts

Re: New in C# 10: Easier Lambda Expressions

#41

Post by spaetzleesser »

FpUser wrote: post #37
thrower123 wrote: post #15

Earlier quoted context omitted.

C++ had operator overloading in the 90s. Mostly we decided it was a bad idea. Every generation must learn this for themselves though.

>"Mostly we decided it was a bad idea." We who? From where I stand people are fine with operator overloading where it makes sense and C++ is far from being the only language with this feature. Problem comes when shitty programmers get orgasmic about some language feature and try to use it everywhere to everyone's detriment.

You have to have real good taste to use operator overloading. Often it just leads to obfuscated code where the operators have weird behavior. Extension methods are also way overused. I have had numerous occasions where I thought the .NET framework was buggy only find out that it was somebody’s badly written extension method causing problems.

Re: New in C# 10: Easier Lambda Expressions

#42

Post by spaetzleesser »

rad_gruchalski wrote: post #33
jbjbjbjb wrote: post #23

Earlier quoted context omitted.

What is better in the JVM?

The ecosystem.

That’s very important. This is the reason why I would use Java over .NET for new code. MS is making a big mistake not providing means to call Java from .NET. There was a library called KVM but I think it has been abandoned.

Re: New in C# 10: Easier Lambda Expressions

#43

Post by spaetzleesser »

thrower123 wrote: post #4

F# is really, really bleeding into C#. There'll be a convergence, for all intents and purposes, by about C# 15 at this rate.

Is F# still moving forward? I am tempted to try it but I don’t want to bet on another tool MS may abandon soon like they did with the .NET frameworks.

Re: New in C# 10: Easier Lambda Expressions

#44

Post by vips7L »

pipeline_peak wrote: post #36
ShinTakuya wrote: post #27

Earlier quoted context omitted.

I think it's been elegant for a number of years now. Pretty much ever since Linq became usable.

Yeah, lambdas and reflection really.

Personally I think reflection is the devil and the reason why we can’t abandon VMs for native compilers.

Re: New in C# 10: Easier Lambda Expressions

#45

Post by FpUser »

spaetzleesser wrote: post #41
FpUser wrote: post #37

Earlier quoted context omitted.

>"Mostly we decided it was a bad idea." We who? From where I stand people are fine with operator overloading where it makes sense and C++ is far from being the only language with this feature. Problem comes when shitty programmers get orgasmic about some language feature and try to use it everywhere to everyone's detriment.

You have to have real good taste to use operator overloading. Often it just leads to obfuscated code where the operators have weird behavior. Extension methods are also way overused. I have had numerous occasions where I thought the .NET framework was buggy only find out that it was somebody’s badly written extension method causing problems.

>"You have to have real good taste"

Gross exaggeration. Just a bit of plain common sense. Do override operators to perform matrix ops. Do not override + operator to do multiplication instead. And do not subtract apples from cars.

As for your further example as I said give shitty programmer code in any language and they will manage to fuck it up.

Re: New in C# 10: Easier Lambda Expressions

#46

Post by munchler »

spaetzleesser wrote: post #43
thrower123 wrote: post #4

F# is really, really bleeding into C#. There'll be a convergence, for all intents and purposes, by about C# 15 at this rate.

Is F# still moving forward? I am tempted to try it but I don’t want to bet on another tool MS may abandon soon like they did with the .NET frameworks.

Yes. F# 6 was just released with .NET 6 and Visual Studio 2022. It's an awesome language with a vibrant community. Plus, it's fully open source and cross-platform, so if MS were to abandon it, I think it could carry on anyway.

Re: New in C# 10: Easier Lambda Expressions

#47

Post by marcodiego »

brundolf wrote: post #30

A couple decades ago everyone was on static types. But then people got sick of the boilerplate, and in what I think was a backlash, dynamic languages like JavaScript, Python, Ruby, etc. took the world by storm. With the raised bar of developer expectations when it comes to agility, static type systems were forced to innovate, and now type-inference and related features are coming to all static languages and bringing…

Some form of type inference was proposed for C: http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2735.pdf

Re: New in C# 10: Easier Lambda Expressions

#48

Post by runevault »

spaetzleesser wrote: post #43
thrower123 wrote: post #4

F# is really, really bleeding into C#. There'll be a convergence, for all intents and purposes, by about C# 15 at this rate.

Is F# still moving forward? I am tempted to try it but I don’t want to bet on another tool MS may abandon soon like they did with the .NET frameworks.

Here's the blog post JUST for the changes in the newest release. It is surprisingly meaty for being something other than c#

https://devblogs.microsoft.com/dotnet/whats-new-in-fsharp-6/

Re: New in C# 10: Easier Lambda Expressions

#49

Post by kaidon »

pipeline_peak wrote: post #36
ShinTakuya wrote: post #27

Earlier quoted context omitted.

I think it's been elegant for a number of years now. Pretty much ever since Linq became usable.

Yeah, lambdas and reflection really.

Type inference with `var` as well; which was necessary for LINQ anyway IIRC.

Re: New in C# 10: Easier Lambda Expressions

#50

Post by pipeline_peak »

vips7L wrote: post #44
pipeline_peak wrote: post #36

Earlier quoted context omitted.

Yeah, lambdas and reflection really.

Personally I think reflection is the devil and the reason why we can’t abandon VMs for native compilers.

Reflection does away the need to manually implement serializers. In a growing codebase where data models transform and references to those models begin to rot, that is incredibly useful.
Post reply on HN