Microsoft not content with "dissing" just the Classic VB Developer Army....

[H-Man]

Jim, you do know that several of those links you posted are the same article don't you? And some are almost 2 years old. And
if you read those articles, it clearly states that Linux is not any cheaper than Windows from a support standpoint.
As for RealBasic and cross-platform support, have you tested it? Having downloaded the Free standard version, I can say that in
the case of a simple app, that RB will compile to Linux (haven't tested on Mac).
But, not being able to build a complicated app and fully test it in Linux (due to the 5 minute time limit in the Standard
edition) I cannot say for sure how well Linux or Mac OS is supported. So, if you are like me and have not used the PRO version
of RB, I would think it would not be a good idea to make a broad statement on how easy to develop a cross-platform application
using RB is. You cannot (or should I say , I cannot) fully stress test an application in 5 minutes in a different OS than it
was developed in and be certain that you/I will not have problems.
My final questions to you is why are you spending so much time on bashing Microsoft over all this? If you have decided to
migrate to Linux and leave Microsoft products behind, why are you still posting on all these different newsgroups? Wouldn't it
be better to get up to speed on RealBasic and Linux?
Just a few thoughts and my .02 and worth exactly what you paid for them...........
james

James,
I've ported one of our VB apps to RealBasic in the interest of making it
more portable. The idea was to not require the VB runtimes to be installed,
and this works very well. The final exe is a bit large, but still not as
large as the VB exe and it's runtimes together. Anyway, just for fun I
compiled the program to Linux, and loandbehold, the thing ran, and for the
most part worked. That's where the kicker is, it didn't work completely as
it did in Windows. The StaticText and Caption on controls would no longer
fit in the respective field sizes. I understand that there are font
differences and such between different OS's but it does require adjustment,
my point here. As well a control array in a GroupBox didn't function
properly, again some more tweaking. Now this was simply a matter of
compiling code that works in Windows and compiling to Linux, with no
further consideration, so I'm sure more work needed to be done, but again,
my point is that it is not as simple as just setting some compiler options.
I really kinda like RealBasic though, just wish it were'nt so Mac oriented,
although I do realize that's it's roots.

 

[Paul Clement]

¤
¤ ¤ > On Fri, 8 Apr 2005 18:13:35 -0400, "Jim Hubbard" <[email protected]>
¤ > wrote:

¤ > Hmmm...I don't think you compared the features of Classic to REALBasic
¤ > very closely. RealBasic may
¤ > have full OO support but you can't create any ActiveX components.
¤ >
¤ > Talk to some of the other Classic VB MVPs to see if they believe REALBasic
¤ > measures up to Classic.
¤
¤ If you'll recall.....I said, "Now, REALbasic still has some growing to do.
¤ Don't expect it to be anything
¤ except REALbasic."
¤
¤ The syntax is similar to VB, the interface is similar to VB and the IDE is a
¤ basic drag-and-drop component-oriented IDE. All of these things will make
¤ REALbasic feeal very familiar to Visual Basic programmers. But, REALbasic
¤ is REALbasic.....not Visual Basic.
¤

Certainly not with respect to features, which will significantly impair code migration.


¤ > ¤ With VB.Net 2005, Microsoft is getting closer to the olde classic
¤ > Visual
¤ > ¤ Basic "task oriented" way of doing things. I am actually impressed with
¤ > ¤ what I have seen of VB.Net 2005 so far. But there is still a ways to go
¤ > to
¤ > ¤ get it back to a tool that "task oriented" developers can feel
¤ > comfortable
¤ > ¤ (i.e. not stupid or overwhelmed) with.
¤ > ¤
¤ > ¤ And, my greatest issue is still the conversion of old Visual Basic 6
¤ > ¤ code. I'll bet my company that if Microsoft were to make VB.Net 2005
¤ > truly
¤ > ¤ "click and upgrade" classic Visual Basic 6 code that ALL of the petition
¤ > ¤ issues would just go away.
¤ > ¤
¤ >
¤ > Pipe dream. Microsoft can't simply wave a magic wand in order to make all
¤ > code upgrade able.
¤
¤ No. But they couldwave a programming team and make it so.
¤

Based upon my knowledge of both versions I'm going to have to disagree.

¤ It's a choice. Microsoft is choosing to abandon classic Visual Basic 6, the
¤ mind-boggling amount of code written in classic Visual Basic and the users
¤ that trusted Microsoft enough to use it. It's a very bad choice....but a
¤ choice nonetheless.
¤

Previous versions of software are ultimately abandoned. While we can debate the ease or difficulty
of the migration as a result of the changes, it doesn't really change the process.

While there are those who believe that Visual Basic.NET is a completely different language, and
product, in order to justify the continued development of Visual Basic 6.0, I'm not buying it one
bit.

¤ >Some
¤ > features are gone, some have been changed according to requirements of the
¤ > .NET framework.
¤
¤ The requirements of the .Net framework have nothing to do with allowing
¤ unmanaged classic Visual Basic applications to be supported from the Visual
¤ Studio .Net IDE. Never have I seen any Microsoft employee give any valid
¤ technical reason that classic Visual Basic code could not be run as
¤ "unmanaged code".
¤

How do you co mingle managed and unmanaged code in the same environment? The .NET and Visual Basic
IDE environments are fundamentally different with respect to how code is compiled, debugged and
executed. In any event, what would be the point of bringing Classic Visual Basic into the .NET
environment if standard (not COM) based unmanaged code cannot interoperate with managed code?

¤ Remember that classic Visual Basic uses a runtime. This runtime contains
¤ the code that actually makes a classic Visual Basic program work. So, why
¤ not include the runtime code to run unmanaged classic Visual Basic code?
¤
¤ All I keep hearing is that there are some sort of technical reasons that
¤ this can't be done......but nobody (not even you) can cite even one of those
¤ phantom reasons.
¤

Well if I remember correctly Classic Visual Basic applications actually execute from within the
process of the IDE during development. .NET applications do not. Are you saying that you want to
modify the .NET IDE to provide for both a managed and unmanaged code environment?

¤ I suspect that there are not real technical reasons behind the decision.
¤ The continual insistance that there are such reasons, without producing even
¤ one of them, leads me to believe this is nothing more than a propaganda
¤ technique in which Microsoft says something often enough and people begin to
¤ take it as fact.....when, in fact, there are no facts to support the
¤ argument at all.
¤

I have yet to hear any cogent explanations as to how it can be accomplished within a reasonable time
frame.

¤ If you know of any hard facts as to why 1) the Visual Studio .Net IDE could
¤ not support classic Visual Basic applications or 2) and hard facts as to why
¤ the small code contained in the classic Visual Basic runtime could not be
¤ integrated to run unmanaged Visual Basic code from inside an intermediate
¤ language like VB.Net....please shaer it with us.

