[Mono-list] ".NET 3.0" misnomer

[reinux]

>On Fri, 2006-08-11 at 14:05 -0700, reinux wrote:
>> Now the problem is this: if nearly all of .NET 2.0 is portable,

>...which is incorrect...

It is portable enough to be functional - without COM, without WinForms,
without EnterpriseServices. You're missing the point here - if any crucial
changes are made in 3.5 that rely on 3.0, all subsequent versions will no
longer be portable. Also, you've trimmed out a crucial point in my message:
the _whole_ of .NET 3.0 is incompatible.

>To be insanely literal, everything outside of ECMA isn't necessarily
portable, and ECMA doesn't contain much (~250 classes, IIRC).

That is insanely literal. You'd expect the Mono project to be abandoned if
everyone worried about that.

>LINQ is supposed to be a very generic framework.  Generic enough to 
>work
for arbitrary object graphs (IEnumerable), System.Xml, and System.Data.

>I would like to see how they could make LINQ depend on something as
specific as Avalon & Indigo, while still permitting it to be generic enough
to work with what they've said it would work with.  (I seriously doubt that
it could be done in any rational manner.)

LINQ may be safe. However, just having an anomaly in there of such size
raises the risk and the _perception_ of risk enough to scare people away
from the framework altogether. Sure, WinForms and such aren't portable, but
are those areas on which newer technologies will be built, as will
undeniably be the case with WCF and WPF?

>This doesn't mean that other features couldn't be introduced that 
>depend
on the newer WinFX libraries, but even if WinFX isn't termed ".NET 3.0,"
does that really change anything?  Really?

>If they _don't_ call it ".NET 3.0", they'd instead require that your
future applications depend on both ".NET 3.0 w/o WinFX" + WinFX -- i.e.
you'd need two dependencies instead of just one.  And nothing stops them
from making ".NET 3.0 w/o WinFX" from depending on WinFX (as a circular
dependency).

If you've seen Vista's development with trying to build a huge chunk of the
OS on a non-existent API, you'd see that circular dependencies while they
may sometimes be tried, they will be less likely. Think WinFS and its
setbacks before it was abandoned. The reason isn't technical but it's still
simple enough: development schedules and team structures. We aren't talking
about just software here - we're also talking about business.

And yes, most of Microsoft's future software will probably require both
WinFX and .NET. However, that is much better than risking everything
requiring both as well. It'd be ridiculous for people to need to say
"Requires .NET 2.0 Framework but not .NET 3.0" or "Requires .NET 3.5
Framework but not .NET 3.0".

>There are _far_ better things to spend your energy on.  The naming of
WinFX is quite inconsequential, and was done primarily to keep the
dependencies sane for ISVs (only one dependency to install, not two) and
marketing purposes (to kill the "WinFX is going to replace .NET!"
insanity from those who really don't know any better).

Of course. Technically it has no effect for now. I spent all this energy
knowing that it all boils down to marketing, and better marketing is what
I'm arguing for. It's not entirely technical; perceptions can change on the
part of Mono devs and users, and worse, they can also change within
Microsoft itself. Then it'll really become technical.

Thanks for the feedback,

Rei
-- 
View this message in context: http://www.nabble.com/%22.NET-3.0%22-misnomer-tf2092941.html#a5789173
Sent from the Mono - General forum at Nabble.com.