Nice - But We Want More!!

[Adam Young]

OK - it all sounds nice, but let's think about these new features for a second.
Web Forms - sounds like what we can do already in InterDev. It looks like
InterDev is being merged with VB, so I imagine this means InterDev is going
out of the window. Frankly, this has to be a good thing - InterDev just doesn't
cut it. If they can make it as easy to create DHTML pages as it is to create
standard apps (i.e. do what they've failed to do with InterDev), then great
- but I doubt they'll manage it.

The new oo features sound nice, but if Inherits does for VB inheritance what
Implements did for VB polymorphism, then it's going to be another one of
those half baked VB features barely anyone uses (like web classes, IIS applications,
and a host of others I don't have time to mention).

What we really want is: 1) to get rid of the VB runtime and its associated
overhead. There's a product called Fusion from BitArts that lets you package
up ALL your dependent files into a single compressed exe, so all you need
to distribute is one file - if they can do it, why can't Microsoft? 2) Faster
string and integer handling (Why isn't this as fast as C??). 3) The ability
to create app wizards, and Management Console snap-ins (like you can in VC++).
3) A faster, better compiler. 4) The Windows API fully 'built in' and accessible
from VB. VB Developers have grown up now - We don't need to be protected
from complexity!

[Tom Barnaby]

"Adam Young" <x.x@x.com> wrote:
>What we really want is: 1) to get rid of the VB runtime and its associated
>overhead. There's a product called Fusion from BitArts that lets you package
>up ALL your dependent files into a single compressed exe, so all you need
>to distribute is one file - if they can do it, why can't Microsoft?

If you are talking about static linking, then I'm all for it. If you want
Microsoft to emulate the Fusion product ... no thanks. Its not the same,
and will NOT save you from DLL **** like true static linking could.

[Colin McGuigan]

Adam Young wrote in message <38d14dab$1@news.devx.com>...
>The new oo features sound nice, but if Inherits does for VB inheritance
what
>Implements did for VB polymorphism, then it's going to be another one of
>those half baked VB features barely anyone uses (like web classes, IIS
applications,
>and a host of others I don't have time to mention).

With the exception that you can only Implement interfaces that inherit
directly from IDispatch, VB's Implements isn't really half-baked. I use it
quite a lot, as do many others in vb.oop

>What we really want is: 1) to get rid of the VB runtime and its associated
>overhead. There's a product called Fusion from BitArts that lets you
package
>up ALL your dependent files into a single compressed exe, so all you need
>to distribute is one file - if they can do it, why can't Microsoft?

At first I was impressed, but, really...what's the big deal about Fusion?
You don't get any space savings. It's less secure than a setup program,
because it may very well overwrite files...and it appears to GPF quite a
lot.

>2) Faster string and integer handling (Why isn't this as fast as C??).

Because VB does preventive error checking for you that C doesn't (eg,
overflow checks, out-of-bound checks, etc). The only optimization that I
think might be improved is getting a character out of a string; Mid produces
a lot of unneeded overhead here.

>3) The ability to create app wizards, and Management Console snap-ins (like
you can in VC++).

>3) A faster, better compiler.

Let's not count the fact that there are two 3)s, but...what do you mean, a
faster, better compiler? How would you propose to make it faster? What do
you mean by better? One thing I'd like to be able to do is to assign the
optimizations on a module or procedure level; so that I can take out (for
instance) integer overflow checks from my MMath.bas module, where I'm damned
sure they're not going to happen, but leave them in the rest of the code.

>4) The Windows API fully 'built in' and accessible from VB. VB Developers
have grown up now - We don't need to be protected
>from complexity!

TMS thinks we do. =) I agree, though it's not as easy as you might think
(SendMessage is a good example).

--
Colin McGuigan

[Vlad Ivanov]

>2) Faster
>string and integer handling (Why isn't this as fast as C??)
>3) A faster, better compiler.

Allow me to disagree. There's plenty of tools that can deliever improved
performance while not being as complex as MFC. Delphi, Powerbasic, C++ Builder.

VB is not a language for calculation intensive apps. Use one of the above
in places where extra boost is needed.

I build n-tier/web apps. And to be perfectly honest i'd rather part with
20% of performance but to gain n-tier debugging features. Oh yes, i'll let
it be 30% slower, but do away with distribution nightmare. 25% decrease in
performance for comprehensive error handling built-in? Yes!

We have 1Ghz processors now. In ten years we will have 10Ghz processors.
It costs around 800$ to add another 1Ghz processor. Plug it in, and forget
about it.

But the developer rates are only going to rise.

[Vlad Ivanov]

> There's plenty of tools that can deliever improved
> performance while not being as complex as MFC.

