Re: Support for optional parameters

> Don't forget, office is the cash
> cow. not c#.

(blinking in astonishment)

Um, C# is a language. I never said it was a "cash cow." It is simply a
programming language, but THE central programming language of the .Net
platform. Microsoft doesn't make ANY money from C#, but they are making some
incredible inroads with the .Net platform. I DID say that the .Net platform
is used for a heck of a lot more than interacting with Office apps. As for
Office being THE cash cow at Microsoft, well, forgive me for restraining my
laughter. Office certainly is A "cash cow" at Microsoft. However, writing
..Net interop with Office certainly is not. And it's not likely to be in the
near future. Remember, the vast majority of Office users never program with
Office. They may create a macro now and then, but they are just users, not
programmers.

> it's good to see that Microsoft frontliners are
> no longer thinking along your lines, they indeed see office as platform
> that
> needs tight integration with the .NET framework.

Again, you're thinking backwards. They see OFFICE as a platform that needs
tight integration with the .Net Framework, NOT the other way round. And for
good reason. In fact, Microsoft is heavily invested in the .Net Framework,
and is steering most of its software fleet in that direction. There are
excellent reasons for this, which are too many to enumerate here in the
short time I have to do this stuff.

> So your 'few' is slightly less than 50% of .NET developers (2
> million from 5 million .NET programmers).

Interesting statistic. I wonder where you got it from? Perhaps there are a
large number of programmers that work with Microsoft Office to a certain
extent. I can guarantee you that the vase majority of those programmers
don't spend the majority of their time doing so.You might want to step away
from the Office marketing hype and take a wide look at the overall Microsoft
strategy. They have far more areas where they want to compete than Office,
and much more of a long-term strategy than is dreamt of in your philosophy,
Horatio.

To know what is, these days, is to know not much. It is far more important
to know what will be. Things are changing very quickly now. In fact,
Microsoft is waging an important battle in the Operating System market share
(Windows is probably THE "cash cow" at Microsoft, if anything), and the .Net
platform is part of that strategy. They are also waging a great battle in
the server software market place, and that is also dependent upon the .Net
platform, and its success or failure. And of course, they are competing with
great gusto in the programming platform and technology marketplace.

> Microsoft has been listening to complaints about C# lack of friendliness
> to
> office programming by the way. I fully expect them to do something in the
> next release once the noise becomes unbearable.
> The success of the VSTO initiative absolutely depends on it.

The success of the VSTO initiative and the success of Office are two
entirely separate things. The success of Office is a long-term goal, and
will depend largely upon many of the changes that are beginning to be made
in the software infrastructure of the Office apps. In a few short years,
there will be no need for Interop assemblies to work with Office
applications, and particularly, with Office documents. So, I wouldn't bet on
Microsoft making any radical changes in the underlying programming
philosophy of the .Net platform to save VSTO. Certainly, they want to get
their investment back on it, and they probably will. But the VSTO that you
see now is not the VSTO that is already in the works, at least on the
drawing board at Microsoft (so my crystal ball tells me). The long-term
success of Office will have little to do with VSTO; it will depend largely
upon the changes that Microsoft is already implementing in Office, and NOT
upon changes made in the .Net Framework to accomdate VSTO. I wish I could
discuss this in more detail, but I do have an NDA to adhere to.

Anyway, that's my story and I'm stickin' to it! ;-)

--
Kevin Spencer
Microsoft MVP
..Net Developer
A watched clock never boils.

