Re: Cat among the pigeons......
From: Dan Barclay (Dan_at_MVPs.org)
Date: 07/16/04
- Next message: Dan Barclay: "Re: Cat among the pigeons......"
- Previous message: Davids: "suggestions for "freezing" a development snapshot"
- In reply to: zedd: "Re: Cat among the pigeons......"
- Next in thread: Craig Stuntz [TeamB]: "Re: Cat among the pigeons......"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Fri, 16 Jul 2004 14:37:42 -0500
"zedd" <nospam@for.me> wrote in message
news:40f78030$1@newsgroups.borland.com...
> > You hang out in a different crowd than I do.
>
> Probably. I know very few large scale apps that are purely VB,
> most VB uses I see and know of are for small scale utilities,
> processes, helpers, services or UI wrappers here or there:
> in other words a lot of scattered uses, where VB is essentially
> used as an UI generator for some "real stuff" written in other
> languages (being it C++, Oracle DB, etc)
>
> > No, VB will give them more language changes.
>
> I don't think so, it's much easier to port to VB.Net than to port
> to Delphi.Net, essentially because the code you're starting with in
> VB was simpler, already garbage-collected and did not have the
> complexities you can encounter in Delphi code.
Obviously I'm not being clear enough.
When somebody ports from VBClassic to VB.Net they will have to rewrite their
app. THEN in a couple of years they will have to rewrite it AGAIN for the
next version of VB. Then, 3 to 5 years later they'll get to do it again
(again). That's not FUD. There is a history that confirms this, and
organizational reasons that will make it happen.
On the other hand, when somebody ports from VBClassic to a more stable
language, they have only to port once. That's whether they port to C++,
Delphi, FORTRAN, or some other stable language. Note that I didn't list C#
as the jury is still out on that one.
VB is fast to develop in. But, so far I have found no faster development
process than to REUSE functions I've already written and debugged.
> > They promised us they wouldn't do it again after VB4, but here we are
again
> > (again).
>
> Can't say much, ported a VB3 app to VB6 a few years ago (about 150k
lines),
> it was a two-day job... I don't call that a difficult port.
If that VB3 app used binary data then what you did is documented to be
unsafe from corruption, unless you rewrote the code to use byte arrays
instead of $trings. Everywhere. Prior to VB4 (including versions of Basic
going back to CP/M) they only documented way to handle binary data was using
$trings. With VB4/32 they changed a fundamental data type. Strings were
wired to UNICODE under the hood and the conversions back and forth are
unsafe. It's documented in the VB docs. Did you know that? If you're
lucky your customers won't hit the right configuration to cause them a
problem. A lot of us have been lucky, but the core data type was changed
(generally considered a bad thing) and the code is unsafe.
But, then, maybe it's just me that handles binary data.
> > See above. Windows, for example, ran on DOS. They called it an OS, but
it
> > wasn't. In fact, truth be told, it was really a program that spent its
> > time calling subroutines (apps) with parameters (messages).
>
> Yes, it wasn't because it could be bypassed (at least on 386+), the only
> true OS layer was the BIOS in those days.
Exactly. The OS does one thing and the library does another. Whether or
how you separate those functions, does it make a difference? They are
still separate functions. Windows (even the latest the blend the lib and
OS) is still both a library and an OS. To the app it is a "platform".
Ahh, hell. They're all just microcode JMPing and CALLing libraries and
drivers anyway.
> > Delphi is pretty much written in Delphi so I assume one or two of them
> > understand it.
>
> As far as I understood, this is no longer the case, the Delphi 8 IDE
> was said to be a mix of different languages, and judging from the blogging
> habits of some core Delphi developpers, I guess at least some of them
> are now using primarily C#.
> So that's an advantage that is on the wane, not to forget that a good
chunk
> of the compilation and library development work is no longer handled by
Borland
> for Delphi.Net, but by MS engineers that certainly don't use Delphi.
Deja vu all over again?
Dan
- Next message: Dan Barclay: "Re: Cat among the pigeons......"
- Previous message: Davids: "suggestions for "freezing" a development snapshot"
- In reply to: zedd: "Re: Cat among the pigeons......"
- Next in thread: Craig Stuntz [TeamB]: "Re: Cat among the pigeons......"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
