A can of worms was opened with this thread, I believe the core context it is
the next evolution in the C++ vs VB saga, and is continuing. Coupled into
this thread is a reprised villainous assault towards another contributor
tiring the conversation out right and taking from heart of the conversation.
It is what it is, and it is about trade-offs. C++ and VB are not dead,
gone, or otherwise non-employable. Purists can still get the nominal
performance gains back simply be implementing those tools. I do not believe
that performance is all that penalized in the .Net framework and have
several applications under my belt as proof of pudding.
That said, it is about trade-offs, and you trade raw performance with
sophisticated simplicity, true connectedness, and commonality in form and
function. Data binding in VB is a taboo thing, not all controls were data
aware, and inheriting them was complex at best and kludgy at worst. API's
were needed for threading and message handling, while most of the samples
and documents were relegated to the world of C++. The C++ world had to
write their event maps, use the APIs, decide on MFC, STL, ATL, SUV, ACLU and
a few other TLA's, still pointer management was rough, workflow continues to
elude even the veteran developer, and, ick, it's C++.
Enter the world of .Net. Nearly everything you want is there out of the
box. Developers really only have to concentrate on their workflow, business
logic and persistent data management. Additionally, it quelled the qualms
and heated debates as to C++ and VB; they are now on an even playing field.
For raw power, performance, and interoperability; stick with the unmanaged
C++. For ritual, mundane UI development any of the C++, C#, and VB
solutions will suffice in the implementation. All three can talk to one
another without too much special consideration, a benefit and relief for
anyone that survived the COM/DLL HELL days.
The UI components provided out of the box are consistent and complete.
However; you are not tied to the implicit use of those controls including
the winforms. While you have been provided the ability to have access to
all events, messages and awareness, you may and can create your own set of
UI components from the ground up inheriting right from System.Object.
Synchronous/Asynchronous, bah who cares, if you don't like red kool-aid, try
the purple.
You may be stuck with deploying the whole framework; however, you are not
tied to the whole framework. And still, this conversation assumes that the
performance hit is such that it bothers the user. ACT is an example of
something funky going on in the .Net world; however I think it has more to
do with data then the interface.
There are not a lot of commercial applications out there that I know of,
that employ .Net. Those that are out there, I wonder about the teams that
employ them, were they trying to stick to the old ways and not taking full
advantage of the new features? What about the code base, was a direct port
from earlier works or was it optimized and tweaked. Did they clean up
disposable object, release resources? Just because it is in commercial
release doesn't make it right, take a look at Windows ME's longevity and
acceptance.
..Net is the necessary evil in my world. A development tool it not always
the most technically proficient bearer of results. Why use .Net when Office
will work? Why use .Net when windows scheduler will suffice? Why drink Bud
Dry? All decisions are influenced by external sources and not always the
right ones, why else would a normal human being pay thousands for a wiper
blade for a government aircraft?
In an experiment, I have created a VB application and a VB.Net application.
One form with one button each. The button launches five new instances of
the form. Using tick count, the times appear very similar. What are
specifically seems slow and sluggish in your application?
I am running out of steam, so I will close with this. Public ridicule
chastising public ridicule discredits your ability to ask serious questions
and weakens your perceived insight in future discussions, reiterating your
contempt was just petty, childish and low.
I don't know Cor, but I know of his work and involvement in the community.
Right or wrong, he and others are there to assist and help. They do so, and
people are resolving their issues. Yes, he may be doctrinated and advocates
his views in his responses, but doesn't a professor do the same when asked
to impart his knowledge?
When a co-worker annoys you, do you say so publicly? When someone at Burger
King steps on your toes, twice, do you make a loud rebuke? Professional
courtesy says you debate the points, agree to disagree, or just keep quite.
Common courtesy says you apologize for the terse, personal, and unwanted
comments.