"Alvin Bruney - ASP.NET MVP" <www.lulu.com/owc> wrote in message
news:%23TurgLN2FHA.4076@xxxxxxxxxxxxxxxxxxxxxxx
> >Office is not written in .Net.
> I don't recall saying that it was.
>
>> So, you're saying that the C# language specification should be changed to
> Yes, that is what I am saying. The office movement is the biggest wave to
> hit the developer shores in a while. It would be well worth Microsoft's
> invest to cater to the demands of such a movement. If microsoft intends to
> woo VBA developers into managed code development, the effort needs to be
> authentic which means building internal support into the tools used to
> build
> office development. If that means bending or breaking C# language
> specification, then that is what must be done. At the end of the day,
> profitability absolutely depends on it. Don't forget, office is the cash
> cow. not c#.
>
>> Office development is not what the .Net platform
> That is not true at all. .NET platform is for .NET development.
> Currently, office development can be done with .NET. In fact the
> integration
> is built right in with
> VSTO. That type of mentality is what caused .NET to ship without authentic
> internal support for Office technology - read vsto 2003 as a lame effort
> to
> repair the blunder. However, it's good to see that Microsoft frontliners
> are
> no longer thinking along your lines, they indeed see office as platform
> that
> needs tight integration with the .NET framework.
>
>> sure it comes in handy for a few developers out there from time to time.
> It is just more than a few developers. The target is well over 2 million
> developers by conservative estimates and they do it far more than from
> time
> to time. So your 'few' is slightly less than 50% of .NET developers (2
> million from 5 million .NET programmers).
>
> Microsoft has been listening to complaints about C# lack of friendliness
> to
> office programming by the way. I fully expect them to do something in the
> next release once the noise becomes unbearable.
> The success of the VSTO initiative absolutely depends on it.
>
> --
> Regards,
> Alvin Bruney [MVP ASP.NET]
>
> [Shameless Author plug]
> The Microsoft Office Web Components Black Book with .NET
> Now Available @ www.lulu.com/owc
> Forth-coming VSTO.NET - Wrox/Wiley 2006
> -------------------------------------------------------
>
>
>
> "Kevin Spencer" <kevin@xxxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
> news:eqqDByM2FHA.2400@xxxxxxxxxxxxxxxxxxxxxxx
>> Office is not written in .Net. VSTO is a set of Primary Interop
> Assemblies.
>>
>> So, you're saying that the C# language specification should be changed to
>> accomodate the use of a narrowly specialized set of Interop assemblies
>> for
> a
>> set of applications that have loosely-typed COM interfaces?
>>
>> Office development is not what the .Net platform was designed for. Most
> .Net
>> developers never touch it. VSTO is a set of Office extensibility tools.
> I'm
>> sure it comes in handy for a few developers out there from time to time.
>>
>> However, as VBA is the language of Office, it seems more logical to use
>> VB.Net to develop with the VSTO than to use C# and complain that it is
> hard
>> to write wrappers for VSTO with it.
>>
>> --
>> HTH,
>>
>> Kevin Spencer
>> Microsoft MVP
>> .Net Developer
>> A watched clock never boils.
>>
>> "Alvin Bruney - ASP.NET MVP" <www.lulu.com/owc> wrote in message
>> news:eqdOGpM2FHA.2212@xxxxxxxxxxxxxxxxxxxxxxx
>> > The reason for optional parameters is not just a fad or a nice to have
>> > feature. VSTO programming is significantly challenged in C# because of
> the
>> > need to keep entering parameters. Like it or not, that has disuaded
>> > many
>> > C#
>> > developers from going with the technology. I contend that most simply
> have
>> > a
>> > passing interest because of this lack of support.
>> >
>> > VB on the other hand suffers no such set back. For instance, some
>> > method
>> > calls require 30+ parameters where only 1 is required
>> >
>> > VB
>> > ThisApplication.ActiveDocument.Add("filepath.doc) in vb becomes
>> > C#
>> > ThisApplication.ActiveDocument.Add("filepath.doc", Type.Missing ....30
>> > times).
>> >
>> > Microsoft's current approach is to promote the use of C# wrappers
>> > around
>> > these method calls. I think they need to do more to help C# developers
> by
>> > promoting internal support for parameters. I certainly do not
>> > appreciate
>> > spending my development day writing wrappers around methods. What's the
>> > point of pushing VSTO so hard without complete support for it in the
>> > darling
>> > C# language? Seems to me like this wasn't thought all the way thru!
>> >
>> > By the way, there are some of us who simply will not program in VB.
>> > Period!
>> >
>> > We either take the abuse in C# or go back to VBA programming for
>> > developing
>> > office applications. There is more than a majority sharing this opinion
>> > for
>> > sure. And it is an important opinion because it will determine wide
> spread
>> > adoption for technologies based on Office.
>> >
>> > --
>> > Regards,
>> > Alvin Bruney [MVP ASP.NET]
>> >
>> > [Shameless Author plug]
>> > The Microsoft Office Web Components Black Book with .NET
>> > Now Available @ www.lulu.com/owc
>> > Forth-coming VSTO.NET - Wrox/Wiley 2006
>> > -------------------------------------------------------
>> >
>> >
>> >
>> > "Mattias Sjögren" <mattias.dont.want.spam@xxxxxxxx> wrote in message
>> > news:unt7OXL2FHA.3756@xxxxxxxxxxxxxxxxxxxxxxx
>> >> Kevin,
>> >>
>> >> >The reason that C# doesn' t have support for optional paramaters is
> that
>> >> >they don't exist.
>> >>
>> >> Actually the reason given most of the time is that optional parameters
>> >> with default values have versioning problems.
>> >>
>> >> http://blogs.msdn.com/csharpfaq/archive/2004/03/07/85556.aspx
>> >>
>> >> I'll buy that for public methods but still think it would be
>> >> convenient to have support for optionals for internal use.
>> >>
>> >>
>> >> >VB.Net creates the illusion that they do, by creating
>> >> >overloads behind your back.
>> >>
>> >> No it doesn't. The CLI definitely supports real optional parameters.
>> >>
>> >>
>> >> Mattias
>> >>
>> >> --
>> >> Mattias Sjögren [MVP] mattias @ mvps.org
>> >> http://www.msjogren.net/dotnet/ | http://www.dotnetinterop.com
>> >> Please reply only to the newsgroup.
>> >
>> >
>>
>>
>
>


.

Relevant Pages

  • Re: Is VB.NET Stable?? To Aaron Kemp - Ahole Extrordinare
    ... We agree with the dissident Microsoft employees, ... is one of the fastest growing programming languages ... 2)Microsoft has yet to define what it will do about VBA support in the ... 3)Microsoft and developers desperately need a language orthogonal to ...
    (microsoft.public.dotnet.languages.vb)
  • Re: A Programmers proposal for the Delphis roadmap
    ... MS isn't *replacing* Win32 for systems-level programming, ... For Microsoft developers .NET is better. ...
    (borland.public.delphi.non-technical)
  • Re: How to name variables in a program?
    ... It may be because I've seen other Hungarian names such as the violinist ... contributions in Programmers at Work (Susan Lammers 1986: Microsoft ... Many people appoint themselves authorities on programming style. ... Microsoft twice and neither time was an offer made: hint hint hint: at ...
    (comp.programming)
  • Re: Penetration of ASP.NET - Developers continue to use VB6 & ASP
    ... and how Microsoft has lost control of the ... >: preferred API. ... a Windows server but don't require Windows clients, ... people and it's certainly good enough for developers, ...
    (microsoft.public.inetserver.asp.general)
  • Re: Penetration of ASP.NET - Developers continue to use VB6 & ASP
    ... and how Microsoft has lost control of the ... : preferred API. ... a Windows server but don't require Windows clients, ... people and it's certainly good enough for developers, ...
    (microsoft.public.dotnet.framework.aspnet)