5 ms·

I can make the same comment about C#/F# guys when I show them Scala. Scala is a better, more powerful language. I quite like C# and do it for my main contract

by runT1ME 13y ago

I can make the same comment about C#/F# guys when I show them Scala. Scala is a better, more powerful language. I quite like C# and do it for my main contract I have, but I am always missing features that Scala has, while I never have the inverse. It's nice that F# has better type inference, but I feel like it really isn't that different than C#. If C# got rid of boilerplate, made brackets optional, and fixed type inference, what does F# buy you?

_random_ 13y ago
I wish Scala for CLR has not been abandoned :(. Imagine a nice modern language that targets both CLR and JVM! A man can dream...
- JackMorgan 13y ago
  Well hold on to your hat: Clojure targets both AND JavaScript!
  - _random_ 13y ago
    Hmm, interesting. Is CLR a second-class citizen for it? How actively is the language developing?
    - _halgari 13y ago
      Very actively. We just released core.async, and Clojure 1.6 should be out by the end of the year (1.5 was released at the start of the year). And yes, the CLR is a bit of a second-class citizen.
endeavour 13y ago
You mean apart from discriminated unions, pattern matching, computation expressions, units of measure, partial function application, immutability by default and general lack of null reference exceptions? See also: http://www.youtube.com/watch?v=ExWfh6sGyso http://www.youtube.com/watch?v=ExWfh6sGyso
stevecooperorg 13y ago
Could you point out a few features? Would be interested to know.
- runT1ME 13y ago
  Higher kinds are quite nice. 1. In scala you could write class MyClass[A[_]](a: A) and it can only take a 'container' (List/Future/Option). in C#/F# this is invalid: class MyClass<A<?>> { public MyClass(A a) { } } You could make a plain ol' generic that took a concrete type List<Int> but not just on the type. 2. Implicit Conversion: In C#/F# you get extension methods, but it doesn't help you take an existing class and ad-hoc make it implement an interface. So in scala I could do this: trait XMLSerializable { def toXML(): XMLNode } and then let's say I want to make existing classes in the standard library implement this interface: implicit def toXMLSerializable(li: List[_]): XMLSerializable = new XMLSerializable { def toXML = { transformListToXML(li) } } I can now do: val genericXmlSerializable: XMLSerializable = List[Int](1,2,3,4)
MichaelGG 13y ago
Workflows. Tuples. Immutable types. Inline functions. First-class functions. Definable operators. Pattern matching. Active patterns. Type providers (although full hygienic macros would be even better). Everything-as-an-expression. Lack of nulls. Nested functions. Discriminated unions. Quotations (expression trees are a weak hack just for LINQ-to-SQL). Object expressions. Concise function definition and application syntax (which naturally creates the illusion called partial application). I make the inverse argument: At a minimum, you can use F# as C# but with better syntax. So what does C# buy you, if you're not using some of the VS designers?
- runT1ME 13y ago
  Good comment. Didn't realize F# let you have inline functions, everything as an expression and partial application. Forgot about pattern matching too! I don't really see a need for workflows, I can do everything I need to use workflows for with custom LINQ. I'll reconsider pushing F# for some of the c# work I do. However, if someone isn't bound to the CLR, i'll ask what F# gives you over Scala :-)
  - MichaelGG 13y ago
    Without workflows, you can't achieve e.g. async without building it into the compiler. You can abuse the LINQ syntax to simulate part of it, but you don't get proper exception handling, and it reads terrible as well. Versus Scala, F# seems far more concise. Scala seems to be very Java/OO oriented, and comparatively verbose. I understand the type system is more advanced in Scala. But I've not written anything in Scala so this is sorta speculation. I'd be surprised to find that the tooling for Scala surpasses F#'s though.

by runT1ME 13y ago

_random_ 13y ago

I wish Scala for CLR has not been abandoned :(. Imagine a nice modern language that targets both CLR and JVM! A man can dream...

JackMorgan 13y ago
Well hold on to your hat: Clojure targets both AND JavaScript!
- _random_ 13y ago
  Hmm, interesting. Is CLR a second-class citizen for it? How actively is the language developing?
  - _halgari 13y ago
    Very actively. We just released core.async, and Clojure 1.6 should be out by the end of the year (1.5 was released at the start of the year). And yes, the CLR is a bit of a second-class citizen.

endeavour 13y ago

You mean apart from discriminated unions, pattern matching, computation expressions, units of measure, partial function application, immutability by default and general lack of null reference exceptions? See also: http://www.youtube.com/watch?v=ExWfh6sGyso http://www.youtube.com/watch?v=ExWfh6sGyso

stevecooperorg 13y ago

Could you point out a few features? Would be interested to know.

runT1ME 13y ago
Higher kinds are quite nice. 1. In scala you could write class MyClass[A[_]](a: A) and it can only take a 'container' (List/Future/Option). in C#/F# this is invalid: class MyClass<A<?>> { public MyClass(A a) { } } You could make a plain ol' generic that took a concrete type List<Int> but not just on the type. 2. Implicit Conversion: In C#/F# you get extension methods, but it doesn't help you take an existing class and ad-hoc make it implement an interface. So in scala I could do this: trait XMLSerializable { def toXML(): XMLNode } and then let's say I want to make existing classes in the standard library implement this interface: implicit def toXMLSerializable(li: List[_]): XMLSerializable = new XMLSerializable { def toXML = { transformListToXML(li) } } I can now do: val genericXmlSerializable: XMLSerializable = List[Int](1,2,3,4)

MichaelGG 13y ago

Workflows. Tuples. Immutable types. Inline functions. First-class functions. Definable operators. Pattern matching. Active patterns. Type providers (although full hygienic macros would be even better). Everything-as-an-expression. Lack of nulls. Nested functions. Discriminated unions. Quotations (expression trees are a weak hack just for LINQ-to-SQL). Object expressions. Concise function definition and application syntax (which naturally creates the illusion called partial application). I make the inverse argument: At a minimum, you can use F# as C# but with better syntax. So what does C# buy you, if you're not using some of the VS designers?

runT1ME 13y ago
Good comment. Didn't realize F# let you have inline functions, everything as an expression and partial application. Forgot about pattern matching too! I don't really see a need for workflows, I can do everything I need to use workflows for with custom LINQ. I'll reconsider pushing F# for some of the c# work I do. However, if someone isn't bound to the CLR, i'll ask what F# gives you over Scala :-)
- MichaelGG 13y ago
  Without workflows, you can't achieve e.g. async without building it into the compiler. You can abuse the LINQ syntax to simulate part of it, but you don't get proper exception handling, and it reads terrible as well. Versus Scala, F# seems far more concise. Scala seems to be very Java/OO oriented, and comparatively verbose. I understand the type system is more advanced in Scala. But I've not written anything in Scala so this is sorta speculation. I'd be surprised to find that the tooling for Scala surpasses F#'s though.