My view of the world

[Rob Teixeira]

If you are already comfortable with more than one language, particularly
a C-derivative, my suggestion has always been to learn both. Once you understand
the core of the CLR, and have a good notion of the layout of the class library,
the majority of the difference between the two languages is syntactic sugar.
In that respect, learning .NET is a more important endeavor than simply learning
either "language". That should make you more marketable as well.

-Rob

"Kevin Moore" <Kevin@MooreSSI.com> wrote:
>
>I will have a closer look at C# and possibly look at moving towards it.
As
>you mentioned, I have to continue my learning of VB.Net or look at C#.
>
>Thanks again.
>
>Kevin

[Mike Mitchell]

On Mon, 18 Feb 2002 07:01:58 -0800, "Michael \(michka\) Kaplan"
<former_mvp@nospam.trigeminal.spamless.com> wrote:

>In genaral you will choose whether to only use the old version or to use the
>"latest" version -- so you will not need to install BOTH versions.

But what happens with the old version of the framework on users'
machines? Does it just sit there, cluttering up the hard disk for
ever? Who will be intrepid enough to remove it? And that is if you
have "only" TWO framework versions. What about when/if there are
multitudinous versions? Some needed for this; others needed for that.
Some being kind of redundant on some PCs, but not on others?

MM

[Kathleen \(MS MVP\)]

Kevin,

Michka got this, but I want to be sure it was clear.

You choose. I can't imagine why you would release both, but if you don't
want to test, or you run into problems with an update, you certainly can
release both (might take some dancing on your machine for the compile). They
decided that static linking has its own share of problems, but that we
absolutely needed the ability to say "this exact one" not just anything that
bears that GUID. The versioning scheme is exremely robust.

Mike is correct that they both "clutter" the users machine. COM GUID stuff
came to pass because the relative size of components (ours and MS's)
relative to the available memory and hard disk space required sharing. Those
days are gone. What user machine notices 20Mb. So now MS gives you complete
control, which means (thank goodness) you don't have to trust future acts by
anyone.

Kathleen

[Mike Mitchell]

On Mon, 18 Feb 2002 13:22:09 -0800, "Michael \(michka\) Kaplan"
<former_mvp@nospam.trigeminal.spamless.com> wrote:

>It sits there unless someone uninstalls it.

But over here in Europe we don't like waste. We have laws now for
dealing with rubbish. Most EU countries have separate trash bins for
different kinds of rubbish. So if people discover they are downloading
20 MB here and 20 MB there, only for it to just "sit there" after a
while, they will want to ask the question "why"? Downloading doesn't
come cheap over here for most consumers.

Also, it sounds like an incredibly wasteful way of distributing
software. It'd be far better to just compile standalone Exe's with the
entire functionality in one memory image. That way you'd only need to
replace the Exe, and by dint of doing that, you'd clean up as you
upgraded to the next version as the old Exe got overwritten.

MM

[Kathleen \(MS MVP\)]

Mike,

Which assuming you have more copies of applications than you have versions
of the CLR (a likely assumption) you are far more wasteful with your
suggestion.

Kathleen

[Jason]

Yep, you are right. WHAT was Microsoft thinking? It would be so much better
if we could all just stick to assembly code. :-)

There are some things that .NET does that an EXE does not do:

(1) Security - I don't like to download things from people I don't know very
well. EXEs don't work well in a web world.

(2) DLL **** - Don't tell me you don't ship ANY Dlls with your app. Come
on, now.

(3) Everything downloads at one time, not "20MB here and 20MB there."

Dang it, Mike, VB has a run time for VB2, VB3, VB4, VB5 and VB6. They all
get included with your OS (well, the later ones at least), but you aren't
complaining about it. Yet the .NET runtime is only about 10 times bigger,
and there is no indication that Microsoft is going to be dropping a new CLR
every 6 months. Every 18 months to 2 years is more likely.

The Windows operating system takes what, 500MB? 1GB? I don't even know,
or care, since it's transparent to me. I have numerous applications that
take 50MB or more on the hard drive. What is a measley 20MB on a 60GB disk?

If you don't like it, you don't have to run it. You can go over to Linux,
and get away from Windows completely if you want to. Be sure to check out
the Mono CLR while you are there. It runs C# too. Nah, you better just
stick with DOS. It's less "wasteful."

>But over here in Europe we don't like waste. We have laws now for
>dealing with rubbish. Most EU countries have separate trash bins for
>different kinds of rubbish. So if people discover they are downloading
>20 MB here and 20 MB there, only for it to just "sit there" after a
>while, they will want to ask the question "why"? Downloading doesn't
>come cheap over here for most consumers.
>
>Also, it sounds like an incredibly wasteful way of distributing
>software. It'd be far better to just compile standalone Exe's with the
>entire functionality in one memory image. That way you'd only need to
>replace the Exe, and by dint of doing that, you'd clean up as you
>upgraded to the next version as the old Exe got overwritten.
>
>MM

