"Fresh Air Rider" <Fresh_Air_Ri***@Hotmail.com> wrote in message
news:556722cb.0501010857.1eb38850@posting.google.com...
> Hi Everyone
>
> I have just been getting up to speed on the forthcoming ASP.Net 2.0
> (Whidbey) that Microsoft is releasing some time this year.
>
> It all looks great but I was a bit concerned that it aims to reduce
> the amount of code that needs to be written by the developer by 70%.
>
> The new GridView control will be "far simpler to use, requires less
> code, and provides far more power than the DataGrid Control".
>
> After working extremely hard to get my Computer Science degree and
> investing my own hard earnt money heavily in MSDN subscriptions and
> programming books etc just to keep my skills up to date, I began to
> wonder if it had all been worthwhile now that the forthcoming ASP.Net
> 2.0 (Whidbey) seems to be abstracting much of the techniques that I
> had learnt to "hand code".
>
> For instance, I was particularly pleased with my implementation of
> Roles Based Forms Authentication that I had mastered in C# but now I
> understand that it will all be wasted now that this functionality will
> be covered by the new Membership classes.
>
> I fully understand that by definition, IT is a constantly evolving
> industry but it does make me worry that the very systems that we use
> to improve business efficiency could one day make the role of the
> qualified developer redundant.
>
> The way things are going, the office junior will be able to do all the
> stuff that the highly qualified and trained developer once did and the
> developers will be ignored because the higher wages that they rightly
> attract will no longer be justified.
>
> Maybe this is what Microsoft are working towards or maybe I'm just a
> Luddite.
>
> Please accept my appologies for the cross-posting but it's just
> something that I feel very stongly about and is of equal importance to
> each group.

"Scott M." wrote:

> I think to some degree your concerns are justified, but remember that there
> will always be a need to customize out of the box solutions.  This is where
> and why there will always be a need for developers.
>
>
> "Fresh Air Rider" <Fresh_Air_Ri***@Hotmail.com> wrote in message
> news:556722cb.0501010857.1eb38850@posting.google.com...
> > Hi Everyone
> >
> > I have just been getting up to speed on the forthcoming ASP.Net 2.0
> > (Whidbey) that Microsoft is releasing some time this year.
> >
> > It all looks great but I was a bit concerned that it aims to reduce
> > the amount of code that needs to be written by the developer by 70%.
> >
> > The new GridView control will be "far simpler to use, requires less
> > code, and provides far more power than the DataGrid Control".
> >
> > After working extremely hard to get my Computer Science degree and
> > investing my own hard earnt money heavily in MSDN subscriptions and
> > programming books etc just to keep my skills up to date, I began to
> > wonder if it had all been worthwhile now that the forthcoming ASP.Net
> > 2.0 (Whidbey) seems to be abstracting much of the techniques that I
> > had learnt to "hand code".
> >
> > For instance, I was particularly pleased with my implementation of
> > Roles Based Forms Authentication that I had mastered in C# but now I
> > understand that it will all be wasted now that this functionality will
> > be covered by the new Membership classes.
> >
> > I fully understand that by definition, IT is a constantly evolving
> > industry but it does make me worry that the very systems that we use
> > to improve business efficiency could one day make the role of the
> > qualified developer redundant.
> >
> > The way things are going, the office junior will be able to do all the
> > stuff that the highly qualified and trained developer once did and the
> > developers will be ignored because the higher wages that they rightly
> > attract will no longer be justified.
> >
> > Maybe this is what Microsoft are working towards or maybe I'm just a
> > Luddite.
> >
> > Please accept my appologies for the cross-posting but it's just
> > something that I feel very stongly about and is of equal importance to
> > each group.
>
>
>

"Cowboy (Gregory A. Beamer) - MVP" <NoSpamMgbworld@comcast.netNoSpamM> wrote
in message news:08570F25-756D-41F9-9BA3-45FB4FDEC3ED@microsoft.com...
>I would both agree and disagree. Look at what the tool is going to do and
> make sure you can fill in the gaps it does not and you have nothing to
> fear.
> The key is looking at development as a career and not a job.
>
> The average coder learns only what is necessary to survive. Many of them
> will drown when Visual Studio 2005 comes out, as they will be replaceable.
>
> I fix code from people who drag and drop fairly regularly. When you make a
> tool any idiot can use, some of the people using the tool will be idiots.
> Others will be ignorant, most likely from time constraints or laziness.
>
> But, I can guarantee you that a lot of people will royally screw up .NET
> 2.0
> applications and people who can fix it will always be in demand.
>
> In addition, it is hard to build a box big enough to hold everyone's
> desires. Microsoft, quite intelligently I might add, tries to use the
> 80-20
> rule (or 70-30 rule in this case) to solve the majority of problems with
> declarative means rather than programatic means. This leaves the problems
> outside of the 20% available for the rest of us to solve. If you knowledge
> base sits strictly in the 80%, you will likely take a salary cut or lose
> your
> job altogether.
>
> I have been through all sorts of "emergencies". 9/11 slammed IT in
> Nashville. I have friends who spent months without a job. In the same
> time, I
> have had to make some minor salary concessions, but the market has,
> overall,
> been very good to me. Why? I am not content to sit on laurels. I spend a
> lot
> of time investing in my career learning new technologies. Result: I have
> been
> unemployed for about a week and a half (total) in the past 3+ years.
>
> Lesson to learn: If you fear the tools are going to replace you, learn
> something the tool cannot automagically do.
> ---
>
> Gregory A. Beamer
> MVP; MCP: +I, SE, SD, DBA
>
> ***************************
> Think Outside the Box!
> ***************************
>
> "Scott M." wrote:
>
>> I think to some degree your concerns are justified, but remember that
>> there
>> will always be a need to customize out of the box solutions.  This is
>> where
>> and why there will always be a need for developers.
>>
>>
>> "Fresh Air Rider" <Fresh_Air_Ri***@Hotmail.com> wrote in message
>> news:556722cb.0501010857.1eb38850@posting.google.com...
>> > Hi Everyone
>> >
>> > I have just been getting up to speed on the forthcoming ASP.Net 2.0
>> > (Whidbey) that Microsoft is releasing some time this year.
>> >
>> > It all looks great but I was a bit concerned that it aims to reduce
>> > the amount of code that needs to be written by the developer by 70%.
>> >
>> > The new GridView control will be "far simpler to use, requires less
>> > code, and provides far more power than the DataGrid Control".
>> >
>> > After working extremely hard to get my Computer Science degree and
>> > investing my own hard earnt money heavily in MSDN subscriptions and
>> > programming books etc just to keep my skills up to date, I began to
>> > wonder if it had all been worthwhile now that the forthcoming ASP.Net
>> > 2.0 (Whidbey) seems to be abstracting much of the techniques that I
>> > had learnt to "hand code".
>> >
>> > For instance, I was particularly pleased with my implementation of
>> > Roles Based Forms Authentication that I had mastered in C# but now I
>> > understand that it will all be wasted now that this functionality will
>> > be covered by the new Membership classes.
>> >
>> > I fully understand that by definition, IT is a constantly evolving
>> > industry but it does make me worry that the very systems that we use
>> > to improve business efficiency could one day make the role of the
>> > qualified developer redundant.
>> >
>> > The way things are going, the office junior will be able to do all the
>> > stuff that the highly qualified and trained developer once did and the
>> > developers will be ignored because the higher wages that they rightly
>> > attract will no longer be justified.
>> >
>> > Maybe this is what Microsoft are working towards or maybe I'm just a
>> > Luddite.
>> >
>> > Please accept my appologies for the cross-posting but it's just
>> > something that I feel very stongly about and is of equal importance to
>> > each group.
>>
>>
>>

