My view of the world

[Kevin Moore]

Hi,

I just wanted to get up on my soap box and offer some insight into my world
and hopefully get some feedback from y'all. I have been developing app for
the last 12 years, the last 6 of which has been predominantly with MS technologies
focusing on VB and SQL. I split my time between consulting to clients and
developing commercial apps. For my commercial app I use VB (6) and SQL 7/2000
and have been doing so for several years. For my consulting I use C++, COM+,
ASP or whatever the client chooses.

Now onto the rant. Within the scope of my commercial app, I chose VB because
it was simply one of the best RAD tools on the market, I could accomplish
all of my goals, quickly and easily and I was able to migrate through the
various release moving from VB3 -> VB4 -> VB5 to finally VB6. Along the way
I enjoyed taking advantage of newer technologies that MS has implemented
with the language, eg VB5 native compiler and VB6 COM+ integration, VB4 classes
(ok not really due to the problems, but close). Now I come to .Net and I
must say from my commercial app point of view I am quite disappointed. Just
to clarify I have been working with .Net Beta 2 since last Sept. When I first
heard about .Net I was hoping that MS would go the way of Delphi in offering
Static linking and remove us from the dependecy on MSVBVMx.DLL, when I heard
about the CLR I was initially pessimistic. Over the time my pessimism has
turned to downright frustration.

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.

For the sake of my commercial apps I am left with some choices and I would
hope that y'all might offer some other insight.

1. Move to .Net, continue the learning cycle of VB.Net and hope that MS deals
with the CLR correctly.
2. Move to Delphi and learn another language
3. Stay with Classic VB and become antiquated (not really an option)
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)

Not sure what else to say. Thanks for reading .

Kevin

[Karl E. Peterson]

Hi Kevin --

I feel your pain. :-(

> 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.

Exactly. ".NET: It's About Trust!" How much do you have? Mine's gone, fwiw.

> For the sake of my commercial apps I am left with some choices and I would
> hope that y'all might offer some other insight.
>
> 1. Move to .Net, continue the learning cycle of VB.Net and hope that MS deals
> with the CLR correctly.
> 2. Move to Delphi and learn another language

I have trouble with these being two different choices. Seems to me that nearly
everyone, except those in Redmond, agrees that moving to .NET *is* learning a
language. The trouble with moving to VFred is that it is close enough, in many
cases, to Classic VB that you're potentially gonna go crazy with the mindgames it
will play on you. You've no doubt found many instances where identical code produces
different results, or where previously valid designs now execute in random order.
Yes, learn a new language. Just be sure what you already know doesn't get in the
way!

> 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)

Well, Borland is heading in a direction where one sourcebase will allow you to
compile to Win32, Linux, Java, and eventually .NET -- that seems like maximal
leverage to me. There's also a conversion tool for existing VB source that works
*far* better (as I'm told) than the one that ships with VS7. Heh, but as we've taken
to saying around here, "Your Suckage May Vary." ;-)

Later... Karl
--
[Microsoft Basic: 1976-2001, RIP]

[Kevin Moore]

Karl,

Thanks for you response. Honestly I was hoping to get some feedback from
yourself and Zane. The two of you seem to respond to posts in this newsgroup
in a reasonable nature. Unlike the rest that seem to get caught up in the
tastes great vs less filling type arguments.

The funny thing is that my prospective clients for my commercial app always
ask about technology. Up until now I'll answer MS written in VB and using
SQL and they'll nod and agree. Not because they no anything but because the
media and the marketing muscle around the world has told them, similar to
IBM in the 70's, noone ever lost their job buying MS. I feel cauget between
a rock and a hardplace. If I migrate to .NET I will be forcing my apps direction
to be dictated by the folks at MS. If I go with a Borland or other technology,
than I'll get the inevitable "Who's that" from my client and I feel that
it could affect my prospective clients buying habits (all other things being
equal).

Know anyone that wants to work on a project to write a VB like language and
take advantage of the seemingly obvious opportunity to fill a void that MS
has left? <bg>

Kevin

