Why VB.NET??

  • Thread starter Thread starter FelixLeung
  • Start date Start date
Dennis,

Cobol Common Business Oriented Language

The reason is that especially big companies are slow in changing, where one
of the reasons are unexpected errors.

An other reason is that Cobol is created for streaming processing. (The
process is to collect data, process that data streaming to a database,
process streaming from the database reports or by instance bills).

What is still a major part of the processes by big companies. Think for that
on Banks, Gas, Electra, Social etc companies.

Cobol fits very well for those processes (a major difference with newer
languages is that it is not event driven). So there is not much reason for
the management to change (a problem can be when a kind of hardware that was
forever used is not anymore deliverable, than we probably see actions driven
by panic.

I hope that this gives an idea

Cor
 
Well, back then Basic was not event driven also. I guess there are some
events in Cobol now :-)



Best Regards,
Alejandro Lapeyre
 
Alejandro,
Well, back then Basic was not event driven also. I guess there are some
events in Cobol now :-)
Click to expand...

I had first in my message (the original) however skipped that.

Because I think (don't know) that those newer ones are not which are used
for the processes I am talking about.

:-)

Cor
 
Zanna said:
That's obvious. Is a prerequisite ...
Click to expand...

True enough, but this particular "prerequisite" runs to 20-odd Mb;
the VB6 equivalent was what? 4 Mb? Not /everyone/ has a T1
connection to Our Friends in Redmonds' down load site ;-)
That's not completely true.
You can share your assemblies in the global cache and ALL programs
will see them.
Click to expand...

Again true, but the O.P. was, IIRC, referring to XCopy deployment,
just lift, drop and run, which precludes use of the GAC.
Surely you don't redistribuite the framework assembly you reference
in each application ;)
Click to expand...

Of //course// I do 8-))
Only if you break the versioning release number.
Click to expand...

For a GAC-"registered" assembly, I'd agree but, to date, I've never
managed to pass data between "local" DLL's in different applications.

Regards,
Phill W.
 
You seem to imply that the more complicated a language is the more of a "man"
you are. FYI, all programming languages are "SIMPLE" including machine
language...it's the applicaiton design and especially the user interface that
really distinguishes the System's analysts from the programmers.
 
Again true, but the O.P. was, IIRC, referring to XCopy deployment,
just lift, drop and run, which precludes use of the GAC.
Click to expand...

And also precludes *dll hell* which is kinda the whole point. Its horses
for courses and with .Net, you the developer get to decide.

Richard
 
more difficult than.... what?

I'm no lover of Microsoft in general ... but you have to give props to
the homies when they knock one out of the park.

I am developing vertical applications for my employer, a large
scientific insturment company, and blowing them away with how fast I
have been able to produce meaningful results, even though I have never
professionally developed desktop apps in my life.

if you are finding VB.NET too difficult, the problem is probably that
(a) you haven't cracked a good book on the subject [because] (b) you
are not a programmer.

If you are a designer, you might consider flash -- it has simple tools
for developing simple forms and can be made into an executable.
 
Back
Top