ASP.NET and F# - Creating MVC web applications in F#
cs.hubfs.netFirst off, I love F#. I use it extensively for offline data processing, managing our build process (via FAKE), and general purpose Windows scripting. I've also dabbled in DSL creation, and if you follow any of examples it really is pretty easy to do. As Don Syme (F#'s creator) has said, F# is a lot like a statically typed Python (with lots more syntax).
But I wouldn't use it with ASP.NET. Learning F# is pretty heady and it would give your average .NET developer fits to learn it. You'd lose an advantage of using the .NET platform then - it's pretty easy to get average developers to be productive in .NET/C#. Forcing developers to learn F# would grind productivity to a halt.
Also, because of the whitespace requirements, F# is lousy in the webforms view engine. (Perhaps a Mako-like templating engine for F# would make sense).
Stick with C# for your web work and your libraries that your web site are using. Life will be easier.
If you really want to delve into F# on the web, these guys did a framework designed to be used with F#: http://www.bistroframework.org/
They also did a .NET port of the django templating engine: http://ndjango.org/
Most of the time, we use F# on the backend, using C# as little as possible. For web apps, that usually means the ASPX files themselves. For the MVC controllers, writing them in F# seems to work great.
The largest contention point arises when we pass F#-ish types to the ASPX page for rendering. It works, it's just that the C# required at that point can be sort of ugly.
Also, don't forget WebSharper, which provides a way to write all your client-side code (JavaScript) in F#. It handles all sorts of things, including async RPC calls. http://www.intellifactory.com/products/wsp/Home.aspx
The Intellifactory guys really know their F#. But this seems too much like WebForms and MSAjax for my tastes. After a while autogenerated javascript and HTML becomes very problematic, to say the least. If I want javascript, I'll just write it myself.
Now what I'd really like to see is an F# stand alone webserver - that would operate outside of ASP.NET/IIS. I envision a functional Request/Response pipeline, where you can augment the pipeline using function compositoin. Perhaps this could even handled by a computation expression or workflow. ( For those unfamiliar with F#, this is one of the killer features. See how simple it is to handle Async or parallel processing in F#).
Chris Smith has an interesting example of a Session State workflow in his F# book - I would like to see someone attempt that with a full fledged server.
Hmm, good article, but I think it does more to expose Microsoft's inability or unwillingness to integrate F# into the .Net platform the way C# is.
He had to create a C# web project, as Visual Studio doesn't support that for F#. He had to create a C# LINQ-to-SQL project to generate model classes as there's no support to do so in F#.
This saddens me greatly. Here is a potentially great language in the .Net ecosystem and the support for the most basic of things is missing.
Has anyone used the WebSharper framework (http://www.intellifactory.com/products/wsp/Home.aspx) designed for F#? It looks like it addresses several issues I have with web development in general and F# web development in particular ...
We've started too, but not on any sizable projects yet. The guy that does our UI stuff loves it, and looking at the code, it looks pretty easy.
To keep apps interactive, you have to doing a lot on the client side. To keep sanity, you want to use a decent language. WebSharper seems to fix both of those.
If you get to write all your business logic in F# and there are no needless sources of headaches, I guess that could be pretty nice if you already use ASP.NET.
The main headache-inducer I've encountered is that to really get the benefits of F# I'd like my model objects to be immutable records, but the ASP.NET MVC model binding infrastructure (along with the binding/serialization/etc. parts of a lot of other .NET frameworks) assumes mutable model properties (and default constructors). You can create a custom model binder, which works but isn't 100% satisfactory for other reasons.
The example gets around this by just using LINQ to SQL generated C# classes as the model, but that's a big compromise.
There was a neat article a while back on building a Starcraft bot using F# for the AI and a C++/C# stack for interfacing with the game at a lower level.
Boo + ASP.NET is also really quite nice. Python syntax with static (inferred) typing and syntactical macros, with a nice base framework. While it hasn't replaced Python+Pylons for me when it comes to rapid development, it's really quite enjoyable for high performance stuff.
Somewhere I read an article about how easy it is to create your own view engine for MVC. Given F#'s facility with DSLs, it seems it wouldn't be too infeasible to make an F# view engine too.
Some links to create your own engine in asp.net mvc: http://www.singingeels.com/Articles/Creating_a_Custom_View_E...
http://amazedsaint.blogspot.com/2010/06/creating-custom-view...
Unrelated, but every time I see an F# article I think of a quote from Juval Lowy I heard on the Dot Net Rocks podcast (I think), which went something like "Yeah, with F# you can just slam your fingers onto random keys and it will be valid code"
(edit:formatting)
...and it will be valid code
There are a lot of subtleties to the syntax that are not easy for someone new to the language to figure out, especially if you are new to the functional family of languages. The error messages are not always helpful. I can see F# will be a great tool for certain problems, and once you are really proficient I can understand making a statement like this.
Agreed, just found Juval's quote entertaining.
Personally, I much prefer simple view engines that have limited computational power - the port of StringTemplate to ASP.Net MVC being my current favorite
Looks pretty cool, I might try that out!