4 ms·

At one point the discussion turned to language productivity and Phillip remarked that writing C# feels like completing government forms in triplicate. As he ela

by pohl 14y ago

At one point the discussion turned to language productivity and Phillip remarked that writing C# feels like completing government forms in triplicate. As he elaborated I experienced a sudden burst of clarity into one of the major things that had been bothering me about C# – it’s verbosity! It's like a parallel universe to the Scala/Java relationship.

Ingaz 14y ago
Even more: 1. Common ascendants Scala is heavily influenced by OCaml and Haskel. F# is descendant of OCaml, heavily influenced by Haskel. 2. Past Don Syme designed generics for .NET. Martin Odersky designed generics for JVM. 3. Erlang influence Acca - heavily influenced by Erlang and OTP, MailboxProcessor looking quite similar to Erlang processes. 4. Multiple paradigms Both languages combine FP and imperative. Scala is more OOP, F# is more FP. And (in my opinion) F# is looking more "clean" than Scala. Simple thing in F#: let (|>) g f = f g In Scala becames much more complicated. Also I think that discriminated unions are "prettier" than case-classes.
- bad_user 14y ago
  > Scala is more OOP, F# is more FP That depends on your background. As far as FP goes, I wouldn't see myself working in a FP language that doesn't have type-classes or something similar. Clojure has protocols and multimethods, Scala has type-classes based on implicits, while F# doesn't have anything like that. > F# is looking more "clean" than Scala. I don't know about that, I got used to Scala code. As far as the languages are concerned, I hate for instance how F# imported some language features from C# that really needed to die a long time ago, like static class members and operator overloading based on said static class members. Scala on the other hand cleaned all that crap. My problem with F# is basically that it has 2 type systems in the same language. Same problem that Ocaml has really, except Ocaml can also do some pretty cool tricks with structural typing for OOP that F# cannot. But anyway, these issues are actually irrelevant because the choice for developers will end up being the answer to ".NET or the JVM?"
  - Ingaz 14y ago
    I like what Odersky did with statics in Scala. I agree that F# is not pure as Haskel and limited in comparison with OCaml and Haskel. But the things that works in F# are working fine. In comparison with Scala: curring (by design) and tail-calls optimization are looking "more FP" in my opinion.
    - bad_user 14y ago
      Yeah, but LISP doesn't do currying and I find Scala's support for currying just fine, although the syntax in F# is definitely much nicer. Also Scala does optimize self-recursive tail-calls and it's pretty easy to work with trampolines. This is a platform limitation btw, as you can't optimize tail-calls without support from the VM. Mono, the open-source .NET implementation, also has problems with optimizing tail-calls (last time I checked) and I don't know about .NET 4.5, but .NET 4 was not optimizing tail-calls on 64-bits Windows. I remember reading a blog post about them fixing it on 64-bits OS in the latest version, but it wasn't the kind of feature you could rely on in the past. I do have hopes that TCO will make it into the JVM at some point, as there are experiments for it available as part of OpenJDK. Unfortunately the JVM moves at a glacial pace in regards to such features. This is both a blessing and a curse. I do agree with you. Not having full TCO in a functional language kind of sucks.
      - abolibibelot 14y ago
        and I don't know about .NET 4.5, but .NET 4 was not optimizing tail-calls on 64-bits Windows. Actually there's a .tail CLI Opcode in .NET for tail call optimization which is not usually emitted, but the JIT does tail call optimization on 64 bits (not on 32 bits though). You can witness this when you have a C# getter calling itself. On 32 bits, you get a StackOverflowException, on 64 bits it keeps running happily forever. For the specifics: http://blogs.msdn.com/b/clrcodegeneration/archive/2009/05/11/tail-call-improvements-in-net-framework-4.aspx http://blogs.msdn.com/b/clrcodegeneration/archive/2009/05/11... It's lower level and more limited than full blown FP aware TCO and it may not catch every call pattern, but it's been there for a while.
      - 14y ago

by pohl 14y ago

Ingaz 14y ago

Even more: 1. Common ascendants Scala is heavily influenced by OCaml and Haskel. F# is descendant of OCaml, heavily influenced by Haskel. 2. Past Don Syme designed generics for .NET. Martin Odersky designed generics for JVM. 3. Erlang influence Acca - heavily influenced by Erlang and OTP, MailboxProcessor looking quite similar to Erlang processes. 4. Multiple paradigms Both languages combine FP and imperative. Scala is more OOP, F# is more FP. And (in my opinion) F# is looking more "clean" than Scala. Simple thing in F#: let (|>) g f = f g In Scala becames much more complicated. Also I think that discriminated unions are "prettier" than case-classes.

bad_user 14y ago
> Scala is more OOP, F# is more FP That depends on your background. As far as FP goes, I wouldn't see myself working in a FP language that doesn't have type-classes or something similar. Clojure has protocols and multimethods, Scala has type-classes based on implicits, while F# doesn't have anything like that. > F# is looking more "clean" than Scala. I don't know about that, I got used to Scala code. As far as the languages are concerned, I hate for instance how F# imported some language features from C# that really needed to die a long time ago, like static class members and operator overloading based on said static class members. Scala on the other hand cleaned all that crap. My problem with F# is basically that it has 2 type systems in the same language. Same problem that Ocaml has really, except Ocaml can also do some pretty cool tricks with structural typing for OOP that F# cannot. But anyway, these issues are actually irrelevant because the choice for developers will end up being the answer to ".NET or the JVM?"
- Ingaz 14y ago
  I like what Odersky did with statics in Scala. I agree that F# is not pure as Haskel and limited in comparison with OCaml and Haskel. But the things that works in F# are working fine. In comparison with Scala: curring (by design) and tail-calls optimization are looking "more FP" in my opinion.
  - bad_user 14y ago
    Yeah, but LISP doesn't do currying and I find Scala's support for currying just fine, although the syntax in F# is definitely much nicer. Also Scala does optimize self-recursive tail-calls and it's pretty easy to work with trampolines. This is a platform limitation btw, as you can't optimize tail-calls without support from the VM. Mono, the open-source .NET implementation, also has problems with optimizing tail-calls (last time I checked) and I don't know about .NET 4.5, but .NET 4 was not optimizing tail-calls on 64-bits Windows. I remember reading a blog post about them fixing it on 64-bits OS in the latest version, but it wasn't the kind of feature you could rely on in the past. I do have hopes that TCO will make it into the JVM at some point, as there are experiments for it available as part of OpenJDK. Unfortunately the JVM moves at a glacial pace in regards to such features. This is both a blessing and a curse. I do agree with you. Not having full TCO in a functional language kind of sucks.
    - abolibibelot 14y ago
      and I don't know about .NET 4.5, but .NET 4 was not optimizing tail-calls on 64-bits Windows. Actually there's a .tail CLI Opcode in .NET for tail call optimization which is not usually emitted, but the JIT does tail call optimization on 64 bits (not on 32 bits though). You can witness this when you have a C# getter calling itself. On 32 bits, you get a StackOverflowException, on 64 bits it keeps running happily forever. For the specifics: http://blogs.msdn.com/b/clrcodegeneration/archive/2009/05/11/tail-call-improvements-in-net-framework-4.aspx http://blogs.msdn.com/b/clrcodegeneration/archive/2009/05/11... It's lower level and more limited than full blown FP aware TCO and it may not catch every call pattern, but it's been there for a while.
    - 14y ago