"Scott M." wrote:

> And also remember that while MS's drag and drop solutions may work, they
> tend to write bloated code.  Many developers find it easier, in the end,
> just writing the functionality from scratch.  Myself, I sometimes use the
> drag and drop as a starting point and then go back and customize it (and
> take lots of it out).
>
> "Cowboy (Gregory A. Beamer) - MVP" <NoSpamMgbworld@comcast.netNoSpamM> wrote
> in message news:08570F25-756D-41F9-9BA3-45FB4FDEC3ED@microsoft.com...
> >I would both agree and disagree. Look at what the tool is going to do and
> > make sure you can fill in the gaps it does not and you have nothing to
> > fear.
> > The key is looking at development as a career and not a job.
> >
> > The average coder learns only what is necessary to survive. Many of them
> > will drown when Visual Studio 2005 comes out, as they will be replaceable.
> >
> > I fix code from people who drag and drop fairly regularly. When you make a
> > tool any idiot can use, some of the people using the tool will be idiots.
> > Others will be ignorant, most likely from time constraints or laziness.
> >
> > But, I can guarantee you that a lot of people will royally screw up .NET
> > 2.0
> > applications and people who can fix it will always be in demand.
> >
> > In addition, it is hard to build a box big enough to hold everyone's
> > desires. Microsoft, quite intelligently I might add, tries to use the
> > 80-20
> > rule (or 70-30 rule in this case) to solve the majority of problems with
> > declarative means rather than programatic means. This leaves the problems
> > outside of the 20% available for the rest of us to solve. If you knowledge
> > base sits strictly in the 80%, you will likely take a salary cut or lose
> > your
> > job altogether.
> >
> > I have been through all sorts of "emergencies". 9/11 slammed IT in
> > Nashville. I have friends who spent months without a job. In the same
> > time, I
> > have had to make some minor salary concessions, but the market has,
> > overall,
> > been very good to me. Why? I am not content to sit on laurels. I spend a
> > lot
> > of time investing in my career learning new technologies. Result: I have
> > been
> > unemployed for about a week and a half (total) in the past 3+ years.
> >
> > Lesson to learn: If you fear the tools are going to replace you, learn
> > something the tool cannot automagically do.
> > ---
> >
> > Gregory A. Beamer
> > MVP; MCP: +I, SE, SD, DBA
> >
> > ***************************
> > Think Outside the Box!
> > ***************************
> >
> > "Scott M." wrote:
> >
> >> I think to some degree your concerns are justified, but remember that
> >> there
> >> will always be a need to customize out of the box solutions.  This is
> >> where
> >> and why there will always be a need for developers.
> >>
> >>
> >> "Fresh Air Rider" <Fresh_Air_Ri***@Hotmail.com> wrote in message
> >> news:556722cb.0501010857.1eb38850@posting.google.com...
> >> > Hi Everyone
> >> >
> >> > I have just been getting up to speed on the forthcoming ASP.Net 2.0
> >> > (Whidbey) that Microsoft is releasing some time this year.
> >> >
> >> > It all looks great but I was a bit concerned that it aims to reduce
> >> > the amount of code that needs to be written by the developer by 70%.
> >> >
> >> > The new GridView control will be "far simpler to use, requires less
> >> > code, and provides far more power than the DataGrid Control".
> >> >
> >> > After working extremely hard to get my Computer Science degree and
> >> > investing my own hard earnt money heavily in MSDN subscriptions and
> >> > programming books etc just to keep my skills up to date, I began to
> >> > wonder if it had all been worthwhile now that the forthcoming ASP.Net
> >> > 2.0 (Whidbey) seems to be abstracting much of the techniques that I
> >> > had learnt to "hand code".
> >> >
> >> > For instance, I was particularly pleased with my implementation of
> >> > Roles Based Forms Authentication that I had mastered in C# but now I
> >> > understand that it will all be wasted now that this functionality will
> >> > be covered by the new Membership classes.
> >> >
> >> > I fully understand that by definition, IT is a constantly evolving
> >> > industry but it does make me worry that the very systems that we use
> >> > to improve business efficiency could one day make the role of the
> >> > qualified developer redundant.
> >> >
> >> > The way things are going, the office junior will be able to do all the
> >> > stuff that the highly qualified and trained developer once did and the
> >> > developers will be ignored because the higher wages that they rightly
> >> > attract will no longer be justified.
> >> >
> >> > Maybe this is what Microsoft are working towards or maybe I'm just a
> >> > Luddite.
> >> >
> >> > Please accept my appologies for the cross-posting but it's just
> >> > something that I feel very stongly about and is of equal importance to
> >> > each group.
> >>
> >>
> >>
>
>
>

> I have just been getting up to speed on the forthcoming ASP.Net 2.0
> (Whidbey) that Microsoft is releasing some time this year.
>
> It all looks great but I was a bit concerned that it aims to reduce
> the amount of code that needs to be written by the developer by 70%.
>
> The new GridView control will be "far simpler to use, requires less
> code, and provides far more power than the DataGrid Control".
>
> After working extremely hard to get my Computer Science degree and
> investing my own hard earnt money heavily in MSDN subscriptions and
> programming books etc just to keep my skills up to date, I began to
> wonder if it had all been worthwhile now that the forthcoming ASP.Net
> 2.0 (Whidbey) seems to be abstracting much of the techniques that I
> had learnt to "hand code".