"Karl E. Peterson" <karl@mvps.org> wrote:
>Hi Kevin --
>
>I feel your pain. :-(
>
>> 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.
>
>Exactly. ".NET: It's About Trust!" How much do you have? Mine's gone,
fwiw.
>
>> For the sake of my commercial apps I am left with some choices and I would
>> hope that y'all might offer some other insight.
>>
>> 1. Move to .Net, continue the learning cycle of VB.Net and hope that MS
deals
>> with the CLR correctly.
>> 2. Move to Delphi and learn another language
>
>I have trouble with these being two different choices. Seems to me that
nearly
>everyone, except those in Redmond, agrees that moving to .NET *is* learning
a
>language. The trouble with moving to VFred is that it is close enough,
in many
>cases, to Classic VB that you're potentially gonna go crazy with the mindgames
it
>will play on you. You've no doubt found many instances where identical
code produces
>different results, or where previously valid designs now execute in random
order.
>Yes, learn a new language. Just be sure what you already know doesn't get
in the
>way!
>
>> 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)
>
>Well, Borland is heading in a direction where one sourcebase will allow
you to
>compile to Win32, Linux, Java, and eventually .NET -- that seems like maximal
>leverage to me. There's also a conversion tool for existing VB source that
works
>*far* better (as I'm told) than the one that ships with VS7. Heh, but as
we've taken
>to saying around here, "Your Suckage May Vary." ;-)
>
>Later... Karl
>--
>[Microsoft Basic: 1976-2001, RIP]
>

[Mike Mitchell]

On 15 Feb 2002 16:18:26 -0800, "Kevin Moore" <Kevin@MooreSSI.com>
wrote:

Kevin, your posting will really open up a hornet's nest, I believe,
because this ng is largely the baliwick of evagelists for .NET and all
things Microsoft, but I'm going to take a back seat on this one and
let some of the others persuade you to go one way or another.

Briefly, before I unfold the dickey seat and take my place on the
sidelines, what I would do, depending on the kind of commercial apps
you produce, is plan to forget Windows long term. I read several trade
newspapers in the UK and it's obvious that more and more companies are
looking (desperately, it has to be said) at alternatives to Windows.
The obvious choice has to be Linux (mainly because it's about the
*only* choice apart from Apple). Linux reigns supreme in the server
world, but still has a long way to go in the desktop application
market. One thing Linux is crying out for is well-designed,
well-crafted, easily installed applications of all kinds. Your apps,
ported to Linux, e.g. using Kylix, which is compatible with Delphi 6,
*could* possibly be the fuse that helps to set the Linux desktop world
alight!. You could be in there at the ground floor as the lift starts
its inevitable rise to the top.

MM

[Karl E. Peterson]

Hi Kevin --

> Thanks for you response. Honestly I was hoping to get some feedback from
> yourself and Zane. The two of you seem to respond to posts in this newsgroup
> in a reasonable nature. Unlike the rest that seem to get caught up in the
> tastes great vs less filling type arguments.

Much appreciated. Zane will likely disagree with me on this score, but I'm sure
he'll appreciate hearing that as much as I did regardless.

> The funny thing is that my prospective clients for my commercial app always
> ask about technology. Up until now I'll answer MS written in VB and using
> SQL and they'll nod and agree. Not because they no anything but because the
> media and the marketing muscle around the world has told them, similar to
> IBM in the 70's, noone ever lost their job buying MS.

I think that's changing, and somewhat rapidly. Just as it dawned on folks in the
late-80s/early-90s that perhaps IBM wasn't operating in *their* best interests, the
same is happening now with Microsoft. Do I really need to go beyond mentioning the
self-destruct mechanisms in their latest OS and Office packages to convince you
(rhetorical you) of that? I defended them relentlessly during the DOJ scandal, but
right after they seemed to come out of that, there was one revelation after another
of (what I considered) consumer abuse. That was embarrassing.

> I feel cauget between a rock and a hardplace.

Yep.

> If I migrate to .NET I will be forcing my apps direction
> to be dictated by the folks at MS. If I go with a Borland or other technology,
> than I'll get the inevitable "Who's that" from my client and I feel that
> it could affect my prospective clients buying habits (all other things being
> equal).