Opps. I meant VC (Visual C++). Or any other C/C++ compiler not oriented towards
RAD like C++ Builder or other tools i have mentioned.

[Mattias Sjögren]

Adam,

>3) The ability to create app wizards, and Management Console snap-ins (like you can in VC++).

You can do that already, with the MMC designer for VB. There's an old
beta available from

http://www.microsoft.com/management/mmc/vb6designer.htm

The final version is included in the January 2000 Platform SDK.


Mattias

__________________________________________________
Mattias Sjögren (MCP) - mattiass @ hem.passagen.se
VB+ http://hem.spray.se/mattias.sjogren/
Please send questions/replies to the newsgroups

[Miha Markic]

.. 4) The Windows API fully 'built in' and accessible
> from VB.

Ahhhh. That would be really cool.

Miha

[Alan Gillott]

Trouble is, the rumor mill says it's the VB UI that's going and we will be
stuck with the Interdev UI. I just hope it is up to or better than the
current VB UI or I for one will squalk very loudly.

Adam Young <x.x@x.com> wrote in message news:38d14dab$1@news.devx.com...
>
> OK - it all sounds nice, but let's think about these new features for a
second.
> Web Forms - sounds like what we can do already in InterDev. It looks like
> InterDev is being merged with VB, so I imagine this means InterDev is
going
> out of the window. Frankly, this has to be a good thing - InterDev just
doesn't
> cut it. If they can make it as easy to create DHTML pages as it is to
create
> standard apps (i.e. do what they've failed to do with InterDev), then
great
> - but I doubt they'll manage it.
>
> The new oo features sound nice, but if Inherits does for VB inheritance
what
> Implements did for VB polymorphism, then it's going to be another one of
> those half baked VB features barely anyone uses (like web classes, IIS
applications,
> and a host of others I don't have time to mention).
>
> What we really want is: 1) to get rid of the VB runtime and its associated
> overhead. There's a product called Fusion from BitArts that lets you
package
> up ALL your dependent files into a single compressed exe, so all you need
> to distribute is one file - if they can do it, why can't Microsoft? 2)
Faster
> string and integer handling (Why isn't this as fast as C??). 3) The
ability
> to create app wizards, and Management Console snap-ins (like you can in
VC++).
> 3) A faster, better compiler. 4) The Windows API fully 'built in' and
accessible
> from VB. VB Developers have grown up now - We don't need to be protected
> from complexity!

[Adam]

I read an interview with the development manager for the InterDev/VJ++ UI
team. In it he said that that UI will be replacing the C++ and the VB UI's
and they will all be integrated under 1 roof. Looking at the UI they were
using in the keynote demo I think proves it.

I for one will be glad to have that UI, I think it's fantastic. Funny thing
is that I see a lot of hard core Java people, who hate Windows and MS, use
VJ++ just because it has a better interface that most other Java IDE's.
I think that bodes well.

Adam Ruth

"Alan Gillott" <agillott@tact.com> wrote:
>Trouble is, the rumor mill says it's the VB UI that's going and we will
be
>stuck with the Interdev UI. I just hope it is up to or better than the
>current VB UI or I for one will squalk very loudly.
>
>Adam Young <x.x@x.com> wrote in message news:38d14dab$1@news.devx.com...
>>
>> OK - it all sounds nice, but let's think about these new features for
a
>second.
>> Web Forms - sounds like what we can do already in InterDev. It looks like
>> InterDev is being merged with VB, so I imagine this means InterDev is
>going
>> out of the window. Frankly, this has to be a good thing - InterDev just
>doesn't
>> cut it. If they can make it as easy to create DHTML pages as it is to
>create
>> standard apps (i.e. do what they've failed to do with InterDev), then
>great
>> - but I doubt they'll manage it.
>>
>> The new oo features sound nice, but if Inherits does for VB inheritance
>what
>> Implements did for VB polymorphism, then it's going to be another one
of
>> those half baked VB features barely anyone uses (like web classes, IIS
>applications,
>> and a host of others I don't have time to mention).
>>
>> What we really want is: 1) to get rid of the VB runtime and its associated
>> overhead. There's a product called Fusion from BitArts that lets you
>package
>> up ALL your dependent files into a single compressed exe, so all you need
>> to distribute is one file - if they can do it, why can't Microsoft? 2)
>Faster
>> string and integer handling (Why isn't this as fast as C??). 3) The
>ability
>> to create app wizards, and Management Console snap-ins (like you can in
>VC++).
>> 3) A faster, better compiler. 4) The Windows API fully 'built in' and
>accessible
>> from VB. VB Developers have grown up now - We don't need to be protected
>> from complexity!
>
>