> F# is not the language I would write an entire app in today. Instead > use it for robust processes. Such as multi threading processes.
I suppose if you don't want to write robust multi-threaded applications, F# might not be the best language. ;) > > I have spoken with a few hard core F# developers over the past few > years and they really love it's flexibility and bend ability. They > also see more internal code that M$ writes to be done in F# replacing > C++ based modules over time. They guys all had M$ employment at the > time. If you think about how F# evolved, it's really remarkable that it's got such traction, even internally at MS. It started out life as a research project, just to see if it was even possible to port a language like Ocaml to the CLR. It proved to be so good in practice as it was supposed to be in theory that many eyebrows were raised. Unlike DLR (dynamic language runtime) language like IronPython and IronRuby et al., it compromises performance not at all for a syntax that feels totally dynamically typed (but is in fact totally and strictly type safe). F# generated code benchmarks remarkably well against "pure C#" at a fraction of the cost in code. But the real power of the language is in the ability to take very complex concepts and extend the language with custom syntax to eliminate most of the boiler plate code to express those concepts, in such a form that it can even be treated as pure data and passed over the wire to remote locations for computation. This somewhat mind-bending idea is essential to taking distributed processing to a new level. I actually have one thing about it's current implementation I totally hate, however. It is not possible in F#, for a reason that I frankly do not fathom, to implement a generic interface more than once with different generic parameters. I discovered this to my dismay the hard way by merely subclassing a class from an ORM library I love (DataObjects.NET), which happens to be written in C# and does in fact implement a generic interface twice, each implementation with different concrete type parameters. F# chokes on that with an error message stating that this is verbotten at this time in F#, even though this was done by the superclass and not the F# code I wrote. I can see Don Syme and the team, sitting around a table, looking at the timeline for the next release and saying, "Oh, we can cut this corner; no one will notice." Well, "no one" noticed. And I was none to happy about it. ;) But I still think, despite this edge case EPIC FAIL, F# is a fantastic language and I enjoy exploring all the nifty things I can build with it that would be difficult even to think about in other .NET languages. :) - Bob > > > > -- > Stephen Russell > > Sr. Production Systems Programmer > CIMSgts > > 901.246-0159 cell > [excessive quoting removed by server] _______________________________________________ Post Messages to: [email protected] Subscription Maintenance: http://leafe.com/mailman/listinfo/profox OT-free version of this list: http://leafe.com/mailman/listinfo/profoxtech Searchable Archive: http://leafe.com/archives/search/profox This message: http://leafe.com/archives/byMID/profox/[email protected] ** All postings, unless explicitly stated otherwise, are the opinions of the author, and do not constitute legal or medical advice. This statement is added to the messages for those lawyers who are too stupid to see the obvious.
