Re: XP? I think not!
From: Al Reid (areidjr_at_reidDASHhome.com)
Date: 06/25/04
- Next message: J French: "Re: Error -2147024822 - Out of memory"
- Previous message: Jan Hyde: "Re: How to use Index in Recordset"
- In reply to: Joshua Trupin \(MSDN Magazine\): "Re: XP? I think not!"
- Next in thread: Peter Young: "Re: XP? I think not!"
- Messages sorted by: [ date ] [ thread ]
Date: Fri, 25 Jun 2004 07:44:19 -0400
"Joshua Trupin (MSDN Magazine)" <http://msdn.microsoft.com/msdnmag> wrote in message news:OYwU2UlWEHA.3800@TK2MSFTNGP11.phx.gbl...
> "Peter Young" <youngpa@comcast.no.net.spam.please> wrote:
> > It's nice to see you participate here. I'd like to comment on your
> rebuttal:
> >
> > > "Just like Visual Basic before it, .NET makes things easier"
> >
> > Easier compared to what? Compared to VB, it's harder.
>
> That's true. Sometimes I use the word "things" lazily. Visual Basic made
> programming for Windows easier. And I feel that .NET made programming for
> Win32 easier as well. I didn't mean that .NET made Visual Basic easier,
> because of that leap between Visual Basic 6.0 and Visual Basic .NET.
>
> Part of the point I was trying to convey in all of this is that the magazine
> isn't responsible for making things more difficult, and we're not leading a
> "camp." It's actually the reverse. We react to what's coming down the pike,
> and it's our responsibility to provide the information that reduces the
> learning curve for people who choose to go in that direction. It would be
> the wrong editorial choice for us to say "Well, guess what? We like VB6 so
> that's all we're going to cover."
>
> We also treat the publication as archival. We don't cover older versions of
> Visual Basic now, but our past coverage (back to 1996) is still available
> online, in its entirety, at no charge. We don't erase what we've done in the
> past for the purposes of pretending it doesn't exist anymore, and that's
> gotten us in trouble in a few places. (It's even our policy not to
> slipstream new information - anything more serious than a spelling
> correction will be updated and posted on our Corrections page at
> http://msdn.microsoft.com/msdnmag/correct.aspx.)
>
> > Compared to the "pain-in-the-ass hard" serial comms using the Win32 API
> (not arguing with that summary) it's *not* any
> > easier, because it doesn't even support it! It took one of us to write a
> wrapper! That's not progress.
>
> That's true, and part of my exasperation at the time was that I was sitting
> there with a GPS device, just dying to see how my existing program would
> look in .NET, and I couldn't get to the serial comm stuff, and wrapping the
> ActiveX control was a fresh hell all its own. However, the Win32 calls were
> still available to wrap, making it a wash in that one particular area. And
> in one way, it made it easier to know that if I couldn't find serial comm in
> System.IO, it wasn't there and I'd need to figure out the workaround. If I
> were still fighting my way through the Win32 API, I'd be staring at the
> CreateFile definition and thinking "Oh, come on - there has to be some
> easier way to do this." I know, it didn't help my problem at hand.
>
> > Compared to edit-and-continue in VB, it sucks. Not even the upcoming
> release truly has this. (Try it in C#, try it in
> > ASP.Net where you *really* need it.)
>
> I miss edit-and-continue too.
>
> > Compared to distributing a VB6 app, it's harder.
>
> I think that distribution ease ebbs and flows. I was on a project back in
> 1995 (I think) where we had to distribute OLE controls and some VB code. But
> that meant that we had to put the OLE DLLs on the installation. And my PM
> wanted it on a single floppy, and it just didn't fit. I know this example
> doesn't have that much to do with your point, but I'm still bitter about it.
>
> > You get the idea. VB did not need to be sh!tcanned. It needed to be
> improved. I agree completely with Joel's article's
> > points. Stability/compatibility is important. New features that serve only
> to preserve Microsoft's revenue stream at the
> > expense of the developers that helped build the empire are not helping us
> one bit.
>
> I do get the idea, and I'm always willing to exchange polite views on what
> we should be covering in the magazine (you can discuss it here or send me
> email directly, either way). I didn't really want to attack Joel's thesis
> because I don't like to argue just for argument's sake. I was just a bit
> surprised when our publication started popping up everywhere last week, and
> wanted to give my personal angle on the whole discussion.
>
> > > "I look at that Win32 CreateFile version and I just don't see why it's a
> shame that that call is consigned to the
> > dustbin of obsolescence by a .NET class wrapper."
> >
> > It's not a shame that it gets wrapped in an easier-to-consume form. It is
> a shame if it's obsoleted, breaking existing
> > code, when there is no advantage to anyone but Microsoft (and digital
> rights owners) to using the replacement
> > (Longhorn). What, we need 3D in our UI? Puleeeze.
>
> Of course, some people don't feel we need UI either. Anyway, this is the
> thing about the magazine's charter. When people get a public beta of
> Longhorn, thousands of people will want to crack it open and see what's
> inside, what it's like to program with it, and how it will eventually change
> their lives if they target it. And that's why we'll be covering it at that
> point - it'll be the story. It won't make all our previous coverage of
> Windows 2000 go away, and some of the material we run will be used by people
> who are trying to decide whether to make the leap now or later. We're very
> much aware of where we sit in the industry, and we make it a point to reach
> out to as many readers as we can to find out how we can best help them. But
> we're not a camp! I haven't made a gimp bracelet in decades.
>
>
Josh,
I, for one, thank you for presenting your thoughts on this issue. As you are not the architect of .Net, I do net feel compelled to
"shoot the messenger."
Like many other long time VB programmers, I was disappointed at the demise of the "Classic" VB programming language. In many ways I
felt, and still feel, betrayed. I agree that there are some neat features in .Net AND if one does not have a substantial investment
in legacy code that would need to be ported (at best) or rewritten (at worst), I believe that the migration to .Net would be
relatively painless. Unfortunately, one accumulates a whole lot of code assets in 10+ years that are hard to part with and
expensive to rewrite.
I can develop a VB app in a fraction of the time in VB6 opposed to VB.Net because, for the most part, I have done it all before and
have a ready to use libraries of procedures and functions available to build the application. The problem is that I can not afford
to migrate the code to the new platform only to find out that in a couple of years it will be obsolete again.
It is not that I do not like VB.Net. There are things about it that I like better than VB6 and there are things I really miss that
were there with VB6. But, from a practical standpoint, it makes no sense for me to take that route. I have yet to have any
customer ask me to produce an application using .Net. My customers want functionality at a proper price point. No one seems to
care what language I use to develop in as long as I meet the expectations set forth in the functional specification, meet the
deadlines and produce a stable product. So here is where I am today.
Web Services: .NET for sure
Web Apps: .NET probably
Desktop, Client Server, 3-Tier: .Net no way.
I guess that this is the end of my rant.
-- Al Reid "It ain't what you don't know that gets you into trouble. It's what you know for sure that just ain't so." --- Mark Twain
- Next message: J French: "Re: Error -2147024822 - Out of memory"
- Previous message: Jan Hyde: "Re: How to use Index in Recordset"
- In reply to: Joshua Trupin \(MSDN Magazine\): "Re: XP? I think not!"
- Next in thread: Peter Young: "Re: XP? I think not!"
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|