Well, if Borland call pull off what they suggest they want to do, you can still
answer ".NET" and folks needn't know the gritty details. <g> ****, I really like
their full story, though! Having a single sourcebase compilable to Win32 and/or
Linux is enough for me! If/when .net becomes acceptable, yeah okay, flip that switch
too. It's about the best leverage anyone is offering today. Vapor, to be sure,
still, but definitely something to keep an eye on. I guess what I'm really saying is
that you don't really need to feel a rush right now. I'd just tell clients that the
jury's still out.

> Know anyone that wants to work on a project to write a VB like language and
> take advantage of the seemingly obvious opportunity to fill a void that MS
> has left? <bg>

Don't I wish. <g>

Good luck... Karl
--
[Microsoft Basic: 1976-2001, RIP]

[Patrick Troughton]

Hi Kevin,

If I may ask a couple follow-up questions...

Your primary concerns are...

- Lack of static linking
- Future versions of the .NET Framework might not be backward compatible

Is that correct? Is there anything else you consider to be a potential showstopper
that you're worried about? Also, how do you currently distribute your application
(CD, internet, etc.)?

/Pat

"Kevin Moore" <Kevin@MooreSSI.com> wrote:
>
>Hi,
>
>I just wanted to get up on my soap box and offer some insight into my world
>and hopefully get some feedback from y'all. I have been developing app for
>the last 12 years, the last 6 of which has been predominantly with MS technologies
>focusing on VB and SQL. I split my time between consulting to clients and
>developing commercial apps. For my commercial app I use VB (6) and SQL 7/2000
>and have been doing so for several years. For my consulting I use C++, COM+,
>ASP or whatever the client chooses.
>
>Now onto the rant. Within the scope of my commercial app, I chose VB because
>it was simply one of the best RAD tools on the market, I could accomplish
>all of my goals, quickly and easily and I was able to migrate through the
>various release moving from VB3 -> VB4 -> VB5 to finally VB6. Along the
way
>I enjoyed taking advantage of newer technologies that MS has implemented
>with the language, eg VB5 native compiler and VB6 COM+ integration, VB4
classes
>(ok not really due to the problems, but close). Now I come to .Net and I
>must say from my commercial app point of view I am quite disappointed. Just
>to clarify I have been working with .Net Beta 2 since last Sept. When I
first
>heard about .Net I was hoping that MS would go the way of Delphi in offering
>Static linking and remove us from the dependecy on MSVBVMx.DLL, when I heard
>about the CLR I was initially pessimistic. Over the time my pessimism has
>turned to downright frustration.
>
>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.
>
>For the sake of my commercial apps I am left with some choices and I would
>hope that y'all might offer some other insight.
>
>1. Move to .Net, continue the learning cycle of VB.Net and hope that MS
deals
>with the CLR correctly.
>2. Move to Delphi and learn another language
>3. Stay with Classic VB and become antiquated (not really an option)
>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)
>
>Not sure what else to say. Thanks for reading .
>
>Kevin

[Kevin Moore]

Hi Patrick,

Thanks for your response. I'll answer your questions inline:

"Patrick Troughton" <Patrick@Troughton.com> wrote:
>
>Hi Kevin,
>
>If I may ask a couple follow-up questions...
>
>Your primary concerns are...
>
>- Lack of static linking

1. This is really an issue of choice. I am concerned that in the commercial
app part of my world, I have no choice with distribution strategy for my
clients. If I use .Net I must distribute with the CLR, no if ands or buts
about it. I would prefer the ability to choose and implement a strategy that
is best for myself and my clients. Not one that is determined by people at
another company.

>- Future versions of the .NET Framework might not be backward compatible

2. Basically yes, I have been burned with DLL **** from MS and I have doubts
that they will deliver on all they promise. I also have issues with this
strategy, but that relates more so to # 1.

>
>Is that correct? Is there anything else you consider to be a potential showstopper

I didn't mention in my original post, but there are alot of things I like
about .Net. Most of them have been discussed here, a small list: true OO,
try/catch and other language improvements.

