Re: Cobol News - Microfocus and AcuCOBOL


<adestrup@xxxxxxxxx> wrote in message
news:1178693192.699748.101870@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Do you really think that C# or VB.NET are the languages of the future?


No, I think they are the languages of today.

It isn't about languages; it is about changing perceptions of data
processing and how information is shared and utilised. It is about a
different model and a different paradigm from procedural coding.

Twenty years ago I read the same things about C, C++ and VB but that
didn't happen!

Must have been wrong then... :-)



What I wrote twenty years ago using VB should be almost completely
rewritten in VB.NET, without any real advantage: nothing changes from
a user's point of view, apart the need of a bigger machine, and a lot
of serious problems for the programmer.


If nothing changes from a User's point of view then either your business is
very static or your understanding of cyber technology is very narrow. Either
way, your users are not being well served.

I disagree strongly about problems for the programmer. Today's tool set is
infinitely better than yesterday's, the languages are more efficient and
quicker and easier to write, it is almost impossible to code incorrectly
thanks to features like Intellisense, and all you have to focus on is the
logic you require. Modern software development is more like assembling LEGO
than coding a line by line solution. How is that more problematic for the
programmer?


What I wrote in COBOL twenty years ago can stay there with minor
changes, again: nothing changes from a user's point of view but, for
the programmer ... a big difference!


Well, if the business you are in has remained static for twenty years, then
I won't argue with you. What I will say is, it is exceptional. Most
businesses need to adapt to an increasingly competitive and dynamic market
place. Fundamental to this is the rapid exchange and sharing of information
and that is why the Internet has changed the way we live and do business.
Companies that can get by without being affected are probably in niche
markets where there is not so much competition.

Apart the durability of your code there's another question which I
think shoud be considered: complexity and readability of code.
Considering a serious application (2.000 to 3.000 programs and hudreds
of thousand of code lines) I think that C#/VB/VB.NET readability and
complexity is far more difficult to maintain than COBOL.

There is no need to maintain code at all if you opt for an object oriented,
component-based approach. I've covered this in depth here and elsewhere, on
other occasions. It is a hard concept for COBOL people to grasp.. Objects
are encapsulated and re-used. They should NOT be maintained. That is one
major difference between the OO and Procedural paradigms. It is too much to
go into here, but if you are still thinking in terms of maintaining source
code then there's little point me pursuing this.

COBOL was/is ideally suited to a procedural paradigm where source code and
the ease of maintenance of it is everything. That is not the modern idiom.
Some sites DO maintain Classes and and tinker constantly with their Java or
whatever. I don't recommend this approach and I have seen it fail in several
shops.

For my own part, I don't maintain the C# I write. It does what it does; new
functionality comes along, it inherits what is there already and extends it.
The existing source, once it is debugged and performing according to
specification does not get changed. Internals of Class libraries do not get
maintained on my watch.


COBOL is certainly very old in its structure; it's OO features, where
present, are not much appreciated and used by programmers; it's
graphical interface, where it exists, is not always easy to be
implemented; etc., etc.

That's all true! But I wouldn't prefer C# or VB.NET just because thier
features are easier to be implemented: what happens if MS decides to
come out with C## or VB#.NET? What about the readability of hunfreds
of thousand of code lines? What about a new ADO#.NET or things like
these?

No problem. Classes and objects remain the same. The 80,000 or so classes
that constitute Dot NET remain the same. There may be some new ones, there
may be some new interfaces, there may be some extensions that inherit
previous methods, properties, and events, but you can bet that your code
will continue to work. Not only in MicroSoft, but on any other platforms
that implement the FCL also. (I have C# code that has run on Linux, just to
see if it would... :-))

First of all there aren't hundreds of thousands of lines of code (that you
can/must manipulate), and even if there were, that code is invoking methods
and propertiers of Classes that you don't write or maintain. They are
pieces of encapsulated functionality (functions, if you like) that you
simply glue together. (or break apart and re-use). The days of sacred source
code ruling everything are over. That was COBOL. Today, the object code
embodied in a Class Library is what matters and you won't have source for it
(unless it is your own library which you wrote yourself, of course), will
never need to have source for it, and couldn't amend it if you wanted to.
The actual source is of purely academic interest; the FUNCTIONALITY is
everything. You don't worry about the source of your Operating System, yet
you use the Classes and Objects embodied in it every day. You expect them to
work, and they do. As specified. The same is true for the Dot NET Framework.

There is no comparison between traditional procedural COBOL and a modern OO
language like C# or Java. They are different paradigms, meeting different
criteria. You might as well compare oranges and submarines...

Pete.


.

Relevant Pages

  • Re: Better MySQL/PHP query formatting (simple question)
    ... > Your code samples are well structured and consistent and I think anyone ... > who would like to be a better PHP programmer would do well to check out ... > time writing COBOL code. ... languages ever), but has been overtaken by newer languages which work ...
    (comp.lang.php)
  • Re: Cobol News - Microfocus and AcuCOBOL
    ... of serious problems for the programmer. ... What I wrote in COBOL twenty years ago can stay there with minor ... Throw away your iPod or TV or even trousers ... those tools don't even have to look like languages. ...
    (comp.lang.cobol)
  • Re: despair
    ... don't own and the programmer must work hard to prevent that. ... If you make a "read" call to SYS$QIO in COBOL or other languages, ... will the COBOL run time detect that QIO is being told to write way ... No maxchar there. ...
    (comp.os.vms)
  • Re: Why COBOL is losing the POWER struggle
    ... simply more concise and more powerful than COBOL. ... Was extremely hard to get into his dumb head that those languages HAD ... Now I focus on functionality. ... BMS back in the late '70s, using mainframe COBOL and green 3270 screens. ...
    (comp.lang.cobol)
  • Re: Ruby, Perl, Python
    ... scripting languages and their roles. ... I am learning Ruby (played a bit ... there is some functionality implemented in one of them that you want to ... -- if you're a good programmer, ...
    (comp.lang.ruby)