Live data from Hacker News

Understanding .NET 2015

blogs.msdn.com

91–100 of 107 posts

Re: Understanding .NET 2015

#91
post #26

Earlier quoted context omitted.

You don't need to use Java for Android or for the JVM, you can just use Scala. See Scaloid [1] for setting up Scala for Android and Scala Async [2] to get that nice "async" syntax you've mentioned. [1] https://github.com/pocorall/scaloid [2] https://github.com/scala/async

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 that for .NET / C#, there's like a circle of jerks on HN that down-vote everything that sounds bad about .NET.

That's fine, I had some hopes for Microsoft's .NET, now that it is finally being open-sourced and made multi platform, but when choosing a language, you're also choosing the ecosystem around it and this instance, amongst other interactions I've had, confirms that .NET is not for me and probably never will be.

Cheers,

Re: Understanding .NET 2015

#92
post #78

Earlier quoted context omitted.

Yes c# generics are often a lot less painful, due to lack of type erasure, and support for variable number of type parameters etc. Having said that, more is possible with Java than many people realise. You can read statically available generic type params at runtime (field declarations, supertype tokens etc) . There are also workarounds for most of the erasure problems like methods that vary by generic type parameter…

Having to rely on reflection is bad though.

Absolutely. My point is just that the Java generics not being available at runtime is a common complaint, but it's only partially true.

Most of the issues can actually be resolved even with type erasure. e.g. method overloading can be resolved statically.

Re: Understanding .NET 2015

#93

Earlier quoted context omitted.

You don't need to use Java for Android or for the JVM, you can just use Scala. See Scaloid [1] for setting up Scala for Android and Scala Async [2] to get that nice "async" syntax you've mentioned. [1] https://github.com/pocorall/scaloid [2] https://github.com/scala/async

Switching to Scala would mean learning all the Scala baggage (which has good intentions - granted). C# is much more accessible, while still being elegant - hence the ever-rising popularity.

I'm a Scala developer, I love Scala (which is why I keep mentioning it) and would be interested to know what baggage you're referring to.

For me Scala is more accessible and elegant than both C# and F# and in my opinion has less baggage.

Re: Understanding .NET 2015

#94
post #61

Earlier quoted context omitted.

> games Ever played something like e.g. Bastion? http://en.wikipedia.org/wiki/Bastion_%28video_game%29 I mean if you are developing the new Unreal Engine - sure. But otherwise gaming industry would benefit from more of maintainable code.

For context, Bastion was written in C#. Here's what the lead developer said on the topic of GC: http://www.reddit.com/r/IAmA/comments/lwljh/iama_dev_team_of...

It's simple: when looping either make stuff quick to collect or make it never collect.

Re: Understanding .NET 2015

#95
post #64

Earlier quoted context omitted.

C# also infers method type parameters, and will implicitly convert a lambda to a matching interface. Fluent code in C# is also very clean. They're great features in both languages.

You're right, c# does to some extent. On balance I do agree with you, and prefer the set of c# features. Just to clarify - I was thinking of things like this class Example { public static void Main() { Predicate foo = Foo (s => s.Contains("foo")); } static Predicate Foo (Predicate p) { return p; } } I can't replace Foo with just Foo on the right hand side on the 3rd line. I could, however, replace the left hand side…

Awesome examples, thank you. I apologize if you already know all of this stuff. You seem much more knowledgeable about this than me.

As for type inference, C# will sometimes infer the RHS from the LHS, lambdas are one example. Also sometimes it can figure out the types from a lambda. Here is an example where the type information for inference comes from the literal int zero:

  public void Main()
  {
    var i = 0;
    var list = MakeThree(() => i++);
    //[0, 1, 2]
  }

  private IList MakeThree(Func generator)
  {
    return new List{ generator(), generator(), generator() };
  }
C# will infer method type parameters from arguments. In your example, there wasn't a type on the parameter to use as a source of inference. You could write it instead as (contrived example):

  Predicate p = s => s.Contains("foo");
  var foo = Foo(p);
The type parameter on Foo is inferred, as well as the variable type on the LHS. The only time I write a type on the LHS is when I am assigning a lambda to a variable. And that is not super often. More realistically though, you would be passing a collection or something else that already has a type. For example in LINQ's IEnumerable extension methods, the IEnumerable is the source of the type information as the first parameter to the extension method, so everything is inferred from there. It's extremely rare for me to type a method type parameter. I cannot remember the last time I did. I do write the types for constructors often, though. new List(), new Dictionary() etc. I guess the tradeoff is that in java you can infer a lambda's type by writing it on the LHS, while in C# you are going to have to get that type from somewhere else. Either write it on the RHS, or it will be written on some other variable or method.