>that you're worried about? Also, how do you currently distribute your application

I currently distrbute the app on CD, so the 20Mb isn't as much of an issue
for the initial distribution. When a new feature is released though and I
want to update various client machines, getting them to D/L 20Mb+ for an
update is a royal pain in the a??. I am also looking at some new web-based
deployment technologies.

I guess it all mainly relates to my first answer, choice. I would like to
choose what is the best for me.

Thanks for you response. Hopefully you have some comments/suggestions.

Kevin


>(CD, internet, etc.)?
>
>/Pat
>
>"Kevin Moore" <Kevin@MooreSSI.com> wrote:
>>
>>Hi,
>>
>>I just wanted to get up on my soap box and offer some insight into my world
>>and hopefully get some feedback from y'all. I have been developing app
for
>>the last 12 years, the last 6 of which has been predominantly with MS technologies
>>focusing on VB and SQL. I split my time between consulting to clients and
>>developing commercial apps. For my commercial app I use VB (6) and SQL
7/2000
>>and have been doing so for several years. For my consulting I use C++,
COM+,
>>ASP or whatever the client chooses.
>>
>>Now onto the rant. Within the scope of my commercial app, I chose VB because
>>it was simply one of the best RAD tools on the market, I could accomplish
>>all of my goals, quickly and easily and I was able to migrate through the
>>various release moving from VB3 -> VB4 -> VB5 to finally VB6. Along the
>way
>>I enjoyed taking advantage of newer technologies that MS has implemented
>>with the language, eg VB5 native compiler and VB6 COM+ integration, VB4
>classes
>>(ok not really due to the problems, but close). Now I come to .Net and
I
>>must say from my commercial app point of view I am quite disappointed.
Just
>>to clarify I have been working with .Net Beta 2 since last Sept. When I
>first
>>heard about .Net I was hoping that MS would go the way of Delphi in offering
>>Static linking and remove us from the dependecy on MSVBVMx.DLL, when I
heard
>>about the CLR I was initially pessimistic. Over the time my pessimism has
>>turned to downright frustration.
>>
>>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.
>>
>>For the sake of my commercial apps I am left with some choices and I would
>>hope that y'all might offer some other insight.
>>
>>1. Move to .Net, continue the learning cycle of VB.Net and hope that MS
>deals
>>with the CLR correctly.
>>2. Move to Delphi and learn another language
>>3. Stay with Classic VB and become antiquated (not really an option)
>>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)
>>
>>Not sure what else to say. Thanks for reading .
>>
>>Kevin
>

[Kunle Odutola]

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

<SNIP>

> For my commercial app I use VB (6) and SQL 7/2000
> and have been doing so for several years. For my consulting I use C++,
COM+,
> ASP or whatever the client chooses.

OK, you've established that picking up new languages (or dialects) isn't
likely to be a barrier for you.

> 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.

They haven't seriously done the open standard thing for their development
tools before as well.....

> For the sake of my commercial apps I am left with some choices and I would
> hope that y'all might offer some other insight.
>
> 1. Move to .Net, continue the learning cycle of VB.Net and hope that MS
deals
> with the CLR correctly.

I would actually recommend C# and not VB.NET. The are aimed at different
segments of developer-world and you fit into either camp. But you already
expressed serious doubts based on past evidence so.....let's scrap this.

> 2. Move to Delphi and learn another language

Given Borland's decision to support .NET, if Delphi can be made to spit out
IL in addition to i386+ code then this would seem to give effortless choices
in terms of deployment options - ship native executables or IL assemblies .
Or even ship to Linux.

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

You're right that this is [really] only a sensible short-mid term option.

> 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)

No need to pray. Most dev tools allow you to decide what features to include
in your app - can't remember a tool that forced me to have a GUI in my
console app <g>. So distribution/deplyment options seems to be the crux for
you.

