It sure feels like there's a strong force within the MS dev tools team to be far more open, and the only thing holding them back was the CEO. I sincerely hope Microsoft continues to open more and more products and truly integrate the open source philosophy into their culture.
I think the new ceo has been appointed through the course that Microsoft has been taken the last years.
People internally has been pushing Microsoft the open source way (some evangelists of MS and .Net). They have gotten greater influence into the firm, because of success and a allround positive influence (and Microsoft didn't had any appeal to a great group of developers because of closed source and patents).
The similarity between the new CEO and those people where greater then with Balmer. So it's a logical step into it's evolution.
It doesn't mean that Balmer hold them back at all, they could thrive under Balmer, but perhaps he hasn't had any experience with this business direction or couldn't grasp the concept of it. And as a result, someone else was more fit for the job.
It doesn't hurt that the same faction that's been pushing for more openness is also delivering some of the best revenue growth within the company. Both directly and indirectly - SQL Server's a pretty solid DBMS, but I'm not sure there are a whole lot of compelling reasons to pick it over one of its competitors if you aren't using .NET.
Steve Jobs promised that FaceTime would be an open protocol... never happened.
AirDrop is yet another closed protocol.
XPC is a new protocol for sandboxed processes to communicate with each other, it's basically distributed objects. Again, a secret even though things like CORBA, Java RMI, etc. have been around for years.
They own the copyright, so they're free to do what they want with the code. That's why dual licensing models (like that of MySQL) are possible.
However, code that's been distributed under an open license stays that way. So Microsoft could add a commercial license, and even stop making updates under an open license. But if they do that, then there's nothing stopping the community from moving forward with their own fork of the open source version.
If I recall correctly, the Darwin operating system might be a good example of how that sort of dynamic could play out.
Everything else they've released has been Apache2, so assuming that, they could decide stop releasing new versions of it. They couldn't "take back" the versions already released, though.
My understanding is that the copyright owner may do whatever they please, including selling modified versions with their own custom proprietary changes, or maintaining multiple versions under differing licenses. However, it's true that once they've released the code under an open license, anyone who has saved a copy of the code may release their own forked version in the future, regardless of what the copyright owner does with their version, so long as the forker continues to follow the terms of that license for the code still under copyright of the original owner. New code under the forker's copyright may be released under other licenses if the forker chooses, etc, etc.
Can someone give reasons why you would want to use this over, say, OCaml, when on a non-MS platform? My understanding is that the Mono runtime on *nix is significantly less {mature,performant,stable} that the Windows .Net runtime.
Are there any benefits besides the obvious 'write-once, run-anywhere' one?
EDIT: I just want to be clear that I don't have any negative opinion of F#, I am genuinely curious why someone would want to use this on a platform that is not Windows.
1. You have much richer libraries available. There's a
decent amount of stuff in OPAM these days, but that's
dwarfed by what you can grab out of NuGet.
2. You have a great asynchronous/multithreading story. The F# async
workflow makes it trivial to write multithreaded apps in
a similar way to C#'s async/await calls (in fact, F# is
the origin of that design), and it performs very well.
OCaml still doesn't do very well with multithreaded
programs.
You also lose some things, two of which that are most poignant to me:
1. OCaml is faster than F# for single-threaded programs.
This has nothing to do with Mono's maturity or speed as
such, but does have to do with its garbage collector,
which has not historically dealt well with F#'s allocation
patterns. I have not taken time since SGen landed to
revisit that, though, so the situation might be much
better.
2. OCaml can produce tiny self-contained binaries. Mono's
AOT gets you the self-contained easily, but you'll be
looking at relatively large executables.
Mono's SGen garbage collector is a massive improvement over the older, non-generational GC. SGen still may not be as a good as the GC in the .NET CLR on Windows, but the performance difference is much smaller now (especially since Mono 3.2.x).
Have you tried with F# specifically? Even the old collector generally did fine for C#, but F# tends to allocate a tremendous number of very-short-lived objects, which is where Mono's old GC got unhappy. I actually do fully expect that SGen likely fixes that entirely, but I haven't had a chance to meaningfully benchmark it.
Yes, I have tried it specifically with F#. In fact, I contributed some minor patches to the SGen GC so it'd work correctly on FreeBSD, just so I could run F# on FreeBSD using Mono/SGen. SGen is a significant improvement over the older GC for any program running on Mono, but especially for F# programs.
I've been looking at doing something crazy like building a toy kernel + lisp to sit on top of it for the RPi, and I've been looking at OCamL to do it in. Thoughts, as someone who's used it?
OCaml works great for systems programming (its runtime is orders of magnitude simpler than F# and the CLR). See http://openmirage.org for a bunch of libraries that may be of use to you, such as TCP/IP in OCaml (or https://github.com/mirage)
Feature-wise you also lose a few more things like OCaml modules and functors (and OCaml style objects, which is not a great loss). You gain integration with .NET (and its classes and objects).
There are a few reasons why I use it on Linux over OCaml.
1) Familiarity, if you already know the language, tooling and libraries then you might be better off sticking F# than learning OCaml.
2) Size of community. I'm willing to be proved wrong here, but I find it alot easier to get an F# question, and often more importantly, a question about a library I'm using when I write F# than when I write OCaml.
3) Libraries, Libraries, libraries...
Also the mono runtime is pretty darn good. I agree its not as tuned to handle the small object and lifetimes that functional languages generate but I'm not really running into that limit currently.
About libraries, .NET has a big, complete and really good documented standard library.
With standard library I mean int/float/string/IO/http/xml/async/etc not speaking about stacks of .net (like ui with wpf).
Standard library work really good cross platform with mono, share documentation/stackoverflow with .NET.
Mono team fix fast bug when behaviour differ from .NET
Instead of use complex stack like wcf (to create service, partially implemented on mono, webservice ok, soap WS-* less) but bundled with .NET, you can use open source libraries (like nancy, servicestack), change serialization library, etc.
F# use .NET standard library (same library/dll, so a c# answer about StringBuilder class is the same from c# and f#).
Can also use every .NET library, bundled with mono/.NET or third party.
i used a lot of F# in the past year for one big reason - access to the dotNet platform. similar to how scala gives you access to the JVM and the massive number of java libraries out there, F# gives you access to a wide and growing body of dotNet tools and libraries out there. in my investigations i found that while the dotNet ecosystem for what i want is smaller than java's it's larger than the OCaml one.
Yes and not, you surely can develop successfully with mono on linux, but .NET is not "write once, run everywhere", is more a "write once, run everything" framework.
It's heavy tangled with all the Microsoft and Windows technology and promote the reuse of code in that ecosystem.
That's a rather unique take, given how Xamarin has managed to build a massively successful company around the idea of using .NET to target non-Windows platforms.
+ core = standard library, io/string/async/thread/etc/linq.
+ some bundled stack, like wcf for create service, wpf for ui, mef for plugin, xml serialization, json serialization, asp.net webforms, etc.
Mono try to reimplement all.
Runtime and standard library work very well on mono.
bundled stacks can work, work partially or not implemented, depends (on contribution, check mono website). Some stack are really old way to do things, deprecated, usefull only on windows.
Also Microsoft for new stacks (like asp.net MVC) try to open source, so mono need to compile source and fix bug/different behaviour, not rewrite
If you use a library who depends on a bundled stack, can or cannot work on mono.
Library who depends on open source or standard lib, should work
Now that they're dogfooding codeplex for such high profile projects I hope we'll see some improvements to it.
[edit]
I suppose if I'm complaining I ought to make some constructive suggestions:
* central page listing my subscribed/voted issues/discussions.
* The only history link on a projects homepage is for the wiki.
It should have a prominent link to the latest changeset
with a date or age.
* Project wide search: issues, code, wiki, discussions
* In fact, remove discussions completely, everything should be an issue.
can someone explain this to me? i thought f# was open source for years? isn't that how most people compile it on their machines?
is it just that people don't know that half the things that were open sourced have already been open sourced(like the asp.net stuff) or do we just copy and paste microsoft press releases here?
OR am i missing something crucial that someone can elaborate on please?
EDIT2: thanks to the responses, it's about accepting contributions
EDIT: for those that don't know the asp.net developments had a lot of influence from the alt.net movements. it was ms' attempt to keep the c# web developers from moving to other frameworks that let you do similar things much easier.
Yes, you are right, F# has been open-source and on github for a while, and that itself isn't new news. However I don't believe users could make contributions that would be upstreamed into the official releases or VS builds.
"Prior to today, contributions were not accepted to the core implementation of the F# language. From today, we are enabling the community to contribute to the F# language, library and tools, and to the Visual F# Tools themselves, while maintaining the integrity and unity of the F# language itself."
F# has been licensed under an open-source license for some time, but in Microsoft fashion, they weren't accepting contributions from third-parties, so the repository was read-only.
Show me where I can directly contribute to random Apple products or where I'd send my upstream Android improvements.
Worse, the Linux kernel is open source, but getting my own changes into the main distribution is probably taking some work and the chance that they won't be accepted is rather good.
No offense, but I'm really unhappy about the continued MS bashing. Yes, right now (due to the BUILD conference) there are a good number of Microsoft related posts on this site. Yes, Microsoft wasn't the corporate citizen most of us wanted them to be in the past. But these news are _nice_ and the slights are really misplaced.
It would be difficult to submit a patch to the Linux kernel, yes. Especially as an outsider with no history with the project. But people do submit them. Because that is how open source projects operate.
As for apple: bugzilla.webkit.org and llvm.org/bugs - you have to invest real time in these before you can submit patches, but they take take them.
'In Microsoft Fashion' here may be more mean than it needs to be, but I do not think it refers to a general greed or selfishness or what-have-you. It sounds to me like it refers specifically to the sort of open source that major Microsoft products had previously been released under, and that was it. Any hating ascribed to the statement is interpretation.
I agree about Android. I wish it were actually open source -- maybe someday. :)
Even for Microsoft open-source (as in 'anyone can send patches and might get them accepted') is nothing new.
From [1], posted March 27, 2012 (and note the author!):
You can also now contribute directly to the development of the products by reviewing and sending feedback on code checkins, submitting bugs and helping us verify fixes as they are checked in, suggesting and giving feedback on new features as they are implemented, as well as by submitting code fixes or code contributions of your own. Note that all code submissions will be rigorously reviewed and tested by the ASP.NET MVC Team, and only those that meet an extremely high bar for both quality and design/roadmap appropriateness will be merged into the source.
--
Sounds like .. any high profile open source project: Feel free to contribute, be aware that we might reject your work. So two years later, after opening more projects to this model, I don't think 'the sort of open source that major Microsoft products had .. been released under' is correct.
(Obviously there's a fair bit of interpretation going on. As it always is in text, unless you're fairly close to the author perhaps)
The problem with Android was never that they didn't have a contribution process. IIRC, they've had that since day 1 (or maybe even before with the pre-device SDK).
The problem is that the success rate for patch submissions is abysmal because Google evaluates patches in the context of the unreleased, unpublished version of Android they're working on internally rather than against the most recent published released that they are typically against.
I think they can theoretically accept a proposed language design change now. Of course it will probably never happen in practice, but it's a nice thing to say on the project page.
I think there's a very good chance they'll accept incremental, high-quality changes to the language. For example, I've proposed some small features to provide better interop with C#; they should fit nicely into the language without requiring major changes. On the other hand, major (re-)design proposals to include features that only really matter to very advanced functional programmers don't have a good chance of being accepted.
I haven't looked closely -- my assumption is that despite this string of announcements we are not really any closer to simply running pkg_add or apt-get to install a real MS development environment (i.e. not Mono). I could be wrong though, of course.
I am waiting for the runtime to be opened up. Although I know that is unlikely to happen. Opening up C# and F# are indeed interesting, but as far as engineering is concerned the real heavy lifting is done in the runtime. Unfortunately, as a Linux user the mono runtime has left me with a bad aftertaste. It is perhaps ok for C#, perhaps ok for use with unity, but for functional code that depends so heavily on proper handling of tail calls, mono is (well at least was) a mess and unstable. Further, developers in charge refused to concede that buggy/incorrect tail call behavior was a problem (why dont you just right loops). If anyone can report that this has changed I would be happy to give it another shot. I wont be able to thank all of you with a comment, but will certainly upvote.
True, a lot of the heavy lifting is done within the runtime. However Mono has been improving at a break-neck pace over the past few years - Mono 3.x with the new garbage-collector and LLVM backend can be quite efficient. Furthermore F# is bundled with Mono nowadays so hopefully they are aware of/fixing any issues with functional-style code, e.g. tail-calls.
I used Mono and F# for a project earlier this year and had no particular performance or behaviour issues, although my work was not generally performance-sensitive.
The latest Mono should be much better for handling F#, as it received some love from Xamarin, as they started promoting it. You can't blame Mono for not running F# well, when .NET itself had and probably still has its own share of problems: http://blogs.msdn.com/b/clrcodegeneration/archive/2009/05/11...
I agree that even the CLR itself needs improvements for functional programming. Besides the tail calls link you gave, there is also (according to MS) inability to implement type classes because of CLR changes that would be necessary: https://visualstudio.uservoice.com/forums/121579-visual-stud...
I think F# would benefit a lot from either ML's module system or at least type classes as a simpler case. As it is it can only (directly) do single virtual dispatch (mainstream OO dispatch), which is pretty limiting and makes it more of a C# with different syntax.
F# could potentially get a module system in the future (a la OCaml or SML). I've put together some proof-of-concept code to show how modules could be implemented on top of the existing .NET type system, so at this point it's just a matter of refining that representation and then implementing that in the language/compiler.
I'd love to see some kind of typeclass support in F#...
In the meantime, honest question: what are modules in OCaml? I tried to read up on it online, but my understanding of the topic is still murky. Regular modules don't really seem that interesting (they look like modules and/or types/classes in F#), parametrized modules seem to be something that is missing in F#.
Second question, do you have that proof of concept code laying somewhere around? I'm just curious how it would look in F#...
Yes, F# is missing parameterized modules ("functors"); these are simply modules which are parameterized by other modules in the same way .NET generics (for example) allow you to parameterize one type by another type. The reason this would be nice to have in F# is that, while the CLR's generics are excellent in general, there are some things that can't be expressed using the CLR's type constraints. Supporting functors in F# would provide a nice way to work around this and allow you to write code which is more generic.
Here's my proof-of-concept code. I'll warn you now though -- it looks quite messy, because the goal was to show that functors could be supported on top of the existing .NET type system. If functors are ever added to the F# language, the syntax will be much, much cleaner.
This is great news (thank you for doing it)! Especially that it doesn't require changes within the CLR which seems to be a death sentence for proposals.
I've been teetering with trying F#, and a proper ML-like module system may tip the balance in its favor for me, I'm sure I'm not alone in that. It just didn't seem like a "real" ML without the module system or at least type classes.
That's a neat feature! So my aside about single dispatch was misplaced.
What I'm really after though is somewhat the opposite, which is static dispatch so that the functions called are known at compile time and can be optimized that way (I do a lot of numerics coding), so avoiding any method resolution lookup and even the vtable jumps and resulting target mispredicts. That's a nice feature of both type classes and ML's module system as usually implemented in functional languages. One really nice thing is they can also typically "dispatch" statically on return types of functions too which makes for some neat patterns as well using type inference.
Anyway thanks for pointing to that. It definitely beats the visitor pattern as is necessary in Java. And I assume it would work for more than two parameters too, which is another advantage over standard visitor.
