+972 52-548-6969
Why RavenDB isn’t written in F#, or the cost of the esoteric choice
In a recent post, a commenter suggested that using F# rather than C# would dramatically reduce the code size (measured in line numbers).
My reply to that was:
F# would also lead to a lot more complexity, reduced participation in the community, harder to find developers and increased costs all around.
And the data to back up this statement:
| C# Developers | F# Developers |
|
|  |
Nitpicker corner: Now, I realize that this is a sensitive topic, so I’ll note that this isn’t meant to be a scientific observation. It is a data point that amply demonstrate my point. I’m not going to run a full bore study. And yes, those numbers are about jobs, not people, but I’m assuming that the numbers are at least roughly comparable.
The reply to this was:
You have that option to hire cheaper developers. I think that the cheapest developers usually will actually increase your costs. But if that is your way, then I wish you good luck, and I accept that as an answer. How about "a lot more complexity"?
Now, let me try to explain my thinking. In particular, I would strongly disagree with the “cheapest developers” mentality. That is very far from what I’m trying to achieve. You usually get what you pay for, and trying to save on software development costs when your product is software is pretty much the definition of penny wise and pound foolish.
But let us ignore such crass terms as money and look at availability. There are less than 500 jobs for F# developers (with salary ranges implications that there isn’t a whole lot of F# developers queuing up for those jobs). There are tens of thousands of jobs for C# developers, and again, the salary range suggest that there isn’t a dearth of qualified candidates that would cause demand to raise the costs. From those numbers, and my own experience, I can say the following.
There are a lot more C# developers than there are F# developers. I know that this is a stunning conclusion, likely to shatter the worldview of certain people. But I think that you would find it hard to refute that. Now, let us try to build on this conclusion.
First, there was the original point, that F# lead to reduced number of lines. I’m not going to argue that, mostly because software development isn’t an issue of who can type the most. The primary costs for development is design, test, debugging, production proofing, etc. The act of actually typing is pretty unimportant.
For fun, I checked out the line count numbers for similar projects (RavenDB & CouchDB). The count of lines in the Raven.Database project is roughly 100K. The count of lines in CouchDB src folder is roughly 45K. CouchDB is written in Erlang, which is another functional language, so we are at least not comparing apples to camels here. We’ll ignore things like different feature set, different platforms, and the different languages for now. And just say that an F# program can deliver with 25% lines of code of a comparable C# program.
Note that I’m not actually agreeing with this statement, I’m just using this as a basis for the rest of this post. And to (try to) forestall nitpickers. It is easy to show great differences in development time and line of code in specific cases where F# is ideally suited to the task. But we are talking about general purpose usage here.
Now, for the sake of argument, we’ll even assume that the cost of F# development is 50% of the cost of C# development. That is, that the reduction in line count actually has a real effect on the time and efficiency. In other words, if an F# program is 25% smaller than a similar C# program, we’ll not assume that it takes 4 times as much time to write.
Where does this leave us? It leave us with a potential pool of people to hire that is vanishingly small. What are the implications of writing software in a language that have fewer people familiar with it?
Well, it is harder to find people to hire. That is true not only for people that your hire “as is”. Let us assume that you’re going to give those people additional training after hiring them, so they would know F# and can work on your product. An already steep learning curve has just became that much steeper. Not only that, but this additional training means that the people you hire are more expensive (there is an additional period in which they are only learning). In addition to all of that, it will be harder to hire people, not just because you can’t find people already experienced with F#, but because people don’t want to work for you.
Most developers at least try to pay attention to the market, and they make a very simple calculation. If I spend the next 2 – 5 years working in F#, what kind of hirability am I going to have in the end? Am I going to be one of those trying to get the < 500 F# jobs, or am I going to be in the position to find a job among the tens of thousands of C# jobs?
Now, let us consider another aspect of this. The community around a project. I actually have a pretty hard time finding any significant F# OSS projects. But leaving that aside, looking at the number of contributors, and the ability of users to go into your codebase and look for themselves is a major advantage. We have had users skip the bug report entirely and just send us a Pull Request for an issue they run into, others have contributed (significantly) to the project. That is possible only because there is a wide appeal. If the language is not well known, the number of people that are going to spend the time and do something with it is going to be dramatically lower.
Finally, there is the complexity angle. Consider any major effort required. Recently, we are working on porting RavenDB to Linux. Now, F# work on Linux, but anyone that we would go to in order to help us port RavenDB to Linux would have this additional (rare) requirement, need to understand F# as well as Linux & Mono. Any problem that we would run into would have to first be simplified to a C# sample so it could be readily understood by people who aren’t familiar with F#, etc.
To go back to the beginning, using F# might have reduce the lines of code counter, but it wouldn’t reduce the time to actually build the software and it would limit the number of people that can participate in the project, either as employees or Open Source contributors.
Comments
This is all true and smart thinking. Many new, shiny things have negative value just by the fact that they are uncommon.
Replace C# with SQL Server and F# with RavenDb.
ijrussell, Good point, except that RavenDB isn't the whole of your application. It is a tool, an important one, for sure, but hopefully it isn't the everything of your app.
What would make an OSS significant?
Steffen, Scope of the project, number of contributors, age of the project, number of users.
Steffen, A better way to point it is, a project is not significant if it is young, or has very small number of users, or hasn't been updated in a long while, etc.
What I meant is what would be typical numbers for you to be significant?
Thanks for using the time and effort to write this blog post. I like it.
About availability, this video describes why Jane Street actually uses OCaml, a language with small community, to build complex systems: https://ocaml.janestreet.com/?q=node/61
As you said, line count doesn't matter when you develop the software: it is not typing, but thinking that matters. But line count really do matter when you try to maintain the software, when you hire new developers to study the existing functionality, etc.
Steffen,
That is a really hard thing to answer, I'm afraid.
Rhino Mocks was significant, it had a lot of users.
Rhino Service Bus I would say wasn't significant. It was about 10 contributors max, and it didn't get a lot of traction after I stopped working on it.
F# is hardly esoteric anymore.
However, where things go off the rails, so to speak, is by equating code size to good directly. The issue isn't code size, the issue is complexity.
Every mutable variable, field, etc. adds complexity. Sometimes, it's essential complexity - you need it to express the idea, and the thing is legitimately mutable. Most of the time, and especially most of the time in most C# code that is written, the complexity is unessential and creates artificial complexity in the codebase. This tends to happen in any language where your default property syntax gives you getter/setter pairs.
What makes F# (and FP, in general) valuable is that you get the right behaviors in your types by default. You can make something mutable, but it requires effort. This is a good thing. I could go on... and often do... about other features of F# and FP that promote simplicity... but especially for code that is going to run in a library, writing it in languages like Erlang or F# that promotes the kinds of practices that lead to more stable software is a huge win.
Aaron, I absolutely agree on code size and quality not being related. But I think that you ignore the issue here. It isn't about the code, it is about the coders.
Also, with regards to immutability...
http://ayende.com/blog/164865/what-about-f-collections
It is great, until it comes back and bite you very hard. Note that this is the case when I actually want stuff to be immutable.
It is a very simplistic argument when it seems to only account for job advertisements for a language.
F# is on the up and there are lots of really GREAT C# developers wanting to move into F#.
We have found that advertising for F# acts as a natural filter amongst .NET developers. It filters out 99% of the riff-raff and leaves you with just CV's from super high end .NET developers that are already either proficient at F#, have dabbled with it, or haven't touched it at all but are conciously aware the only way to achieve true SOLID principles (and much more) is with F# and not C#.
Thanks for your answer.
You are right there are not that many really prominent F# OSS projects, but there are lot's of interesting projects in https://github.com/fsprojects
Only a couple of numbers I found:
https://github.com/tpetricek/FSharp.Formatting - 35 contributors, ~ 3 years, > 700 commits, 5k nuget downloads in the last 6 weeks
https://github.com/fsharp/FAKE - 140 contributors, > 5 years, 4300 commits, about 20000, 19.5k nuget downloads in the last 6 weeks
https://github.com/fsprojects/Paket- 75 contributors with 3600 commits in less than a year, I don't have download stats since it's retrieved from Guthub
https://github.com/fsprojects/VisualFSharpPowerTools - 26 contributors, > 2000 commits, > 2 years, lots of downloads from VS Gallery (seems to be done right now)
Especially if you look at Paket then it's really interesting to see how many C# devs are joing this project in this short time frame and try to write F# because the project seems useful enough to invest the time.
Nathan, do you have anything that tell you that the number of people that have familiarity with F# is anywhere near the number of people familiar with C#? I intentionally provided a single data point because it is easy, not because that is what I rely on.
Note that I'm all for having easier time getting better people, and I certainly agree that even passing knowledge of F# is likely a strong indicator of a higher quality candidate. But that isn't what I'm discussing here.
I'm discussing the implications of having a large codebase in F# and the likely results from my point of view.
Steffen,
The link to Paket you want is here:
https://github.com/fsprojects/Paket
And the mere fact that you have projects under:
https://github.com/fsprojects
Is a bad indication.
I'm maintainer of FAKE and Paket, yes. What's bad about that?
Steffen, Nothing. The issue is with:
https://github.com/fsprojects
There isn't https://github.com/csprojects (actually, there is, but it isn't for C# projects).
The need to put all F# projects together is a problem. It is indication that without having them there, they would be lost. It also mean that people tend to create projects there because they are F# projects. Indeed, most of the projects there tend to be development tools related to working with F#.
Both Fake and Paket are great in our non-F# environment.
Thorium, Did you hear about them through F#? Or independently?
Yes I understand that argument and we discussed to move things like Paket and ProjectScaffold to somewhere else (since both projects target the whole .NET/mono ecosystem), but we're still trying to figure out a good place.
Most of the stuff is in fsprojects since it started to build a ring of trust. If you analyze the dependencies between these then you will see that many projects depend on each other. Tomas Petricek did a very cool talk about this (see https://skillsmatter.com/skillscasts/6153-the-big-f-and-open-source-love-story)
I guess my point about the numbers was: interesting and useful projects attract developers even if they are written in esoteric languages.
I tend to follow development of .NET-environment leading edge technologies. And yes, both Raven* and F# still belongs to those.
Steffen, I absolutely agree with you that you can get devs to interesting projects regardless of the language. It is just _harder_. And one of the things that we explicitly set out to do was to create a broad based community. Stuff that make it harder (such as a language that doesn't have a lot of audience) is going to reduce participation. Not eliminate it, for sure, but it will have a measurable impact.
Ayende,
Nobody is going to argue that F# has anywhere near the number of developers familiar with it as say C#. But that's almost irrelevant if 90% of the C# developers that apply are corporate drones that write it like it's the 1990s and J2EE. You're always left with a small set of hireable developers, irrespectively of the language.
For what it's worth I have a large codebase written in 100% F# and Xamarin. We really haven't seen, yet, the issue that you seem to be suggesting is there. It is more a fear than reality. Yes F# has different practices and not all of them are well documented yet. So what? Does this increase the risk to a project? Yes, maybe. For sure a large F# codebase needs a stronger lead person than a large C# project. That will reduce over time.
I feared I couldn't hire developers for my codebase but it turned out that F# actually helped me and made my hiring process far more simple. There are even recruitment agents, at least in the UK, that cater specifically to F# and functional languages. What more could you want?
I would argue that all good C# devs, and I hope you're looking for good devs, will be able to learn F# in a couple of days and will most likely write better code in F# than they did in C# in a couple of months. With better code i mean less complexity and fewer bugs. Regarding to speed they might not yet be up to speed, but that will come. The important point is that good devs will learn! Hiring someone should be as much about the new employees willing to learn, fail, learn more and contribute even more compared to hiring on what the already know. If they get hired for what they know they might have a tendency to deliver just that.
Also, using the statistics to see how many people actually doing something right now doesn't reflect what people want to do. I hear more people interesting in F# than I hear people thinking they will spend their entire life in C#.
Why is fsprojects bad? This is drifting into a strange territory now...
Lots of languages have "foundation organisations" which look after "critical" projects related to that language's ecosystem. The fact that C# sort of doesn't is the odd thing. Not that F# does.
Tomas, exactly. Good developers will use any language and extract the best from it. Though Ayende seems to be retreating from that now and suggesting a wider issue with F# and large codebases.
Only people with a foot in both camps have enough information to make a rational decision. So rather than arguing about the size of the community or salaries, perhaps a better way would be to ask people who have shipped products in both C# AND F# what they think: "For your next project, would you prefer to use C# or F#?"
Similarly, you could do the same thing with RavenDB. Ask people who have used both SQLServer and RavenDB what they think: "For your next project, would you prefer to use SqlServer or RavenDB?"
This is basically the Net Promoter concept: http://www.netpromoter.com/why-net-promoter/know
My suspicion is that the Net Promoter score is very high for F#, which would give me the confidence to investigate it further.
Great Post! Totally agree. one of the biggest advantages of RavenDB is that its written in C#, the best programming language.
the cost of software is mostly maintenance, hence, its critical to make the software easy to maintain / qa / debug / perf ...
Uri,
Not convinced it is a great post. More an opinion piece made from, mostly, fear.
C# is a good language, but F# is better. It fixes all the deficiencies of C#, and more.
Great post. You made your point fairly clearly in my opinion. I get that the sense that you were misunderstood by a few people (probably not for the first time). Specially on discussion on twitter...
Ayende, Why C#? Why not JavaScript? JS community is larger, you can hire even cheaper developers, number of significant JS projects is probably also higher than in C# world. I think that it is a sign to rewrite everything in JS.
While it's true that there are millions of C# developers, and not a lot of F# developers, it doesn't mean that you can't get those F# developers. Many F# developers will self-select into positions where they can use F# instead of C# or Visual Basic; F# becomes a benefit of the job.
This is known as the Python Paradox (http://www.paulgraham.com/pypar.html) because it was originally described when Python was a hot programming language.
Now, RavenDB is considered a cool technology already, so I guess it's not that hard to find contributors and employees, so you (Oren) don't need to resort to advertising with a cool language in order to attract developers. However, for other organisations without a cool public profile, advertising for F# programmers may turn out to be a good hiring strategy.
"F# would also lead to a lot more complexity, reduced participation in the community, harder to find developers and increased costs all around."
You don't substantiate 1 in this post at all, so I'm going to ignore that point (especially since high complexity projects is an area where even MS suggests using F#).
Points 3 and 4 have, I think, been addressed by other people adequately, but to throw in my 2 cents, from my experience, even having to spend a substantial amount of time training C# developers to use F#, and assuming the F# tooling can be lacking frequently (anything Azure related, for example) the cost/benefit clearly falls in F#'s favor.
Point 2 is really the only one I think has merit. Even assuming each F# maintainer is worth 2 C# maintainers (in terms of maintenance and productivity), there are still at least 10x the number of C# maintainers available. Additionally, if you have 10 F# maintainers vs 100 C# maintainers, each maintainer is a higher risk. Lose 5 C# maintainers, oh well, lose 5 F# maintainers and you might be in trouble.
Getting a developer who has never written a line of F# up to speed is going to require an investment in training. It will take some time, and it will cost you more than if you just go out and hire an experienced F# developer (of which there are fewer than there are experienced C# developers). There is no way to argue against that.
But in a scenario where you hire an experienced developer who isn't familiar with F#, the (very real) cost of getting the new team member productive writing code in F# is, in my opinion, only a small part of the training that is required for anyone starting a new job.
The new person has to become familiar with a ton of things like an existing code base, a new problem domain, a new set of tools, operations, and maybe even company politics shivers. For someone with extensive programming experience, picking up a new language at the same time adds to the burden, but it shouldn't be a dealbreaker.
Taking that further I think there is a tendency here to put too much emphasis on the programming languages. Rather than looking for C# or F# developers, perhaps a better approach would be to look for .NET developers, preferably with experience from different programming language paradigms.
Usually when we discuss programming problems, we are not discussing language features, we are discussing how to apply our experience as developers to solve a problem in a robust, scalable and testable way. Experience doing this applies across languages (even though some language paradigms naturally lend themselves to certain problem domains).
While most of the time I have spent programming for a living has been in a Microsoft-heavy environment, I would say my skills are applicable in other environments as well. I should be able to go work at a Java or Ruby shop and contribute to the team within reasonable time. Does the lack of experience with Ruby affect the cost of getting me onboard? Absolutely. Enough that it wouldn't make sense to hire me? I don't think (hope?) so..
A good programmer writes good code on any language. A bad one the other way around. It is useless to agrue which language is better as both come from different programming paradigms. Programming constructs that make sense in one language don't make sense for the other and vice versa, but that doesn't mean you cannot write great code with any of then because X language doesn't have Y features. Don't forget that some of the most prominent and modern technologies are still built or built upon C.
Last but not least, this discussion is just also useless because of the fact that RavenDB was built with C# and a rewrite on F# just because it's x, y or z is plain dumb. You would throw years of debugging, hardening and performance enhancement to the trash can.
Nicolas I applaud you, most rational comment made.
The fact is; RavenDB was written in C#, rewriting 835,000 loc is a huge undertaking that would introduce all kinds of subtle behavioural differences and adds very little benefit to people using RavenDB. Also, while I love FP & F# for all the problems it avoids I would argue most of the complexity for new devs is in understanding all the concepts used and the history behind why certain design decisions were made.
I am unfamiliar with F#, but trying to understand what's meant to be so great about it.
How does one use F# without consuming the huge C#/OO framework of .net sitting under it. Isn't that kind of defying the point of functional programming? Couldn't you achieve similar code quality with the appropriate level of discipline in C# and also make use of OO where appropriate?
For example, I think in order to qualify a language for a complex project, it needs to solve certain problems like complex File and Socket IO. If I search for something like "F# socket server" I get stuff like this:
https://gist.github.com/panesofglass/765088
Which is using .net framework objects like Socket and NetworkStream which are stateful OO objects (violating the purity of functional programming, surely?), and yep, written in C#.
Can anyone please show me a reasonably complex F# project which doesn't just bootstrap the C# portions of the .net Framework, nor just do complex Math expressions in less lines of code? I really want to be convinced.
Hi Jahmai, See Scott's comment above: "Only people with a foot in both camps have enough information to make a rational decision".
Please read http://www.paulgraham.com/avg.html.
"But when our hypothetical Blub programmer looks in the other direction, up the power continuum, he doesn't realize he's looking up. What he sees are merely weird languages. He probably considers them about equivalent in power to Blub, but with all this other hairy stuff thrown in as well. Blub is good enough for him, because he thinks in Blub."
To answer your question, yes F# programs often use C# libraries. They don't have to but it is convenient. Typically the imperative / OO code is wrapped in a functional API so the effect is local. This is the same as Clojure and Scala on the JVM.
I too struggle to find a complex F# project that's not complex.
There is a huge volume of open source F# code available to read.
I guess that I would not change RavenDB to another programming language in the near future unless driven by market.
Another classic Paul Graham article is about the language Lisp: http://www.paulgraham.com/avg.html
By the way: Lisp was mostly used to make user configurable HTML-templates (RTML). Trevor Blackwell and Robert Morris used C++ as far as I remember.
C# is multiparadigm and ends with IL-code like F# so I guess that you can make almost everything in C#. Maybe use F# for prototyping or testing of algoritms that are more easily programmed with F#.
NB: @Ayende.com: I miss a favicon. It is difficult to find your tab between all the other open tabs in my browser.
Hi Liam,
Thanks for replying.
Disclosure:
I co-founded a company a few years back (SaaS + mobile) and went with C# as a preferred language (.net and Xamarin). I like C#. I've come here from C and C++ (C a pattern?). Apart from general OO concepts, my favourite C# features are TPL, generics, lambdas and extension methods. I use them extensively. I appreciate some of the aspects of functional programming, but have a real difficulty envisioning F# solving big complex system problems without consuming a bunch of hard work done by C# libraries. So far I've convinced myself that C# can generally solve problems better than F# because C# can be somewhat functional in nature when you need it (with a different syntax and more LOC perhaps) but you can also exploit OO when it's appropriate (or most of the time if that solves the particular problem the best). Oh yeah, and of course we use RavenDB as our database, I've been a contributor and even forked and made private builds to solve problems we needed to solve immediately. RavenDB being both open source and C# was a huge positive in selling it as our database of choice.
"Please read http://www.paulgraham.com/avg.html."
I'm not sure the parallel I should be drawing from the article. Does F# represent a contemporary Lisp?
Coming from a C++ background I find it very hard to believe they managed to solve problems in Lisp that couldn't be solved in other languages (they allude that somehow Lisp macro's were secret sauce competitors couldn't compete with). The most complex project I worked on in C++ was a real time stock market surveillance system which utilized language features like templates and MPL and other methods like memory mapped files and relative pointers to solve problems such as order books in very interesting ways, which I think gave it a competitive advantage (especially in performance), but I also think you could have done it in other languages given the right expertise and resources (in fact over time I believe they ported a load of it into Java for a product targeting a different end of the market). I believe that more likely these guys were above average programmers that chose a language they were very capable in, rather than choosing the "more powerful" language.
I think being first to market with a lean focused team that are more than competent in the technology they are using the solve the problem is a big bonus to keeping competitors at bay, not necessarily the particular technology that it is. They also mention toward the end of the article that they later used C and Perl to solve other problems.
"To answer your question, yes F# programs often use C# libraries. They don't have to but it is convenient."
I'm not convinced this is the case, hence my particular example. My inexperience in F# disavows me of the ability to envision how to achieve a complex socket server in pure F# that is actually easier than C#. I could isolate myself and try to write a socket server in F# and find out first hand, but hey, what's the point of Internet forums if not to get a leg up on enlightenment?
"I too struggle to find a complex F# project that's not complex."
Are you implying that all complex projects are inherently complex Math projects? Did you misread what I said? shrug
"There is a huge volume of open source F# code available to read."
Can you link me to just one that solves a particularly complex or interesting problem without using C# libraries underneath it? A single representative project of just how powerful F# can be without sitting on the shoulders of C# would go a long way to convince me of what we've been missing out on.
Nathan, In our hiring practices, we turn down a lot of people, sure. But you miss something very important. It isn't just the people we hire that are important to us. It is the community at large. We have a large number of people that can go into the code, suggest fixes and send improvements.
Using F# wouldn't prevent that, but it would dramatically reduce the number of people that would be able to do major things in the codebase.
Nathan, It is a measurement of the ecosystem. If all the large projects for a particular language are related directly to that language, that indicate that it doesn't have a wide spread usage yet.
Roslyn, for example, is a C# project that is critical to the eco system. But it is hardly one of the first projects that one would point to when you look for large scale C# projects.
Nathan, I never said a single word about F# itself as a language or platform. I talked about the general ecosystem and making decisions based on that
Scott, That is a very narrow view. We aren't talking about a single developer point of view, we are talking about an entire product, with implications to hiring, community, future development, etc.
Yawar, The language most certainly impact the number of people you have contributing to a project. If more people know a certain language, the pool of people who can contribute is much higher. The chances for contribution are also higher
Sergey, JS isn't a suitable language to write a database in.
Michael, Let us talk about complexity, I gave the example of Linux port, but maybe that was too obscure.
Let us say that we need to fix a bug in the spatial query implementation. That is a pretty narrow field, with a lot of dedicated knowledge. Fixing some complex bugs there would require that we would get an outside help. Now we need to get:
Sure, this is all .NET, but that doesn't mean that our outside expert wouldn't require either hand holding or much higher ramp up time. Or simply refuse to help.
That lead to additional complexity for the project. Note that this isn't about the codebase. It is about the project as a whole.
Claus, Now take that same logic, and apply that to an OSS contributor. This guy knows C#, and maybe dabbled a bit in F#. But making a significant contribution to a large codebase in F#? That make things harder, so more people would just skip it, and either ask for help in the mailing list (more support cost) or just skip the product (less customers).
Ayende What a strange idea. Yes, F# is good, but nobody actually knows how god it performs for application like DB. I mean, C# isn't perfect for it, but at least you know the deal about LOH (pretty sure you had a look at it) and anti-LOH collections, GC and how it performs. There are tools, consulting companies, name it... for F#, nothing. JetBrains... nothing like memory profiler for F#.
However... you state "RavenDB is the premier NoSQL database for .NET. " Not C#, but .NET. People actually expect to be able to run programs at any language available on MSDN: C#, C++, F#, JScript, VB Bacause it works.
I am writing on F#, latest docs are from v.1, missing a lot. Most of the time I am able to figure out what I need from C# code. Query syntax is basically the same. But sometimes it drives me crazy. How about some examples, best practices, talks?
You actually new a couple of guys that understand F# a little bit. Something like "C# developer with a basic knowledge of F# or ability to learn it quickly". He could translate your knowledge of C# into F# syntax.
Ayende, There is no way around the penalty of having to learn a new language, I agree on that. You can only really argue about how significant the penalty is, and whether it's worth it.
I also agree that the learning curve is additionally problematic for OSS projects, since the cost of learning cannot be absorbed by a company with plentiful resources, but instead becomes the responsibility of the individual developer (who is volunteering his precious spare time).
In reality however I think we are already in this situation. Plenty of developers aren't confined to one language and one platform. We strive to find the right tool for the job, even if the tool isn't implemented using our bread and butter programming languages and platforms.
A .NET developer might for example decide to use Cassandra for a project, because it's the best tool for a given situation. While contributing might be more difficult for the developer because of the unfamiliar programming environment, there is a good chance the developer might pay the additional cost and decide to contribute anyway.
I don't disagree that there is a cost of choosing a less commong programming language, but that cost should be weighed against other factors when deciding which way to go. I also think that many developers can be persuaded to spend time learning new things to be able to contribute.
In the case of F# vs C#, your project might even become more appealing to people from other functional programming communities (a bit far fetched, but who knows).
It's difficult to say how much of an impact the choice of programming language will have, but I don't think it, by itself, is enough to make or break a useful and desirable OSS project. But of course you should have a rational reason for your choice, not just choosing it because it's new and shiny.
Dmitri, F# is a .NET language. That means that all profilers, debug tools, reflector, etc would actually work. That is a great thing for F#, it means that a lot of the existing tools are going to just work without having to have new ones.
Jahmai: I use libraries and usually when I find some bug from my application it is not in the library. So I don't care if the library is written in C#, F# or VB.NET. I don't use C# or F# as stand-alone programming language.
Ayende: One thing I like with F# is that it uses the function composition in a way that if I feel the need to contribute to some OSS, I don't have to learn the code base business logic totally. In C# there is always like 7 parameters in a method, some complex IoC, some mutable state (as class and global) variables and so on. I have done some commits OSS projects, both C# projects and F# projects. When there is some F#-library, I just clone the repo, focus on the 30 lines I need and make the commit. With C# it is much harder to reason about the code that where is actually the functionality that I need to change and will the change break something.
My current feeling is that F# is better than C# in both FP and OO, when you write business logic. I don't hate C#, I use it daily, I just have to accept that C# code generally has lot more noise and hacks.
@Thorium, I love both C# and F#, IMHO - for RavenDB C# is much more suitable.
F# is good to solve functional programming, while C# is much more versatile.
So, in this case, C# is the best option.
The arguments in favor of F# have been pretty weak in my estimation. I mean, for RavenDB specifically it makes some sense, but as a general purpose programming tool I don't know.
Is F# really neat to read & terse? YES. I won't lie, it is very interesting. Surprisingly, I really really like it as a functional language. Does it rid the code base of some boiler plate code? I don't know. Maybe you haven't created the proper abstractions and you need to refactor some things. After all, you reap what you sow! F# is different than creating type hierarchies and using inheritance for code reuse, but a better general purpose tool? I'm not convinced that it's even as good as C# for that.
Is there a canonical application in GitHub on the subject? I know I'm being argumentative here, but I'm happy to be proven wrong. It's happened before :)
P.S. - I meant "instantiation of the Date on the stackframe's heap space instead of the global heap"... just to state the obvious. Also, I'll add that I really admire the direction of the .NET community lately. Really cool tech space to watch. I'm glad I tuned in when I did.
I hope that developers of any kind of databases should be quite familiar with relational algebra as a mathematical concept.
Why do you think functional programming would not be suitable for RavenDB or noSQL-databases? Erik Meijer has proven that noSQL is duality of relational databases: http://queue.acm.org/detail.cfm?id=1961297
Functional algebra is very near to relational algebra. LINQ (FP-concept, poor man's F# really) is very much like SQL-language (relational concept). Actually a function is just a special case of a relation: http://en.wikipedia.org/wiki/Function_%28mathematics%29
For example Rich Hickey's project, Datomic, is a database developed with Clojure (functional programming language): http://www.datomic.com/rationale.html Also, as Ayende stated, some noSQL-databases are using Erlang.
Eli:
Types are for compiler automatic error correction. Types are not for developer/code reviewer. They are always correct if your code compiles. You shouldn't use printer to make code reviews.
For me as code reader, the most important thing is that the intention of the developer can easily be read from the code. So any non-alpha-numeric characters are noise as well as type definitions.
I very much agree that parallelism should be infrastructure level concern. I think that in this discussion people haven't encourage "going full F#" but just try it before judging. You can include some F# projects with your existing C# just fine.
I agree and disagree there. Types announce the behavior of the application to the developer as well. For instance the implementation details of a HashSet versus a TreeSet is very different in Java terms... not sure if there is an equivalent in C#, been out of it for a very long time, but these Java Sets extend the same Interface but they differ in critical ways.
I guess I can't really argue with that, but if curlies are noise they are a slight hum. Certain things are easier to ignore. I never got bad code smells from curlies. The code around the curlies makes me want to throw up all the times :D. The boilerplate argument has a lot of merit, but I like AOP for that. It is mature, easy to work with, and it's very effective at handling cross cutting concerns.
Yes, coincidentally RavenDB falls into the infrastructure category, and being a datastore it probably could see a lot of the FP benefits. I don't think Ayende disagrees with that - at least I didn't get the overall impression. He's more focused on the composition of the existing community and what that means going forward in the long term and in the short term... after all he is running a real business for it. It's interesting that the CLR is a lot of C# from what I read on Microsoft's press release in Feb "the coreclr repo has ~ 2.6M lines of code" ... "coreclr includes large collections of both C# and C++ code". Obviously, this is not a new way of thinking about managing large mission critical .NET projects.
Ayende Rahien what is your advice to you license-paying customers who write F# applications that use RavenDB?
Ayende: You are just so wrong in all your statements. You has offended a whole horde of talented programmers and opened the gate to the holy war between the ignorants and the arrogants from both sides here. Please remove this shaming entry and take the next haskell book or WTF-FP Programming language tutorial first. Or event better spend this time with you daughter. My Statement is - an average FP-Programmer is at least twice so good like an average OOP-Dev, because he can speak both paradigms. Just try to find an F#-Developer who can't C#. Or C++ one who can't C. Does it mean C is better than C++?! Even C can be functional or object oriented, but it doesn't make the development fast, unless you use some Tools or language features, or IDE-Codegen. Just try to hire one F#-ler. I come between the firsts to help you, just because i'm bored with C# in all this years.
It seems to me that if one could create a significantly better document database by coding it in F#, one should simply write one in F#. If it would really be better that would be an opportunity, no?
Of course the argument is the most popular # is the easiest\cheapest to find people who use it. So with that in mind we all should use Oracle, MySQL and MSSQL (http://db-engines.com/en/ranking) with C, Java and PHP (http://langpop.com/) but that would be quite a dull world to live in.
Having said that I think its a bit cheeky to suggest that someone re-writes their existing production app in any different language since a re-write is almost never worth the money.
Having said that I think its another thing to take to the web and denounce a lot of very talented peoples profession based on some very loose statistics.
Andy, please remove your comment, it's not just plainly silly, it's offending, ignorant and arrogant.
Nicolas, no, not any good programmer writes good code on any language. Fortunately for all of us this is completely untrue.
Thorium, Absolutely wrong. When you are reading non trivial codebase, and you are midway through a pretty complex call chain, not having types visible can make it all the more harder to figure out what the code is doing. What is this variable? What data does it contain? How do I see it? If I need an IDE just to figure those out, it is very bad.
I have seen this often when reading complex Erlang codebases, it is not fun or easy to do, because you have to reference back across several method invocations to figure out what is actually going on.
Bob, You can absolutely write RavenDB apps using F#, that has nothing to do with the discussion. The choice of language is highly dependent on what you do and what are the needs of the project
Andy, Thank you for your concern about the time I spend with my daughter.
I'm actually quite familiar with FP in general and have used several functional programming languages.
That said, you still haven't actually addressed the content of the post.
Alexander & Nicolas, That is a very true statement. Not only that, a C# developer can pick up F# in a few days, for sure, and he'll continue to write C# code in F# syntax for a very long time afterward.
Regarding, C# and F#, especially if the developer was looking for very SOLID code, etc. - this is very true.
But take a Cobol developer and give him Lua, or Boo/Lisp, or even Java/JavaScript and vice versa. How long will it take him to learn and produce good code? A month? I don't think so. I'd say a year. And for this year he will produce bad good.
Not every good developer can produce good code in any language right away. Any developer is a human being and needs time to learn.
Also remember the rule about the 10,000 hours of practice required to learn anything to do it well .
While I agree that it would be foolish to rewrite a working app in a different language (because this http://www.joelonsoftware.com/articles/fog0000000069.html among other excellent reasons), I would hasten to point out that at one point in time many of the same concerns you express about F# were expressed about C#. It's not a coincidence that Managed C++ was one of the first languages on the CLR; at the time MS was really in the C++ business. C# and OO are orthodoxy, not historic inevitability.
This is not addressed to Ayende but to the commenters who keep asking why they would bother with F#: I like F# and I think it will get more adoption as more people discover it. But it's really good to avoid making OO orthodoxy. Things like assuming one way is better than another simply because "we've always done it that way" (especially when you haven't always done it that way) just retard forward progress. Galileo was forced to recant his scientific work simply because it didn't accord with the majority accepted world view of the time.
Onorio, I was a C++ guy at the time, and I remember looking at C# not as a language to replace C++, it "obviously" couldn't do that. But it was a (much) better than VB6, and for the quick & dirty business app that was the VB bread & butter, it was much nicer.
There is in the original post a mix of : 1 - real arguments against F# 2- arguments which only arise due to the nature of that project, and do not generalize 3- arguments which are outright disputable
Seeing that, F# enthusiasts should not be offended by such point of view, but take it seriously. Fanboyism might feel good (does it?) but in the end it does real harm.
One can argue that it is hard to imagine a sharp C# developer who could not pick up F# in less than a week, or flip the argument about the numbers of programmers and say it saves times and effort recruiting (which can itself be countered by other arguments), etc..
Bottom line is : F# fanboys, raise the level or keep it up. Be rational. You have a nice tool which is using superior FP concepts on a very popular platform.
Learn about the messages out there, the pain points, don't listen just to annoying self-serving fanbase hype...
You could have summarized this post as "I don't make technical decisions based on merit, but based on popularity".
Please read the Blub Paradox by Paul Graham to understand why you are not able to rationally compare your favorite language with another unfamiilar (possibly superior) language.
To repeat what Scott Wlashin's commented: "Only people with a foot in both camps have enough information to make a rational decision."
Every F# developer can program in C#. They choose not to. Try implementing the same feature set in idiomatic F# and idiomatic C# and you will see why. If your assumption that the "cost of F# development is 50% of the cost of C# development" holds true than you are not programming in idiomatic F#. Iʼd say F# development is at least 5x cheaper than C# if you give the same task to developers in the same salary range.
Comment preview