Marc said:
You simply have not supported this at all.
F# simply takes the capabilities of C# and adds functional programming,
pattern matching, type inference and a variety of other features. So this
is a no-brainer.
You have just given some examples (in the F# sweet-spot), but this does
not support the "everything you can do" argument.
The examples I've given were designed to showcase the new features offered
by F#. Everything else is the same as C#.
I will happily accept that it would
be possible for a highly targetted language to address a specific
problem better than a general purpose language (possibly such as F#
with your examples) - but that simply isn't a common problem *to the
majority of developers*. It is my suspicion that you are so deep in
the niche that you cannot accept that the niche exists.
Then I am also "deep in the niche" that OOP improves upon procedural
programming.
Sorry, but IMO
F# will always be a minority language - perhaps highly valuable in a
few areas, but (going back to your original post) making no impact on
the typical developer who simply has other things to do.
The same can be said of C#, of course.
That is the exact *opposite* intent of the CLR.
Yes. This progression is inevitable. At the core of the CLR is an inherently
mutating OOP style that is ill suited to the future landscape of computing
(most notably concurrent programming). While future developments are made
much easier by leveraging the CLR now, they will make progressively less
use of its OOP features as people migrate to better paradigms in the
future. The front-ends of the compilers for these languages will grow to be
much more sophisticated (just as F# is compared to C#). Eventually, a next
generation CLR will be created that has a wildly different style at its
core, one that can handle the massive parallelism of the future and expose
higher-level constructs (like closures) between languages.
Rather than spending
time and money trying to bring ML into .NET, don't you think the
overall community would have been better off by extending CLR
libraries with similar functionality?
In essence, you cannot retrofit functional programming onto and OOP system
as a library in a usable way just as you could not retrofit OOP onto
procedural programming as a library.
The CLR was extended with IL extensions (ILX) for some core functional
features like tail calls (which the JVM still lacks) but functional
programming is largely about what the programmer sees.
OOP makes it easy to extend types but hard to extend functions. Functional
programming makes it easy to extend functions but harder to extend types.
Both approaches have relative merits but, when they have the choice,
programmers generally find functional programming more useful than OOP
(objects are rarely used in OCaml and self-contained F#, for example).
F# also adds a variety of other language features like pattern matching,
which is a vastly better way to manipulate trees including XML data. These
benefits are widely appreciated because XSLT provides pattern matching
specifically for XML data, but F#'s pattern matching can be applied to any
data and is arbitrarily extensible.
Picking an exampe at random, the point being, I don't need to look for
"AJAX for C#" - just "AJAX for .NET". I don't care what language the
assembly was written in. The only thing language specific is the code
samples. If F# does things differently, it will have a major
difficulty getting converts.
I must have misled you. F# provides the same seamless interoperability with
existing .NET libraries that C# does. So an AJAX for .NET will work
perfectly with F# just as it does with C#.
The point I was trying to convey is that many applications in parsing, XML,
graphics and so forth stand to benefit enormously from the features
provided by F# but you can only get APIs written using these higher-level
constructs by sitting down and writing the interface yourself.
OK, each CLR compiler might provide a few
small nicities (anonymous methods, a LINQ compiler, late-binding
(VB.NET) etc), but these are just wrappers around framework calls,
that can be used from any CLR language.
Yes.
[JS]> this discussion is a waste of time, I suspect.
Seconded. Sorry Jon (H), but I don't think you're convincing anyone.
If you are genuinely interested in learning about what other paradigms have
to offer and when they are preferable then I can direct you at more
information.
Suffice to say, Microsoft will be inundating everyone here with such
information in the near future.
