5 ms·

The CLR is more flexible than the JVM, but if you're only using C# you'll usually only notice when doing C interop. With the major exception of structs and gene

The CLR is more flexible than the JVM, but if you're only using C# you'll usually only notice when doing C interop. With the major exception of structs and generics, which may provide large speed improvements. C# the language is superior in essentially every way to Java. Far less code = less bugs. F# takes it up another notch, while allowing you to keep interop. Microsoft has had plenty of opportunity to officially support Mono, but they have not. Their patent promise only extends to Mono as long as you don't run into other issues with Microsoft. If MS wanted, they could, at any time, start really supporting Mono and work to unify runtimes. But anything's possible.

V-2 12y ago
To be fair, F# has its counterparts in the JVM world (like Scala or Clojure). I used the rather niche Kotlin lang on Android, for hobby projects so far, and it's pretty nice, too, even if not fully mature. More similar to Scala, I believe.
- pmoriarty 12y ago
  I don't think F# is particularly similar to Clojure. No more similar than OCaml or SML are to Lisp (which is not very).
  - V-2 12y ago
    True, it's a different FP flavor. They (F#, Scala, Clojure) are in similar position though in that they're FP-centred alternatives to the main language of the platform (C#, Java)
pmoriarty 12y ago
"Far less code = less bugs" ? By that measure, APL programs must be the least buggy in existence.
- MichaelGG 12y ago
  The recent discussion on K suggests that may be the case.
  - azth 12y ago
    Link?
    - MichaelGG 12y ago
      https://news.ycombinator.com/item?id=8475809 https://news.ycombinator.com/item?id=8475809 I'm not sure if K generalizes well. It may be that plenty of software has edge cases that must be handled that don't have any elegant representations. I have a hard time believing such little code can actually work that well. But it seems impressive enough that I plan on learning it some and making sure I'm not massively missing out on something because it seems foreign. From my own experience, less code certainly means less bugs. Even with denser code. Simply having to jump around to find stuff (due to more lines) seems to cause more problems
      - chipsy 12y ago
        I've been gravitating towards the stance lately(independently of reading about K and the APL family style) of aiming towards "total-factor symbol reduction" - i.e. a program coded with fewer symbols, and fewer unique symbols, is preferable to one that introduces many new symbols, or uses existing ones inefficiently. From this perspective, just factoring out imperative code into a named subroutine becomes a pain point because it adds new symbolic content - a new name, things being passed in, things being returned, things that were in scope suddenly falling outside of it. It is no longer an "organization tool" - you can add a level of block scope and a comment for that instead, and navigate the resulting large functions with code folding. And classes - well, classes become something to avoid! APL style simply moves this concept down to the per-character level of thought and advocates additional care towards certain measures of readability. "It is more likely," says the APL programmer, "that you will see a typo in a 2 character name than in a 10 character name." The language aids in this process by providing tools that drastically condense common operations and encouraging their use as the default.

V-2 12y ago

To be fair, F# has its counterparts in the JVM world (like Scala or Clojure). I used the rather niche Kotlin lang on Android, for hobby projects so far, and it's pretty nice, too, even if not fully mature. More similar to Scala, I believe.

pmoriarty 12y ago
I don't think F# is particularly similar to Clojure. No more similar than OCaml or SML are to Lisp (which is not very).
- V-2 12y ago
  True, it's a different FP flavor. They (F#, Scala, Clojure) are in similar position though in that they're FP-centred alternatives to the main language of the platform (C#, Java)

pmoriarty 12y ago

"Far less code = less bugs" ? By that measure, APL programs must be the least buggy in existence.

MichaelGG 12y ago
The recent discussion on K suggests that may be the case.
- azth 12y ago
  Link?
  - MichaelGG 12y ago
    https://news.ycombinator.com/item?id=8475809 https://news.ycombinator.com/item?id=8475809 I'm not sure if K generalizes well. It may be that plenty of software has edge cases that must be handled that don't have any elegant representations. I have a hard time believing such little code can actually work that well. But it seems impressive enough that I plan on learning it some and making sure I'm not massively missing out on something because it seems foreign. From my own experience, less code certainly means less bugs. Even with denser code. Simply having to jump around to find stuff (due to more lines) seems to cause more problems
    - chipsy 12y ago
      I've been gravitating towards the stance lately(independently of reading about K and the APL family style) of aiming towards "total-factor symbol reduction" - i.e. a program coded with fewer symbols, and fewer unique symbols, is preferable to one that introduces many new symbols, or uses existing ones inefficiently. From this perspective, just factoring out imperative code into a named subroutine becomes a pain point because it adds new symbolic content - a new name, things being passed in, things being returned, things that were in scope suddenly falling outside of it. It is no longer an "organization tool" - you can add a level of block scope and a comment for that instead, and navigate the resulting large functions with code folding. And classes - well, classes become something to avoid! APL style simply moves this concept down to the per-character level of thought and advocates additional care towards certain measures of readability. "It is more likely," says the APL programmer, "that you will see a typo in a 2 character name than in a 10 character name." The language aids in this process by providing tools that drastically condense common operations and encouraging their use as the default.