Leon_Amirreza said:
In a very brief I can say that:
1- .Net has proved its productivity and many want to go for it
Well, in some areas, yes it is undoubtedly much improved in what was there
before. For instance, I'm told by friends that it provides a vastly improved
toolset for web programming. That's not kind of programming I get involved
with myself, so I rely on others for news from that area.
2- ported to many platforms
Windows and um, Windows. Last I heard, the Unix and Mac ports aren't stable
enough for serious use yet. I'm not holding my breath.
3- proved its technological aspect and correct engineering used to biuld
it
so why they dont go for it? i think roll out cost
would they start to roll out in near future? i think yes in near future (3
to 5 years later i think)
would have MS something to offer? I hope so build by (in my opinion) add
some functionality to .net to be able to replace VBA i think .Net
technologies have the capacity to add some interpreted features (look at
the IL nature, reflection and ... in the .net)
The problem is incompatibility with existing code, and following on from
that, trust.
The fact is that VB.NET is sufficiently incompatible with the previous
version of VB (VB6, from which VBA is derived) that for all practical
purposes an upgrade wasn't possible, you had to rewrite the code more or
less from scratch. The automated code converters provided by Microsoft were
next to useless, and the fact that Microsoft went and changed lots of names
of objects and properties meant that late-binding code wouldn't work without
rewrite because it couldn't be automatically converted at all.
To take a very simple example, in a VB6 Form, a Label object had a Caption
property. The equivalent property in Windows Forms is called Text. In VB6
there was a naming convention regarding such things. If the visible text of
the control was editable by the user, then the property was called Text. If
it was not editable, it was called Caption. In Winforms, for any text
displayed on a control, the property is called Text irrespective of whether
it is editable or not.
Both are perfectly good naming conventions. If the language was being made
from scratch, you might decide the second one was better than the first.
However, VB.NET was supposedly not being made from scratch, it was supposed
to be an upgrade to VB6. That being the case, there needs to be a much
better reason than "I like the new naming convention better" to make a
change that breaks existing code. Lots of people asked Microsoft what that
reason was, with regard to that and dozens of other changes to the language.
In the vast majority of cases, there was no technically plausible reply from
Microsoft. I was involved in a lot of these discussions and concluded that
of all the changes they made between VB6 and VB.NET, only about 3 had a
valid technical reason based on the design of the framework. From memory
they were:
1, Changing the manner & timing of object destruction, from the ActiveX
method of "deterministic finalization" to "garbage collection". This
wouldn't have affected many projects, but those it did affect would have
needed some serious rewrite.
2. Loss of parameterless default properties
3. Loss of mixed scope for properties (mixed scope was restored in a
subsequent update, but by then they had completely changed the syntax of
property declarations)
There were upwards of a hundred changes of syntax, naming or behavior of
existing VB6 functions. (I'm not counting the new features added, they don't
affect the ability to port existing projects). Each one of these changes
increased the amount of effort necessary to port a VB6 project to VB.NET.
Collectively, they made porting any significant project entirely
impractical. The sad thing is that had Microsoft strived to keep VB.NET as
close as practicable to 100% compatibility with VB6, say 99% compatible,
(i.e. on average only 1 line of code in every hundred having to be
modified), which was perfectly achievable, then we could by now *already*
have had a VBA.NET integrated into Office and making full use of the
framework.
As far as I can tell, the people at Microsoft responsible for this couldn't
distinguish between a language and the platform it compiles to, and
therefore a change in platform justified changes to "clean up" the language,
even where the language changes were not necessitated by the platform
change. I have discussed this with the people responsible, I'm working on
that basis of what they have told me directly.
This brings me to the other issue - trust. If Microsoft has done this once,
and caused immense cost and inconvenience to the very many companies who had
developed VB6 applications, and has neither apologised, attempted to set
things right, nor even quite understood the effect of its actions, what is
to stop them doing it again?
Eventually the .NET platform will become too patched to be usable as a base
for further development and will have to be replaced, just as the old VB
runtime was. When that happens, unless the people in Microsoft have learned
from their mistakes, the .NET languages may be in for another major round of
changes, meaning that *your* code cannot be ported to the post-.NET world
without you rewriting it. And don't think that the Microsoft submitting C#
as a spec to ECMA is any kind of protection. The mere existence of a
standard does not create a legal obligation to continue producing compliant
compilers. They can change the de facto spec any time they want.
Do you want your code to have to be completely rewritten next time Microsoft
replaces its platform? Or having seen it happen once before to others, might
you decide that you are safer moving at your leisure towards a non-Microsoft
product?
Now, if that choice has to be made by a business deciding on an Office
upgrade, Microsoft doesn't just lose the price of a few Visual Studio
licenses. They stand to lose a large number (perhaps several throusand)
sales of Office upgrade licenses as well. If a very large number of
companies end up making similar decisions, then we are talking about some
serious quantities of money missing from Microsoft's sales projections.
While Microsoft as a company could probably recover from the financial
consequences of a mistake of that magnitude, I don't think the careers of
the executives responsible for the decision would be as resilient!
That is why three versions of Office have been developed and launched since
..NET was first introduced, and VBA is in every one of them, and Microsoft
have indicated that this state of affairs is not going to change anytime
soon. Effectively, the people in charge of Office have looked at the likely
consequences of doing the same as what the Visual Studio people have done,
and have decided they don't like what they see.
