[fpc-pascal] .NET FAQ

[James K Smith]

I sent this once already. Sorry if it duplicated, but I didn't see it
showing up on the list:

JMO:

The last thing we want the FPC team to consider is a port to .NET. Delphi
already does .net, and MSFT C# does it even better. Additionally, porting to
.net invites FPC to become mired in the same mud that Borland has been stuck
in since it decided to allow MSFT to dictate the terms of its market. Lots
of good stuff in .net, but let's face it, our spending our brain cells
developing for .net is better for MSFT than is it for us. I'll be happy to
argue why that's the case.

There is functionality in .net that we all like, but FPC is going in exactly
the right direction, albeit slowly without the commercial help that I wish
the team would consider. The direction is the right one
because it's serving a growing need represented by how the internet is
evolving into it's own platform and devaluing the OS. So what's the
presentation engine for this new platform? The browser. A great example of
what can be done with a browser user interface is Morfik. Guess what one of
the compiler targets is for Morfik applications. Morfik has a way to go, but
their effort is looking much better than it did even several months ago.

What's the other part of this equation? The server side. As the internet
becomes a platform in its on right, endpoints could care less about what the
server OS is, as long as it efficiently provides services. That means we
developers should become platform agnostic, and mono is **not** the solution
for this. FPC is, and as computing power becomes more centralized, quality,
scalability and efficiency will be even more valued. Hopefully FPC will
evolve into a tool that will help us to address these issues so that we can
build optimized server software, regardless of OS. Again, some judicous
commercialization would help FPC in this regard.

So instead of supporting .net, I'd like to see FPC evolve into a language
that has a personality that is radically different from anything MSFT is
developing (and unfortunately by extension, Delphi). Imagine a FPC that
supports Design by Contract, or  has a Ravenscar profile. I'm convinced that
future development will demand this sort of programmable quality assurance,
so it would be another sales advantage for developers and companies using
FPC. Whatever the example, the point is to be willing to put good ideas into
code without letting MSFT decide what those good ideas will be.

James