Microsoft To Open-Source .NET, Bring It Officially To Linux

[DeepDayze]

Now why taint your Linux system with Microsoft-ware?

[slacka]

Can someone explain me please: How is this beneficial for Microsoft? Why are they doing this?

Web developers don't want to pay for system administrators and resources necessary to run their own web servers. By levering the economy of scale, the cloud services like Amazon have taken off with free OS's leading the way. For small shops in this environment, the cost of that Windows license looks less attractive.

Microsoft Azure business is doing well, and they see the writing on the wall. And you can run free operating systems on Azure, and .NET is already well supported on Azure. So what will sell more Azure? Make .NET run on the free operating systems. Now all the developers who like the free OSs on their personal dev systems are suddenly able to develop stuff they can deploy on Azure.

This is all about making Azure services more compelling and more competitve with Amazon.

[Michael_S]

I like int x = 4; For me it is easier to read, and I know everyone reading the code will know that 4 is not a string or object, but a primitive int 4. Other things like setters, new Object etc, from my POV, are done completelly automatically by IDEs for a decade now. After typing ClassName one usually just hits Ctrl + space two times, or something, and get ClassName className = new ClassName();

Now, why is def className = className.newInstance() better than 'new className();'? This is really a question since I have neither experience, nor theoretical knowledge in Scala or Groovy.

The IDE does the work for you, but it often means you have a class with 35 lines of code in which 32 are boilerplate and 3 do something useful. When you're reading the code, you find yourself skimming past boilerplate over, and over, and over again to get to the important bits.

Say I need a POJO (plain old Java object) with six fields and no custom behavior, and one of those fields is a Java Set, and one of those fields is, for the sake of argument, a java File. That's one package declaration (1 line of code), two import statements - two import statements anyone that knows the language past a beginner level could provide in their sleep (2 lines of code) - a class declaration and end closing bracket (2 lines of code), six field declarations (6 lines of code), a getter for each field (if you follow standard syntax conventions, that's 18 lines of code), a setter for each field (again, standard syntax conventions, 18 lines of code), and if you want a constructor that populates all of the fields that's 8 lines of code. 55 lines of code for your POJO. You can squish it down to 5 (package, two imports and one agonizingly long class declaration) if you don't care about readability. But idiomatic code layout, 55.

In Scala you would have the package statement, two import statements and then a one line class declaration:
class Foo(x:Int, y:Long, z:Set[String], a:File, b:String, c:Int)
That's not exactly equivalent to a POJO, in order to manipulate Foo.x instead of instance.getX() and instance.setX(22) you do foo.x and foo.x = 22, respectively. If you want to match Java with get and set you have to do more work. But inside Scala, that class works fine. You've just replaced 55 lines of Java code with 4 lines of Scala. In Java, our hypothetical class probably gets its own source file. It could be a static inner class elsewhere, but it's too big for that to make sense. In Scala, we could declare our hypothetical file as a static inner class (to be honest, I forget that syntax - but it's not complicated) right next to the code that will be passing those objects around and manipulating them.

In Groovy, you've got more work than Scala but less than Java. In Groovy when you declare an instance variable, it's automatically private and public getters and setters are created. You can use annotations to change that behavior, or if you provide your own public getter or setter it overrides the default. Groovy, takes all of the instance field declarations in order and automatically generates a constructor for you. So I could do a package declaration plus:
class Foo {
int x;
long y;
Set<String> z;
File a;
int c;
}
and get something identical in all respects to the Java POJO. From 55 lines of Java to 8 in Groovy.

But this is just the tip of the iceberg. Scala and Groovy (and other languages) have literal syntax for sets, lists, and maps. In Groovy those are included in the default imports. I'm not sure if they are in Scala. So in Groovy if I need to declare a map of Strings to Integers, I can just do Map<String,Integer> m = ["hello":26,"goodbye":33,"whatever":55] and then start using it.