Also I use Func and Action every day, but I basically never use other delegate types.

Your example of structure typing of lambdas looks weird to me. It's the same feeling I get when I see a downcast. I mean no criticism; I suspect this is a Blub reaction in me. I am not used to looking at the left-hand side to figure out the type for the right-hand side. Lambdas will implicitly convert to a Func or Action. A reference to a method with a matching signature will also convert. As a silly example: Select takes a Func, and will implicitly convert a method that accepts the same T as its only parameter.

  public ShortTons ConvertTons(LongTons t) { ... }

  public void Main()
  {
    var readings = GetReadings();
    var exportWeights = readings.Select(x => x.Weight).Select(ConvertTons);
  }
In this example, there are elided, inferred type parameters everywhere. The source of the type is in the missing GetReadings method, and the Weight property on the reading type. That's pretty typical.

That builder pattern is pretty cool. In C# you have object initialization syntax, which is similar in being more readable as to which members are getting set. However, that's pretty much incompatible with immutability afaik. It only lets you set public properties with public setters. Normally you would make something immutable by making your setters private, or leaving them off entirely. Public fields (even readonly ones) are strongly discouraged in C#. Either way, that prohibits object initialization.

Thanks for responding, I learned a lot about Java.

Re: Understanding .NET 2015

#96
post #57

.NET Native ... It would be great to have it for back-end also as opposed to only front-end. I'd take that 60% startup increase in IIS also, the first request is always slow...

> I'd take that 60% startup increase in IIS also, the first request is always slow... But startup cost is less relevant in a server scenario. In a server you startup once per ~1B requests or more. In a front-end app, it might run 10 requests and then stop.

Agreed. But we do have API for internal jobs that are only used a few times a week. Then there is also the other 15%-20% memory reduction discussed in the article that I'd like to have back.

Re: Understanding .NET 2015

#97
post #87

Earlier quoted context omitted.

Citation? I was unaware that the little IEnumerable functions did fusion. If you mean an IQueryable execution, like LINQ-To-SQL, then sure.

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 fact, how else could "Where" be implemented while keeping lazy semantics?

(Rust, AFAIK, can actually do this, by inlining everything including the lambdas.)

Re: Understanding .NET 2015

#98
post #2

Recently I got to use some C# on Linux (with Mono framework), and I gotta say it wasn't bad. I didn't do anything with GUI elements, was all back-end server code. C# wouldn't be my top "go to" language, but I would put it above Java. I liked some of the generics handling better, it can be less verbose it seems. Monodevelop is not on par with Visual Studio, but it is solid and worked well for me. I usually don't like…

I am python developer, I am looking forward to program in F#. F# just seems right after developing with python unlike languages like c#, java.

I'd say Python is more like C# and Java than it is like F#. If you've never used F# (or Haskell, or something else like them) you're in for a surprise.

Re: Understanding .NET 2015

#99
post #38

Earlier quoted context omitted.

That's not the same, though; that's you purposefully combining your query (which you can do in LINQ). LINQ doesn't just combine Wheres. It tries to optimize your query as much as possible and executes lazily, so you aren't actually doing any work until you try to use the resultset (in a ToList, for example).

Yes. IQueryable actually implements an expression tree, which means that it may never be executed, at least directly. LINQ to Entities (Entity Framework) actually evaluates the expression tree to build SQL statements, then runs those and returns the results (after coercion back to the mapped POCO object).

Right. Actually Linq to SQL did the same thing, but a big philosophical difference is Entity will reject stuff that it can't resolve from the database instead of just letting you do whatever (which may involve multiple queries).

Re: Understanding .NET 2015

#100
post #77
post #25

I thought Microsoft was phasing out .NET and encouraging people to write their GUIs in JavaScript. That's what they were saying early last year.

I think the state of the Windows Store shows that approximately nobody took that seriously. Unfortunately there are a few libraries I use at work that were released around the whole Windows RT/JS debacle, so their documentation takes a little more figuring, and is frequently incorrect, due to only having code samples in these dead/orphaned variants.

I think part of it is that MS tied WinRT to full screen-only apps, a mistake they're fixing in Windows 10. Some of the features of the WinRT API look neat.
Post reply on HN