Re: some interesting perspectives on .NET from the other camp ...

From: Dan Barclay (Dan_at_MVPs.org)
Date: 02/14/05 

Date: Sun, 13 Feb 2005 22:46:09 -0600

"Bob Dawson" <RBDawson@prodigy.net> wrote in message
news:42102411$1@newsgroups.borland.com...
> "Dan Barclay" wrote
>> is no different in that regard than CP/M was. There are (or were<g>)
>> functions in VB to trim strings, for example. Most VB.Net users would
>> now rather use framework functionality directly. They're going to get
>> burned if they try to move that app to Whatever.Next, unless the
>
> Couldn't the same be said of relying on windows printer drivers rather
> than
> writing your own?

Actually, I'm suggesting you go the other way. If you have something to
print, and it uses printing capability you can put in a generic form, make
higher level functions. If those use printer drivers, so be it. The
BigThing.Next (like maybe DotNet) will likely print some other way. If
you've got your printing all corralled into one or two functions you don't
have to dig into your entire library fixing things when you move.

>I'm very aware of the dependency issue, but while I don't
> provide the OS, I don't provide the language either--so it's not like
> utility functions being one place or the other is particularly liberating
> or
> confining. Do you really think a VB.NET writer is any more dependent on MS
> than a VB6 writer is?

LOL. Sorry, but I'll have to get past the "dependent on MS" thing here and
change it to "dependent on the platform". Yea, but not because of VB.Net.
It's just the way I've seen most of them doing things, and because of the
practices I've seen recommended coming out of that camp. Most VB.Net apps
are heavily dependent on the framework.

> And it's not like all dependencies can be avoided, even when one tries. C
> and Java are each virtually worthless in terms of business productivity
> unless one considers the standard libraries, just as Delphi would be much
> less powerful were one to shun dependency on the rtl and vcl.

Right. Not all dependencies can be avoided. We're not talking about
absolute "rules" here, only objectives and methods. It's one thing to shun
low platform or framework level functions altogether. It's quite another to
recognize them for what they are, and protect yourself from them when it's
reasonable. At the other extreme, which I see out of a lot of the DotNet
camps, is to embrace the framework and deeply embed it in your apps.

> At the heart of it, all of this is technical code, not solution domain
> code--just the raw materials we need to use to build business solutions.
> So
> I see standardizing and moving all this technical code back into the
> platform as a good thing. Trimming a string just seems to me to be exactly
> the sort of thing that shouldn't have to be coded redundantly (and
> differently) in every language--pull it up into a utility library at the
> platform level (the FCL) and be done with it, and let language providers
> move on to higher level concerns.

No, the heart of it is providing of business functions to the user. All the
rest is just delivery.

If every platform trimmed a string the same way (or even agreed on what a
string was!) I'd agree with you that it belonged at the platform level.
They don't. Hell, Integers aren't even the same. Strings should be defined
by the language, along with functions to tinker with them. The *language*
may use the framework functions rather directly, but the programmer
shouldn't care how it's done.

You can use the framework directly for nearly everything if you want. Just
plan on rewriting that code when Whatever.Next comes along. In the long run
the less your code has to know about the platform, the better. I've come
here from CP/M and TRSDOS, that advice has worked at every platform change
so far. But I could be wrong<g>.

Dan

Relevant Pages

  • Re: Concerns with COM+
    ... Are you sure your problem is with the framework and not with this "very ... If they want platform independence they can't use COM+. ... Java is interpreted, ...
    (comp.programming)
  • Concerns with COM+
    ... as an application framework. ... Bloated - it takes up too many server resources for the support ... Platform Dependent - I don't want to say that J2EE is the end-all ... minimal library changes so that it could run in various platforms as ...
    (comp.programming)
  • RE: IE headers w patch level - new info
    ... Internet Settings\User Agent\Post Platform ... String Value: Q312461 ... The patch information that Internet Explorer displays ... logfiles, under the UserAgent field. ...
    (Focus-Microsoft)
  • Re: Re: chr() .Net equivalent
    ... look at the notes from the conversion and the ... A new platform may introduce differences of its own simply due to ... framework. ... If you start dropping Visual Basic functionality in order to simply avoid ...
    (microsoft.public.dotnet.languages.vb)
  • Re: IE Hosts Windows Control
    ... statement in the "What's new in the .NET Framework 1.1" ... Internet-based Web page or Windows Forms assemblies ... could get my control to execute on a framework v1 sp1 ... >> assemblyName, String ...
    (microsoft.public.dotnet.security)