Yes, because it would take several years to implement and couldn't be justified from a business
perspective.


¤ >They may
¤ > be able to bring back some features but those that have changed will not
¤ > be reverted.
¤
¤ I agree. Microsoft is not likely to change their stance, no matter how
¤ wrong it may be for their customers. This is why we need a valid
¤ alternative to Windows, .Net and the forced marches of Microsoft.
¤

There are many customers who support Microsoft's stance and do not believe it to be wrong.

¤ >
¤ > ¤ > Don't get me started on the Firefox issue. As market share increases
¤ > it
¤ > ¤ > becomes a much bigger target
¤ > ¤ > to hackers and those looking to exploit security holes. If probably
¤ > won't
¤ > ¤ > help that MS is now
¤ > ¤ > working on an updated version of IE.
¤ > ¤
¤ > ¤ I was only pointing out that people are not as adverse to change as you
¤ > ¤ might think. They will change when they see (either real or perceived)
¤ > ¤ benefits of doing so.
¤ > ¤
¤ >
¤ > You mean like, "the grass is always greener on the other side"?
¤
¤ Sometimes the grass really is greener. (Not that there won;t be the
¤ occassional "cow patty"....)
¤
¤ >
¤ > ¤ > ¤ In the past, developing for different platforms has been costly.
¤ > This,
¤ > ¤ > for
¤ > ¤ > ¤ the most part, negated any potential gains from supporting Linux or
¤ > MAC
¤ > ¤ > ¤ operating systems.
¤ > ¤ > ¤
¤ > ¤ > ¤ But, REALbasic makes this as easy as recompiling the software. Just
¤ > ¤ > click
¤ > ¤ > ¤ and run on a different OS. There is no additional development
¤ > required.
¤ > ¤ > ¤ Just select the checkboxes of the platforms you want to distribute
¤ > your
¤ > ¤ > app
¤ > ¤ > ¤ on and click "Build".
¤ > ¤ > ¤
¤ > ¤ > ¤ REALbasic builds your app for all of the platforms you have
¤ > selected.
¤ > ¤ > ¤ Developing cross-platform desktop applications can't be any easier
¤ > than
¤ > ¤ > ¤ that.
¤ > ¤ >
¤ > ¤ > Unfortunately not all operating systems support the same level of
¤ > features
¤ > ¤ > so there is almost always
¤ > ¤ > a trade-off - another reason why companies spend little time
¤ > developing
¤ > ¤ > their applications for
¤ > ¤ > multiple platforms.
¤ > ¤
¤ > ¤ In REALbasic, all core components work on all OSs. (Jon....correct me
¤ > here
¤ > ¤ if I'm wrong please).
¤ >
¤ > If developers only used core language components that might be true. But
¤ > how many actually develop
¤ > applications that don't implement extensions of the operating system?
¤
¤ I'm new to REALbasic.....so, I wouldn't know at this time.
¤

The issue isn't specific to REALBasic. It's simply a matter of fact.

¤ > What about database
¤ > components?
¤
¤ A simple database is built in.
¤

Well lets say I have an application that uses an Access database. How do I get this to work on
multiple platforms?

¤ > What about third-party controls?
¤
¤ With REALbasic 2005, it is easier to write 3rd party controls using
¤ REALbasic. That makes them essentially core components.
¤

I want to use the components (ActiveX controls) I've already invested in. How do I resolve this
issue? Are you saying I have to rewrite these in REALBasic?

¤ > What about the operating system APIs?
¤
¤ Good question! This one had me worried, until I found this......
¤
¤ #If TargetBoolean [Then]
¤ //OS specific code
¤
¤ [#Else]
¤
¤ //Other OS-specific code
¤
¤ [#ElseIf TargetBoolean]
¤
¤ //Other OS-specific code for this target platform
¤
¤ #Endif

But what if there is no equivalent functionality in the other OS? Am I SOL?


Paul
~~~~
Microsoft MVP (Visual Basic)

 

[james]

James,
I've ported one of our VB apps to RealBasic in the interest of making it
more portable. The idea was to not require the VB runtimes to be installed,
and this works very well. The final exe is a bit large, but still not as
large as the VB exe and it's runtimes together. Anyway, just for fun I
compiled the program to Linux, and loandbehold, the thing ran, and for the
most part worked. That's where the kicker is, it didn't work completely as
it did in Windows. The StaticText and Caption on controls would no longer
fit in the respective field sizes. I understand that there are font
differences and such between different OS's but it does require adjustment,
my point here. As well a control array in a GroupBox didn't function
properly, again some more tweaking. Now this was simply a matter of
compiling code that works in Windows and compiling to Linux, with no
further consideration, so I'm sure more work needed to be done, but again,
my point is that it is not as simple as just setting some compiler options.
I really kinda like RealBasic though, just wish it were'nt so Mac oriented,
although I do realize that's it's roots.

Thanks for the info. I think you could probably make those changes for the different OS's the same way
Jim did in his example for File I/O using the #TargetBoolean to have the compiler output the correct options for the targeted
OS. I have not done much testing with the Standard Version that I downloaded as I feel the 5 minute run time for Linux & Mac OS
are too short for me to fully evaluate and test anything. Sure, something as simple as a Form's Caption should show up right
away, but, things much deeper in an application may not show up as quickly or be as obvious. I guess I will wait and see if I
manage to be in the top 100 people who manage to get others to follow their personalized links. If that happens, then I might be
able to do some better tests with the PRO version or even RB 2005.
Good luck and I hope that RB is all you hope it is and need.
james


Only a few days left to Download and get a FREE License for Real Basic Standard Edition!!!
Offer expires April 15, 2005 .
Go here for your copy: http://www.realbasic.com/vb6/index.php?id=CMZJCYDC

 

[Jim Hubbard]

¤ If you'll recall.....I said, "Now, REALbasic still has some growing to
do.
¤ Don't expect it to be anything
¤ except REALbasic."
¤
¤ The syntax is similar to VB, the interface is similar to VB and the IDE
is a
¤ basic drag-and-drop component-oriented IDE. All of these things will
make
¤ REALbasic feeal very familiar to Visual Basic programmers. But,
REALbasic
¤ is REALbasic.....not Visual Basic.
¤

Certainly not with respect to features, which will significantly impair
code migration.

REALbasic still has some growing to do. Fortunately, it has seen a great
spike in downloads and usage lately....with more 3rd party component vendors
signing on.

It seems I'm not the only one that likes to be able to write OS independent
applications.

¤ > ¤ With VB.Net 2005, Microsoft is getting closer to the olde
classic
¤ > Visual
¤ > ¤ Basic "task oriented" way of doing things. I am actually impressed
with
¤ > ¤ what I have seen of VB.Net 2005 so far. But there is still a ways
to go
¤ > to
¤ > ¤ get it back to a tool that "task oriented" developers can feel
¤ > comfortable
¤ > ¤ (i.e. not stupid or overwhelmed) with.
¤ > ¤
¤ > ¤ And, my greatest issue is still the conversion of old Visual
Basic 6
¤ > ¤ code. I'll bet my company that if Microsoft were to make VB.Net
2005
¤ > truly
¤ > ¤ "click and upgrade" classic Visual Basic 6 code that ALL of the
petition
¤ > ¤ issues would just go away.
¤ > ¤
¤ >
¤ > Pipe dream. Microsoft can't simply wave a magic wand in order to make
all
¤ > code upgrade able.
¤
¤ No. But they couldwave a programming team and make it so.
¤

Based upon my knowledge of both versions I'm going to have to disagree.

AGAIN! I PLEAD WITH YOU TO SHARE YOUR INTIMATE KNOWLEDGE OF VISUAL BASIC
THAT MAKES IT TECHNICALLY NOT FEASABLE TO SUPPORT CLASSIC VISUAL BASIC AS
UNMANAGED CODE IN THE SAME WAY THAT UNMANAGED C++ CODE IS SUPPORTED.

¤ It's a choice. Microsoft is choosing to abandon classic Visual Basic 6,
the
¤ mind-boggling amount of code written in classic Visual Basic and the
users
¤ that trusted Microsoft enough to use it. It's a very bad choice....but
a
¤ choice nonetheless.
¤

Previous versions of software are ultimately abandoned. While we can
debate the ease or difficulty
of the migration as a result of the changes, it doesn't really change the
process.

While there are those who believe that Visual Basic.NET is a completely
different language, and
product, in order to justify the continued development of Visual Basic
6.0, I'm not buying it one
bit.

Really? So, you can run unaltered VB6 code from large, enterprise
applications in VB.Net? Please share......we'd all like to do that.

¤ >Some
¤ > features are gone, some have been changed according to requirements of
the
¤ > .NET framework.
¤
¤ The requirements of the .Net framework have nothing to do with allowing
¤ unmanaged classic Visual Basic applications to be supported from the
Visual
¤ Studio .Net IDE. Never have I seen any Microsoft employee give any
valid
¤ technical reason that classic Visual Basic code could not be run as
¤ "unmanaged code".
¤

How do you co mingle managed and unmanaged code in the same environment?

The same way Microsoft did it for C++.

The .NET and Visual Basic
IDE environments are fundamentally different with respect to how code is
compiled, debugged and
executed.

The same goes for C++. This is a BS argument.

In any event, what would be the point of bringing Classic Visual Basic
into the .NET
environment if standard (not COM) based unmanaged code cannot interoperate
with managed code?

I think (and feel free to correct me if I'm wrong) that there's a little
thing called interop that allows just such things to take place in VB.Net -
it just wasn't taken far enough. They wanted to spend more time on a
language adopted by MILLIONS FEWER programmers - simply because the internal
programmers were calling the shots.

This is a classic example of the lunatics running the asylum.

¤ Remember that classic Visual Basic uses a runtime. This runtime
contains
¤ the code that actually makes a classic Visual Basic program work. So,
why
¤ not include the runtime code to run unmanaged classic Visual Basic code?
¤
¤ All I keep hearing is that there are some sort of technical reasons that
¤ this can't be done......but nobody (not even you) can cite even one of
those
¤ phantom reasons.
¤

Well if I remember correctly Classic Visual Basic applications actually
execute from within the
process of the IDE during development. .NET applications do not. Are you
saying that you want to
modify the .NET IDE to provide for both a managed and unmanaged code
environment?

Yes. Just like Microsoft did for C++.

¤ I suspect that there are not real technical reasons behind the decision.
¤ The continual insistance that there are such reasons, without producing
even
¤ one of them, leads me to believe this is nothing more than a propaganda
¤ technique in which Microsoft says something often enough and people
begin to
¤ take it as fact.....when, in fact, there are no facts to support the
¤ argument at all.
¤

I have yet to hear any cogent explanations as to how it can be
accomplished within a reasonable time
frame.

And, I have yet to hear any technical reason that prevents the inclusion of
unmanaged Visual Basic code.....JUST LIKE MICROSOFT DID WITH C++.

You are beginning to bore me with this unsubstantiated assumption of the
phantom roadblocks that clearly do not exist. Put up....or move on.

¤ If you know of any hard facts as to why 1) the Visual Studio .Net IDE
could
¤ not support classic Visual Basic applications or 2) and hard facts as to
why
¤ the small code contained in the classic Visual Basic runtime could not
be
¤ integrated to run unmanaged Visual Basic code from inside an
intermediate
¤ language like VB.Net....please shaer it with us.

Yes, because it would take several years to implement and couldn't be
justified from a business
perspective.

On what do you base these assumptions? It didn't take that long, or cost
too much, to do it for C++.

¤ > If developers only used core language components that might be true.
But
¤ > how many actually develop
¤ > applications that don't implement extensions of the operating system?
¤
¤ I'm new to REALbasic.....so, I wouldn't know at this time.
¤

The issue isn't specific to REALBasic. It's simply a matter of fact.

They can still do so in REALbasic. However, if the code is core to the
program (as opposed to a "nice feature" that can be added for a specific OS
without adversely affecting the core functionality of the project) they will
confine that application to the specific OS for which they write the hooks.

I want to use the components (ActiveX controls) I've already invested in.
How do I resolve this
issue? Are you saying I have to rewrite these in REALBasic?

Completely understandable. This is the same reason we want to keep classic
VB viable - to preserve our investments.

I believe that ActiveX controls CAN be used from REALbasic. You'd have to
ask them if you need more specifics.

¤ > What about the operating system APIs?
¤
¤ Good question! This one had me worried, until I found this......
¤
¤ #If TargetBoolean [Then]
¤ //OS specific code
¤
¤ [#Else]
¤
¤ //Other OS-specific code
¤
¤ [#ElseIf TargetBoolean]
¤
¤ //Other OS-specific code for this target platform
¤
¤ #Endif

But what if there is no equivalent functionality in the other OS? Am I
SOL?

What do you think? They are not replacing the operating systems.

If a car doesn't have wings it can't fly.

Jim Hubbard

 

[Paul Clement]

¤ > ¤ >
¤ > ¤ > Pipe dream. Microsoft can't simply wave a magic wand in order to make
¤ > all
¤ > ¤ > code upgrade able.
¤ > ¤
¤ > ¤ No. But they couldwave a programming team and make it so.
¤ > ¤
¤ >
¤ > Based upon my knowledge of both versions I'm going to have to disagree.
¤
¤ AGAIN! I PLEAD WITH YOU TO SHARE YOUR INTIMATE KNOWLEDGE OF VISUAL BASIC
¤ THAT MAKES IT TECHNICALLY NOT FEASABLE TO SUPPORT CLASSIC VISUAL BASIC AS
¤ UNMANAGED CODE IN THE SAME WAY THAT UNMANAGED C++ CODE IS SUPPORTED.

Doesn't work that way my friend. The environments for Classic Visual Basic and C++ are quite a bit
different. Besides C++ uses managed extensions to inter operate with .NET. Do you really believe
that managed extensions for Classic Visual Basic is even the slightest bit feasible considering the
baggage it caries along with it?

In any event you're claiming this can be done feasibly but have offered little if any technical
information to back your statement.

¤ > ¤ It's a choice. Microsoft is choosing to abandon classic Visual Basic 6,
¤ > the
¤ > ¤ mind-boggling amount of code written in classic Visual Basic and the
¤ > users
¤ > ¤ that trusted Microsoft enough to use it. It's a very bad choice....but
¤ > a
¤ > ¤ choice nonetheless.
¤ > ¤
¤ >
¤ > Previous versions of software are ultimately abandoned. While we can
¤ > debate the ease or difficulty
¤ > of the migration as a result of the changes, it doesn't really change the
¤ > process.
¤ >
¤ > While there are those who believe that Visual Basic.NET is a completely
¤ > different language, and
¤ > product, in order to justify the continued development of Visual Basic
¤ > 6.0, I'm not buying it one
¤ > bit.
¤
¤ Really? So, you can run unaltered VB6 code from large, enterprise
¤ applications in VB.Net? Please share......we'd all like to do that.

Who said that? Not me. Do you believe Visual Basic.NET is a completely different language? If so,
then explain why it shares a very high percentage of the same language components and syntax with
Classic Visual Basic?


¤ > ¤ >Some
¤ > ¤ > features are gone, some have been changed according to requirements of
¤ > the
¤ > ¤ > .NET framework.
¤ > ¤
¤ > ¤ The requirements of the .Net framework have nothing to do with allowing
¤ > ¤ unmanaged classic Visual Basic applications to be supported from the
¤ > Visual
¤ > ¤ Studio .Net IDE. Never have I seen any Microsoft employee give any
¤ > valid
¤ > ¤ technical reason that classic Visual Basic code could not be run as
¤ > ¤ "unmanaged code".
¤ > ¤
¤ >
¤ > How do you co mingle managed and unmanaged code in the same environment?
¤
¤ The same way Microsoft did it for C++.
¤

What is it about the C++ and Visual Basic 6.0 development environments that indicate to you that
they operate under the same implementation?


¤ >The .NET and Visual Basic
¤ > IDE environments are fundamentally different with respect to how code is
¤ > compiled, debugged and
¤ > executed.
¤
¤ The same goes for C++. This is a BS argument.
¤

Oh so it's not true. Please share your wealth of technical knowledge because so far all you're
saying is, "it can be done", "they did it with C++ so they can do it with VB", etc. etc. etc.

¤ > In any event, what would be the point of bringing Classic Visual Basic
¤ > into the .NET
¤ > environment if standard (not COM) based unmanaged code cannot interoperate
¤ > with managed code?
¤
¤ I think (and feel free to correct me if I'm wrong) that there's a little
¤ thing called interop that allows just such things to take place in VB.Net -
¤ it just wasn't taken far enough. They wanted to spend more time on a
¤ language adopted by MILLIONS FEWER programmers - simply because the internal
¤ programmers were calling the shots.
¤
¤ This is a classic example of the lunatics running the asylum.
¤

As I mentioned it's COM interop (RCW or CCW). Microsoft would have to devise some method other than
an interop assembly in order to generate the dynamic bridge between managed and unmanaged code.

¤ >
¤ > ¤ Remember that classic Visual Basic uses a runtime. This runtime
¤ > contains
¤ > ¤ the code that actually makes a classic Visual Basic program work. So,
¤ > why
¤ > ¤ not include the runtime code to run unmanaged classic Visual Basic code?
¤ > ¤
¤ > ¤ All I keep hearing is that there are some sort of technical reasons that
¤ > ¤ this can't be done......but nobody (not even you) can cite even one of
¤ > those
¤ > ¤ phantom reasons.
¤ > ¤
¤ >
¤ > Well if I remember correctly Classic Visual Basic applications actually
¤ > execute from within the
¤ > process of the IDE during development. .NET applications do not. Are you
¤ > saying that you want to
¤ > modify the .NET IDE to provide for both a managed and unmanaged code
¤ > environment?
¤
¤ Yes. Just like Microsoft did for C++.
¤

How? They're not the same.

¤ > ¤ I suspect that there are not real technical reasons behind the decision.
¤ > ¤ The continual insistance that there are such reasons, without producing
¤ > even
¤ > ¤ one of them, leads me to believe this is nothing more than a propaganda
¤ > ¤ technique in which Microsoft says something often enough and people
¤ > begin to
¤ > ¤ take it as fact.....when, in fact, there are no facts to support the
¤ > ¤ argument at all.
¤ > ¤
¤ >
¤ > I have yet to hear any cogent explanations as to how it can be
¤ > accomplished within a reasonable time
¤ > frame.
¤
¤ And, I have yet to hear any technical reason that prevents the inclusion of
¤ unmanaged Visual Basic code.....JUST LIKE MICROSOFT DID WITH C++.
¤
¤ You are beginning to bore me with this unsubstantiated assumption of the
¤ phantom roadblocks that clearly do not exist. Put up....or move on.
¤

That's my line and your repeated assertions are an exercise in futility. If you have no technical
evidence as to how it can be done within a reasonable time frame then your claim that it can is
baseless. It's not incumbent upon me to disprove something that has yet to be proven or
demonstrated. That's nonsense. You're not the first one to assume facts not in evidence and then
demand that I disprove them - but it was a nice try. ;-)

I have no reason to accept your claims at their face value.

¤ >
¤ > ¤ If you know of any hard facts as to why 1) the Visual Studio .Net IDE
¤ > could
¤ > ¤ not support classic Visual Basic applications or 2) and hard facts as to
¤ > why
¤ > ¤ the small code contained in the classic Visual Basic runtime could not
¤ > be
¤ > ¤ integrated to run unmanaged Visual Basic code from inside an
¤ > intermediate
¤ > ¤ language like VB.Net....please shaer it with us.
¤ >
¤ > Yes, because it would take several years to implement and couldn't be
¤ > justified from a business
¤ > perspective.
¤
¤ On what do you base these assumptions? It didn't take that long, or cost
¤ too much, to do it for C++.
¤

Well I guess if C++ and Visual Basic 6.0 were the same you would have a winner. For the last time,
they're not and I don't know why you believe that they would require the same implementation under
..NET.

¤ > ¤ > If developers only used core language components that might be true.
¤ > But
¤ > ¤ > how many actually develop
¤ > ¤ > applications that don't implement extensions of the operating system?
¤ > ¤
¤ > ¤ I'm new to REALbasic.....so, I wouldn't know at this time.
¤ > ¤
¤ >
¤ > The issue isn't specific to REALBasic. It's simply a matter of fact.
¤
¤ They can still do so in REALbasic. However, if the code is core to the
¤ program (as opposed to a "nice feature" that can be added for a specific OS
¤ without adversely affecting the core functionality of the project) they will
¤ confine that application to the specific OS for which they write the hooks.
¤

Core functionality often involves operating system specific functionality. That's why cross-platform
development is often problematic. It has nothing to do with the language or development environment
you use - it's an issue with the concept with respect to operating system implementations.

¤ > I want to use the components (ActiveX controls) I've already invested in.
¤ > How do I resolve this
¤ > issue? Are you saying I have to rewrite these in REALBasic?
¤
¤ Completely understandable. This is the same reason we want to keep classic
¤ VB viable - to preserve our investments.
¤
¤ I believe that ActiveX controls CAN be used from REALbasic. You'd have to
¤ ask them if you need more specifics.
¤ >
¤ > ¤ > What about the operating system APIs?
¤ > ¤
¤ > ¤ Good question! This one had me worried, until I found this......
¤ > ¤
¤ > ¤ #If TargetBoolean [Then]
¤ > ¤ //OS specific code
¤ > ¤
¤ > ¤ [#Else]
¤ > ¤
¤ > ¤ //Other OS-specific code
¤ > ¤
¤ > ¤ [#ElseIf TargetBoolean]
¤ > ¤
¤ > ¤ //Other OS-specific code for this target platform
¤ > ¤
¤ > ¤ #Endif
¤ >
¤ > But what if there is no equivalent functionality in the other OS? Am I
¤ > SOL?
¤
¤ What do you think? They are not replacing the operating systems.
¤
¤ If a car doesn't have wings it can't fly.

Hmm...OK so much for the cross-platform implementation feature. ;-)


Paul
~~~~
Microsoft MVP (Visual Basic)

 

[Tom Shelton]

I have made no attempts to hide my displeasure at the way Microsoft has
treated the VB6 developers - as you will notice in the Microsoft.public.vb
newsgroup postings.

And, with the current pricing structure of MSDN and rising costs of
Microsoft's desktop software, I truly believe we need a valid alternative to
Microsoft developer tools. Currently, I am looking into REALbasic
(www.REALbasic.com) as just such an alternative.

Now, REALbasic still has some growing to do. Don't expect it to be anything
except REALbasic.

If you are a classic Visual Basic developer (pre-VB.Net), you will find the
interface and syntax very familiar. You will be able to upgrade your VB6
apps better than Microsoft's transition tool to VB.Net. And, the coming
2005 interface (60 days until release) has a much enhanced UI (screenshots
at http://www.realsoftware.com/demo15/).

REALbasic 5.5 is even FREE to former Visual Basic developers and they will
receive a discount on REALbasic 2005 when it gets released in 60 days (or
less). Just sign up here -
http://www.realsoftware.com/realbasic/vb6/index.php - BEFORE APRIL 15, 2005.

Although those reasons are all good enough to at least take a look at
REALbasic, the true value of REALbasic, for developers AND end users, is
freedom of choice with the OS. REALbasic applications are truly
cross-platform and will run on MAC, Linux or Windows machines. This means
that, as prices continue to climb for Microsoft MSDN subscriptions (almost
$10,000 for the top MSDN subscription) Microsoft OSs and Microsoft software
(like $499 for Office 2003 Pro) you and your customers have the option of
choosing a less expensive OS like MAC, a supported (but way less expensive
than XP) Linux OS like Novell's Linux desktop, Red Hat Workstation or even a
FREE OS like one of the hundreds of free Linux distros.

Microsoft has shown that they no longer value (or even listen to) their
customers. They will be the next IBM.....decimating the empire that they
have built by ignoring customer needs and pricing themselves out of Windows
development.

Make no mistake about it, Microsoft IS pricing themselves out of the
software market by pricing the small and mid-sized business out of Windows
development.

Microsoft seems to be forgetting that the ability for small and mid-sized
shops to do their own development is a large part of what has made Microsoft
the largest software company in the world. Its what drew small companies to
Windows - the ability to develop their own relatively inexpensive software
solutions in-house. Not to mention the millions of developers that used
Windows tools to develop and sell their own software.

And, while there are certainly alternatives other than REALbasic (Mono +
Linux, C++ + MAC, Java, Borland's Delphi, etc.) None of them offer the
platform dependence that REALbasic does........nope, not even JAVA.

You need to do your reasearch.... Mono runs on way more platfroms than
REALbasic. And even supports VB.NET - though, that is still not fully
operational, though should be by the end of this year.

Here are the current supported OS's for Mono:
Linux, Windows (2K and up), OSX, BSD, Solaris

 

[Tom Shelton]

I wish this were the case. But, it seems that no other company has put 2
and 2 together yet.....

Sun, Borland, Novell......all of them are missing the main 2 ingredients
that are absolutley neccessary to give Microsoft a run for their money and
the people of the world a real choice in desktop operating systems and
applications.

You have to have an affordable desktop....Linspire, Novell (SUSE), Mandrake,
even the MAC OS (only $199 for 5 licenses - and you don't have to lie and
say you're a student) are all more affordable than Microsoft. The thing
they are missing is an easy way to develop applications (like Visual Basic
was for Microsoft).

You really have no idea what your talking about... The fact is, I can
be pretty productive using Mono+C#+Glade# on my Gentoo linux box. And
once they get mbas fully up to speed, then I can use Mono+VB.NET+Glade#.

 

[Tom Shelton]

¤ While still far behind Windows, the demand for Linux is growing by leaps and
¤ bounds....if I may....
¤

Well that's what some folks having been saying for the last five years. You would have thought by
now that Linux would have passed up Windows by now. ;-)

Do you read the news much? Linux is being adopted... Not so much on the
desktop (though that is happening) - but on the server side it is
growing pretty darn fast.

¤ It's like the adoption of Firefox in place of IE. Firefox is making great
¤ strides in the browser market, with no signs of stalling. People will adopt
¤ the best technology for their enterprise, whether that is MAC, Windows or
¤ Linux.
¤

Don't get me started on the Firefox issue. As market share increases it becomes a much bigger target
to hackers and those looking to exploit security holes. If probably won't help that MS is now
working on an updated version of IE.

I agree that Firefox is not as big a target at the moment... But, you
need to look at the fix rate as well:

http://www.tigertools.net/board/?topic=topic8&msg=7567
According to Brussels-based ScanIT, users of Microsoft's Internet
Explorer (IE) were "unsafe" 98 percent of the time during 2004, while
Mozilla users -- which would include those using Mozilla and Firefox
-- were "unsafe" only 15 percent of last year.

The fact is that Firefox IS more secure, not to mention it is just a
better browser. I have high hopes for IE7, but right now Firefox just
plain kicks IE's butt.

¤ The adoption of Linux will happen sooner than you think, in more places than
¤ you think. There are things in the works right now that will make Linux the
¤ premier desktop of small and mid-sized businesses worldwide. Add them to
¤ the governments making the switch, and you have yourself a little
¤ revolution.
¤

They way Linux has been hyped over the last several years I would have expected a significantly
higher adoption rate. Problem is there's literally no money to be made in this market in comparison

Tell that to Novell and IBM. Both major Linux players.

to the Windows market so quality applications lag behind.

Some do, some don't.

In addition, there's simply too many user
interfaces and variations for this OS so standardization becomes virtually impossible.

To be honest, I actually like having the choices. But, this makes no
sense really. It is quite simple for a distro maker to standardize on a
particluar interface, if they so choose.

 

[Jim Hubbard]

You really have no idea what your talking about... The fact is, I can
be pretty productive using Mono+C#+Glade# on my Gentoo linux box. And
once they get mbas fully up to speed, then I can use Mono+VB.NET+Glade#.

Tom,

I'm certain that you can be very productive in those languages. But the
point that I was trying to make is that most developers are "task oriented"
developers and not professional developers such as yourself.

In most cases, these task oriented developers have a main job that is
not programming, but they needed a quick way (without spending a large
amount of time learning a more complex programming language and without
learning about the internal workings of the IDE or framework) to create
applications to make their jobs easier.

Classic Visual Basic was the king of RAD, and fit this bill more than
any language in the world.. It made programmers of CEOs, mail clerks,
secretaries, attorneys......and so on. Because of the extreme ease of use,
the component architecture and the English-like syntax, classic Visual Basic
made developers out of more people than any other language in the world and
made Windows the champion of small businesses and task oriented developers
the world over.

Classic Visual Basic saved money in that small businesses did not have
to hire professional programmers to get applications that helped them
streamline their operations. And, as more businesses used classic Visual
Basic, 3rd party developers cropped up to deliver components to make it even
easier to use. This resulted in more adoption of the classic Visual Basic
and Windows platform.

In VB.Net, Microsoft has lost the RAD edge that task oriented developers
loved (and actually needed). The VB.Net books that I have read (all 54 of
them) are even more of an affront to the task oriented developer. The vast
majority of task oriented developers simply don't want to be professional
programmers. If they did, they'd stop being attorney's or mail clerks or
whatever and devote themselves to it full time. For the most part, they
just want a simple IDE to make applications to make making a living easier.

For the majority of them, C#, Mono and related languages are not nearly
as easy to use and learn as languages like Visual Basic and REALbasic. This
is the reason I suggest that classic Visual Basic developers that feel
slighted by Microsoft take a look at REALbasic.

REALbasic offers the ability to use a much less expensive desktop (like
Linspire, SUSE or even Red Hat) with applications that interact with
Microsoft Office and offers the developer the chance to develop on MAC,
Linux or Windows and distribute their apps to all 3 platforms.

The REALbasic/Linux platform will not be for everyone. But, for task
oriented developers, developers that would like to target all 3 platforms
from a single set of source code and developers and small businesses looking
for a more cost effective solution than Microsoft's ridiculous pricing of
its products.....REALbasic is worth a look.

A look is even free. They can get a free copy at
http://www.realbasic.com/vb6/index.php?id=GVVDPQFY .

Jim Hubbard

 

[Jim Hubbard]

You need to do your reasearch.... Mono runs on way more platfroms than
REALbasic.

Are you saying that Mono puts out exe's for all supported platforms with a
single set of source code and a single compile like REALbasic does?

I haven't really been attracted to Mono because of the syntax. I just don't
like it. And, I don;t like the idea of always playing catch=up with
Microsoft. Mono should make a clean break with Microsoft and
innovate.....but, then it may lose it's ability to play well with .Net.

Fortunately, REALbasic isn't caught in that trap andcan move in any
direction that their developers need without really worrying too much about
how Microsoft does things.

And even supports VB.NET - though, that is still not fully
operational, though should be by the end of this year.

I'd love to take a look at it. Hopefully it gets more back to the RAD IDE
that wa classic Visual Basic.

Here are the current supported OS's for Mono:
Linux, Windows (2K and up), OSX, BSD, Solaris

The only real concern I have is that it is basically unsupported. As a
business owner and having to deal with ISO9000 issues, most executives that
I deal with demand accountablity in the products that they adopt and feel
that this is missing with Mono. It's the same reason that companies adopt
RedHat instead of their own version of Linux. They need a support team
ready when they need help.

Who on the Mono team can we call if we need help today with a project?

REALbasic has a great support team.

Jim Hubbard

 

[Tom Shelton]

Tom,

I'm certain that you can be very productive in those languages. But the
point that I was trying to make is that most developers are "task oriented"
developers and not professional developers such as yourself.

Ah, so were not talking about proffesional hackers... I guess I missed
that. For that, I agree you are right. I know of nothing in linux that
is as easy to use as VB.CLASSIC.

I apologize for my misunderstanding.

 

[Tom Shelton]

Are you saying that Mono puts out exe's for all supported platforms with a
single set of source code and a single compile like REALbasic does?

Yes... In fact, for the most part an exe compiled in VS will run on
linux under mono and a exe compiled with mono will run on windows under
..net. There are exceptions - some classes and namespaces that haven't
been fully implemented yet (most notably, system.windows.forms - which
is also comming at the end of this year).

I haven't really been attracted to Mono because of the syntax. I just don't
like it.

Well, it's just C# and to be honest, I like C# better anyway But, if
that's not to your liking - the full VB.NET syntax will be available.
There is already a Java implementation (IKVM), and IronPython runs on
..NET and Mono. There are several language choices on Mono as well as
..NET.

And, I don;t like the idea of always playing catch=up with
Microsoft. Mono should make a clean break with Microsoft and
innovate.....but, then it may lose it's ability to play well with .Net.

Actually, Mono does innovate. They have tones of libraries of their
own.

Fortunately, REALbasic isn't caught in that trap andcan move in any
direction that their developers need without really worrying too much about
how Microsoft does things.

Same with Mono - since their primary goal is not actually compatability
with .NET. That is just a side affect of implementing the ECMA/ISO
standard. The primary goal of Mono is to make Linux development easier.
Compatability, is a secondary goal - primarily to make Linux a more
attractive platform for ISV's. If you look at the way Mono is deployed,
it is done in 3 stacks... The mono core that contains all of the
ECMA/ISO stuff (this is pretty much complete), the mono specific stuff
(libaries that are distributed with mono and not with .NET), and the ms
compatability stack. The ms stack contains stuff like,
System.Windows.Forms, ASP.NET, ADO.NET, etc.

I'd love to take a look at it. Hopefully it gets more back to the RAD IDE
that wa classic Visual Basic.

Mono, like .NET is not tied to an IDE... Yes, there is a Mono specific
IDE in the works (MonoDevelop) but it is pretty rough around the edges
at this point....

The only real concern I have is that it is basically unsupported.

Not really true. Mono is supported by Novell. You can purchase support
and technical consulting if you so desire/need it.

As a
business owner and having to deal with ISO9000 issues, most executives that
I deal with demand accountablity in the products that they adopt and feel
that this is missing with Mono. It's the same reason that companies adopt
RedHat instead of their own version of Linux. They need a support team
ready when they need help.

SuSE is begining to ship with Mono as part of the default package as of
9.3 I believe. SuSE is a paid for distribution from Novell. So, you
can use Mono and have support. In fact, many of the new Novell Linux
products are based on Mono.

Who on the Mono team can we call if we need help today with a project?

You call Novell. Or you do like you do with VB - you get on the mailing
list, and ask away

 

[Jim Hubbard]

Ah, so were not talking about proffesional hackers... I guess I missed
that. For that, I agree you are right. I know of nothing in linux that
is as easy to use as VB.CLASSIC.

I apologize for my misunderstanding.

No problem. I may have not been clear enough in my postings, and maybe this
will help clear things up.

Thanks for the questions.

Jim Hubbard

 

[Jim Hubbard]

Yes... In fact, for the most part an exe compiled in VS will run on
linux under mono and a exe compiled with mono will run on windows under
.net. There are exceptions - some classes and namespaces that haven't
been fully implemented yet (most notably, system.windows.forms - which
is also comming at the end of this year).

That's good to know. Thanks for pointing that out.

Well, it's just C# and to be honest, I like C# better anyway But, if
that's not to your liking - the full VB.NET syntax will be available.
There is already a Java implementation (IKVM), and IronPython runs on
.NET and Mono. There are several language choices on Mono as well as
.NET.

I've been waiting on the VB.Net version. But, seeing as it has been so
long, and that the release will be far from the RAD environment that I loved
with classic Visual Basic, I think it will be quite some time before the
Mono's VB.Net version is a viable option for me.

Actually, Mono does innovate. They have tones of libraries of their
own.

Also a good thing. Developers should be in control of where apps go.....not
Microsoft - or any single company.

Same with Mono - since their primary goal is not actually compatability
with .NET.

Again...something I did not know....cool.

That is just a side affect of implementing the ECMA/ISO
standard. The primary goal of Mono is to make Linux development easier.
Compatability, is a secondary goal - primarily to make Linux a more
attractive platform for ISV's.

I'm all for this!

If you look at the way Mono is deployed,
it is done in 3 stacks... The mono core that contains all of the
ECMA/ISO stuff (this is pretty much complete), the mono specific stuff
(libaries that are distributed with mono and not with .NET), and the ms
compatability stack. The ms stack contains stuff like,
System.Windows.Forms, ASP.NET, ADO.NET, etc.



Mono, like .NET is not tied to an IDE... Yes, there is a Mono specific
IDE in the works (MonoDevelop) but it is pretty rough around the edges
at this point....

I guess this is a major sticking point for me. I want (and even need) the
RAD IDE of a classic Visual Basic-like language to keep my productivity at
its current levels.

VB.Net 2005 is heading back in that direction some, and I am glad. But,
I'll reserve final judgement on that implementation until I see the final
product.

Not really true. Mono is supported by Novell. You can purchase support
and technical consulting if you so desire/need it.

I knew that they were a major backer, but I did not know that they sold
support for Mono.

SuSE is begining to ship with Mono as part of the default package as of
9.3 I believe. SuSE is a paid for distribution from Novell. So, you
can use Mono and have support. In fact, many of the new Novell Linux
products are based on Mono.

I just bought 9.2 Pro a couple of weeks ago and have enjoyed playing with it
(although I wish it would run under VMWare - they only support version 9.1
at this time).

You call Novell. Or you do like you do with VB - you get on the mailing
list, and ask away

You know....I'm actually working on a little product to make that
easier......

Thanks for enlightening me on some Mono facts that I was ignorant
concerning.

Jim Hubbard

 

[james]

Ah, so were not talking about proffesional hackers... I guess I missed
that. For that, I agree you are right. I know of nothing in linux that
is as easy to use as VB.CLASSIC.

I apologize for my misunderstanding.

Tom, there is a Linux-only, VB Like language, with a pretty nice IDE called Gambas.
Here's the link: http://gambas.sourceforge.net/ (free)
I have messed with it and it seems to be prettty nice and easy to use. I have built a couple of test apps in Linux using Gambas
and it ran just fine in both KDE & Gnome.
(Just thought you might be interested in another alternitive)
james

 

[Tom Shelton]

Tom, there is a Linux-only, VB Like language, with a pretty nice IDE called Gambas.
Here's the link: http://gambas.sourceforge.net/ (free)
I have messed with it and it seems to be prettty nice and easy to use. I have built a couple of test apps in Linux using Gambas
and it ran just fine in both KDE & Gnome.
(Just thought you might be interested in another alternitive)
james

James - thanks. I'll have to check that out...

 

[Tom Shelton]

That's good to know. Thanks for pointing that out.

No problem.

I've been waiting on the VB.Net version. But, seeing as it has been so
long, and that the release will be far from the RAD environment that I loved
with classic Visual Basic, I think it will be quite some time before the
Mono's VB.Net version is a viable option for me.

Here's the things... If you stick to .NET stuff, then you can actually
deploy VB.NET programs to mono right now. At that point, it's just IL.
It's really just the mbas compiler that is in need of some work

Also a good thing. Developers should be in control of where apps go.....not
Microsoft - or any single company.

I agree.

Again...something I did not know....cool.


I'm all for this!

Me to. Don't get me wrong. I like and use MS products - but, I also
like and use Linux. It's nice to have something that will work on both.

I guess this is a major sticking point for me. I want (and even need) the
RAD IDE of a classic Visual Basic-like language to keep my productivity at
its current levels.

VB.Net 2005 is heading back in that direction some, and I am glad. But,
I'll reserve final judgement on that implementation until I see the final
product.


I knew that they were a major backer, but I did not know that they sold
support for Mono.

For your enjoyment...

http://mono-project.com/FAQ:_General#The_Novell_Role_in_the_Mono_Project
Will Novell offer Mono commercially?

Novell will offer a commercial support and services for Mono. Mono
components are also available to be licensed commercially. For
licensing details, contact (e-mail address removed)

I just bought 9.2 Pro a couple of weeks ago and have enjoyed playing with it
(although I wish it would run under VMWare - they only support version 9.1
at this time).

To be totally up front... I haven't been all that impressed with SuSE.
It's not that it's bad - I just don't like RPM based packaging. I have
really fallen in love with my Gentoo system and it's portage package
manager.

You know....I'm actually working on a little product to make that
easier......

Thanks for enlightening me on some Mono facts that I was ignorant
concerning.

No Prob. I'm a big mono fan.

 

[Aaron Smith]

Tom,

I'm certain that you can be very productive in those languages. But the
point that I was trying to make is that most developers are "task oriented"
developers and not professional developers such as yourself.

In most cases, these task oriented developers have a main job that is
not programming, but they needed a quick way (without spending a large
amount of time learning a more complex programming language and without
learning about the internal workings of the IDE or framework) to create
applications to make their jobs easier.

Classic Visual Basic was the king of RAD, and fit this bill more than
any language in the world.. It made programmers of CEOs, mail clerks,
secretaries, attorneys......and so on. Because of the extreme ease of use,
the component architecture and the English-like syntax, classic Visual Basic
made developers out of more people than any other language in the world and
made Windows the champion of small businesses and task oriented developers
the world over.

Classic Visual Basic saved money in that small businesses did not have
to hire professional programmers to get applications that helped them
streamline their operations. And, as more businesses used classic Visual
Basic, 3rd party developers cropped up to deliver components to make it even
easier to use. This resulted in more adoption of the classic Visual Basic
and Windows platform.

Not to get all philisophical here... But, isn't this one of the biggest
problems that a lot of professional developers face? I'm not talking
about losing money to people who become simple programmers... I'm
talking about professional programmers having to always go back and fix
broken or misused code because a mail room clerk wrote a program that a
business now has to rely on, and that clerk did something wrong. I have
only run into this a few times in my career, but I have read countless
articles that pointed out the fact that classic VB created a ton of bad
code. It was these people that don't have the fundamental knowledge of
programming, or even computers, that created a ton of programs that ran,
but had problems and when they leave a company, now they are forced to
hire someone to rewrite it. It would have just been easier to have it
done professionally once instead of paying to have it written once
unprofessionally then pay someone twice as much to fix it.

In VB.Net, Microsoft has lost the RAD edge that task oriented developers
loved (and actually needed). The VB.Net books that I have read (all 54 of
them) are even more of an affront to the task oriented developer. The vast
majority of task oriented developers simply don't want to be professional
programmers. If they did, they'd stop being attorney's or mail clerks or
whatever and devote themselves to it full time. For the most part, they
just want a simple IDE to make applications to make making a living easier.

For the majority of them, C#, Mono and related languages are not nearly
as easy to use and learn as languages like Visual Basic and REALbasic. This
is the reason I suggest that classic Visual Basic developers that feel
slighted by Microsoft take a look at REALbasic.

REALbasic offers the ability to use a much less expensive desktop (like
Linspire, SUSE or even Red Hat) with applications that interact with
Microsoft Office and offers the developer the chance to develop on MAC,
Linux or Windows and distribute their apps to all 3 platforms.

The REALbasic/Linux platform will not be for everyone. But, for task
oriented developers, developers that would like to target all 3 platforms
from a single set of source code and developers and small businesses looking
for a more cost effective solution than Microsoft's ridiculous pricing of
its products.....REALbasic is worth a look.

A look is even free. They can get a free copy at
http://www.realbasic.com/vb6/index.php?id=GVVDPQFY .

Jim Hubbard

If real basic is so great for these "task oriented" developers, than why
are you even asking for VB.Com? If the programs they wrote were so
simple and a mail clerk could do it, then the switch to real basic would
be simple and they could do it with no problem. If there are other tools
out there that these people can use, then let them go use them.

 

[Aaron Smith]

Fortunately, REALbasic isn't caught in that trap andcan move in any
direction that their developers need without really worrying too much about
how Microsoft does things.

Careful with that. They are a business too. Just because they say they
listen to the developer doesn't always make that the case. I've seen,
and heard that before.

The only real concern I have is that it is basically unsupported. As a
business owner and having to deal with ISO9000 issues, most executives that
I deal with demand accountablity in the products that they adopt and feel
that this is missing with Mono. It's the same reason that companies adopt
RedHat instead of their own version of Linux. They need a support team
ready when they need help.

Who on the Mono team can we call if we need help today with a project?

Just like every other linux project that crops up, there is always
community support, just like what you get with Microsoft. And I'm sure a
ton of support companies will crop up once it starts to get adopted more.

REALbasic has a great support team.

So, if it's so great, why are we all still arguing? Why don't the people
that have a big problem with Microsoft dumping classic VB just switch to
real basic?

 

[Jim Hubbard]

Not to get all philisophical here... But, isn't this one of the biggest
problems that a lot of professional developers face? I'm not talking about
losing money to people who become simple programmers... I'm talking about
professional programmers having to always go back and fix broken or
misused code because a mail room clerk wrote a program that a business now
has to rely on, and that clerk did something wrong. I have only run into
this a few times in my career, but I have read countless articles that
pointed out the fact that classic VB created a ton of bad code. It was
these people that don't have the fundamental knowledge of programming, or
even computers, that created a ton of programs that ran, but had problems
and when they leave a company, now they are forced to hire someone to
rewrite it. It would have just been easier to have it done professionally
once instead of paying to have it written once unprofessionally then pay
someone twice as much to fix it.

While it is true that a lot of code written by task oriented developers does
not conform to proper use of the language (from the point of view of
professional programmers) and may require rewriting, the very fact that the
task oriented developer could write the program in the first place helped
the small business along and showed the usefulness of the task oriented
developers idea.

I have been called upon to enhance and "fix" these applications for most of
my career. But, I have also seen many ingenious methods of solving problems
that have streamlined businesses and departments that were not only adequate
for their purpose, but whose usage saved companies thousands of dollars each
year.

In my experience, the companies that needed rewrites were the companies that
rushed the employees instead of giving them the time to learn and use Visual
Basic correctly. These same companies frequently assign ridiculous
deadlines to professional developers while changing specs constantly and
will have the same problems as before (not every time, but most of the time
I see this as being the case).

If real basic is so great for these "task oriented" developers, than why
are you even asking for VB.Com?

I signed the petition before I was introduced to REALbasic.

If the programs they wrote were so simple and a mail clerk could do it,
then the switch to real basic would be simple and they could do it with no
problem. If there are other tools out there that these people can use, then
let them go use them.

I agree. REALbasic is not the only alternative. However, it is the
alternative that allows for upgrading of VB6 apps and uses a similar syntax
to VB6 and runs its apps on Mac, Linux or Windows.

In all, I find that REALbasic offers more "bang for your buck" than the
other alternatives that I have looked at so far. If you have any suggested
alternatives, please post them here. I'd love to look at them.

Remember that REALbasic is only FREE for 2 more days, so download your copy
from http://www.realbasic.com/vb6/index.php?id=GVVDPQFY ASAP.

Jim Hubbard