Is Whidbey the beginning of the end for the developer ?

  • Thread starter Thread starter Fresh Air Rider
  • Start date Start date
Even for developers, things won't be "tight". As I said, this assumes a
closed problem set, in which no new problems come along and the only
thing left to do is formalize the problems at hand, and then consult
with businesses as to how to plug the "Lego blocks" together.

In my experience this doesn't happen. The problem set is open-ended,
and the only result of making today's problems "plug and play" is
dreaming up new problems that require more developers.
 
They have definitely gotten better than they were in the VS 6.0 days. In
addition, the bloat compiles down very well, so it is not as bad as it could
be.

The bigger problem with drag and drop is it paints you into a box.

---

Gregory A. Beamer
MVP; MCP: +I, SE, SD, DBA

***************************
Think Outside the Box!
***************************
 
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.
Click to expand...

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
 
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.
 
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
 
Then, by your definition, all software "added-in" to the OS become part of
the OS. In this case, MS Excel is part of my OS?
 
Back
Top