[Jay Glynn]

Your making the assumption that this 20 meg would have to be
downloaded/installed "every" time. That won't be the case. Even if Karl and
Michael's runtime **** scenario plays out, I don't see major upgrades
appearing every 6 months. I would say it would be closer to the 18-24 month
range. So after 4 years of running you may have 2 or possibly 3. I would
aslo wager that some enterprising individual will develop a handy dandy
utility that will sniff out what versions of the runtime you will need and
let you know that you can uninstall the ones you don't need.

BTW, there are a lot of us in the USA that separate the trash for recycling
as well.

>
> >It sits there unless someone uninstalls it.
>
> But over here in Europe we don't like waste. We have laws now for
> dealing with rubbish. Most EU countries have separate trash bins for
> different kinds of rubbish. So if people discover they are downloading
> 20 MB here and 20 MB there, only for it to just "sit there" after a
> while, they will want to ask the question "why"? Downloading doesn't
> come cheap over here for most consumers.
>
> Also, it sounds like an incredibly wasteful way of distributing
> software. It'd be far better to just compile standalone Exe's with the
> entire functionality in one memory image. That way you'd only need to
> replace the Exe, and by dint of doing that, you'd clean up as you
> upgraded to the next version as the old Exe got overwritten.
>
> MM

[Kevin Moore]

Kathleen,

I appreciate your clarification, and I can see how Michka was correct. The
issue I have with this is that if MS happens to break compatibility and unfortunately
given their track record the odds are better that they will, I might have
to distribute both or all versions of the CLR. The choice they have given
me is still within the CLR and I have the biggest complaint with it.

I would have thought that the folks at MS could have enabled a linker that
was smart enought to include all used components of an app instead of the
full 20 Mb. For example a plain Windows app might only utilize < 5 Mb of
the CLR. A strict Web Service might only need < 2 Mb, and so on. But for
whatever reason, they didn't do this and we are stuck the CLR.

As for the point that this won't happen frequently, the only statistic I
can safely utilize is a historical one. VB6 came out approximately 3 years
ago. Since then there have been, I believe, 5 service packs, which basically
means every 6 months or so. This is where my concerns stem from.

I do appreciate your comments, and for the whole .Net is a positive step
forward but it isn't without its downfalls, and I believe that the market
will eventually determine the true success or failure of it.

Kevin


"Kathleen \(MS MVP\)" <someone@nomail.com> wrote:
>Kevin,
>
>Michka got this, but I want to be sure it was clear.
>
>You choose. I can't imagine why you would release both, but if you don't
>want to test, or you run into problems with an update, you certainly can
>release both (might take some dancing on your machine for the compile).
They
>decided that static linking has its own share of problems, but that we
>absolutely needed the ability to say "this exact one" not just anything
that
>bears that GUID. The versioning scheme is exremely robust.
>
>Mike is correct that they both "clutter" the users machine. COM GUID stuff
>came to pass because the relative size of components (ours and MS's)
>relative to the available memory and hard disk space required sharing. Those
>days are gone. What user machine notices 20Mb. So now MS gives you complete
>control, which means (thank goodness) you don't have to trust future acts
by
>anyone.
>
>Kathleen
>
>

[Zane Thomas [.NET MVP]]

On Mon, 18 Feb 2002 23:38:19 GMT, kylix_is@yahoo.co.uk (Mike Mitchell)
wrote:

>>It sits there unless someone uninstalls it.
>
>But over here in Europe we don't like waste.

We've been around on this one before Mikee. Yesterday my g/f got a 40gb
hard drive for $119 - let's call it $120 making it $3 per gigabyte. You
probably aren't aware of this because you have a 500mb drive, but 1 gb
(depending upon marketting skew) is 1000mb. If the runtime takes 20mb
then there's room for 50 of them per $3 worth of disk storage at today's
prices. At a rate of 6 months per update it's going to take 25 years to
use $3 worth of storage - and, of course, storage will be terabytes per
pennies by then.


>We have laws now for dealing with rubbish.

Which explains why you're posting on an american news server.


--
When freedom is outlawed
only outlaws will be free.

[Kunle Odutola]

"Kevin Moore" <Kevin@MooreSSI.com> wrote in message
news:3c71adee$1@10.1.10.29...

> I would have thought that the folks at MS could have enabled a linker that
> was smart enought to include all used components of an app instead of the
> full 20 Mb. For example a plain Windows app might only utilize < 5 Mb of
> the CLR. A strict Web Service might only need < 2 Mb, and so on. But for
> whatever reason, they didn't do this and we are stuck the CLR.

Assuming you are right, that 5MB is different for each program or genre.
Eventually many program will duplicate parts of the CLR or we would be pack
to user apps needing to update system files. Not pretty.

> As for the point that this won't happen frequently, the only statistic I
> can safely utilize is a historical one. VB6 came out approximately 3 years
> ago. Since then there have been, I believe, 5 service packs, which
basically
> means every 6 months or so. This is where my concerns stem from.

VB <> VB.NET
Win32 <> .NET

> I do appreciate your comments, and for the whole .Net is a positive step
> forward but it isn't without its downfalls, and I believe that the market
> will eventually determine the true success or failure of it.

Oh, it _will_ be successful no doubt. Very.

Kunle

[Zane Thomas [.NET MVP]]

Kevin,

>I have serious doubts of MS's claim that the CLR (20 Mb at least) in size
>will be easily updated and will remain backward compatible. They haven't
>really done the backward comptability in the past so why should they start
>now.

I think it's reasonable to assume that MS has learned from the past - as
we all have. I don't recall a great outcry about backwards compatibility
when VBXes (and later OCXes) first came out - we're all learning as
technology evolves.

They may not have the perfect solution at this time (and there may not be
one, reality is messy sometimes). But I suspect that it will be better
and that the thing which will the most annoying isn't anticipated yet by
most of us (although I'd bet that MS has a better perspective on problems
we'll see five years down the road than most of us do, and that they will
be looking for solutions).

>1. Move to .Net, continue the learning cycle of VB.Net and hope that MS deals
>with the CLR correctly.

My opinion is that the CLR will not be successful unless it ships with the
operating system. At which point it is simply another set of DLLs such as
those which exist already in all windows operating systems. Yes, there
have been versioning problems with those, and yes the .net approach will
avoid those problems.

>2. Move to Delphi and learn another language

That is an option some people have been looking at. You've probably heard
by now that Borland is planning on targetting the framework. How they're
going to do that without buying into the framework escapes me, but if they
don't then we'll be seeing you back here I suppose. :-)