"Frans Bouma [C# MVP]" <perseus.usenetNOSPAM@xs4all.nl> wrote in message
news:uCO%23c2C8EHA.3076@TK2MSFTNGP15.phx.gbl...
> Fresh Air Rider wrote:
>> I have just been getting up to speed on the forthcoming ASP.Net 2.0
>> (Whidbey) that Microsoft is releasing some time this year.
>>
>> It all looks great but I was a bit concerned that it aims to reduce
>> the amount of code that needs to be written by the developer by 70%.
>>
>> The new GridView control will be "far simpler to use, requires less
>> code, and provides far more power than the DataGrid Control".
>>
>> After working extremely hard to get my Computer Science degree and
>> investing my own hard earnt money heavily in MSDN subscriptions and
>> programming books etc just to keep my skills up to date, I began to
>> wonder if it had all been worthwhile now that the forthcoming ASP.Net
>> 2.0 (Whidbey) seems to be abstracting much of the techniques that I
>> had learnt to "hand code".
>
> Programming is not 'typing code' but working out algorithms and create
> programs which represent these algorithms in executable form. How that is
> done, is up to the tools you use. So this will not change, the tools you
> use will change, over time.
>
> Do not feel offended, but I don't think you need a CS degree to write
> ASP.NET gui's as it's fairly straightforward once you know the tricks and
> pitfalls.
>
> What is way more important is the layer stack right below the GUI: the BL
> layer and the BL facade layer (or gui facade, depending on which way you
> look at it). The vast majority of your application's code is in there, or
> better: the vast majority of interesting code is in there.
>
>> For instance, I was particularly pleased with my implementation of
>> Roles Based Forms Authentication that I had mastered in C# but now I
>> understand that it will all be wasted now that this functionality will
>> be covered by the new Membership classes.
>
> As with everything MS gives out: the more it is detailed and towards 'end
> user stuff' (i.e. the farther you get away from a 'framework'), the more
> the following rule is applicable: "The Microsoft Way or Your Own Way".
> Often there are situations in which the MS provided controls don't work
> very well and you need own code or customize the provided controls.
>
> Don't be fooled by the slick demos with drag-n-drop 'RAD' 'programming':
> professional software is often written in total different ways than the
> demos show you. This is for a reason: demos are meant to sell stuff, not
> to teach you best practises.
>
>> I fully understand that by definition, IT is a constantly evolving
>> industry but it does make me worry that the very systems that we use
>> to improve business efficiency could one day make the role of the
>> qualified developer redundant.
>
> this will never be the case. Programming is not related to typing, but to
> thinking.
>
>> The way things are going, the office junior will be able to do all the
>> stuff that the highly qualified and trained developer once did and the
>> developers will be ignored because the higher wages that they rightly
>> attract will no longer be justified.
>
> no, the office monkey will do the dull gui-stuff while you will be doing
> business logic components and the controller layers below the GUI, which
> are not created by drag-n-drop clicketyclick.
>
> Frans.
>
> --
> ------------------------------------------------------------------------
> Get LLBLGen Pro, productive O/R mapping for .NET: http://www.llblgen.com
> My .NET blog: http://weblogs.asp.net/fbouma
> Microsoft MVP (C#)
> ------------------------------------------------------------------------

"Scott M." <s-mar@nospam.nospam> wrote in message
news:e9bvzGD8EHA.3012@TK2MSFTNGP09.phx.gbl...
> Just a quick comment:
>
> You mention several times that the business logic is where the work gets
> done and that there is no RAD clickety-click for that code.  I think what
> you missed from the OP was that in Whidbey, there IS RAD for the business
> and data layers.  In Whidbey, the RAD and drag & drop is greatly improved
> for the backend of an application as well as the front.
>
>
>
>
> "Frans Bouma [C# MVP]" <perseus.usenetNOSPAM@xs4all.nl> wrote in message
> news:uCO%23c2C8EHA.3076@TK2MSFTNGP15.phx.gbl...
> > Fresh Air Rider wrote:
> >> I have just been getting up to speed on the forthcoming ASP.Net 2.0
> >> (Whidbey) that Microsoft is releasing some time this year.
> >>
> >> It all looks great but I was a bit concerned that it aims to reduce
> >> the amount of code that needs to be written by the developer by 70%.
> >>
> >> The new GridView control will be "far simpler to use, requires less
> >> code, and provides far more power than the DataGrid Control".
> >>
> >> After working extremely hard to get my Computer Science degree and
> >> investing my own hard earnt money heavily in MSDN subscriptions and
> >> programming books etc just to keep my skills up to date, I began to
> >> wonder if it had all been worthwhile now that the forthcoming ASP.Net
> >> 2.0 (Whidbey) seems to be abstracting much of the techniques that I
> >> had learnt to "hand code".
> >
> > Programming is not 'typing code' but working out algorithms and create
> > programs which represent these algorithms in executable form. How that
is
> > done, is up to the tools you use. So this will not change, the tools you
> > use will change, over time.
> >
> > Do not feel offended, but I don't think you need a CS degree to write
> > ASP.NET gui's as it's fairly straightforward once you know the tricks
and
> > pitfalls.
> >
> > What is way more important is the layer stack right below the GUI: the
BL
> > layer and the BL facade layer (or gui facade, depending on which way you
> > look at it). The vast majority of your application's code is in there,
or
> > better: the vast majority of interesting code is in there.
> >
> >> For instance, I was particularly pleased with my implementation of
> >> Roles Based Forms Authentication that I had mastered in C# but now I
> >> understand that it will all be wasted now that this functionality will
> >> be covered by the new Membership classes.
> >
> > As with everything MS gives out: the more it is detailed and towards
'end
> > user stuff' (i.e. the farther you get away from a 'framework'), the more
> > the following rule is applicable: "The Microsoft Way or Your Own Way".
> > Often there are situations in which the MS provided controls don't work
> > very well and you need own code or customize the provided controls.
> >
> > Don't be fooled by the slick demos with drag-n-drop 'RAD' 'programming':
> > professional software is often written in total different ways than the
> > demos show you. This is for a reason: demos are meant to sell stuff, not
> > to teach you best practises.
> >
> >> I fully understand that by definition, IT is a constantly evolving
> >> industry but it does make me worry that the very systems that we use
> >> to improve business efficiency could one day make the role of the
> >> qualified developer redundant.
> >
> > this will never be the case. Programming is not related to typing, but
to
> > thinking.
> >
> >> The way things are going, the office junior will be able to do all the
> >> stuff that the highly qualified and trained developer once did and the
> >> developers will be ignored because the higher wages that they rightly
> >> attract will no longer be justified.
> >
> > no, the office monkey will do the dull gui-stuff while you will be doing
> > business logic components and the controller layers below the GUI, which
> > are not created by drag-n-drop clicketyclick.
> >
> > Frans.
> >
> > --
> > ------------------------------------------------------------------------
> > Get LLBLGen Pro, productive O/R mapping for .NET: http://www.llblgen.com
> > My .NET blog: http://weblogs.asp.net/fbouma
> > Microsoft MVP (C#)
> > ------------------------------------------------------------------------
>
>

"W.G. Ryan eMVP" <WilliamRyan@NoSpam.gmail.com> wrote in message
news:eWxsJSD8EHA.1300@TK2MSFTNGP14.phx.gbl...
> Scott:
>
> I respectfully disagree.  I love Whidbey - I'm heavily involved in the
> beta
> and think it's going to be the coolest thing since sliced bread.  However
> it
> simply can not build business and data layers without a programmer or
> someone putting thought into it and building it correctly.
>
> Anyone can make an Object - but building solid and powerful classes takes
> knowledge and understanding -and experience garnered from making mistakes.
>
> How is Whidbey going to make for instance, a Data Access layer that's
> remotable - know what channel to send things through based on my network
> topology and whether or not I should use Client or Server activated
> objects?
> What if my business objects need send everything via messages instead of
> to
> a database all of a sudden?
>
> Sure, whidbey and VS.nET make things like this pretty straightforward -
> but
> it still entails thought on someone's part and someone needs to make those
> decisions and implement them.
>
> The best analogy I can come up with is this:  Look at TurboTax or whatever
> other tax software you want.  It has functionality to handle virtually the
> entire US Tax code.  My neighbor is a tax attorney and I think he's
> pulling
> about $150.00 hour doing primarily individual and small business accounts
> which could  - be done with TurboTax. Are there just that many naive
> people
> out there that are willing to pay him $150.00/hr for stuff that a 30.00
> software package can do?  No.  And we both know that there are thousands
> of
> CPA and tax accountants making much more than $30.00 flat fee to handle
> tax
> stuff that could be done by a software package.  Why?  Because even though
> that software is great - many prefer humans for a whole host of reasons -
> but the most important ones is that those professionals know the tax code
> and it's interpretations and many cases aren't black and white.
>
> The demand for tax professionals is so much greater than the supply in
> most
> places that the advent of Turbo Tax doesn't hurt them one bit.  Not one -
> it
> actually helps them b/c they can also use software to speed up the simple
> stuff so they can concentrate on the more complex issues.
>
> So it goes with Software developers and Whidbey.
>
> Whidbey is my friend - it will make my life easier and allow me to do
> things
> quicker and easier - but there's plenty of demand for new stuff  and it
> won't take anything away from us.
>
> --
> W.G. Ryan MVP (Windows Embedded)
>
> TiBA Solutions
> www.tibasolutions.com | www.devbuzz.com | www.knowdotnet.com
> "Scott M." <s-mar@nospam.nospam> wrote in message
> news:e9bvzGD8EHA.3012@TK2MSFTNGP09.phx.gbl...
>> Just a quick comment:
>>
>> You mention several times that the business logic is where the work gets
>> done and that there is no RAD clickety-click for that code.  I think what
>> you missed from the OP was that in Whidbey, there IS RAD for the business
>> and data layers.  In Whidbey, the RAD and drag & drop is greatly improved
>> for the backend of an application as well as the front.
>>
>>
>>
>>
>> "Frans Bouma [C# MVP]" <perseus.usenetNOSPAM@xs4all.nl> wrote in message
>> news:uCO%23c2C8EHA.3076@TK2MSFTNGP15.phx.gbl...
>> > Fresh Air Rider wrote:
>> >> I have just been getting up to speed on the forthcoming ASP.Net 2.0
>> >> (Whidbey) that Microsoft is releasing some time this year.
>> >>
>> >> It all looks great but I was a bit concerned that it aims to reduce
>> >> the amount of code that needs to be written by the developer by 70%.
>> >>
>> >> The new GridView control will be "far simpler to use, requires less
>> >> code, and provides far more power than the DataGrid Control".
>> >>
>> >> After working extremely hard to get my Computer Science degree and
>> >> investing my own hard earnt money heavily in MSDN subscriptions and
>> >> programming books etc just to keep my skills up to date, I began to
>> >> wonder if it had all been worthwhile now that the forthcoming ASP.Net
>> >> 2.0 (Whidbey) seems to be abstracting much of the techniques that I
>> >> had learnt to "hand code".
>> >
>> > Programming is not 'typing code' but working out algorithms and create
>> > programs which represent these algorithms in executable form. How that
> is
>> > done, is up to the tools you use. So this will not change, the tools
>> > you
>> > use will change, over time.
>> >
>> > Do not feel offended, but I don't think you need a CS degree to write
>> > ASP.NET gui's as it's fairly straightforward once you know the tricks
> and
>> > pitfalls.
>> >
>> > What is way more important is the layer stack right below the GUI: the
> BL
>> > layer and the BL facade layer (or gui facade, depending on which way
>> > you
>> > look at it). The vast majority of your application's code is in there,
> or
>> > better: the vast majority of interesting code is in there.
>> >
>> >> For instance, I was particularly pleased with my implementation of
>> >> Roles Based Forms Authentication that I had mastered in C# but now I
>> >> understand that it will all be wasted now that this functionality will
>> >> be covered by the new Membership classes.
>> >
>> > As with everything MS gives out: the more it is detailed and towards
> 'end
>> > user stuff' (i.e. the farther you get away from a 'framework'), the
>> > more
>> > the following rule is applicable: "The Microsoft Way or Your Own Way".
>> > Often there are situations in which the MS provided controls don't work
>> > very well and you need own code or customize the provided controls.
>> >
>> > Don't be fooled by the slick demos with drag-n-drop 'RAD'
>> > 'programming':
>> > professional software is often written in total different ways than the
>> > demos show you. This is for a reason: demos are meant to sell stuff,
>> > not
>> > to teach you best practises.
>> >
>> >> I fully understand that by definition, IT is a constantly evolving
>> >> industry but it does make me worry that the very systems that we use
>> >> to improve business efficiency could one day make the role of the
>> >> qualified developer redundant.
>> >
>> > this will never be the case. Programming is not related to typing, but
> to
>> > thinking.
>> >
>> >> The way things are going, the office junior will be able to do all the
>> >> stuff that the highly qualified and trained developer once did and the
>> >> developers will be ignored because the higher wages that they rightly
>> >> attract will no longer be justified.
>> >
>> > no, the office monkey will do the dull gui-stuff while you will be
>> > doing
>> > business logic components and the controller layers below the GUI,
>> > which
>> > are not created by drag-n-drop clicketyclick.
>> >
>> > Frans.
>> >
>> > --
>> > ------------------------------------------------------------------------
>> > Get LLBLGen Pro, productive O/R mapping for .NET:
>> > http://www.llblgen.com
>> > My .NET blog: http://weblogs.asp.net/fbouma
>> > Microsoft MVP (C#)
>> > ------------------------------------------------------------------------
>>
>>
>
>

>
>
>
>
> "Frans Bouma [C# MVP]" <perseus.usenetNOSPAM@xs4all.nl> wrote in message
> news:uCO%23c2C8EHA.3076@TK2MSFTNGP15.phx.gbl...
>
>>Fresh Air Rider wrote:
>>
>>>I have just been getting up to speed on the forthcoming ASP.Net 2.0
>>>(Whidbey) that Microsoft is releasing some time this year.
>>>
>>>It all looks great but I was a bit concerned that it aims to reduce
>>>the amount of code that needs to be written by the developer by 70%.
>>>
>>>The new GridView control will be "far simpler to use, requires less
>>>code, and provides far more power than the DataGrid Control".
>>>
>>>After working extremely hard to get my Computer Science degree and
>>>investing my own hard earnt money heavily in MSDN subscriptions and
>>>programming books etc just to keep my skills up to date, I began to
>>>wonder if it had all been worthwhile now that the forthcoming ASP.Net
>>>2.0 (Whidbey) seems to be abstracting much of the techniques that I
>>>had learnt to "hand code".
>>
>>Programming is not 'typing code' but working out algorithms and create
>>programs which represent these algorithms in executable form. How that is
>>done, is up to the tools you use. So this will not change, the tools you
>>use will change, over time.
>>
>>Do not feel offended, but I don't think you need a CS degree to write
>>ASP.NET gui's as it's fairly straightforward once you know the tricks and
>>pitfalls.
>>
>>What is way more important is the layer stack right below the GUI: the BL
>>layer and the BL facade layer (or gui facade, depending on which way you
>>look at it). The vast majority of your application's code is in there, or
>>better: the vast majority of interesting code is in there.
>>
>>
>>>For instance, I was particularly pleased with my implementation of
>>>Roles Based Forms Authentication that I had mastered in C# but now I
>>>understand that it will all be wasted now that this functionality will
>>>be covered by the new Membership classes.
>>
>>As with everything MS gives out: the more it is detailed and towards 'end
>>user stuff' (i.e. the farther you get away from a 'framework'), the more
>>the following rule is applicable: "The Microsoft Way or Your Own Way".
>>Often there are situations in which the MS provided controls don't work
>>very well and you need own code or customize the provided controls.
>>
>>Don't be fooled by the slick demos with drag-n-drop 'RAD' 'programming':
>>professional software is often written in total different ways than the
>>demos show you. This is for a reason: demos are meant to sell stuff, not
>>to teach you best practises.
>>
>>
>>>I fully understand that by definition, IT is a constantly evolving
>>>industry but it does make me worry that the very systems that we use
>>>to improve business efficiency could one day make the role of the
>>>qualified developer redundant.
>>
>>this will never be the case. Programming is not related to typing, but to
>>thinking.
>>
>>
>>>The way things are going, the office junior will be able to do all the
>>>stuff that the highly qualified and trained developer once did and the
>>>developers will be ignored because the higher wages that they rightly
>>>attract will no longer be justified.
>>
>>no, the office monkey will do the dull gui-stuff while you will be doing
>>business logic components and the controller layers below the GUI, which
>>are not created by drag-n-drop clicketyclick.
>>
>>Frans.
>>
>>--
>>------------------------------------------------------------------------
>>Get LLBLGen Pro, productive O/R mapping for .NET: http://www.llblgen.com
>>My .NET blog: http://weblogs.asp.net/fbouma
>>Microsoft MVP (C#)
>>------------------------------------------------------------------------
>
>
>

"Frans Bouma [C# MVP]" <perseus.usenetNOSPAM@xs4all.nl> wrote in message
news:uURSQbD8EHA.2568@TK2MSFTNGP11.phx.gbl...
> Scott M. wrote:
>> Just a quick comment:
>>
>> You mention several times that the business logic is where the work gets
>> done and that there is no RAD clickety-click for that code.  I think what
>> you missed from the OP was that in Whidbey, there IS RAD for the business
>> and data layers.  In Whidbey, the RAD and drag & drop is greatly improved
>> for the backend of an application as well as the front.
>
> If you think that RAD and drag-n-drop will give you a business logic layer
> which can manage for example this action:
> - new customer purchases 10 products P.
> -> you need to add the new customer
> -> you need to manage inventory
> -> you need to add the order
>
> and perhaps some other things along the lines, you didn't get the point.
> Say the actions have to be controlled, by a transaction, perhaps a COM+
> transaction because the orders database is a SAP system.
>
> A rad tool can do that? No way. Dragging some classes together in a
> designer perhaps looks like developing these kind of components but it
> isn't.
>
> This is the kind of BL you have to write by hand, ALWAYS. There is no RAD
> tool for this. Everyone who thinks he can click this together using
> whidbey is mistaken. You can probably click together some class-set and
> very rough plumbing code but that's it.
>
> And make no mistake: the fact that plumbing code is being generated for
> you is a GOOD thing, because writing plumbing code is not what you want,
> because you want to write the code which represents the application's
> *functionality* !
>
> Frans
>
>>
>>
>>
>>
>> "Frans Bouma [C# MVP]" <perseus.usenetNOSPAM@xs4all.nl> wrote in message
>> news:uCO%23c2C8EHA.3076@TK2MSFTNGP15.phx.gbl...
>>
>>>Fresh Air Rider wrote:
>>>
>>>>I have just been getting up to speed on the forthcoming ASP.Net 2.0
>>>>(Whidbey) that Microsoft is releasing some time this year.
>>>>
>>>>It all looks great but I was a bit concerned that it aims to reduce
>>>>the amount of code that needs to be written by the developer by 70%.
>>>>
>>>>The new GridView control will be "far simpler to use, requires less
>>>>code, and provides far more power than the DataGrid Control".
>>>>
>>>>After working extremely hard to get my Computer Science degree and
>>>>investing my own hard earnt money heavily in MSDN subscriptions and
>>>>programming books etc just to keep my skills up to date, I began to
>>>>wonder if it had all been worthwhile now that the forthcoming ASP.Net
>>>>2.0 (Whidbey) seems to be abstracting much of the techniques that I
>>>>had learnt to "hand code".
>>>
>>>Programming is not 'typing code' but working out algorithms and create
>>>programs which represent these algorithms in executable form. How that is
>>>done, is up to the tools you use. So this will not change, the tools you
>>>use will change, over time.
>>>
>>>Do not feel offended, but I don't think you need a CS degree to write
>>>ASP.NET gui's as it's fairly straightforward once you know the tricks and
>>>pitfalls.
>>>
>>>What is way more important is the layer stack right below the GUI: the BL
>>>layer and the BL facade layer (or gui facade, depending on which way you
>>>look at it). The vast majority of your application's code is in there, or
>>>better: the vast majority of interesting code is in there.
>>>
>>>
>>>>For instance, I was particularly pleased with my implementation of
>>>>Roles Based Forms Authentication that I had mastered in C# but now I
>>>>understand that it will all be wasted now that this functionality will
>>>>be covered by the new Membership classes.
>>>
>>>As with everything MS gives out: the more it is detailed and towards 'end
>>>user stuff' (i.e. the farther you get away from a 'framework'), the more
>>>the following rule is applicable: "The Microsoft Way or Your Own Way".
>>>Often there are situations in which the MS provided controls don't work
>>>very well and you need own code or customize the provided controls.
>>>
>>>Don't be fooled by the slick demos with drag-n-drop 'RAD' 'programming':
>>>professional software is often written in total different ways than the
>>>demos show you. This is for a reason: demos are meant to sell stuff, not
>>>to teach you best practises.
>>>
>>>
>>>>I fully understand that by definition, IT is a constantly evolving
>>>>industry but it does make me worry that the very systems that we use
>>>>to improve business efficiency could one day make the role of the
>>>>qualified developer redundant.
>>>
>>>this will never be the case. Programming is not related to typing, but to
>>>thinking.
>>>
>>>
>>>>The way things are going, the office junior will be able to do all the
>>>>stuff that the highly qualified and trained developer once did and the
>>>>developers will be ignored because the higher wages that they rightly
>>>>attract will no longer be justified.
>>>
>>>no, the office monkey will do the dull gui-stuff while you will be doing
>>>business logic components and the controller layers below the GUI, which
>>>are not created by drag-n-drop clicketyclick.
>>>
>>>Frans.
>>>
>>>--
>>>------------------------------------------------------------------------
>>>Get LLBLGen Pro, productive O/R mapping for .NET: http://www.llblgen.com
>>>My .NET blog: http://weblogs.asp.net/fbouma
>>>Microsoft MVP (C#)
>>>------------------------------------------------------------------------
>>
>>
>>
>
>
> --
> ------------------------------------------------------------------------
> Get LLBLGen Pro, productive O/R mapping for .NET: http://www.llblgen.com
> My .NET blog: http://weblogs.asp.net/fbouma
> Microsoft MVP (C#)
> ------------------------------------------------------------------------

> Scott M. wrote:
>
>> Just a quick comment:
>>
>> You mention several times that the business logic is where the work
>> gets done and that there is no RAD clickety-click for that code.  I
>> think what you missed from the OP was that in Whidbey, there IS RAD
>> for the business and data layers.  In Whidbey, the RAD and drag & drop
>> is greatly improved for the backend of an application as well as the
>> front.
>
>
>     If you think that RAD and drag-n-drop will give you a business logic
> layer which can manage for example this action:
> - new customer purchases 10 products P.
> -> you need to add the new customer
> -> you need to manage inventory
> -> you need to add the order
>
> and perhaps some other things along the lines, you didn't get the point.
> Say the actions have to be controlled, by a transaction, perhaps a COM+
> transaction because the orders database is a SAP system.
>
>     A rad tool can do that? No way. Dragging some classes together in a
> designer perhaps looks like developing these kind of components but it
> isn't.
>
>     This is the kind of BL you have to write by hand, ALWAYS. There is
> no RAD tool for this. Everyone who thinks he can click this together
> using whidbey is mistaken. You can probably click together some
> class-set and very rough plumbing code but that's it.
>

"Joakim Karlsson" wrote:

> Frans Bouma [C# MVP] wrote:
> > Scott M. wrote:
> >
> >> Just a quick comment:
> >>
> >> You mention several times that the business logic is where the work
> >> gets done and that there is no RAD clickety-click for that code.  I
> >> think what you missed from the OP was that in Whidbey, there IS RAD
> >> for the business and data layers.  In Whidbey, the RAD and drag & drop
> >> is greatly improved for the backend of an application as well as the
> >> front.
> >
> >
> >     If you think that RAD and drag-n-drop will give you a business logic
> > layer which can manage for example this action:
> > - new customer purchases 10 products P.
> > -> you need to add the new customer
> > -> you need to manage inventory
> > -> you need to add the order
> >
> > and perhaps some other things along the lines, you didn't get the point.
> > Say the actions have to be controlled, by a transaction, perhaps a COM+
> > transaction because the orders database is a SAP system.
> >
> >     A rad tool can do that? No way. Dragging some classes together in a
> > designer perhaps looks like developing these kind of components but it
> > isn't.
> >
> >     This is the kind of BL you have to write by hand, ALWAYS. There is
> > no RAD tool for this. Everyone who thinks he can click this together
> > using whidbey is mistaken. You can probably click together some
> > class-set and very rough plumbing code but that's it.
> >
>
> And this is a problem, one we ought to have solved by now. Around the
> globe developers are writing almost identical BL code as if it is the
> first time that problem is solved.
>
> Software Factories [1][2] is an attempt to address this by synthezising
> patterns in common problem domains such as CRM, e-commerce etc.
>
> I agree that we will never be able to create our applications using drag
> and drop, but we ought to be able to consider a lot of the code we
> manually write today as plumbing.
>
> /Joakim
>
> [1] http://msdn.microsoft.com/architecture/overview/softwarefactories/
> [2] http://www.softwarefactories.com/
>

"Cor Ligthert" <notmyfirstn***@planet.nl> wrote in message
news:exP4cCL8EHA.2600@TK2MSFTNGP09.phx.gbl...
> Hi,
>
> This discussion is as old as there has been programs.
>
> In the sixties was told that after the  begin of the seventies there would
> be no programmers more needed because all could be done by end users by
> design tools.
>
> Luckily it is mostly stated by non programmers who don't understand what
> programs are
>
> Just my thought,
>
> Cor
>

"Fresh Air Rider" wrote:

> Hi Everyone
>
> I have just been getting up to speed on the forthcoming ASP.Net 2.0
> (Whidbey) that Microsoft is releasing some time this year.
>
> It all looks great but I was a bit concerned that it aims to reduce
> the amount of code that needs to be written by the developer by 70%.
>
> The new GridView control will be "far simpler to use, requires less
> code, and provides far more power than the DataGrid Control".
>
> After working extremely hard to get my Computer Science degree and
> investing my own hard earnt money heavily in MSDN subscriptions and
> programming books etc just to keep my skills up to date, I began to
> wonder if it had all been worthwhile now that the forthcoming ASP.Net
> 2.0 (Whidbey) seems to be abstracting much of the techniques that I
> had learnt to "hand code".
>
> For instance, I was particularly pleased with my implementation of
> Roles Based Forms Authentication that I had mastered in C# but now I
> understand that it will all be wasted now that this functionality will
> be covered by the new Membership classes.
>
> I fully understand that by definition, IT is a constantly evolving
> industry but it does make me worry that the very systems that we use
> to improve business efficiency could one day make the role of the
> qualified developer redundant.
>
> The way things are going, the office junior will be able to do all the
> stuff that the highly qualified and trained developer once did and the
> developers will be ignored because the higher wages that they rightly
> attract will no longer be justified.
>
> Maybe this is what Microsoft are working towards or maybe I'm just a
> Luddite.
>
> Please accept my appologies for the cross-posting but it's just
> something that I feel very stongly about and is of equal importance to
> each group.
>

"Bruce Wood" <brucew***@canada.com> wrote in message
news:1105496108.936995.206020@z14g2000cwz.googlegroups.com...
> I have been working in the programming business for 20 years. Just
> after I had graduated, I had the same concerns that you do: I had heard
> that reports would be so easy to write that managers would be doing it.
> SQL was going to make data analysis so easy that clerks could do it.
> Programmers were going to be obsolete.
>
> In fact, what happened is what has happened over and over again for the
> last 20 years: today's problems because formalized and companies like
> Microsoft build drag-and-drop tools to solve those problems so that
> anyone can do it. However, far from reducing the workload, this causes
> customers (usually business people) to simply raise their expectations.
> I'll give you an example from one job I had.
>
> When I arrived on the scene at company B, it took them a week to write,
> test, and put a report in production. After a lot of work on re-usable
> code and refactoring, we got it down to a half a day. Instead of laying
> off most of the team, what happened was that the business users started
> dragging out old projects that they had been told were "impossible",
> but which were now within reach because of our improving software
> technology. By the time I left we were finishing up a project that our
> database vendor had told us "couldn't be done," and we were churning
> out those tedious reports in a couple of hours.
>
> The problems you're solving today will be drag-and-drop tomorrow, but
> all that will happen is that the world will invent new uses for
> computers that will require all of your skill to design and implement
> solutions. I'm doing things today that I wouldn't even have understood
> 20 years ago, and the stuff I was doing 20 years ago, like writing
> linked list routines and hash table routines now come bundled with
> every respectable modern language.
>
> The only bad thing about all of this is that every stitch of code I
> write more than 5 years ago is now gone, replaced by newer, better
> stuff. This isn't architecture: you don't get to show your kids your
> work, particularly not since just as the problems you'll be solving 20
> years from now are today's "impossible" problems, the solutions you
> were so proud of 20 years ago are today's trivialities.
>
> The belief that programmers will shortly become obsolete is founded in
> the mistaken idea that the current problem set is closed, and that all
> there is to do is formalize solutions to current problems and we're
> done. Or, put another way, that we have already discovered all of the
> things for which we could use computers. The now-infamous comment that
> the world would need only six or seven computers was based on the same
> line of thinking, and it's short-sighted thinking.
>
> I doubt that they heydays of 1998 and 1999 will return, but then I
> doubt you'll go hungry.
>

"User" <U***@aol.com> wrote in message
news:%234kMmCN%23EHA.2876@TK2MSFTNGP12.phx.gbl...
>
> "Bruce Wood" <brucew***@canada.com> wrote in message
> news:1105496108.936995.206020@z14g2000cwz.googlegroups.com...
>> I have been working in the programming business for 20 years. Just
>> after I had graduated, I had the same concerns that you do: I had heard
>> that reports would be so easy to write that managers would be doing it.
>> SQL was going to make data analysis so easy that clerks could do it.
>> Programmers were going to be obsolete.
>>
>> In fact, what happened is what has happened over and over again for the
>> last 20 years: today's problems because formalized and companies like
>> Microsoft build drag-and-drop tools to solve those problems so that
>> anyone can do it. However, far from reducing the workload, this causes
>> customers (usually business people) to simply raise their expectations.
>> I'll give you an example from one job I had.
>>
>> When I arrived on the scene at company B, it took them a week to write,
>> test, and put a report in production. After a lot of work on re-usable
>> code and refactoring, we got it down to a half a day. Instead of laying
>> off most of the team, what happened was that the business users started
>> dragging out old projects that they had been told were "impossible",
>> but which were now within reach because of our improving software
>> technology. By the time I left we were finishing up a project that our
>> database vendor had told us "couldn't be done," and we were churning
>> out those tedious reports in a couple of hours.
>>
>> The problems you're solving today will be drag-and-drop tomorrow, but
>> all that will happen is that the world will invent new uses for
>> computers that will require all of your skill to design and implement
>> solutions. I'm doing things today that I wouldn't even have understood
>> 20 years ago, and the stuff I was doing 20 years ago, like writing
>> linked list routines and hash table routines now come bundled with
>> every respectable modern language.
>>
>> The only bad thing about all of this is that every stitch of code I
>> write more than 5 years ago is now gone, replaced by newer, better
>> stuff. This isn't architecture: you don't get to show your kids your
>> work, particularly not since just as the problems you'll be solving 20
>> years from now are today's "impossible" problems, the solutions you
>> were so proud of 20 years ago are today's trivialities.
>>
>> The belief that programmers will shortly become obsolete is founded in
>> the mistaken idea that the current problem set is closed, and that all
>> there is to do is formalize solutions to current problems and we're
>> done. Or, put another way, that we have already discovered all of the
>> things for which we could use computers. The now-infamous comment that
>> the world would need only six or seven computers was based on the same
>> line of thinking, and it's short-sighted thinking.
>>
>> I doubt that they heydays of 1998 and 1999 will return, but then I
>> doubt you'll go hungry.
>>
>
> Some of the "reports" and "programming" of old have become user
> spreadsheets.
> 40 years ago, there was IBM and the seven dwarfs, and how many viable
> OS's?
> A more pertinent question is will there be decent numbers of decent paying
> jobs for developers in the developed world.
>
>
>
>
>

"RobertW" <Robe***@discussions.microsoft.com> wrote in message
news:9A20D01E-9E7D-46A0-825E-5685D024CF84@microsoft.com...
>> It all looks great but I was a bit concerned that it aims to reduce
>> the amount of code that needs to be written by the developer by 70%.
> ..
>> For instance, I was particularly pleased with my implementation of
>> Roles Based Forms Authentication that I had mastered in C# but now I
>> understand that it will all be wasted now that this functionality will
>> be covered by the new Membership classes.
>
> Pardon me for saying so, but isn't role-base forms authentication
> something
> that the OS "should" handle for you easily, if the OS, in fact, is doing
> the
> authentication in the end.  Should you really have to be clever to do
> something so basic??  In the end, no, programming was not meant to be
> difficult.
>
> If you studied computer science, then you should be familiar with the
> concept of "abstracting" or "black-boxing" (back when I went to school,
> object-oriented programming wasn't "hip" yet, but same idea).  Basically,
> if
> the writers of the OS (including libraries) are competant enough, you
> should
> get an interface that hides as much details of what goes on behind the
> scenes
> as possible; you shouldn't have to know how the OS does things in order to
> develop a program for it (especially since .NET is supposed to be OS
> independent and even run on Linux with mono).  Do you think your
> "role-based
> forms authentication" would run on Linux as you had written it?  (and if
> you
> tell me you don't care, you're missing the point of .NET programming.)
>
> Disclaimer: I am not an authority, I am not an expert, and my opinion
> doesn't amount to a hill of beans as I haven't written a program in over 2
> years.  I probably won't come back to look for a reply.  I'm here because
> I'm
> about to start learning C#, mostly for my own amusement (and who knows, I
> might look for a work as a developer again in the future).  It sounds like
> I'll have to pay attention to the upgrades coming in .NET as they might
> make
> my life simpler (of course, remembering that I'll probably have to toss in
> a
> chunk of change to upgrade, which i'm not sure i'm willing to do.)
>
> -Rob

"Scott M." wrote:

> Actually it's not really the OS that is doing the authentication.  It is a
> Domain Server using Access Control Lists (ACL's).  There is, in fact, an
> interface to these ACL's as you suggested would be a good idea.
>
>
>
> "RobertW" <Robe***@discussions.microsoft.com> wrote in message
> news:9A20D01E-9E7D-46A0-825E-5685D024CF84@microsoft.com...
> >> It all looks great but I was a bit concerned that it aims to reduce
> >> the amount of code that needs to be written by the developer by 70%.
> > ..
> >> For instance, I was particularly pleased with my implementation of
> >> Roles Based Forms Authentication that I had mastered in C# but now I
> >> understand that it will all be wasted now that this functionality will
> >> be covered by the new Membership classes.
> >
> > Pardon me for saying so, but isn't role-base forms authentication
> > something
> > that the OS "should" handle for you easily, if the OS, in fact, is doing
> > the
> > authentication in the end.  Should you really have to be clever to do
> > something so basic??  In the end, no, programming was not meant to be
> > difficult.
> >
> > If you studied computer science, then you should be familiar with the
> > concept of "abstracting" or "black-boxing" (back when I went to school,
> > object-oriented programming wasn't "hip" yet, but same idea).  Basically,
> > if
> > the writers of the OS (including libraries) are competant enough, you
> > should
> > get an interface that hides as much details of what goes on behind the
> > scenes
> > as possible; you shouldn't have to know how the OS does things in order to
> > develop a program for it (especially since .NET is supposed to be OS
> > independent and even run on Linux with mono).  Do you think your
> > "role-based
> > forms authentication" would run on Linux as you had written it?  (and if
> > you
> > tell me you don't care, you're missing the point of .NET programming.)
> >
> > Disclaimer: I am not an authority, I am not an expert, and my opinion
> > doesn't amount to a hill of beans as I haven't written a program in over 2
> > years.  I probably won't come back to look for a reply.  I'm here because
> > I'm
> > about to start learning C#, mostly for my own amusement (and who knows, I
> > might look for a work as a developer again in the future).  It sounds like
> > I'll have to pay attention to the upgrades coming in .NET as they might
> > make
> > my life simpler (of course, remembering that I'll probably have to toss in
> > a
> > chunk of change to upgrade, which i'm not sure i'm willing to do.)
> >
> > -Rob
>
>
>

"RobertW" <Robe***@discussions.microsoft.com> wrote in message
news:9915CD50-0B1B-47CB-8F17-9DEB8D00A802@microsoft.com...
> Call it what you will.. As a former professional OS developer (UNIX), I
> consider all ths "services" (of a server or workstation ) that are (for
> the
> most part) included with the OS or sold as add-ons (by the developer of
> the
> OS), as part of the Operating Sytem.  The OS is more than a kernel.
>
> -Rob
>
> "Scott M." wrote:
>
>> Actually it's not really the OS that is doing the authentication.  It is
>> a
>> Domain Server using Access Control Lists (ACL's).  There is, in fact, an
>> interface to these ACL's as you suggested would be a good idea.
>>
>>
>>
>> "RobertW" <Robe***@discussions.microsoft.com> wrote in message
>> news:9A20D01E-9E7D-46A0-825E-5685D024CF84@microsoft.com...
>> >> It all looks great but I was a bit concerned that it aims to reduce
>> >> the amount of code that needs to be written by the developer by 70%.
>> > ..
>> >> For instance, I was particularly pleased with my implementation of
>> >> Roles Based Forms Authentication that I had mastered in C# but now I
>> >> understand that it will all be wasted now that this functionality will
>> >> be covered by the new Membership classes.
>> >
>> > Pardon me for saying so, but isn't role-base forms authentication
>> > something
>> > that the OS "should" handle for you easily, if the OS, in fact, is
>> > doing
>> > the
>> > authentication in the end.  Should you really have to be clever to do
>> > something so basic??  In the end, no, programming was not meant to be
>> > difficult.
>> >
>> > If you studied computer science, then you should be familiar with the
>> > concept of "abstracting" or "black-boxing" (back when I went to school,
>> > object-oriented programming wasn't "hip" yet, but same idea).
>> > Basically,
>> > if
>> > the writers of the OS (including libraries) are competant enough, you
>> > should
>> > get an interface that hides as much details of what goes on behind the
>> > scenes
>> > as possible; you shouldn't have to know how the OS does things in order
>> > to
>> > develop a program for it (especially since .NET is supposed to be OS
>> > independent and even run on Linux with mono).  Do you think your
>> > "role-based
>> > forms authentication" would run on Linux as you had written it?  (and
>> > if
>> > you
>> > tell me you don't care, you're missing the point of .NET programming.)
>> >
>> > Disclaimer: I am not an authority, I am not an expert, and my opinion
>> > doesn't amount to a hill of beans as I haven't written a program in
>> > over 2
>> > years.  I probably won't come back to look for a reply.  I'm here
>> > because
>> > I'm
>> > about to start learning C#, mostly for my own amusement (and who knows,
>> > I
>> > might look for a work as a developer again in the future).  It sounds
>> > like
>> > I'll have to pay attention to the upgrades coming in .NET as they might
>> > make
>> > my life simpler (of course, remembering that I'll probably have to toss
>> > in
>> > a
>> > chunk of change to upgrade, which i'm not sure i'm willing to do.)
>> >
>> > -Rob
>>
>>
>>