Variable Capture in C#

pie_flavor

@Mason_Wheeler said in Variable Capture in C#:

@error said in Variable Capture in C#:

LINQ has its own special syntax that ties to IEnumerable and IQueryable

Which is very rarely used IME. From what I've seen, it's far more common to do LINQ as extension method calls than as the SQL-esque "LINQ syntax".

Depends. If you have very complex joins, LINQ syntax can be far more convenient to write than LINQ chains, because LINQ syntax abstracts away anonymous classes and field lookup therein, and all you see is that you have several variables that you can refer to.

error

True enough. Can we talk about how weird it is that C# has optional late-binding? dynamic is a thing.

pie_flavor

@error I dunno, I think it's fine. Some languages let you turn on a type system. C# lets you turn it off.

ObjectMike

@pie_flavor said in Variable Capture in C#:

@error I dunno, I think it's fine. Some languages let you turn on a type system. C# lets you turn it off.

Because there are bad people in the world.

Mason_Wheeler

@error said in Variable Capture in C#:

True enough. Can we talk about how weird it is that C# has optional late-binding? dynamic is a thing.

Can we please not talk about 'dynamic'?

Jaloopa

@Mason_Wheeler said in Variable Capture in C#:

@error said in Variable Capture in C#:

True enough. Can we talk about how weird it is that C# has optional late-binding? dynamic is a thing.

Can we please not talk about 'dynamic'?

I've never encountered a case where dynamic makes sense except for using a library that had it in its API. And given the choice is try to find a different library that used the type system.

I do occasionally define something as dynamic to shut the compiler up when I'm playing around trying to work out what fields a new POCO might need before writing it out, but it never lasts close to check in time

pie_flavor

@Jaloopa I dunno, I think it's pretty neat for expandos.
But then they could just put expandos right in the language and not backend it to the entire scripting runtime.

Jaloopa

@pie_flavor said in Variable Capture in C#:

expandos

Not sure why packing materials should have first class language support, or even how that would be possible

pie_flavor

@Jaloopa

dotnet-bot

ExpandoObject Class (System.Dynamic)

Represents an object whose members can be dynamically added and removed at run time.

Magus

@pie_flavor Javascript is bad. Don't Javascript up your c# with that mess.

Mason_Wheeler

@Magus Blazor thread is

error

@Magus said in Variable Capture in C#:

Javascript is bad.

NodeBB is Javascript, are you saying NodeBB is... Oh.

Filed under: error_bot is Javascript, are you saying error_bot is... Oh.

Magus

@error yes.

hungrier

@error

dkf

@Mason_Wheeler said in Variable Capture in C#:

Any and all IEnumerables are lazy evaluation built on top of eager evaluation.

There's a sense in which eager evaluation is linked naturally to operational semantics and lazy evaluation to denotational semantics. Neither way is strictly linked of course, but the nature of expression of problems within the paradigm leads one to think in that way more easily.

The real key thing? Sometimes one way of doing it is better than the other, but neither is ever universally superior.

dkf

@pie_flavor said in Variable Capture in C#:

@Jaloopa

dotnet-bot

ExpandoObject Class (System.Dynamic)

Represents an object whose members can be dynamically added and removed at run time.

<p sourcefile="api/System.Dynamic.ExpandoObject.yml" sourcestartlinenumber="1" jsonPath="/summary">Represents an object whose members can be dynamically added and removed at run time.</p>

Nice onebox text, MS!

Mason_Wheeler

@dkf said in Variable Capture in C#:

The real key thing? Sometimes one way of doing it is better than the other, but neither is ever universally superior.

Right. You'll likely end up needing both at different points, which is why the system that makes it easier to implement both is objectively better.

dkf

@Mason_Wheeler said in Variable Capture in C#:

Right. You'll likely end up needing both at different points, which is why the system that makes it easier to implement both is objectively better.

Experience suggests that it's usually best to expect to use multiple languages on all but the most trivial of projects. The advantages of being able to actually say what you mean without the extra crap, and to do so on several levels (because sometimes you need to express high level things and sometimes you need to express low level things), those advantages definitely outweigh the increased complexity. This is closely related to the different types of semantics too, though not exactly the same.

topspin

@Mason_Wheeler said in Variable Capture in C#:

@dkf said in Variable Capture in C#:

The real key thing? Sometimes one way of doing it is better than the other, but neither is ever universally superior.

Right. You'll likely end up needing both at different points, which is why the system that makes it easier to implement both is objectively better.

And this statement is objectively wrong, assuming "easier" doesn't mean it's impossible in the other one.

Let's say:
System A defaults to doing X, and incurs a 200% penalty for doing Y.
System B defaults to doing Y, and incurs a 10% penalty for doing X.
Is system B objectively better?

Neither X nor Y are universally superior, but X accounts for 99% of things you do, while Y is 1%.
Total costs:
A = 0.99 * 1 + 0.01 * (1+2) = 1.02
B = 0.99 * (1 + 0.1) + 0.01 * 1 = 1.099
So no, B turned out to be worse even though it made it easier to do both things.

dkf

@topspin If you're doing enough of X and Y, it can be worthwhile creating a composite system, C, that uses A for X and B for Y.

Gąska

@dkf or setting up integration between A and B is so painful that it's better to just stick to A or B entirely. It's all about tradeoffs.

I've had exactly this kind of dilemma recently. I needed to make a GUI application that used one very particular library available only in OCaml. My choices were:

Do GUI in OCaml (painful).
Reimplement the library in another language, such as C# (also painful).
Make an OCaml library that I can link with C# somehow (turns out to be also painful).
Make two separate programs that communicate using streams (less painful, but I had to add serialization and deserialization on both sides and implement part of functionality twice).

I was lucky not to work in resource-constrained environment that would make (4) unfeasible.