>3. Stay with Classic VB and become antiquated (not really an option)

Right.

>4. Pray that someone releases an new product that allows me to pick and choose
>what features I want to include in my app and how I want to distribute it,
>ie (static vs dynamic linking)

I wonder about that one. Dynamic-linking has, since MS started heavily
using it with VB4, had its problems. But they've gone a long ways towards
addressing those issues and static linking has problems of its own
including large image size and the inability to get automatic updates as
component pieces change.


--
When freedom is outlawed
only outlaws will be free.

[W.E.(Bill) Goodrich, PhD]

In article <3c71aa42$1@10.1.10.29>,
"Jay Glynn" <jlsglynn@hotmail.com> writes:

> Your making the assumption that this 20 meg would have to be
> downloaded/installed "every" time. That won't be the case. Even
> if Karl and Michael's runtime **** scenario plays out, I don't see
> major upgrades appearing every 6 months.

They wouldn't have to be "major" to disrupt things.

> I would say it would be closer to the 18-24 month range. So after 4
> years of running you may have 2 or possibly 3.

There already *are* 3, thanks to all the "early adopters" who coded
apps and fragments in B1, B2, and V1.

--

W.E. (Bill) Goodrich, PhD

*-----------------------*--------------------------------------------*
* CHANGE YOUR SEXUALITY * http://www.nyx.net/~bgoodric/ctg.html *
* * *
* Without Aversive * ctgcentral@earthlink.net *
* Behavior Modification * Creative Technology Group *
* or Drugs * PO Box 286 *
* * Englewood, CO 80151-0286 *
*-----------------------*--------------------------------------------*

[Zane Thomas [.NET MVP]]

On Mon, 18 Feb 2002 21:42:24 -0700, "W.E.(Bill) Goodrich, PhD"
<bgoodric@netzero.net> wrote:

>> I would say it would be closer to the 18-24 month range. So after 4
>> years of running you may have 2 or possibly 3.
>
>There already *are* 3, thanks to all the "early adopters" who coded
>apps and fragments in B1, B2, and V1.

That's absurd.


--
When freedom is outlawed
only outlaws will be free.

[Ed Courtenay]

"W.E.(Bill) Goodrich, PhD" <bgoodric@netzero.net> wrote in message
news:3C71D7B0.52DD7F08@netzero.net...
> > I would say it would be closer to the 18-24 month range. So after 4
> > years of running you may have 2 or possibly 3.
>
> There already *are* 3, thanks to all the "early adopters" who coded
> apps and fragments in B1, B2, and V1.
>

Even for you PhD, this is a serious case of clutching at straws...

[Jay Glynn]

> There already *are* 3, thanks to all the "early adopters" who coded
> apps and fragments in B1, B2, and V1.

That would be about the stupidest thing anyone in this group has said to
date. Those would be beta, in case you haven't noticed.