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

91–100 of 111 posts

Re: New in C# 10: Easier Lambda Expressions

#91

Post by thinkharderdev »

FpUser wrote: post #45
spaetzleesser wrote: post #41

Earlier quoted context omitted.

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.

I think you and the parent are saying basically the same thing. I've been working in Scala for the past 10ish years and we have definitely gone through the "hype cycle" of operator overloading. Early Scala libs went a little nuts with creating an incredible array of symbolic operators (most famously this atrocity http://www.flotsam.nl/dispatch-periodic-table.html). We collectively realized that this was overboard and now Scala libraries typically provide a more modest set of symbolic operators (and generally the symbolic operators are just aliases for named methods so you can decide which ones you want to use in any particular codebase).

I would also disagree with the characterization as shitty code. The operators are actually really nice if you manage to learn them all well. It can make the code both very concise and readable. But it optimized for people who know the libraries extremely well over people who don't, which usually is not a great tradeoff for widely used libraries.

Re: New in C# 10: Easier Lambda Expressions

#92

Post by agumonkey »

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…

What you see as innovation is just slow diffusion into mainstream, the last decade is basically 80s sml family.

The funny .. or sad.. part is that the c#9 explicit ~verbose style would have been the only one accepted before. If you wrote implicitely typed variables people would get angry (I think there are many online articles about how java 9 `var` was bad)

Re: New in C# 10: Easier Lambda Expressions

#93

Post by caseymarquis »

pipeline_peak wrote: post #71
oaiey wrote: post #58

Earlier quoted context omitted.

There are anonymous types for intermediate results in the linq stream. And since they are anonymous types you need the c var keyword when working with the outcome.

….All these years and I’ve never known about Anonymous types. I know about records and dynamic objects. I’m guessing they aren’t used often because I have yet to find them.

LINQ GroupBy() is the most common use I can think of. I would definitely look into that as it's a nice tool to have. Otherwise, keep them in mind if you're ever pulling data from an external source (SQL, JSON, GQL, Redis, etc) and you're annoyed about having to make a class for some trivial operation.

If a library doesn't have an API for using them with generics, you can paper over that with:

    T fn(T throwAway) => Library.Deserialize();

Re: New in C# 10: Easier Lambda Expressions

#94

Post by xigoi »

5e92cb50239222b wrote: post #56
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…

Static type systems with global type inference haven't had this problem since the beginning (for example OCaml, right around the time Java came out). However, for some obscure reasons the shittier the technology, the more chances it has at becoming popular. Try Elm as a simple example (can be done in a weekend), it'll probably blow your mind. You don't have to write type annotations at all, but the compiler complains…

> However, for some obscure reasons the shittier the technology, the more chances it has at becoming popular.

The reasons are simple: it's promoted by a big company. Same reason why C# and Go are popular.

Re: New in C# 10: Easier Lambda Expressions

#95

Post by FpUser »

thinkharderdev wrote: post #91
FpUser wrote: post #45

Earlier quoted context omitted.

>"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.

I think you and the parent are saying basically the same thing. I've been working in Scala for the past 10ish years and we have definitely gone through the "hype cycle" of operator overloading. Early Scala libs went a little nuts with creating an incredible array of symbolic operators (most famously this atrocity http://www.flotsam.nl/dispatch-periodic-table.html ). We collectively realized that this was overboard an…

>"The operators are actually really nice if you manage to learn them all well. It can make the code both very concise and readable."

This sounds suspiciously regex like. Concise it is, readable it is not. But regex is unique case and and harassing people with similar patterns in every line of code should be punishable by at least 10 years of maintaining complex software written in Brainfuck.

Re: New in C# 10: Easier Lambda Expressions

#96

Post by d3nj4l »

kqr wrote: post #90
vicda wrote: post #89

Earlier quoted context omitted.

Haskell is held back by pushing category theory into their tutorials. Want to do IO? Great, first learn about monads.

That's not true and never has been. Want to do I/O? main = do putStrLn "Who are you?" name There. Do you really need to know something about monads to understand that example? No. Do you need to know how do syntax and the assignment operator <- works? Sure. But that has nothing to do with category theory. That's just syntax.

Cunningham's law in action, everyone!

Re: New in C# 10: Easier Lambda Expressions

#97

Post by brundolf »

agumonkey wrote: post #92
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…

What you see as innovation is just slow diffusion into mainstream, the last decade is basically 80s sml family. The funny .. or sad.. part is that the c#9 explicit ~verbose style would have been the only one accepted before. If you wrote implicitely typed variables people would get angry (I think there are many online articles about how java 9 `var` was bad)

> What you see as innovation is just slow diffusion into mainstream

It can be both. Type inference isn't a brand-new idea, but it still takes work to diffuse it into mainstream, practical languages, especially retrofitting it onto existing languages that weren't designed for it. That still counts as innovation in my book.

Re: New in C# 10: Easier Lambda Expressions

#98

Post by lamontcg »

TheMatten wrote: post #66
thomasz wrote: post #64

Earlier quoted context omitted.

Local inference is a gift sent from heaven, global inference not so much. Reading OCAML (and F#) is exhausting because you have to look into the implementation of each function (or into a separate interface file) to figure out how it's supposed to be called and what it is going to return.

One could argue that this is better covered by IDE/tooling showing you inferred types / suggestions.

If the function is printed in a journal article, or you just use something like 'less' to look at the file all that information is not available.

I find it kind of weird that we've normalized not being able to read the code outside of the proper program for it. Since those IDEs often cost money it starts to feel a bit like steps towards a walled garden to me, and I'm not sure its good for actual computer science.

Re: New in C# 10: Easier Lambda Expressions

#99

Post by metaltyphoon »

sirwhinesalot wrote: post #87
5e92cb50239222b wrote: post #59

Earlier quoted context omitted.

JVM's garbage collectors are at least a decade worth of effort ahead of CLR. I am talking out of my ass here, but from reading people working on large projects JVM has no problem chewing through multi-terabyte large heaps. The recently introduced collectors (Shenandoah and ZGC) even keep the same pause times (something like 99 percentile within 1 ms and 99.9 within 10 ms). The largest heap you might be able to use un…

You know C# has records too right? "With" and all.

That should be enough to know he/she hasn't done "enough" to know anything.

Re: New in C# 10: Easier Lambda Expressions

#100

Post by pharmakom »

lamontcg wrote: post #98
TheMatten wrote: post #66

Earlier quoted context omitted.

One could argue that this is better covered by IDE/tooling showing you inferred types / suggestions.

If the function is printed in a journal article, or you just use something like 'less' to look at the file all that information is not available. I find it kind of weird that we've normalized not being able to read the code outside of the proper program for it. Since those IDEs often cost money it starts to feel a bit like steps towards a walled garden to me, and I'm not sure its good for actual computer science.

I think development containers are a better way to deliver code with a paper.

Besides, the paper itself should optimise for clarity and global type inference languages allow type annotation where it might help. They simply let you skip type annotations which only add noise.

Post reply on HN