Quote Originally Posted by ciplogic View Post
you can get that C++ to perform faster than .Net, but even so, you cannot get more than 20-30%. (you can get for specific cases, "happy cases").
This sounds reasonable.

Quote Originally Posted by ciplogic View Post
I agree and I know what you mean. First of all let's clarify: this doesn't make a person writing bad code to not have a more code usage. The "round of 8 bytes" of every data set and boxing make Java to consume much more than the dataset you want to represent. C# doesn't need this and this is a good thing.
...
But in the same time [C#] is not 10x more memory wasteful (like Java)
Claiming Java is 10x more memory wasteful is ridiculous. Even you don't believe that. The Mono guys purposefully design benchmarks like that, but that is deceptive in that you won't see anything so dramatic in more normal world scenarios. JVM has larger fixed memory overhead so you see a large percentage difference on a "hello world" program. But when you start loading actual data into memory, you won't see a dramatic memory difference like that.

If you load a byte[] in Java or a Array[Byte] in Scala, there is very close to zero overhead. I already agreed that it is a good thing that C# generics works with value types without a boxing overhead. You are just blowing that minor benefit out of proportion. Scala basically gives you the same benefit, where you don't have boxing overhead on somethign like Array[Byte].

Quote Originally Posted by ciplogic View Post
C# and Linq/database features are not related. Linq can be used from Boo, VB.Net, or any .Net language with a decent support of lambdas. It could be written in C# (which it is) but it doesn't relate with the fact that Linq (as technology) to be Windows centric. I use Linq day by day, and I don't target Windows or Sql server. Even I do programming on Windows (let's say), Linq can be used against Xmls, collections (arrays, List<T>), etc. which have no relation with the support of C#.
Sure, the in-memory LINQ functionality isn't permanently bound to C# or Microsoft and it could be potentially adopted by other non-Microsoft ecosystems. And if it makes sense to do so, it should adopted, regardless of passed history and politics.

However, LINQ isn't an originator and isn't unique in it's functionality. Scala natively provdes the functionality of in-memory LINQ, long before LINQ ever existed, and does it more seamlessly than LINQ where it's not this disjoint syntax separate from the rest of the language. Scala has arguably better technology, it's lacking the trademarked brand name, and Microsoft marketing, and all that, which isn't important to many people.

Quote Originally Posted by ciplogic View Post
C++ was probably made for describing business logic, and metaprogramming and was targetted for Unix development. This doesn't make C++ to not be very good for other environments (including Windows).
Same argument. If C# is technologically beneficial in other platforms, it can and should be adopted for technical reasons, regardless of whatever political issues have plagued that past.

I agree with this sentiment, but C# isn't even good technology. It has minor advantages over Java like reified generics and lack of generics related boxing (which Scala fixes) and native unsigned primitives (which isn't hard to work around). But C# is _far_ behind a more modern language like Scala. To quote myself in response to someone asking "Can you provide examples of legacy hacks and how Scala, Haskell and F# are actually better than languages like C# or Java?":

Quote Originally Posted by DanLamb View Post
Java has this horrific convention of writing getters/setters everywhere because you can't change a variable to a function without breaking source + binary compatability.

C# automates this with properties, but in some ways it's even worse. There is no reason C# should have both mostly redundant language constructs of variables/fields and properties. You can have a local variable, but not a local property. You can have an instance variable, but generally you can always replace it with an instance property. "readonly" works on instance/class fields, but not properties and not local variables, and it's different from const. If you want a read only property, that uses a completely separate syntax. Props can be overridden, variables can not. The "var" type inference mechanism works with local variables, but not instance variables or class variables or properties or function return values. What a complete chaotic mess!!

Scala has var (read/write) and val (read only) and that's it. Whether you use them as local var/vals, instance var/vals, or singleton var/vals, they work the same and use the same syntax and don't need a myriad of weird rules and legacy syntaxes and keywords. Type inference works in all cases and also works similarly with function return types.

null. Scala/F# support null for Java/C# interop, but native Scala/F# otherwise doesn't use null at all. Option is a much better solution than null. C#'s nullable types are a much weaker partial solution, which is why Microsoft's newer F# uses Option.

Arrays. C#/Java both started with arrays and added generics as a separate system later. Arrays should use the generics syntax. And they should use the same casting rules. Scala does, Java/C# do not. Java/C# have arrays that can downcast (covariance) which is a mistake that they can't fix for legacy reasons as you can write code that compiles but fails at runtime.

I mentioned LINQ. Scala does all the in-memory stuff that LINQ does in the core language where C# has this separate disjoint syntax bolted on.

Ternary operator. C/Java/C#/JavaScript use the ternary operator, because they don't have "if" expressions that return a value like Ruby, Scala, or most other modern languages. The ternary operator also doesn't extend cleanly to multiple else if conditions or multi-line expressions like an "if" expression.

Partial functions. C had switch/case statements which was carried over into JavaScript/C#/Java. This is similar to a mathematical partial function (a function defined for only some range of inputs like a logarithm function). Scala basically replaces the C-era switch/case with native partial function support.

Native support for tuples is extremely useful.

Native support for pattern matching is huge. This dove tails with Option btw.

Native support for currying. You can approximate it with C#/Java, but it's nice to have native support.

Look at Scala's parser combinator library for an example of some useful, practical code that really showcases the conciseness and elegance of Scala in a way that would be far more bulky in Java/C#.
Quote Originally Posted by ciplogic View Post
Java 7 was announced less than a week ago as supported by Dalvik when async/await support (VS 2012 feature, VS launched in October 2012) was ready as for start of 2013 in the master branch in Mono.
It's much worse than that. Dalvik doesn't support the major Java 7 enhancements, specificially the NIO.2 library which Google helped write, and Invoke Dynamic byte code. The Android toolset just supports soms superficial petty Java 7 syntax improvements, which is barely better than nothing.

The dated Java support is almost surely due to the legal battles with Oracle. I presume Google has been working to phase out Java and replace with something else, and that just hasn't been ready to announce.

IMO, there are much better languages than Java: Scala, Haskell, Ocaml, Rust, etc. But worse than Java, is using a completely out of date, legacy version of the language that is incompatabile with much of the more recent developments.

I am not downplaying this disaster, but are you just gloating? I never claimed Mono had this problem.

The async issue seems to be a tangent. Scala has super nice syntax for dealing with async programming, and I believe that can compile to Dalvik binaries.