Often in Java, I'm doing something like this:
SomeClass someInstance = null;
if (foo != null && foo.getBar() != null && foo.getBar().getBaz() != null) {
someInstance = foo.getBar().getBaz().getQuux();
}
In Groovy, they have the "save de-reference" operator "?." - which returns null if the variable it modifies is null, otherwise it walks the object graph. So that becomes
SomeClass someInstance = foo?.getBar()?.getBaz()?.getQuux();
If any of the objects in that graph relationship is null, someInstance is just set to null.

And so forth, and so on. Yes, Java does anything those languages can do. But why write 2000 lines of Java to accomplish something you can do with 500 lines of Scala or Groovy when you don't have to? The next time you need to change the code, reading 500 lines is faster than reading 2000 even when you know which parts of the Java to skim.

[yakman2020]

There was a study done in 1980 (I think) at IBM research which studied bug rates in code vs size, and concluded that in the sample series, there was a strong relationship indicating bug count was proportional to the number of lines to the power of 5.2.

Reasonable people may disagree on the exact number, which certainly would vary by team, programming practices etc, but clearly the fewer lines of code the better, unless the language itself has issues (for example weak typing) that would tend to make it less reliable.

An additional Groovy feature to Scala..... is that you can mix scala and java classes, so you can use existing runtime, and covert gradually, or only use scala where it "feels best".

[Luke_Wolf]

There was a study done in 1980 (I think) at IBM research which studied bug rates in code vs size, and concluded that in the sample series, there was a strong relationship indicating bug count was proportional to the number of lines to the power of 5.2.

Reasonable people may disagree on the exact number, which certainly would vary by team, programming practices etc, but clearly the fewer lines of code the better, unless the language itself has issues (for example weak typing) that would tend to make it less reliable.

An additional Groovy feature to Scala..... is that you can mix scala and java classes, so you can use existing runtime, and covert gradually, or only use scala where it "feels best".

That is an incredibly naive way to look at bug rates. Bugs increase with code complexity not with lines of code. The correlation between lines of code and bugs has to do with the fact that code complexity tends to increase as the number of lines increase, however code written to be compact will be more likely to contain bugs because it is harder to understand and thus more complex to read and write.

[Luke_Wolf]

The next time you need to change the code, reading 500 lines is faster than reading 2000 even when you know which parts of the Java to skim.

Have you never heard of code folding? I don't know about Java but C# has this nifty little thing called #region which lets me set up logical areas to fold code on besides just class and function level, so that I can create regions for constructors, properties, member functions, logical groups of functions, logical regions inside of functions and so on. With proper #region-ing all you need to read is a region label and the stuff you care about

[BlackStar]

Have you never heard of code folding? I don't know about Java but C# has this nifty little thing called #region which lets me set up logical areas to fold code on besides just class and function level, so that I can create regions for constructors, properties, member functions, logical groups of functions, logical regions inside of functions and so on. With proper #region-ing all you need to read is a region label and the stuff you care about

Which is, of course, irrelevant.

If you have to do a code review you have to go through each line regardless. I'd much rather review 500 lines of readable code than 2000 lines of boilerplate. C# definitely wins against Java here (and the upcoming C# 6 is even better.)

[Luke_Wolf]

Which is, of course, irrelevant.

If you have to do a code review you have to go through each line regardless. I'd much rather review 500 lines of readable code than 2000 lines of boilerplate. C# definitely wins against Java here (and the upcoming C# 6 is even better.)

Well if you're having to do code review you're having to do code review, that's ancilliary to you making changes to a codebase, and code folding helps significantly with making those changes, because it lets you locate things quickly.

But that said on the code review aspect I would agree

[ArchLinux]

the upcoming C# 6 is even better.

How could it possibly be better, if they keep on improving it?

Makes no sense.

Now why taint your Linux system with Microsoft-ware?

This was probably a tad sarcastic, but because it would be stupid to dismiss a product because you don't like the developer.

[vein]

Often in Java, I'm doing something like this:
SomeClass someInstance = null;
if (foo != null && foo.getBar() != null && foo.getBar().getBaz() != null) {
someInstance = foo.getBar().getBaz().getQuux();
}
.

Actually...this way of doing this in java in pretty old....I suggest you read about "Optional" in Java8, it should make your life easier:

http://www.oracle.com/technetwork/articles/java/java8-optional-2175753.html