Well, for my money in terms of offering what you feel you need (static vs
dynamic linking):
a) C++ already offers that option. But your productivity will likely take a
dive. And there is no code migration support.
b) There is _talk_ that C# might be added gcc's list of front-ends - with a
view to producing native code - but I see no concrete signs of that yet. And
there is no code migration support. Actually this is untrue, decompilers can
produce C# source from your VB.NET assemblies for you ;-)
c) You could write in Java and use ArtInSoft's JCLA EE to convert to C#. For
EVERY release ;-)
d) VB.NET allows you continue to use most of your VB skills but there is no
native exe option. Cleanest upgrade path.
d) Borland promises that Delphi will generate .NET code. IMHO it isn't as
productive as C# or VB.NET. There are VB2Delphi code conversion tools but,
if the .NET framework libraries are hidden away behind Delphi's own VCL, I'd
be wary. It is the most flexible in terms of code deployement options
though - i386+, .NET or Linux (via Kylix). Assuming Borland can deliver....

So, what to choose, if "static vs dynamic linking" is a hard requirement
choose Delphi. If not then flip a coin between C# and VB.NET. Remember,
VB.NET has a code migration wizard but so does C# ;-)

Kunle

[Kevin Moore]

Kunle,

Thanks for your response. You have made some strong points and I appreciate
the clarification. I feel that static vs dynamic linking is a pretty big
issue, but that relates to another issue about choice. I feel that MS has
predetermined one route and only one route for software development. I am
not a big fan of being forced to choose, I am also pretty stubborn and find
some resistance to MS because of this.

I appreciate your comments about C++, I finished up a year long project integrating
C++, VB and COM+, it was pretty interesting and a good learning experience.
I did find that from a productivity point C++ was difficult compared to VB.
But once I got up to speed on it I became reasonably productive. Part of
the reason for me staying away from C++ and looking at VB was because of
the low-level memory manipulatin type stuff. I found it much easier and more
productive using VB.

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


"Kunle Odutola" <kunle.odutola@<REMOVETHIS>okocha.freeserve.co.uk> wrote:
>
>"Kevin Moore" <Kevin@MooreSSI.com> wrote in message
>news:3c6da552$1@10.1.10.29...
>>
>> Hi,
>
><SNIP>
>
>> For my commercial app I use VB (6) and SQL 7/2000
>> and have been doing so for several years. For my consulting I use C++,
>COM+,
>> ASP or whatever the client chooses.
>
>OK, you've established that picking up new languages (or dialects) isn't
>likely to be a barrier for you.
>
>> 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.
>
>They haven't seriously done the open standard thing for their development
>tools before as well.....
>
>> For the sake of my commercial apps I am left with some choices and I would
>> hope that y'all might offer some other insight.
>>
>> 1. Move to .Net, continue the learning cycle of VB.Net and hope that MS
>deals
>> with the CLR correctly.
>
>I would actually recommend C# and not VB.NET. The are aimed at different
>segments of developer-world and you fit into either camp. But you already
>expressed serious doubts based on past evidence so.....let's scrap this.
>
>> 2. Move to Delphi and learn another language
>
>Given Borland's decision to support .NET, if Delphi can be made to spit
out
>IL in addition to i386+ code then this would seem to give effortless choices
>in terms of deployment options - ship native executables or IL assemblies

[Kunle Odutola]

"Mike Mitchell" <kylix_is@yahoo.co.uk> wrote in message
news:3c6dadeb.18621587@news.devx.com...

> Linux reigns supreme in the server world,

Only in what passes for your mind Mike.

Kunle

[Tom Shelton]

Good thing Perl runs under .NET . Seriously, I love Perl, but it is my
impression that it is sort of begin replaced in the web world with
ASP/JSP/PHP. I could be wrong, I haven't had any Perl work for about a year
now, and that is what is giving me that impression I guess.

Tom Shelton

