So, Microsoft just open sourced most of .NET...

[DanLamb]

maybe try another language feature example? I am interested in seeing just what's so elegant about Scala but these examples with properties so far aren't particularly convincing.

- C# (and C++/Java) have both the old A[] syntax and the newer List<A> which are mostly the same thing. In C#, the A[] syntax is there for mostly pre C# 2.0 legacy. Scala completely removes the A[] style syntax and just has Array[A]. C++/Java/C# are also broken in that they let you cast arrays to parent types: you can cast Dog[] to Animal[] but they fixed generics to correctly stop code from casting List<Dog> to List<Animal>.
- if expressions return values.

C++/C#/Java have the ternary operator

A x = (condition) ? b : c;

Scala doesn't need that. Regular if handles that and extends to multiple else if cases as well:

val x = if (condition) b else c;

- Better type inference. C# does type inference on local variables with "var" but doesn't do type inference on class/static variables or properties or function return types. Scala does all of them.
- A class can return this.type so that "return this" returns the derived sub type. C#/Java require super complex use of generics to get a similar effect.
- Pattern matching. This is a key feature of the language.
- Native partial functions.
- Native function currying.
- for comprehensions. Scala's "for" is like a language native query engine. It works with any type with map and flatMap. If you use flatMap a lot, this is really nice. Standard types that define flatMap and are commonly used in for comprehensions are Option, List, Map, and Future.
- Option rather than null. Scala handles null for Java interop, but the Scala ecosystem uses Option instead of nullable values. C++/Java/C# are all primarily null based. Java 8 has Optional, but it's not used everywhere. F# and Haskell use Option (or Maybe). Also Scala's pattern matching and for comprehensions are ideal for supporting Option.

Lastly, I can't think of anything that C# or Java actually do better.

[Luke_Wolf]

- C# (and C++/Java) have both the old A[] syntax and the newer List<A> which are mostly the same thing. In C#, the A[] syntax is there for mostly pre C# 2.0 legacy. Scala completely removes the A[] style syntax and just has Array[A]. C++/Java/C# are also broken in that they let you cast arrays to parent types: you can cast Dog[] to Animal[] but they fixed generics to correctly stop code from casting List<Dog> to List<Animal>.

Well C++ ingrained it into me hard to never ever use arrays directly anyway, and to always use containers, and as a result I don't use arrays in C# either, particularly as I don't really have a use case for arrays vs containers.

- if expressions return values.

C++/C#/Java have the ternary operator

A x = (condition) ? b : c;

Scala doesn't need that. Regular if handles that and extends to multiple else if cases as well:

val x = if (condition) b else c;

I will certainly give you that one, while it's not as concise If-Elses are a lot more readable

- Better type inference. C# does type inference on local variables with "var" but doesn't do type inference on class/static variables or properties or function return types. Scala does all of them.

Actually I don't want type inferencing in my class definitions, it makes things more concise yes but it should really only be used when you're either requiring the dynamicism it allows or are making the code more concise by listing the type only once, otherwise it can destroy the clarity of the code without tool assistance.

- A class can return this.type so that "return this" returns the derived sub type. C#/Java require super complex use of generics to get a similar effect.

I'm not quite sure I understand. This sounds like a reflection problem and then you mention generics, could you give an example use case, maybe that'll help me understand what you're getting at here better?

- Pattern matching. This is a key feature of the language.

What's it have over LINQ?

- Native partial functions.

C# has those, I just mark a class or function as partial and then define it somewhere else

- Native function currying.

after some looking around it looks like C# has this, although my understanding of it is basically that it really just amounts to making one argument helper functions, which... isn't really that useful

- for comprehensions. Scala's "for" is like a language native query engine. It works with any type with map and flatMap. If you use flatMap a lot, this is really nice. Standard types that define flatMap and are commonly used in for comprehensions are Option, List, Map, and Future.

I looked this up and found this http://tataryn.net/2011/10/whats-in-...comprehension/ I don't understand what advantage this has over using LINQ?

- Option rather than null. Scala handles null for Java interop, but the Scala ecosystem uses Option instead of nullable values. C++/Java/C# are all primarily null based. Java 8 has Optional, but it's not used everywhere. F# and Haskell use Option (or Maybe). Also Scala's pattern matching and for comprehensions are ideal for supporting Option.

I read the wikipedia article on Option types and I still don't understand the difference/justification, care to explain this point?

Lastly, I can't think of anything that C# or Java actually do better.

Does Scala have code attributes and related to that data contracts? these are essential features for me when I'm doing anything involving serialization and deserialization because I can just mark up my code with attributes and as long as the data is in a standard format it does it all automatically for me.

[droste]

The Scala translation of that C# would be the following. I added a dummy wrapping TestClass and an initial value.
[...]

You missed the point of my post. I'm not denying that it has an "easier" syntax or can't do the same as C#. My statements were:

1. Easier syntax doesn't mean easier code!
2. Class/instance variables + properties add the additional value of what is interface and what's not.
3. You could create all your classes with only properties and no class/instance variables, but I won't be doing this (alt least since C# 3.0).

[justmy2cents]

Why would you want a C# class instance variable instead of a class instance property?

I know the difference between a C# class instance variable and a class instance property. C# properties have more features that C# class instance variables, so why is the latter necessary?

seems you don't know the difference then and if you don't know basic thing like that

... You probably should have a more articulate objection to Scala before you post about it.

you should listen to this guy more also, when did i ever said scala is bad? i said that some old remnants of my pascal beginnings are downright screaming when looking at scala. so, why bother with something you don't like at first glance?

ok, that was a bit sarcastic on my part, but unfortunatelly true

What bothers you about the naming conventions? camel case?

more or less everything. but, camel case is probably biggest.

[DanLamb]

- A class can return this.type so that "return this" returns the derived sub type. C#/Java require super complex use of generics to get a similar effect.

I'm not quite sure I understand. This sounds like a reflection problem and then you mention generics, could you give an example use case, maybe that'll help me understand what you're getting at here better?

Try to do the following where a ShapeBuilder can "return this" with the derived type. You can do it in C#/Java, but it requires elaborate use of generics:

class ShapeBuilder {
  def color(color: String): this.type = {
    this.color = color
    this
  }
  
  def build() = new Shape(color)
  
  protected var color: String = ""
}

class CircleBuilder extends ShapeBuilder {
  def radius(radius: Int): this.type = {
    this.radius = radius
    this
  }
  
  override def build() = new Circle(color, radius)

  protected var radius: Int = 0
}

object BuilderTest extends App {
	val c = new CircleBuilder().color("blue").radius(5).build();
}

- Pattern matching. This is a key feature of the language.

What's it have over LINQ?

LINQ is not really related.

- Native partial functions.

C# has those, I just mark a class or function as partial and then define it somewhere else

Same keyword, completely different concept. C# has the "partial" keyword where you can split a class definition across multiple files. Microsoft added that specifically to accommodate a MS auto-generated code framework.

That has nothing to do with what I was referring to: mathematical partial functions, where the function is defined only for a specific domain of input values.

- for comprehensions. Scala's "for" is like a language native query engine. It works with any type with map and flatMap. If you use flatMap a lot, this is really nice. Standard types that define flatMap and are commonly used in for comprehensions are Option, List, Map, and Future.

I looked this up and found this http://tataryn.net/2011/10/whats-in-...comprehension/ I don't understand what advantage this has over using LINQ?

There is a lot of overlap.

- Option rather than null. Scala handles null for Java interop, but the Scala ecosystem uses Option instead of nullable values. C++/Java/C# are all primarily null based. Java 8 has Optional, but it's not used everywhere. F# and Haskell use Option (or Maybe). Also Scala's pattern matching and for comprehensions are ideal for supporting Option.

I read the wikipedia article on Option types and I still don't understand the difference/justification, care to explain this point?

Option/Maybe are better than traditional C++/Java/C# null for two reasons:

- static type safety and more compile time correctness checking over plain null. With plain null, the compiler does almost nothing to stop a NullPointerException. With Option[A]/Optional<A>, the compiler can stop most errors.
- Simplifies a lot of common code surrounding null: factors common "if" checks into a library type. Also removes the need for many temporary variables.
- Works particularly well with Scala's pattern matching:

Simple function in C#:

    static void simpleMapTest(Dictionary<String, int> m, String s) {
        if (m.ContainsKey(s)) Console.WriteLine(String.Format("found match for {0} = {1}", s, m[s]));
        else Console.WriteLine(String.Format("no match for {0}", s));
    }

Scala version using Option and pattern matching:

  def simpleMapTest(m: Map[String,Int], s: String): Unit = m.get(s) match {
    case None => println(s"no match for ${s}")
    case Some(i) => println(s"found match for ${s} = ${i}")
  }

The Scala version correctly does the map lookup once. The C# is actually doing the map lookup twice. You can use C# TryGetValue to fix that, but then the code is more complex.

Secondly, the C# code is more fragile and easier to break. If you are copy/pasting code or refactoring and accidentally pass a different key to m[s] you can trigger a NullPointerException without the compiler catching it.

Does Scala have code attributes and related to that data contracts? these are essential features for me when I'm doing anything involving serialization and deserialization because I can just mark up my code with attributes and as long as the data is in a standard format it does it all automatically for me.

Scala has attributes, but calls them annotations. There are tons of Scala serialization frameworks, but I'm not familiar with them and I don't know if they do exactly what you have in mind.

[justmy2cents]

Try to do the following where a ShapeBuilder can "return this" with the derived type. You can do it in C#/Java, but it requires elaborate use of generics:

... random bs

