Live data from Hacker News

Understanding .NET 2015

blogs.msdn.com

101–107 of 107 posts

Re: Understanding .NET 2015

#101
post #87

Earlier quoted context omitted.

LINQ IEnumerable functions are implemented using the `yield return` operator: public static IEnumerable Where (IEnumerable source, Predicate predicate) { foreach(var item in source) { if(predicate(item)) yield return item; } } which means var results = myList .Where(x => x.name == 'Person'); .Where(x => x.age > 18); .ToList(); is executed just like var results = new List (); foreach(var x in myList) { if(x.name == 'P…

I think your "executed like" is missing another foreach loop, and the actual function calls (lambdas don't get inlined on the C# compiler, and it's a bit of a crap shoot when counting on the JIT). The end result is the same, but you're eliding a bunch of allocation, branches and method invocations that occur in the actually executed code. Which is the whole point of optimizations for such code, which LINQ lacks. In f…

There is no missing foreach loop because LINQ iterators are smart enough to combine predicates whenever possible (source here: http://referencesource.microsoft.com/#System.Core/System/Lin..., see line 204 when dealing with arrays).

You're right it's missing the actual function calls, but that wasn't the point: the point here was that LINQ avoids building temporary enumerations and iterating over them like JS functions do.

Re: Understanding .NET 2015

#102
post #85
post #82

Earlier quoted context omitted.

Why? I hear this a lot, but I never understood it. I do a lot of work with reflection to achieve things I can't otherwise do (around application extension, dynamic systems for games, etc.). I mean, attributes are reflection, and they're absolutely invaluable.

Because it's not maintainable in a large code base. You write your code, and move on to something else, someone else comes a long and does a refactor, but they and/or the IDE misses the member names that were in strings. The program crashes on the next deploy because it built just fine. Reflection is like anything else it can be used properly and it can be abused. I've seen it abused far too many times. I realize the…

A killer feature of the Ceylon programming language is its typesafe metamodel. Metamodel references are refactored like everything else in eclipse.

Re: Understanding .NET 2015

#103
post #26

Earlier quoted context omitted.

Yes, the problem can be solved by using a different language. I'm pretty sure that was the point.

It's choosing a different language, versus choosing a different VM, different libraries, a whole different ecosystem, plus it happens to be quite expensive. The JVM is not home only to Java. One PITA for me is that whenever talks about various technologies happen on HN, I tend to comment on disadvantages, because it's the disadvantages that dictate the best use cases for that particular technology. But whenever I do…

I just don't see the relevance of your comment. Nobody had indicated any need to use JVM, as far as I'm aware. So you seemed to be addressing "what's the best language for JVM" rather than "what's the best way to solve this problem."

This just isn't a JVM vs .NET competition. If Prolog were the best answer, you could port it to JVM or .NET to your heart's content.

Re: Understanding .NET 2015

#104
post #101

Earlier quoted context omitted.

I think your "executed like" is missing another foreach loop, and the actual function calls (lambdas don't get inlined on the C# compiler, and it's a bit of a crap shoot when counting on the JIT). The end result is the same, but you're eliding a bunch of allocation, branches and method invocations that occur in the actually executed code. Which is the whole point of optimizations for such code, which LINQ lacks. In f…

There is no missing foreach loop because LINQ iterators are smart enough to combine predicates whenever possible (source here: http://referencesource.microsoft.com/#System.Core/System/Lin... , see line 204 when dealing with arrays). You're right it's missing the actual function calls, but that wasn't the point: the point here was that LINQ avoids building temporary enumerations and iterating over them like JS functio…

Ah, that's a cool optimization.

But here's a microbenchmark[1]. It's still not close to non-LINQ code. A factor of 10, with a trivial body, just summing up some numbers. (I didn't used Sum() as it appears to use checked arithmetic.)

As far as the optimizations, the smart combining code (which still has to allocate a combined delegate + lambda object, that'll cost, what 2 objects at like 40 bytes each?)) only happens when Select is followed by Select, or Where by Where. Select after Where gets a new "WhereSelectEnumerableIterator" and so on.

So you're right that it does eliminate some overhead though depending on the order of your Wheres and Selects there may be more "foreach" loops in the comparable code. And it's still not even close to being free like it should be. (Like, say, Haskell can do sometimes.)

1: http://pastebin.com/7J9FErWN

Re: Understanding .NET 2015

#105

Any reasons I should switch to Java or other technologies? What I get with the (much hated) Microsoft stack: - C# with LINQ and async await - Roslyn compiler as a service which speeds up development - mature .NET framework - more and more open source and cross platform parts and smaller independent libs - typescript - Xamarin cross platform tools I also use python and used Java in the past. I don't see any reason why…

The Clojure language is far more mature on the JVM than on .NET. Clojure is useful for scripting Java classes, and you can use its macros to create new syntax if other JVM scripting languages (e.g. Beanshell, Xtend, JRuby, Jython) don't have pre-existing syntax to meet your needs.

Re: Understanding .NET 2015

#106
post #28

Earlier quoted context omitted.

I don't think it's written from scratch. Why would it be? WPF and Windows Forms have some Windows specific stuff that would be irrelevant in a cross-platform version.

That's what I'm asking. It's very unclear, even when reading stuff like http://blogs.msdn.com/b/dotnet/archive/2014/12/04/introducin... I remember looking at the corefx github project just after the announcement, and it was very sparse with just a few commits and classes; it looked a lot like a brand new project written from scratch. This wording also makes it sound like ".net core" is a re-boot, scorched earth reimp…

They didn't develop it in git, just dumped it in github. That explains the lack of commits.

I don't see how the quote substantiates the notion that .NET core is written from scratch.

Re: Understanding .NET 2015

#107
post #28

Earlier quoted context omitted.

I don't think it's written from scratch. Why would it be? WPF and Windows Forms have some Windows specific stuff that would be irrelevant in a cross-platform version.

That's what I'm asking. It's very unclear, even when reading stuff like http://blogs.msdn.com/b/dotnet/archive/2014/12/04/introducin... I remember looking at the corefx github project just after the announcement, and it was very sparse with just a few commits and classes; it looked a lot like a brand new project written from scratch. This wording also makes it sound like ".net core" is a re-boot, scorched earth reimp…

In fact, a quote from [1] clearly states that it contains "largely the same code ... refactored":

".NET Core also includes the base class libraries. These libraries are largely the same code as the .NET Framework class libraries, but have been factored (removal of dependencies) to enable us to ship a smaller set of libraries."

[1] http://www.dotnetfoundation.org/netcore5

Post reply on HN