"Michael D. Kersey" <mdkersey@hal-pc.org> wrote in message
news:3C6DBA09.6C499148@hal-pc.org...
> Notes inline...
> Kevin Moore wrote:
> > Now onto the rant. Within the scope of my commercial app, I chose VB
because
> > it was simply one of the best RAD tools on the market, I could
accomplish
> > all of my goals, quickly and easily and I was able to migrate through
the
> > various release moving from VB3 -> VB4 -> VB5 to finally VB6.
>
> You slipped here: the best choice would have been PowerBuilder, which
> remains the best Windows client/server development tool today.
>
> > 1. Move to .Net, continue the learning cycle of VB.Net and hope that MS
deals
> > with the CLR correctly.
> > 2. Move to Delphi and learn another language
> > 3. Stay with Classic VB and become antiquated (not really an option)
> > 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)
>
> If you'll be doing web apps, use Perl (which runs under Windows or Linux
> or Unix). Perl has everything *today*: web services, XML, SOAP, UDDI,
> thousands of web and client/server utilities that Microsoft products
> simply don't have: see the CPAN libraries of tested and thoroughly
> debugged code at
> http://www.cpan.org/
> or better, search to see what's available at
> http://search.cpan.org/
>
> Perl is also used for client/server development: there are Perl/TK
> libraries in CPAN that are used for C/S development.
>
> Perl is undergoing changes today: a new Perl 6, with significant
> changes, is in the works. Now is a good time to find out what's
> happening and to get up to speed with a real web language.

[Robert Scoble]

>is plan to forget Windows long term.

Interesting you should say this. .NET to me looks like Microsoft's plan for
the day when we all forget Windows. After all, let's say we all move to OS
X. All Microsoft has to do is build a CLR for that OS and all our apps will
move to it.

But, I don't see Windows going away anytime soon. I have continued to watch
the Linux market very closely and I just don't see anyone normal moving to
it (normal being "non technical"). If anything Apple's OS X is stealing even
some of the die hard Linux fans back. Linux isn't gaining users on the
desktop and it's arguable whether it's gaining market share on the server
too. My friends who are analysts are noticing that Linux is losing
server-side market share too.

> I read several trade
> newspapers in the UK and it's obvious that more and more companies are
> looking (desperately, it has to be said) at alternatives to Windows.

I'd like to see who's writing these articles. Yes, companies want to get
away from paying the "Windows Tax" but really, what are the alternatives?
Linux? Give me a break. The retraining costs alone would outstrip the $100
you'd save per desktop. Not to mention that Linux needs far more tech
support per machine and really can't support the wide variety of hardware
that's already deployed on enterprise desktops. Heck, it's taken Microsoft
10 years to get NT to do a decent job of supporting all the hardware.

> The obvious choice has to be Linux (mainly because it's about the
> *only* choice apart from Apple).

Actually I'm seeing Apple's OS X making some gains in the corporate world.
It really is a nice OS. Certainly nicer for a desktop user than any form of
Linux (and the new PowerBooks have even die-hard VB developers drooling -- I
was just at breakfast with several of them here at VSLIVE and a few said
they were considering getting PowerBooks cause they liked the way the
machines looked and worked).

>Linux reigns supreme in the server
> world,

You live in a different world than I do. Yeah, Linux is used a lot at ISPs
(Sonic.net, my ISP, for instance, uses Linux exclusively but really, ISPs
don't serve as platforms for corporate developers and just need a way to
give users 10MB of server space for an incredibly low cost). But look at the
corporate market and I don't think you'll see near as many Linux boxes as
you might expect. Even at UserLand, which does use Linux boxes, they are
used for just basic Web serving tasks and not as a development platform. So,
if you are looking at just sheer numbers of boxes deployed you'd be getting
an incomplete, and misleading, picture.


>but still has a long way to go in the desktop application
> market.

Understatement of the year.

>One thing Linux is crying out for is well-designed,
> well-crafted, easily installed applications of all kinds.

Duh.

And the corporate types won't invest until at least 50% of the desktops are
running an OS. Heck, Apple has somewhere around 5 to 10% and it still
struggles in the corporate world (Apple has many times more corporate
desktops than Linux does).

> Your apps,
> ported to Linux, e.g. using Kylix, which is compatible with Delphi 6,
> *could* possibly be the fuse that helps to set the Linux desktop world
> alight!.