i'm starting to wonder what this pissing contest is about, since it makes no sense at all with the thread. and the only reason why i participate is if anyone else would see what i can't, like "hmm, they didn't open source x or y and this doesn't guarantee you as much freedom as you thought"
MS open sourcing .Net compiler is not equal to MS open sourcing c#, but rather c# is part of the scope they open sourced.

note to you, all high level languages in this era are more or less covering all the bases and choice about which one you prefer is more or less bound by syntactic sugar and deployment requirements than by features. do i like java?... no, i have my reasons. do you like .Net?... no, you probably have your own reasons. but, do we really need to care about each others reasons? no

in both, java and .net you can extend language which makes any "yea, but mine has...." absolutely pointless.

i don't know for java, but in .Net (note, i use .Net, not c#, since roslyn is not bound to c# beside the fact it provides already done compiler for c# and vb) you could always write CodeCom provider. now, with roslyn being opensourced, this became even more trivial. not to mention there is a patent grant to do so legally, which is complete 180 from ECMA state before

[justmy2cents]

i'm starting to wonder what this pissing contest is about, since it makes no sense at all with the thread. and the only reason why i participate is if anyone else would see what i can't, like "hmm, they didn't open source x or y and this doesn't guarantee you as much freedom as you thought"
MS open sourcing .Net compiler is not equal to MS open sourcing c#, but rather c# is part of the scope they open sourced.

note to you, all high level languages in this era are more or less covering all the bases and choice about which one you prefer is more or less bound by syntactic sugar and deployment requirements than by features. do i like java?... no, i have my reasons. do you like .Net?... no, you probably have your own reasons. but, do we really need to care about each others reasons? no

in both, java and .net you can extend language which makes any "yea, but mine has...." absolutely pointless.

i don't know for java, but in .Net (note, i use .Net, not c#, since roslyn is not bound to c# beside the fact it provides already done compiler for c# and vb) you could always write CodeCom provider. now, with roslyn being opensourced, this became even more trivial. not to mention there is a patent grant to do so legally, which is complete 180 from ECMA state before

CodeDom, not CodeCom, lol

[DanLamb]

You missed the point of my post. I'm not denying that it has an "easier" syntax or can't do the same as C#. My statements were:

1. Easier syntax doesn't mean easier code!
2. Class/instance variables + properties add the additional value of what is interface and what's not.
3. You could create all your classes with only properties and no class/instance variables, but I won't be doing this (alt least since C# 3.0).

1. You agree that Scala's syntax is simpler regarding properties/variables with less keywords and syntax complexity and that Scala can usually implement the same property/variable logic with less code. Your point is that this isn't easier? I don't follow. Are you sure this just isn't what you are used to?

2. You don't need the complexity of C# for that value. Example:

// Abstract trait (interface) with a read-only property/definition and a read-write property/variable
trait SomeInterface {
  def rprop: Int
  
  var rwprop: Int
}

// Implementation without custom get/set logic.
class SomeSimpleClass extends SomeInterface {
  val rprop: Int = 3;
  
  var rwprop: Int = 4;
}

// Implementation with custom get/set logic. Uses an internal variable (aka property)
class SomeNonTrivialClass extends SomeInterface {
  private var x = 100;
  
  def rprop: Int = x + 1;
  
  def rwprop: Int = x + 2;
  def rwprop_=(v: Int): Unit = x = v;
}

[DanLamb]

i'm starting to wonder what this pissing contest is about, since it makes no sense at all with the thread. and the only reason why i participate is if anyone else would see what i can't, like "hmm, they didn't open source x or y and this doesn't guarantee you as much freedom as you thought"

in both, java and .net you can extend language which makes any "yea, but mine has...." absolutely pointless.

Earlier, you said there is no decent competition to .NET/C#:

which competition? more or less fare equally bad

And you said Java isn't even close to as good as C#:

https://code.google.com/p/dblinq2007/
not even close. they are very much different. for example, java class has no real in code visible properties. you need to write get_/set_ methods and then remember that those are property methods. in c# you write as public int something { get; set; }. languages differ on lots of things where c# simply took nicer approach

When I articulate how Scala addresses that _exact_ issue better than Java or C#, you dismiss the whole discussion...

To tie this in to the original discussion:

- It is legitimately good that Microsoft is moving more of their tech to open source.
- Technology preference is both subjective and contentious, but JVM is at the very least a close match for what .NET can do.
- Neither C# or Java can legitimately be called cutting edge languages. There are reasons to use them, but there are free better choices.
- In many practical measures of "openness", JVM is ahead of .NET. On JVM, Linux/Mac/Windows have been fully supported in every way and there is community momentum behind that. The .NET side does have Mono and legally open standardization, and if you want to build out C# infrastructure you have some protection from litigation, but a lot of the real world .NET community is Windows only. If you want ready to use tools and ecosystem that fully supports Linux/Mac/Windows and beyond OS, you want better support for non-Microsoft databases or a more vendor neutral community, JVM is way ahead and ready to use.

[jayrulez]

Scala is just as broken: https://www.youtube.com/watch?v=TS1lpKBMkgg