[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[open-cobol-list] Fwd: open-cobol-list Digest, Vol 51, Issue 3
|
From: |
damon |
|
Subject: |
[open-cobol-list] Fwd: open-cobol-list Digest, Vol 51, Issue 3 |
|
Date: |
Wed, 17 Aug 2011 07:58:45 -0700 |
|
User-agent: |
RoundCube Webmail/0.5.2 |
For my two cents I'd rather have UDF and a solid framework for
integrating with a GUI api.
COBOL is a solid language and has been for many years. If I ever get
anytime I want to work with Brian Tiffin on solidifying a working
framework with some GUI interface language.
I think that will help move OC onto a more accepted platform in the
windowed world.
Again my two cents.
Damon
-------- Original Message --------
Subject: open-cobol-list Digest, Vol 51, Issue 3
Date: Thu, 11 Aug 2011 04:05:53 +0000
From: address@hidden
To: address@hidden
Reply-To: address@hidden
Send open-cobol-list mailing list submissions to
address@hidden
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.sourceforge.net/lists/listinfo/open-cobol-list
or, via email, send a message with subject or body 'help' to
address@hidden
You can reach the person managing the list at
address@hidden
When replying, please edit your Subject line so it is more specific
than "Re: Contents of open-cobol-list digest..."
Today's Topics:
1. Re: On forum registration problems (William M Klein)
2. Re: On forum registration problems (John Culleton)
3. Re: On forum registration problems (David Jackson)
----------------------------------------------------------------------
Message: 1
Date: Sun, 7 Aug 2011 14:28:43 -0500
From: "William M Klein" <address@hidden>
Subject: Re: [open-cobol-list] On forum registration problems
To: "'David Jackson'" <address@hidden>,
<address@hidden>
Message-ID: <address@hidden>
Content-Type: text/plain; charset="us-ascii"
I strongly recommend AGAINST supporting the *full* 2002 COBOL Standard.
It
has as required a NUMBER of things that are now OPTIONAL in the draft
revision (which should become official in the next year or so).
for example,
VALIDATE
Report Writer
WRITE file-name (not record-name)
ARITHMETIC is STANDARD (Standard-Decimal and Standard-binary are new
in
the revision)
Locale support
Multiple Inheritance and Parametric polymorphism
* * *
Supporting OO is certainly a "nice" to do item, and with gc++ being
available, I can see it as NOT impossible to do. However, as far as I
know,
of the commercial COBOL vendors only Micro Focus has actually
implemented a
fully 2002 conforming OO, so that doesn't seem (to me) to indicate much
of a
user demand for it among existing COBOL programmers.
From: David Jackson [mailto:address@hidden
Sent: Saturday, August 06, 2011 10:05 AM
To: address@hidden
Subject: Re: [open-cobol-list] On forum registration problems
COBOL 2002 includes Object Oriented features. I think complete COBOL
2002
support would be a great thing for OpenCOBOL and would help make it
even
more useful. That should be a project goal in my view is to fully
support
COBOL 2002.
On Sat, Aug 6, 2011 at 9:36 AM, David Jackson <address@hidden>
wrote:
Like with C++ additions to C, object oreinted extensions to COBOL can
be
done in a way that extends and fits into the existing language, i think
that
the goal with that should be to maintain complete compability with the
existing form of the COBOL language. Maintaining backwards
compatability is
important, one thing I like about COBOL is its storied and rich
history,
going back to the 1950s, this has made the language have an interesting
story to go along with it and is one of the reasons in my interest in
it.
On Sat, Aug 6, 2011 at 9:19 AM, David Jackson <address@hidden>
wrote:
Thank you for the reply to my message, it is greatly appreciated.
Hopefully
the problems can be fixed.
I am a COBOL hobbyist and I am so glad that OpenCOBOL is here since I
have
long had an interest in learning COBOL and now I can.
Does OpenCOBOL include any object oriented features? I know with many
non-OO
languages you can simulate objects, such as with a function pointer in
a
struct in C, but the syntax is not particularly easy to write or
elegant,
C++ added an OO extension to make things more elegant. Has there been
anything similar in regards to OpenCOBOL? Languages are partly about
making
code easy to write and "syntax sugar", all high level languages are
syntax
sugar, and thats a very good positive thing, if they were not we would
still
be coding in binary opcodes, not even assembly.
On Fri, Aug 5, 2011 at 7:36 PM, David Jackson <address@hidden>
wrote:
Greetings,
Being an OpenCOBOL fan, I have recently tried to register a forum
account
at opencobol.org. However, it has said that I cannot do this. Others
who
have also wanted to register accounts have also mentioned this. Please
reopen the forum registration so people can participate in OpenCOBOL.
OpenCOBOL should be an "open" project.
-------------- next part --------------
An HTML attachment was scrubbed...
------------------------------
Message: 2
Date: Sun, 7 Aug 2011 16:48:20 -0400
From: John Culleton <address@hidden>
Subject: Re: [open-cobol-list] On forum registration problems
To: address@hidden
Message-ID: <address@hidden>
Content-Type: text/plain; charset="utf-8"
On Sunday, August 07, 2011 03:28:43 pm William M Klein wrote:
I strongly recommend AGAINST supporting the *full* 2002 COBOL
Standard. It
has as required a NUMBER of things that are now OPTIONAL in the
draft
revision (which should become official in the next year or so).
for example,
VALIDATE
Report Writer
WRITE file-name (not record-name)
ARITHMETIC is STANDARD (Standard-Decimal and Standard-binary are
new in
the revision)
Locale support
Multiple Inheritance and Parametric polymorphism
Sounds like common sense has taken over. Perhaps the standard makers
actually talked to working COBOL programmers for a change.
One problem is that the professors who teach COBOL in school (if
there are any left) and most COBOL text book writers are for the most
part people who never worked as a COBOL programmers. They like OO,
they like Java, they like C++. So they try to bend COBOL to make it
fit their predilictions. For a while it seems that the COBOL standard
writers were of the same ilk.
COBOL will never be like Ruby, or Scheme, or any similar language. It
has a different mission. It deals with very large data bases and the
decimal arithmetic of accounting systems. Order Entry, Inventory
Control, General Ledger, Payroll, Shop Orders, Mailing Lists: these
are the tasks that COBOL does better than any other language. And it
should read like plain English. To the extent practible is should
have the tools to make it self-documenting, including all the
paragraphs of the Identification Division as an agreed-upon template.
(End rant, I have to get ready for church.)
--
John Culleton
"Death Wore Black" Police procedural: http://www.deathworeblack.com/
"Create Book Covers with Scribus"
http://booklocker.com/books/4055.html
-------------- next part --------------
An HTML attachment was scrubbed...
------------------------------
Message: 3
Date: Thu, 11 Aug 2011 00:05:42 -0400
From: David Jackson <address@hidden>
Subject: Re: [open-cobol-list] On forum registration problems
To: John Culleton <address@hidden>
Cc: address@hidden
Message-ID:
<address@hidden>
Content-Type: text/plain; charset="iso-8859-1"
On Sun, Aug 7, 2011 at 4:48 PM, John Culleton <address@hidden>
wrote:
**
On Sunday, August 07, 2011 03:28:43 pm William M Klein wrote:
> I strongly recommend AGAINST supporting the *full* 2002 COBOL
Standard.
It
> has as required a NUMBER of things that are now OPTIONAL in the
draft
> revision (which should become official in the next year or so).
>
>
>
> for example,
>
> VALIDATE
>
> Report Writer
>
> WRITE file-name (not record-name)
>
> ARITHMETIC is STANDARD (Standard-Decimal and Standard-binary are
new in
> the revision)
>
> Locale support
>
> Multiple Inheritance and Parametric polymorphism
>
>
>
Sounds like common sense has taken over. Perhaps the standard makers
actually talked to working COBOL programmers for a change.
One problem is that the professors who teach COBOL in school (if
there are
any left) and most COBOL text book writers are for the most part
people who
never worked as a COBOL programmers. They like OO, they like Java,
they like
C++. So they try to bend COBOL to make it fit their predilictions.
For a
while it seems that the COBOL standard writers were of the same ilk.
COBOL will never be like Ruby, or Scheme, or any similar language. It
has a
different mission. It deals with very large data bases and the
decimal
arithmetic of accounting systems. Order Entry, Inventory Control,
General
Ledger, Payroll, Shop Orders, Mailing Lists: these are the tasks that
COBOL
does better than any other language. And it should read like plain
English.
To the extent practible is should have the tools to make it
self-documenting, including all the paragraphs of the Identification
Division as an agreed-upon template.
(End rant, I have to get ready for church.)
--
John Culleton
"Death Wore Black" Police procedural: http://www.deathworeblack.com/
"Create Book Covers with Scribus"
http://booklocker.com/books/4055.html
------------------------------------------------------------------------------
BlackBerry® DevCon Americas, Oct. 18-20, San Francisco, CA
The must-attend event for mobile developers. Connect with experts.
Get tools for creating Super Apps. See the latest technologies.
Sessions, hands-on labs, demos & much more. Register early & save!
http://p.sf.net/sfu/rim-blackberry-1
_______________________________________________
open-cobol-list mailing list
address@hidden
https://lists.sourceforge.net/lists/listinfo/open-cobol-list
I will disagree with this, it should be a project goal to support COBOL
2002
as well as COBOL 85. Only some compilers may support COBOL 2002 at this
time
but we want to remain compatable with them and assure that there is
compatability, and other compilers probably will implement support for
it.
OO features are well known to improve the design of programs. People
are
looking for these features, by adding them to COBOL no one is required
to
use them, but those who want them and look for this in the language
will
find them, this will increase COBOLs uptake. You may not like OO, i
think
thats your loss, but, COBOL is not a very popular language today and
that is
due to the perception it does not support higher level programming
features
such as OO which are needed by many massive software projects.
It is best to take a mechanism not policy design goal here and make
functionality available and let the programmers decide whether they are
appropriate for a specific project. We cannot anticipate if a certain
feature will be useful for a programmer or make assumptions that it is
not
valuable for some unforeseen circumstances.
I fully support COBOL 85 and traditional support for all COBOL features
and
traditional styles, as well it is crucial that OpenCOBOL also support a
full
set of modern features such as OO, for it to become more popular. COBOL
is a
fading language and I think these features will help revive it, adn
these
features are an addition to the current language, they do not require
the
existing language be changed at all. So its still COBOL, just more
powerful
and with more capability.
Standards and features support is important. lets not limit the
capabilities
or compatability.
https://lists.sourceforge.net/lists/listinfo/open-cobol-list
-------------- next part --------------
An HTML attachment was scrubbed...
------------------------------
------------------------------------------------------------------------------
Get a FREE DOWNLOAD! and learn more about uberSVN rich system,
user administration capabilities and model configuration. Take
the hassle out of deploying and managing Subversion and the
tools developers use with it.
http://p.sf.net/sfu/wandisco-dev2dev
------------------------------
_______________________________________________
open-cobol-list mailing list
address@hidden
https://lists.sourceforge.net/lists/listinfo/open-cobol-list
End of open-cobol-list Digest, Vol 51, Issue 3
**********************************************
- [open-cobol-list] Fwd: open-cobol-list Digest, Vol 51, Issue 3,
damon <=