Is it simply better language features ( typing, generics, etc.?), or does the argument also include .NET and the CLR?
Will Microsoft open up development on unix systems (not mono)? I've interpreted signals from the CEO as an indication this could happen. What about visual studio?
Ah, and then there's still the inferior, type erasure based generics. There is nothing on par with C#'s awesome async-await. There's no yield return semantics (when used properly, you can create very clean and robust code thanks to it). You've got to deal with the infamous checked exceptions (I think it's the consensus these days that this wasn't such a good design choice after all). No single-root type system (so you've got Integers and ints, and the latter aren't objects) etc. And there's more, even little things like var keyword or partial classes that don't exist in Java (like many language features, partial classes can be used for evil, but it's very helpful for dealing with autogenerated code). Operator overloading. Nasty and weird syntax for annotations (in compare to C#'s attributes).
Some of these can be a matter of taste for sure and I'm not interested in language flamewars :) I write both Java and C# for living, just personally I prefer the latter.
It would be real big if Microsoft purchased Xamarin and made it free (or much cheaper). They've really gained momentum in recent time and it feels like they are getting recognition from MS now.
C# feels like Java done right. Many of Java's shortcomings can be masked with a great IDE (making setters and getters) nobrainers - but I prefer C#.
Take a look at this presentation: http://www.slideshare.net/omervk/scala-for-c-developers
It draws some parallels between C# and Scala.
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.
By that measure, APL programs must be the least buggy in existence.
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
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.
I just hit a major bug due to that kind of thing, where stuff wasn't clear due to messy size of the code (customer insisted on C#). If the relevant sections had been sitting on screen, then I most likely would have noticed or never even made it in first place.
I also started working with a new hire, one that isn't an FP proponent, and I'm shocked at the variable names. Even iterating a list of entry objects: I'd naturally write the list as 'es', and the current item 'e'. Versus 'entriesToProcess' and 'current entry'. Or even 'entries' and 'ent'.
People's objections there seem to be that 'entries' is more readable than 'es'. While that may be true in isolation, I'm not sure it matters when working on a codebase above a few hundred lines. The amount if context is likely to be high enough that you're not going to be plucking one line out for changing, and the local context (and typing) should make it apparent it's a plural of e.g. entries, not employees.
It's also vb.net, f# and so much else. Even node.js is integrated now! In short, it's a very adaptable IDE (with a lot of features also).
But it isn't Windows anymore since Owin.
What's also nice is that they are innovating the platform for integrations with popular (opensource) like features. Eg. The scaffolding of Rails got integrated into Asp.Net MVC in it's own way. NodeJS selfhostable option is adapted into .Net as "Owin". SignalR is their realtime component, you got live IDE features when developing webapps (it uses SignalR in the background)
It's kinda a mix of "all worlds" :)
To MS's credit, .NET did aim to be a true multi language runtime, back to Project 7. They got feedback from many people to make sure many languages could be accommodated (looks like they've since given up on this goal). Ironically, the JVM, with it's strictly less capable VM, boasts far more languages targeting it's runtime. Probably because Microsoft worked against releasing it for other platforms and is still a bit standoffish.
This is not true. C# got functional features thanks to the work of Erik Meijer and his team.
His paper "Confessions of a used programming language salesman" about this work, is very well known in the compiler design community.
http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.118....
Yeah, LINQ was what got enterprise developers slowly started into the FP world.
According to Don Syme's blog posts, certain "product team members" said that "generics is for academics only." However, he did not name Anders Hejlsberg as being one of them.
Here's the blog post: http://blogs.msdn.com/b/dsyme/archive/2011/03/15/10141602.as...
Also see: http://blogs.msdn.com/b/dsyme/archive/2012/07/05/more-c-net-...
Also see the story from the other side: http://blogs.msdn.com/b/scottwil/archive/2007/10/24/working-...
I wonder if MSR's implementation of generics in .NET 2.0 was why F# got bundled into Visual Studio as a first-class language. IronPython, IronRuby, etc. never got that type of internal buy-in and got spun-off instead.
I've no real clue why F# was productized, but I'd like to think it was because MS realized it has to stay competitive. F# is probably the most advanced language with that level of tooling, support, libraries, etc. I know F# is the only reason I continue to target the CLR. At the same time, MS's F# support certainly feels like it's just lip service, even while their flagship language lacks basics like a REPL. (I know, Roslyn will cure all.) I've yet to see any marketing suggesting F# would be a better choice for many projects; only esoteric sciencey and maths usages see suggested.
What'd really be forward would be for MS to support Rust or a project like that. (I believe they hired the guy behind BitC but I don't think it was for language design.)
After joining Microsoft, Hejlsberg led the company’s efforts in Visual J++
[...]
Hejlsberg helped make Visual J++ the most popular
and most productive Java IDE in the late '90s.
Although adding ReSharper to the party doesn't hurt.