What would also be great to know, if anybody of you use f# to write "common" desktop applications? I often see expamles using f# in scientifc or mathematical areas, but is it also an good idea to write an normal deskop application with gui and lots of interactions with f#?
Thanks for any help in advance.
Daniel
I wrote such an app recently. It was basically a puzzle solving app that solved Rush Hour puzzles. It was reasonably complex though. The "grid" was custom drawn, and a numeric spinner control allowed you to change the size of the grid. Whenever you did it would recalculate all the sizes and redraw the board. You could alternate between design and play mode, and in design mode you could drag the mouse around to create a selection rectangle (similar to clicking and dragging on your desktop in Windows). Once you release the rectangle, it would calculate all the grid squares that occupied the rectangle touched, and create a car occupying those squares, facing horizontally if your rectangle was longer than it was tall, and vertically if it was taller than it was long. There were also a few other types of interactions you could have with the board in design mode. There were a couple of combo boxes allowing you to select different combination of AI search algorithms and heuristics, and a button to solve. If a solution was found, the entire solution would be animated in real time.
Perhaps this falls under the "scientific" category you mentioned, but the GUI interactions were complex enough that I think at the very least it demonstrates they are not that much of a problem with F#. There were a few quirks I ran into, and it's certainly easier to do it in C#, but overall it wasn't that bad. The hardest part was having to design the forms in C#, copy and paste the code into the F# window, and then hand convert it all to F#. I would imagine that in a future release they would add code generation for the UI editor, it can't be that hard.
That being said, the advantage of the .NET Framework is that all of these languages interoperate with each other fairly fluently. There's really no reason -not- to design the UI in C# and the core algorithms in F#. The only possible drawback is that your exported F# interface may not be able to use all of F#'s available features. Or not easily anyway.
I don't expect us to see UI-Designer tools for F# in the near future, and I honestly thinkt that it's better to use C# or VB for the GUI and front-ends (yes even for thinks like WCF).
Not only is C# better supported for those tasks but this sort of code is often written with good designers and good GUI-programmers - and I guess those don't are overly eager to learn a FP - theres just not enough incentive for them to leave the imperative track.
So yes I guess MS is right on that one - F# for algorithms, and core-code, C#/VB/... for the front-ends and persistence scenarios (I guess we won't see any good ORM - or whatever this would be called for F# - either).
I don't expect us to see UI-Designer tools for F# in the near future, and I honestly thinkt that it's better to use C# or VB for the GUI and front-ends (yes even for thinks like WCF).
Not only is C# better supported for those tasks but this sort of code is often written with good designers and good GUI-programmers - and I guess those don't are overly eager to learn a FP - theres just not enough incentive for them to leave the imperative track.
Speaking as someone fairly new to the dotNet world, I don't see why any of this needs to be true.
It's not really about converting existing users - it's about winning the new ones. From my point of view, F# is interesting, and C# is mostly a kind of Java-ish language that runs on fewer platforms. I can write C#, but it's not why I'm here.
It seems like tools for dotNet GUIs are fairly limited right now. WPF is all about hand editing pseudo-HTML; the tooling seems to be equally limited for any language that runs on dotnet.
WinForms are a dying niche technology, so even if the tools are better, it doesn't matter. It's like having great tools for building buggy whips.
The new MVC stuff for web sites might be interesting (haven't looked at it yet), but from what I've gathered the tooling is in about the same shape as WPF - you're mostly in the land of hand-editing text files.
Old-school ASP.NET isn't going to bring in any new converts to the dotNet world - anyone doing Ruby/some Java thing/PHP already knows about and has rejected it as an interesting choice. Maybe the tools are better here for C#, but again, not all that important.
I think it's perfectly reasonable to think/hope that F# will be the dominant language on the platform and C# will be the niche player. Maybe there are some edge cases where an imperative language will be the right choice :-).
It's not really about converting existing users - it's about winning the new ones. From my point of view, F# is interesting, and C# is mostly a kind of Java-ish language that runs on fewer platforms. I can write C#, but it's not why I'm here.
It seems like tools for dotNet GUIs are fairly limited right now. WPF is all about hand editing pseudo-HTML; the tooling seems to be equally limited for any language that runs on dotnet.
WinForms are a dying niche technology, so even if the tools are better, it doesn't matter. It's like having great tools for building buggy whips.
The new MVC stuff for web sites might be interesting (haven't looked at it yet), but from what I've gathered the tooling is in about the same shape as WPF - you're mostly in the land of hand-editing text files.
Old-school ASP.NET isn't going to bring in any new converts to the dotNet world - anyone doing Ruby/some Java thing/PHP already knows about and has rejected it as an interesting choice. Maybe the tools are better here for C#, but again, not all that important.
I think it's perfectly reasonable to think/hope that F# will be the dominant language on the platform and C# will be the niche player. Maybe there are some edge cases where an imperative language will be the right choice :-).
Well you won't come to .net land because of F# or C# or some other language (there is even a P(rolog)#, some kind of Lisp, Python, ...). You will come because of the framework itself - it's great and you can programm everything in .net - from RIAs to old-school internet applications, from desktop apps to mobile phones, ...
I think you are a minority if you really are willing to learn the framework just because of F# - why not go for haskel, erlang or scala, scheme, ... ?
And the tools for .net GUIs are not limited at all - WPF has it's own editor for designers/programmers (expression blend), WinForms is not dead at all and won't be for some time.
As far as ASP.NET is concerned you might be right. It was a (successful) try to bring all those VB-programmers to the internet-world without rethinking the way you write your apps - but at a price (just look at the traffic of those sites - forcing stateful behavior to a stateless protocol is tricky - and you allways end up having BL-code in your front-end.
F# will never be the core-languague - C# was and allways will be. To change this I guess you would have to rebuild the CLR to better support FP-paradigms like immutability.
I don't expect to see F# emitting tools, but I think interop could be made easier than how it is now. For instance, there's no reason the ASP.NET project type couldn't allow me to write F# behind. Even more so for ASP.NET MVC which doesn't emit much C# (no designer like forms).
I have yet to see anything that makes C# "better" for those tasks -- what specific things did you have in mind?
There's no reason, say, the XAML editor couldn't produce F# code. All it does is essentially create some fields to strongly refer to XAML objects...
The difficulty in using C# on the "front end" is that then you can't really take advantage of F#'s types like records, discriminated unions, and so on. You end up wanting to export a "dumb" F# API for C# consumption. Not always a problem, but certainly something to consider.
Good ORMs? F# works on .NET, and works fine with NHibernate. I just wrote this: [link:www.atrevido.net]
There are a few unpolished parts, but I'd be surprised if a lot of this doesn't get cleaned up in the release version. Even with the bit of extra work here and there, I'd be willing to bet it's still an overall gain using F#.
Just as food for thought, Robert Pickering suggests a simple and useful approach for GUI apps in his 'Foundations of F#' book. Basically, he recommends creating a C# project which contains all of the forms, as modeled in the WinForms designer. However, omit all of the normal 'glue' code, business logic, and data access. Then in an F# project orchestrate the whole shebang together. This is an inversion of what the 'official' marketing verbiage recommends for C#/F# integration. In essence, the WinForms assembly becomes a collection of resources which the real (F#) app code just leverages; very similar to a localized strings file. This can give you the best of both worlds with minimal non-F# code. Also, it (theoretically, anyway) avoids, or at least reduces, the need to use C#-friendly data types. It won't be right for every situation, but its certainly worth exploring.
Now, if someone could just make an F#-friendly ORM, and a better F# CodeDom library, my coding would be much more fun!
Now, if someone could just make an F#-friendly ORM, and a better F# CodeDom library, my coding would be much more fun!
How would you define a "F#-friendly" ORM? What would make an ORM "F# friendly" for you?
Good question... Mostly, I would just like existing ORMs to generate F# code files (which, of course, explains my comment about a complete CodeDom implementation for F#). Also, it might be useful to have an ORM which better exploits immutability, tuples, records, and pattern-matching. (Hmmm, maybe I'll write one someday.)
On the first point, getting F# code -- that's not a huge barrier and I'm sure we'll see some progress here and there. F# can do the OO stuff required, and some ORMs don't even have codegen so F# already works fine.
On tuples, I'd be surprised if more APIs don't start adopting them in general, as they're in .NET 4's BCL. For databases, tuples are great for composite key types, and that way APIs won't need separate classes/functions in those cases.
I think the second point, support for F# constructs and types, is the interesting one. It's probably not too difficult to generate a record-based mapper. Would be a fun project.
The part I'm a bit hesitant on is how to accomplish things like lazy loading, when using immutable structures. Other frameworks make use of properties and OO inheritance to magic this stuff up.
Then actually providing all the production level features like caching, querying, change tracking, etc. -- I think it's probably more fruitful *for production apps* (I still love the idea of an F# ORM for fun) to try to extend existing ORMs to support F# records, discriminated unions, etc. on a limited basis. In fact, I'd be surprised if some of this isn't somewhat easy on a hack basis: discriminated union cases are just subclasses so using an ORM's inheritance feature, those might already be mappable.
Finally, one pain point is getting F# quotations to "C#" expression trees. Right now there's a lot of extra verbosity; it'd be cool if instead F# supported magic conversion to expression trees when necesary. Oh when will VS2010 B1 come out so we can see where F#'s headed? :)
I agree the extra verbosity around converting from F# Quotations to Expression Trees is unpleasant. However, it would only be a necessary step while staying in the confines LiNQ to SQL (or LiNQ to Entities) for use in the larger .NET ecosystem. An different ORM implementation might make extensive use of Quotations in a way which is difficult to leverage from other .NET languages; but I've been mostly thinking about 'something F#-friendly', and not 'something friendly to any .NET language'. And yes, change tracking and caching would very likely be major issues without using something mutable. But I think, based on some existing code, querying and lazy loading could be made very straight-forward. That having been said, the straight-forwardness might very well be undercut by performance issues.
I agree the extra verbosity around converting from F# Quotations to Expression Trees is unpleasant. However, it would only be a necessary step while staying in the confines LiNQ to SQL (or LiNQ to Entities) for use in the larger .NET ecosystem.
Expression<T> is much bigger than just "LINQ to SQL (or LINQ to Entities)". Many other APIs are turning to expression trees to do transforms outside of query. For instance, ASP.NET MVC uses expression trees to generate links that will execute specific actions. Other APIs, as I have mentioned, use expression trees as a form of sorta strongly typed reflection. With .NET 4, expression trees get more powerful, and I'm sure more APIs will pickup on it. While pattern matching over quotations is very sexy, having clunky interop with expression trees will hurt.
I'm most interested in seeing what ideas there are for dealing with lack of mutability, lazy loading in particular. I can see wrapping stuff with certain types and using async workflows (like the gneverov's F# STM code) -- but I'm not sure how clean that is overall.
My comments about caching and change tracking were just examples of things that also need to be implemented well. Querying and other features are also needed. That's why I think it'd be more productive (as in being able to deploy) overall to look at extending something like NHibernate, versus trying to write things from the ground up just to add certain features.
Well, yea, you are right, and it goes even deeper...
I would say that the ORM central idea of object (business object) being the communication vehicle between the program and persistence media does not sit well with immutability. As long as you are just reading data, you are good, but when you try to manipulate the status of the object...
And giving up the ability to modify the business object breaks the encapsulation of the persistence media provided by the standard ORM model.
I can see your point, but I think your focusing too much on the 'Object' part of ORM. Perhaps the answer is more of an FRM (Function Relational Model)? I just made that up, but think about it--that's pretty much how SQL works anyway. Its all data, and operations on data. You're right in saying encapsulation would be broken. But, couldn't many of the same encapsulation benefits be achieved through other functional paradigms? In fact, ignoring performance issues for a now, wouldn't the only major sticking points be caching and change tracking (as MichaelGG has already mention on this thread)? I dunno. I think these warrants some further thought (and maybe some research).
I think immutable data and database-data are like fire and ice. Normally you'll want immutable data because you can pass this around and never worry about concurency and this stuff. On the other hand you want every data representating some part of your database to be exactly the current data. So in FP you working on making everything immutable while in your DL/BL you are working hard to make sure that you are only manipulating the current data and that those manipulations are based on valid data that didn't get outdated in the meantime.
And why should I try so hard to implement this in FP if .net gives me the opportunity to have both?
Sure it's fun to programm in F# and I'm going to use it in every reasonable way - but I've got so many great tools it's my responsibility to choose the right one for the right job too. And for DB and GUI IMO this is still C#.
in your DL/BL you are working hard to make sure that you are only manipulating the current data and that those manipulations are based on valid data that didn't get outdated in the meantime.
Well, that doesn't really change because you have immutable structures or not. Cache coherency, concurrency and transactions still apply regardless.
And why should I try so hard to implement this in FP if .net gives me the opportunity to have both?
Sure it's fun to programm in F# and I'm going to use it in every reasonable way - but I've got so many great tools it's my responsibility to choose the right one for the right job too. And for DB and GUI IMO this is still C#.
This is half my point: .NET already provides us with excellent frameworks, and F# can leverage them. I'd find it interesting to see a more-F# ORM, but that seems like a big task to bring it to production quality.
One question for you. I agree that the tooling on the C# side of things is much better right now. Is there anything in the F# language that you find inferior to C# for DB/GUI?
One question for you. I agree that the tooling on the C# side of things is much better right now. Is there anything in the F# language that you find inferior to C# for DB/GUI?
Ok - ignoring tooling and editorsupport (I hope both will improve in future versions ), there are several things that is a bit more comfortable in C#:
- partial classes and ther obvious benefit for GUI
- no upcast/downcast by hand (F# frees you mostly from the nasty typedeclarations but if you are working with interfaces / OOP they are back by large)
- the order of files in the project and type definition still matters
But overall F# IS better than C# and it could be so much better if we could get our hands on nice thinks like type classes.
One last point: the biggest problems for F# right now seems to be:
- getting your coworkers to look at it
- only basic intellisense, editor and online help support (directly linked to point 1)
- getting architects to think beyond OOP and well-known patterns
Sadly C#/.net 4.0 won't bring any big new FP features like 2.0 and 3.0 - so the mainstream will focus on dynamic programming and those other new toys.
Of course I am (focusing too much that is). It's been only 3 weeks into my first F# project and my LISP experience from long time ago does not help much. I am aware that the OOP paradigm has a hold on me, a hold I am trying to break.
So this term you just coined - FRM what can it be? If we stick with a record as a read-only object representation how would we approach manipulating the object - not the record - it is immutable, but the object behind it.
For instance we could use the same approach as the 'modification' methods on the map - where any updates cause creation of a new instance with modifications applied. With this approach tracking changes is not a problem. What is a probelm is usability. Essentially after the modifications the old instance (the before instance) should be discarded and from this point on the program should use the updated one. I guess. Or am I again thinking in OOP terms?
As to caching and lazy loads I am not too worried. Of course it breaks the immutability but, this can be well hidden inside the implementation, so that from the rest of the world standpoint it will still be immutable (with delayed initialization).
All of this is just thinking aloud...
As to the "copy on write" model with immutable records -- I don't see that as a problem. If you're writing in a functional style, you're already handling things in this way. It's only an issue if you do things like pass around objects and let others touch them and expect to see the changes. This is more fundamental than ORMs.
Even then, when you have multiple processes/threads/requests accessing a database and using an ORM, you still have the issue of knowing when to get new data. Sure, it's not affecting you directly at the code level of passing arguments, but it's still something that must be considered.
The reason I am concerned about the lazy loading in particular is that records don't _have_ mutability. The only ways I see around this is doing things behind the scenes, for example, creating a special lazy type that gets loaded as needed or whatnot. But these break the model of having your code not have to know/deal with the fact it really is persistable and optimized for performance. With non-records and OO inheritance, ORM frameworks are free to take care of this stuff behind your back.
I guess I don't see why a record's immutability would be relevant for lazy loading. I can see how mutability makes change tracking easier. But for lazy loading, if one F# record instance equals one database record, and some consumer is interacting with an IEnumerable collection of these records, then how would it be different from lazily iterating any other sequence of immutable 'things'? Or am I misunderstanding what you mean by lazy loading?
I guess I don't see why a record's immutability would be relevant for lazy loading.
Well, I haven't figured out a way to make the data field here be lazy:
type Photo = { id : int; data : byte array }
I.e., data should only be loaded if I actually access it. This is easy with an F# type like this:
type Photo() =
[<DefaultValue>]
val id : int
abstract data : byte array with get, set
Because now the ORM can generate a subclass on the fly that wires up code to load the byte array as needed. But with records, there's no subclassing or anything, so it becomes more difficult. It could be solved with extra types (like "byte array lazyloader"), but a good ORM shouldn't force us to change our structures to reflect DB/perf reality :).
Hi Daniel,
F# provides a lot of advantages, yes.
F# encourages immutability, which can make writing multi-threaded apps much easier.
.NET 4 will ship with new threading APIs to allow you to more easily parallelize code. Many of these APIs rely on passing functions around, and F# does a great job at this -- so that makes it easier.
F# has workflows, which allow you to write very simple code that the compiler turns into more complicated code. Here is a quick look at these: [link:blogs.msdn.com]
Basically, to go from a single-threaded to a multi-threaded version, you add "async { }" and a few ! in the right places :). Compared to using, say, C#, you're looking at far less code and confusion.
The compiler won't "auto-parallelize" -- F# doesn't even have the concept of "pure" like, say, Haskell does. But, all these things combined make it very easy for you to do it yourself.
Hi Michael,
thanks for your help!
Let me see, if i got it right. F# doesn't do some kind of auto parallize, but the characteristics of a functional programm (immutability) makes it lot easier to write an multithread-application...
So far so good, sounds all reasonable to me. The only thing i still have to struggle with is the question if it make sense to write an desktop application in f#? Our desktop application have typlically a complicated gui, lots of user interaction and often i/o traffic. Their are algorithmen which have to be calculated. But this doesn't cost lots of time...
In this context does it make sense to use f#? At the moment i cannot imagine how to design/write an complete desktop application in f#? Are their any experience? Or is the common way to write only special parts of the application in f#?
Thanks
Daniel
Ah, sorry I missed that.
The biggest weakness with F# and desktop UI is that there are no designer tools that will interface with the F# editor or generate F# code. So, all the nice stuff you get with VB and C# -- not for F#, yet. The same applies for ASP.NET. F# works fine, but VS and the designers won't cooperate. I am hoping this is made a bit easier in VS 2010.
But, all this means is that the very front-end of the software will use C# or VB. From there, C# can proxy all the controls, data, etc. back to F# and let F# be in charge. You just have the added overhead of having to hook up all this code.
With ASP.NET MVC, for example, you can keep the web designer and C# code in pages and so on, but have your controller classes implemented in F#, in another assembly. This works fine.
An alternative approach pushed a lot in the MS marketing is to use F# for "core" parts of the application, then have C# simply call F# code. This is certainly less work on the interop side. All you have to do is define some nice F# boundaries. The downside is that you end up having to use C# more ;).
Does that give you a clear idea?
Topic tags
- f# × 3705
- websharper × 1897
- compiler × 286
- functional × 201
- ui next × 139
- c# × 121
- classes × 97
- web × 97
- .net × 84
- book × 84
- async × 76
- ui.next × 67
- bug × 54
- core × 49
- website × 49
- server × 45
- parallel × 43
- ui × 43
- enhancement × 41
- parsing × 41
- testing × 41
- trywebsharper × 41
- typescript × 37
- html × 35
- javascript × 35
- owin × 35
- asynchronous × 30
- monad × 28
- ocaml × 28
- tutorial × 27
- warp × 27
- haskell × 26
- sitelet × 25
- linq × 22
- workflows × 22
- wpf × 20
- fpish × 19
- introduction × 19
- silverlight × 19
- sitelets × 19
- monodevelop × 17
- rpc × 17
- suave × 17
- piglets × 16
- collections × 15
- feature request × 15
- jquery × 15
- templates × 15
- getting started × 14
- pipeline × 14
- kendoui × 13
- reactive × 12
- 4.1.0.171 × 11
- monads × 11
- opinion × 10
- 4.0.190.100-rc × 9
- deployment × 9
- fixed × 9
- formlets × 9
- in × 9
- json × 9
- plugin × 9
- proposal × 9
- scheme × 9
- solid × 9
- basics × 8
- concurrent × 8
- highcharts × 8
- how-to × 8
- python × 8
- 4.1.1.175 × 7
- complexity × 7
- documentation × 7
- visual studio × 7
- 4.1.2.178 × 6
- lisp × 6
- real-world × 6
- released in 4.0.192.103-rc × 6
- remoting × 6
- resources × 6
- scala × 6
- websharper ui.next × 6
- workshop × 6
- xaml × 6
- 4.0.193.110 × 5
- 4.2.3.236 × 5
- aspnetmvc × 5
- authentication × 5
- azure × 5
- bootstrap × 5
- conference × 5
- dsl × 5
- formlet × 5
- java × 5
- list × 5
- metaprogramming × 5
- ml × 5
- released in Zafir.4.0.188.91-beta10 × 5
- sql × 5
- visualstudio × 5
- websharper.forms × 5
- zafir × 5
- 4.0.192.106 × 4
- 4.0.195.127 × 4
- 4.1.0.38 × 4
- 4.2.1.86 × 4
- 4.2.6.118 × 4
- css × 4
- example × 4
- extensions × 4
- fsi × 4
- fsx × 4
- html5 × 4
- jqueryui × 4
- lift × 4
- reflection × 4
- remote × 4
- rest × 4
- spa × 4
- teaching × 4
- template × 4
- websocket × 4
- wontfix × 4
- 4.0.196.147 × 3
- 4.1.0.34 × 3
- 4.1.6.207 × 3
- 4.2.1.223-beta × 3
- 4.2.11.258 × 3
- 4.2.4.114 × 3
- 4.2.4.247 × 3
- 4.2.5.115 × 3
- 4.2.6.253 × 3
- 4.2.9.256 × 3
- ajax × 3
- alt.net × 3
- aml × 3
- asp.net mvc × 3
- canvas × 3
- cloudsharper × 3
- compilation × 3
- database × 3
- erlang × 3
- events × 3
- extension × 3
- file upload × 3
- forums × 3
- inline × 3
- issue × 3
- kendo × 3
- macro × 3
- mono × 3
- msbuild × 3
- mvc × 3
- pattern × 3
- piglet × 3
- released in Zafir.4.0.187.90-beta10 × 3
- svg × 3
- type provider × 3
- view × 3
- 4.1.1.64 × 2
- 4.1.5.203 × 2
- 4.1.7.232 × 2
- 4.2.10.257 × 2
- 4.2.3.111 × 2
- 4.2.5.249 × 2
- android × 2
- asp.net × 2
- beginner × 2
- blog × 2
- chart × 2
- client × 2
- client server app × 2
- clojure × 2
- computation expressions × 2
- constructor × 2
- corporate × 2
- courses × 2
- cufp × 2
- d3 × 2
- debugging × 2
- direct × 2
- discriminated union × 2
- docs × 2
- elm × 2
- endpoint × 2
- endpoints × 2
- enterprise × 2
- entity framework × 2
- event × 2
- f# interactive × 2
- fable × 2
- flowlet × 2
- formdata × 2
- forms × 2
- fsc × 2
- google maps × 2
- hosting × 2
- http × 2
- https × 2
- iis 8.0 × 2
- install × 2
- interactive × 2
- interface × 2
- iphone × 2
- iteratee × 2
- jobs × 2
- jquery mobile × 2
- keynote × 2
- lens × 2
- lenses × 2
- linux × 2
- listmodel × 2
- mac × 2
- numeric × 2
- oauth × 2
- obfuscation × 2
- offline × 2
- oop × 2
- osx × 2
- packaging × 2
- pattern matching × 2
- performance × 2
- pipelines × 2
- q&a × 2
- quotation × 2
- reference × 2
- released in Zafir.4.0.185.88-beta10 × 2
- rx × 2
- script × 2
- security × 2
- self host × 2
- seq × 2
- sockets × 2
- stm × 2
- tcp × 2
- trie × 2
- tutorials × 2
- type × 2
- url × 2
- var × 2
- websharper.charting × 2
- websharper4 × 2
- websockets × 2
- wig × 2
- xna × 2
- zh × 2
- .net interop × 1
- 2012 × 1
- 4.0.194.126 × 1
- 4.1.3.184 × 1
- 4.1.4.189 × 1
- 4.2.0.214-beta × 1
- 4.2.12.259 × 1
- 4.2.2.231-beta × 1
- 4.2.8.255 × 1
- Canvas Sample Example × 1
- DynamicStyle Animated Style × 1
- Fixed in 4.0.190.100-rc × 1
- Released in Zafir.UI.Next.4.0.169.79-beta10 × 1
- SvgDynamicAttribute × 1
- WebComponent × 1
- abstract class × 1
- accumulator × 1
- active pattern × 1
- actor × 1
- addin × 1
- agents × 1
- aggregation × 1
- agile × 1
- alter session × 1
- animation × 1
- anonymous object × 1
- apache × 1
- api × 1
- appcelerator × 1
- architecture × 1
- array × 1
- arrays × 1
- asp.net 4.5 × 1
- asp.net core × 1
- asp.net integration × 1
- asp.net mvc 4 × 1
- asp.net web api × 1
- aspnet × 1
- ast × 1
- attributes × 1
- authorization × 1
- b-tree × 1
- back button × 1
- badimageformatexception × 1
- bash script × 1
- batching × 1
- binding-vars × 1
- bistro × 1
- body × 1
- bundle × 1
- camtasia studio × 1
- cas protocol × 1
- charts × 1
- clarity × 1
- class × 1
- cli × 1
- clipboard × 1
- clojurescript × 1
- closures × 1
- cloud × 1
- cms × 1
- coding diacritics × 1
- color highlighting × 1
- color zones × 1
- combinator × 1
- combinators × 1
- compile × 1
- compile code on server × 1
- config × 1
- confirm × 1
- content × 1
- context × 1
- context.usersession × 1
- continuation-passing style × 1
- coords × 1
- cordova × 1
- cors × 1
- coursera × 1
- cross-domain × 1
- csla × 1
- current_schema × 1
- custom content × 1
- data × 1
- data grid × 1
- datetime × 1
- debug × 1
- declarative × 1
- delete × 1
- devexpress × 1
- dhtmlx × 1
- dictionary × 1
- directattribute × 1
- disqus × 1
- distance × 1
- do binding × 1
- doc elt ui.next upgrade × 1
- docker × 1
- dojo × 1
- dol × 1
- dom × 1
- domain × 1
- du × 1
- duf-101 × 1
- dynamic × 1
- eastern language × 1
- eclipse × 1
- edsl × 1
- em algorithm × 1
- emacs × 1
- emotion × 1
- enums × 1
- error × 1
- etw × 1
- euclidean × 1
- eventhandlerlist × 1
- examples × 1
- ext js × 1
- extension methods × 1
- extra × 1
- facet pattern × 1
- failed to translate × 1
- fake × 1
- fantomas × 1
- fear × 1
- float × 1
- form × 1
- form-data × 1
- forum × 1
- fp × 1
- frank × 1
- fsdoc × 1
- fsharp × 1
- fsharp.core × 1
- fsharp.powerpack × 1
- fsharpx × 1
- fsunit × 1
- function × 1
- functional style × 1
- game × 1
- games × 1
- gc × 1
- generic × 1
- geometry × 1
- getlastwin32error × 1
- getting-started × 1
- google × 1
- google.maps × 1
- grid × 1
- group × 1
- guide × 1
- hash × 1
- headers × 1
- hello world example × 1
- heroku × 1
- highchart × 1
- history × 1
- how to × 1
- html-templating × 1
- http405 × 1
- httpcontext × 1
- hubfs × 1
- i18n × 1
- ie 8 × 1
- if-doc × 1
- iis × 1
- image × 1
- images × 1
- inheritance × 1
- initialize × 1
- input × 1
- install "visual studio" × 1
- installer × 1
- int64 × 1
- interfaces × 1
- internet explorer × 1
- interop × 1
- interpreter × 1
- io × 1
- iobservable × 1
- ios × 1
- iot × 1
- ipad × 1
- isomorphic × 1
- javascript optimization × 1
- javascript semanticui resources × 1
- jquery-plugin × 1
- jquery-ui × 1
- jquery-ui-datepicker × 1
- js × 1
- kendo datasource × 1
- kendochart × 1
- kendoui compiler × 1
- knockout × 1
- l10n × 1
- learning × 1
- library × 1
- libs × 1
- license × 1
- licensing × 1
- lineserieszonescfg × 1
- local setting × 1
- localization × 1
- logging × 1
- loop × 1
- macros × 1
- mailboxprocessor × 1
- mapping × 1
- maps × 1
- markerclusterer × 1
- markup × 1
- marshal × 1
- math × 1
- mathjax × 1
- message × 1
- message passing × 1
- message-passing × 1
- meta × 1
- metro style × 1
- micro orm × 1
- minimum-requirements × 1
- mix × 1
- mobile installation × 1
- mod_mono × 1
- modal × 1
- module × 1
- mouseevent × 1
- mouseposition × 1
- multidimensional × 1
- multiline × 1
- multithreading × 1
- mysql × 1
- mysqlclient × 1
- nancy × 1
- native × 1
- nested × 1
- nested loops × 1
- node × 1
- nunit × 1
- object relation mapper × 1
- object-oriented × 1
- om × 1
- onboarding × 1
- onclick × 1
- optimization × 1
- option × 1
- orm × 1
- os x × 1
- output-path × 1
- override × 1
- paper × 1
- parameter × 1
- persistence × 1
- persistent data structure × 1
- phonegap × 1
- pola × 1
- post × 1
- powerpack × 1
- prefix tree × 1
- principle of least authority × 1
- privacy × 1
- private × 1
- profile × 1
- programming × 1
- project × 1
- project euler × 1
- projekt_feladat × 1
- protected × 1
- provider × 1
- proxy × 1
- ptvs × 1
- public × 1
- pure f# × 1
- purescript × 1
- qna × 1
- quant × 1
- query sitelet × 1
- question × 1
- quotations × 1
- range × 1
- raphael × 1
- razor × 1
- rc × 1
- reactjs × 1
- real-time × 1
- ref × 1
- region × 1
- released in 4.0.190.100-rc × 1
- reporting × 1
- responsive design × 1
- rest api × 1
- rest sitelet × 1
- restful × 1
- round table × 1
- router × 1
- routing × 1
- rpc reverseproxy × 1
- runtime × 1
- sales × 1
- sample × 1
- sampleapp × 1
- scriptcs × 1
- scripting × 1
- search × 1
- self hosted × 1
- semanticui × 1
- sequence × 1
- serialisation × 1
- service × 1
- session-state × 1
- sharepoint × 1
- signals × 1
- sitelet website × 1
- sitelet.protect × 1
- sitlets × 1
- slickgrid × 1
- source code × 1
- sqlentityconnection × 1
- ssl × 1
- standards × 1
- static content × 1
- stickynotes × 1
- streamreader × 1
- stress × 1
- strong name × 1
- structures × 1
- submitbutton × 1
- subscribe × 1
- svg example html5 websharper.ui.next × 1
- sweetalert × 1
- system.datetime × 1
- system.reflection.targetinvocationexception × 1
- table storage × 1
- targets × 1
- tdd × 1
- templates ui.next × 1
- templating × 1
- text parsing × 1
- three.js × 1
- time travel × 1
- tls × 1
- tooltip × 1
- tracing × 1
- tsunamiide × 1
- turkish × 1
- twitter-bootstrap × 1
- type erasure × 1
- type inference × 1
- type providers × 1
- type-providers × 1
- typeprovider × 1
- ui next forms × 1
- ui-next × 1
- ui.next jqueryui × 1
- ui.next charting × 1
- ui.next formlets × 1
- ui.next forms × 1
- ui.next suave visualstudio × 1
- ui.next templating × 1
- unicode × 1
- unittest client × 1
- upload × 1
- usersession × 1
- validation × 1
- vb × 1
- vb.net × 1
- vector × 1
- view.map × 1
- visal studio × 1
- visual f# × 1
- visual studio 11 × 1
- visual studio 2012 × 1
- visual studio shell × 1
- vs2017 compiler zafir × 1
- vsix × 1
- web api × 1
- web-scraping × 1
- webapi × 1
- webcomponents × 1
- webforms × 1
- webgl × 1
- webrtc × 1
- webshaper × 1
- websharper async × 1
- websharper codemirror × 1
- websharper f# google × 1
- websharper forms × 1
- websharper reactive × 1
- websharper rpc × 1
- websharper sitelets routing × 1
- websharper warp × 1
- websharper-interface-generator × 1
- websharper.chartsjs × 1
- websharper.com × 1
- websharper.exe × 1
- websharper.owin × 1
- websharper.ui.next × 1
- websharper.ui.next jquery × 1
- websockets iis × 1
- why-websharper × 1
- windows 7 × 1
- windows 8 × 1
- windows-phone × 1
- winrt × 1
- www.grabbitmedia.com × 1
- xamarin × 1
- xml × 1
- yeoman × 1
- yield × 1
- zafir beta × 1
- zafir websharper4 × 1
- zarovizsga × 1
|
Copyright (c) 2011-2012 IntelliFactory. All rights reserved. Home | Products | Consulting | Trainings | Blogs | Jobs | Contact Us | Terms of Use | Privacy Policy | Cookie Policy |
Built with WebSharper |
Hi,
to start off, i must admit that i'm really a newbie to functional programming. In fact i'v got only experience in programming imperative appliction using c#.
At the moment i got the task to investigate new ways to develop parallel applications in .NET. What i found was technologies like parallel extensions, concurrency and coordination runtime and f#.
Now i just wonder what is the advantage of writing parallel applications using f#? Am i right that the major advantage is, that if you purly programm in the functional programming way, the compiler could auto-parallelise your code, because its garanteed that the code has no side-effects?
What would also be great to know, if anybody of you use f# to write "common" desktop applications? I often see expamles using f# in scientifc or mathematical areas, but is it also an good idea to write an normal deskop application with gui and lots of interactions with f#?
Thanks for any help in advance.
Daniel