After trying to build a slightly above-toy-size project in F#, I came to the conclusion that with current tools it would be quite difficult to maintain a project of even moderate complexity. Unfortunately, I don’t believe this situation will dramatically improve any time soon.
\n<\/p>\n
Maintaining F# projects is hindered by two main obstacles:<\/p>\n
* Necessity to maintain a proper source file order
\n* Awkwardness of assembly references<\/p>\n
In F# the order of files in a project is significant. It seems that F# completely lacks the concept of a linker. The F# compiler takes all source files in the project and compiles them in order, as if they were a single large file. Of course, this may not be how it exactly works internally, but this is the way it looks from the outside.<\/p>\n
A type (variable, module, class) may be used only after its definition.<\/p>\n
#light\n\nlet foo = new Foo()<\/font> \/\/ does not work - type Foo is not defined\n\ntype Foo =\n class\n new() = {}\n end\n\nlet bar = new Foo()\n<\/code><\/pre>\nThere are two very bad consequences that arise from this:<\/p>\n
* You always need to worry about the file order
\n* Since no other major language cares about it, reordering files is not properly supported by Visual Studio<\/p>\n
You Always Need to Worry about the File Order<\/h3>\n
Whenever something in file B uses something in file A, file A must precede file B in the project. This means that a developer must always keep a mental picture of the entire project dependency graph. Needless to say, this graph grows exponentially with project size, and it is not explicitly stored anywhere. Since each file may (and normally does) define multiple entities, all this becomes even more complicated. If you inherit a big project you don’t know much about, I don’t want to be in your shoes. Let say you want to add this little class or function. Between which of the 133 source files do you insert it?<\/p>\n
Maintaining File Order Is Hard<\/h3>\n
Visual studio does not have built-in support for reordering files, even with F# plugin. If you add a file, it goes to the end of the project. If you rename a file, it goes to the end of the project. Current recommendations<\/a> for changing the file order are outright ridiculous, not to mention time consuming and error prone:<\/p>\nTo change the order of the files in the project tree you must unload the project (right click on the project in the solution explorer), choose “edit ProjectName.fsharpp” on the closed project node (again in the solution explorer), make your edits then reload the project.<\/i><\/p>\nAssembly References<\/h2>\n
You cannot normally reference an F# project from C#, or C# project from F#. By “normally” I mean going to the “references” folder of your project and choosing a project from the list.<\/p>\n
Assembly references are added via compiler options, including the path information, or in the source files themselves (the #r<\/code> directive). This is not as bad as reordering files, but it still is an impediment.<\/p>\nSummary<\/h2>\n
The file order problem makes writing large F# projects impractical. The assembly reference problem only slightly adds to it. After all, you usually have many more files than assemblies.<\/p>\n
I believe that the technical issue of nicely reordering files in Visual Studio may eventually be resolved. It may be not easy though. Since none of the major languages require file reordering, Visual Studio may “resist” that kind of changes. However, even if Visual Studio cooperates, the dependency of F# compiler on the exact file order will remain, and this makes dealing with large projects difficult. I am afraid that this dependency is baked into the language: I saw some references that it is required for type inference. It seems unlikely that the dependency on the file order could go away completely.<\/p>\n
So, the prospects of F# becoming big-project-friendly are not very good.<\/p>\n","protected":false},"excerpt":{"rendered":"
After trying to build a slightly above-toy-size project in F#, I came to the conclusion that with current tools it would be quite difficult to maintain a project of even […]<\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"Layout":"","footnotes":""},"categories":[10],"tags":[9],"class_list":["entry","author-ikriv","has-more-link","post-28","post","type-post","status-publish","format-standard","category-fsharp","tag-fsharp"],"_links":{"self":[{"href":"https:\/\/ikriv.com\/blog\/index.php?rest_route=\/wp\/v2\/posts\/28","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/ikriv.com\/blog\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/ikriv.com\/blog\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/ikriv.com\/blog\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/ikriv.com\/blog\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=28"}],"version-history":[{"count":0,"href":"https:\/\/ikriv.com\/blog\/index.php?rest_route=\/wp\/v2\/posts\/28\/revisions"}],"wp:attachment":[{"href":"https:\/\/ikriv.com\/blog\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=28"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/ikriv.com\/blog\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=28"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/ikriv.com\/blog\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=28"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}