51–60 of 60 posts
LINQ definitely helped me get my Unity gamedev sideproject get completed faster
I only have ever used LINQ in the context of enterprise. What are your thoughts on using it in game dev?
For example, in a game you may have a situation where you maintain a runtime list of objects with a certain property but you want to filter by some other property
Earlier quoted context omitted.
I only have ever used LINQ in the context of enterprise. What are your thoughts on using it in game dev?
Very useful when you need to do logic on Iterables. Feels almost like python. For example, in a game you may have a situation where you maintain a runtime list of objects with a certain property but you want to filter by some other property
I worked in a C# shop for a bit, but never wrote LINQ and saw very little of it. However, in my Java days, I've very much enjoyed using streams. Looking back at LINQ now, it seems like a nice DSL around streams (which probably exist in C# land, too). Interested in commentary around this!
You worked in a C# shop and never wrote LINQ? How is that possible? That's like driving a manual car and never shifting out of first gear.
"But what if I told you we could make it simpler" ... and then the author proceeds to presenting clunky, unreadable fluent syntax That was a good joke for the afternoon.
Can you show me how you would write it? I don't see how this contributes to the conversation unless you show me how or why These patterns are commonplace for many years now in many languages. The intention was to show how declarative code can come from imperative with a 'true' one-liner.
i've worked with people in the past who refused to allow any actual LINQ in the codebase (use resharper to convert it to fluent!) even though it essentially became obfuscated.
Earlier quoted context omitted.
Very useful when you need to do logic on Iterables. Feels almost like python. For example, in a game you may have a situation where you maintain a runtime list of objects with a certain property but you want to filter by some other property
Interesting. I remember a gripe being the performance of LINQ wasn't great even for a webapp years back. I'm assuming its negligible nowadays or did you notice less frames when the LINQ runs?
For my game it's irrelevant because most linq loops are only triggered by events so there's no loops running on every frame.
For example, lets say you have state machine based AI, and a scripted event triggers tells an enemy starship to change allegiance. The enemy starship then scans a runtime set of enemy factions using LINQ that are within 3 km to identify new targets to attack.
Earlier quoted context omitted.
> 100% purity down the entire vertical is a very strong anti-pattern. It really isn't. The benefit of pure all the way down is that later you can replace bits with something more performant if necessary. But starting out with the idea that some bits should never be pure just means none of it is. The beauty of pure functional programming is that its very compositional nature means that you can replace a component with…
The problem is this tends to collide hard with things which are both stateful and mandatory ubiquitous, like logging. "Functional core, imperative shell" is a great tradeoff position though. >> Does F# care if a DLL it references was coded in a functional style Deeper problem: it can't know. It can only assume. I'd have to check how the loader works but it may be the case that "first call to a function in an external…
Logging is a side-effect and should be treated as such by using a declarative side-effect type, like an IO monad, or could be tracked for later persistence with a Writer monad.
The oft repeated “Functional core, imperative shell” is just nonsense when you try to do it for real. It’s one of those dogmatic statements that gets dragged out in these types of discussions and adds nothing. This is why effect monads are so useful: there’s no need to create arbitrary boundaries to have effectful and pure code.
Alan Turing already proved the equivalence between lambda calculus and the Turing Machine: anything imperative can be done functionally. There really is no need to create arbitrary boundaries.
In languages like C# it may be pragmatic to do so in certain circumstances, like making ASP.NET request-handlers invoke pure functional computations and return the result of the invocation. This is pragmatic/preferable to writing a competitor to ASP.NET. Outside of situations like that I don’t see any value to an ‘imperative shell’, whatever that actually means.
I'm the author of language-ext [1] a pure functional framework for C# and have been pushing the declarative programming thing in C# for over decade. C# is a great language for declarative programming and LINQ is awesome. You need to constrain yourself (and your team) so you don't fall into bad habits, but it can really pay dividends in terms of code stability/maintainability. I have a couple of samples that I think m…
Your documentation appears to be a bit broken. When I try to click on pipes I get a 404. Just to let you know.
The API docs are all auto-generated [1] so sometimes my repo markdowns get out of sync when I refactor!
But it’s also a fine line, when to use it and when not to. While LINQ is easy to read and make sense of, it is far from being easy to debug. Especially on inexperienced teams I tend to limit my LINQ usage and try to write more “debuggable” code. But that’s my approach, I would love to hear other peoples thoughts on it.
Earlier quoted context omitted.
> 100% purity down the entire vertical is a very strong anti-pattern. It really isn't. The benefit of pure all the way down is that later you can replace bits with something more performant if necessary. But starting out with the idea that some bits should never be pure just means none of it is. The beauty of pure functional programming is that its very compositional nature means that you can replace a component with…
The problem is this tends to collide hard with things which are both stateful and mandatory ubiquitous, like logging. "Functional core, imperative shell" is a great tradeoff position though. >> Does F# care if a DLL it references was coded in a functional style Deeper problem: it can't know. It can only assume. I'd have to check how the loader works but it may be the case that "first call to a function in an external…
Luckily you can log functionally.
Earlier quoted context omitted.
Interesting. I remember a gripe being the performance of LINQ wasn't great even for a webapp years back. I'm assuming its negligible nowadays or did you notice less frames when the LINQ runs?
I don't know why LINQ would have any better or worse performance than a standard loop for most tasks. Abusing LINQs will of course lead to degraded performance. I've found if you want to insert more logic into your loop, sometimes you have to switch batch to good 'ol loops. I'm sure folks abuse the convenience factor to write more loops rather than modify existing ones which can lead to degraded performance. For my g…