Nope. Corporate apps are the tail. You gotta get the mouth of the dog first.
How do you get people to push Linux onto desktops? Get them to use Linux at
home. That means you need killer applications for the home market. I haven't
seen anything "killer" come out for Linux yet (and, if you've had a chance
to look at Microsoft's new Tablet computer, coming out next year, you'll
realize that Linux is gonna be behind in the home market for probably
forever). When the next "big video game" or "music application" or "digital
photography application" comes out for Linux (and stays exclusively on Linux
for 18 months or so) then we can talk. I don't see that happening anytime
soon.

Don't think that matters to the corporate market? Bull.

I saw Windows 95 get deployed at home way before it got deployed in the
workforce. That's precisely what's happening with Windows XP too. Folks are
getting it at home and then forcing their IT departments to react "why the
**** do I have an OS at home that doesn't crash when you're forcing me to
stick with Windows ME here at work?"

>You could be in there at the ground floor as the lift starts
> its inevitable rise to the top.

Keep dreaming. Actually, if you wanna go anti-Microsoft you should take a
second look at Mac OS X. It's far superior to Linux for the desktop. Heck,
look at Doc Searls. He's the Editor of one of those Linux magazines. He
admitted to me that he uses OS X on a PowerBook and never uses Linux on the
desktop anymore. http://doc.weblogs.com/

Robert Scoble

###

[Kathleen \(MS MVP\)]

Karl,

Well, I got back to town to find I agree and disagree.

> I have trouble with these being two different choices. Seems to me that
nearly
> everyone, except those in Redmond, agrees that moving to .NET *is*
learning a
> language.

Agree. A great new language, btw.

> You've no doubt found many instances where identical code produces
> different results, or where previously valid designs now execute in random
order.

You know this is what I fought for. Migrated code should fail or produce
nothing. But I really didn't think we were that far off. I know there are
tons of places the code won't run, and I know Integer/Long is going to cause
problems. But where else does the code run and give different results. Head
games are not good. Also, there are places that events fire differently,
but where have you heard it is random other than DF?

Kathleen

[Kathleen \(MS 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.

You are missing the point here. You create your app against a particular CLR
and mark it as such. If MS screws up the CLR in the next release of it (I
expect these releases to be fairly slow) you can just let your users
download both (if something else runs on the new CLR). They are independent,
with some fairly fancy stuff allowing granularity in what version is used. I
am with you in thinking that MS is capable of mistakes. I was here in the
VB4 days. But the one of the good things about .NET is that you are no
longer wed to a single DLL that you have to trust for backward compatibilty.

I'll post a separate message about cost that I hope you will read. It is
partially in response to this, but I want to head a thread with it.

Kathleen

[Kevin Moore]

Kathleen,

I appreciate your response. I do have issues with the CLR and if I mis-understand
what you are saying please correct me. For example, say I have an app that
is 4 Mb in size. If I generate my app against V1 of the CLR and distribute
it, everything is fine, I have a 24 Mb release. MS release a service pack
to the CLR, lets call it V2, and it corrects a feature I wanted to use. I
recompile my app against V2 and release the change, but to ensure backward
compatibility, I have to release the V1 framework and the V2 framework, which
assuming 20Mb for each CLR, creates an install size of 40 Mb + my 4 Mb app
size. If my above example is correct, obviously you can see the inherent
problems with it. For every CLR release I have to update the entire CLR and
add another 20Mb to my app.

Kevin

"Kathleen \(MS MVP\)" <someone@nomail.com> wrote:
>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.
>
>You are missing the point here. You create your app against a particular
CLR
>and mark it as such. If MS screws up the CLR in the next release of it (I
>expect these releases to be fairly slow) you can just let your users
>download both (if something else runs on the new CLR). They are independent,
>with some fairly fancy stuff allowing granularity in what version is used.
I
>am with you in thinking that MS is capable of mistakes. I was here in the
>VB4 days. But the one of the good things about .NET is that you are no
>longer wed to a single DLL that you have to trust for backward compatibilty.
>
>I'll post a separate message about cost that I hope you will read. It is
>partially in response to this, but I want to head a thread with it.
>
>Kathleen
>
>