Home > Archive > Cobol > June 2007 > for a laught (???)
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
for a laught (???)
|
|
|
|
| Pete Dashwood 2007-06-07, 6:55 pm |
|
"William M. Klein" <wmklein@nospam.netcom.com> wrote in message
news:v5N9i.249145$oS7.209162@fe04.news.easynews.com...
> If anyone is "interested" - you might want to check out the J4 "annual
> report" at:
>
> http://www.cobolstandard.info/j4/files/07-0096.htm
>
> --
> Bill Klein
> wmklein <at> ix.netcom.com
>
Sadly it isn't funny.
I find it absolutely appalling that an official document, under the auspices
of the official guardians of COBOL, can have a very important section of
itself that is simple bullshit and hearsay.
I refer, of course to Section 8, which is the only part of the document that
would be of any interest to me (and probably a number of other people...)
I reproduce it here, with my comments: (Quoted lines are prefixed with a
single chevron)
>8. Future Trends and Related Technical Activities
There are no discernable technical activities under this heading...
>COBOL continues to be widely used for development of new applications, and
>for enhancement and re-engineering of existing >applications.
Does it? Says who? I know a number of IT managers and none of them feels
this way. I know of no sites which are undertaking new development in
COBOL. I know of some who are re-engineering their existing COBOL.
>The trend in the industry is to web-enable COBOL applications, with COBOL
>running on a server interacting with a non->COBOL >user interface.
Yes, that seems to be the case, but would it hurt to give some sources for
the figures? Even if the author simply said "In my opinion..." or "According
to my observations" you could at least respect him/her for being honest.
This kind of sweeping statement should be confined to Usenet where we expect
bullshit, and not form part of an official report from a serious Authority.
>The following facts give you an idea of the importance of COBOL:
FACTS????!!!! I am reminded of a definition of the term I once heard:
"Fact" is a little furry animal that lives at the bottom of the sea and
strides around in seven league sea boots collecting fish farts to put in
spirit levels. And that's a fact"
It would seem the author is operating on the same definition of a fact.
>· More than $1.5 trillion has been invested in COBOL applications
Gosh, where have I heard this before?
>· More than 30 billion COBOL transactions occur daily
Gosh, where have I heard this before?
>· More than 200 billion lines of COBOL code are working as you read
>this
No, 100 billion of them are being retired... It's a fact... I just said
it...
>· More than 5 billion lines of COBOL are written every year
And the guy who's doing it has severe carpal tunnel syndrome... This is
such a horrific misquote it beggars belief. Gartner said (in year 2000, that
they expected 5 billion lines of COBOL (notice they did NOT say "more than 5
billion") to be written each year for the next 4 years. NOT every year for
as long as you like... Systems are being converted, COBOL programmers are
retiring, it is highly unlikely that in 2007 there will be 5 billion lines
of COBOL being written, but the fact is that nobody knows for sure. So why
include unverifiable speculation in an official document, and claim that it
is FACT? Exactly how does this improve the image and credibility of J4?
>· 75% of the world's business data is in COBOL.
It was once. 25 years ago. What really annoys me about this is that it isn't
hard to find sources and they simply don't stack up with Gartner. (In fact,
even Gartner themselves have revised their year 2000 estimates.)
For example, (read the complete article at:
http://www.itjungle.com/tug/tug121406-story03.html it is very
interesting...):
"If you want to get a second opinion on the popularity of languages, Tiobe
Software puts together an annual study of the popularity of programming
languages, too. This survey is based on using Web search engines to find the
phrases "Java programming," "COBOL programming," "C programming," and so on
and averaging across the search engines. The average hits are counted up to
give a ranking. This may not be scientific, but it is interesting. Card
walloper languages like COBOL rank at number 18 (with 0.601 percent of hits)
on the Tiobe chatter index, and RPG comes in at number 31 (with 0.238
percent). Java, by contrast, comes in number one with 19.9 percent of hits,
followed by C at 16.6 percent, C++ at 10.4 percent, Visual Basic at 8.9
percent, PHP at 8.5 percent, and C# at 3.17 percent.:"
If this is true, it would indicate that C# (a comparative Johnny-come-lately
in the programming world) is over 5 times more popular than COBOL is... But
I strongly doubt that there are 25 billion lines of C# being written every
year (Ok, it is a much more powerful language, so you need less of it... :-)
It seems that the author, completely unable to research anything remotely
probable, has decided to simply drop a 7 year old Gartner press release into
what is arguably the most important section of the document.
What REALLY is the future for COBOL and what part do J4 see themselves
playing in it?
"Er... dunno, but here's something that looks impressive... Let's just
boilerplate some bullshit and head off on another boondoggle..."
>Continued evolution of the international standard for COBOL is essential to
>provide the benefits of new technologies and new >environments to COBOL
>users worldwide.
These same users are voting with their feet as far as J4 is concerned, and
who can blame them. If this document is a reflection of the Quality of the
management at J4 there is absolutely no hope for COBOL.
I wish I could laugh at it.
I can't.
Pete.
| |
| Howard Brazee 2007-06-07, 6:55 pm |
| On Fri, 8 Jun 2007 01:43:05 +1200, "Pete Dashwood"
<dashwood@removethis.enternet.co.nz> wrote:
>
>It was once. 25 years ago. What really annoys me about this is that it isn't
>hard to find sources and they simply don't stack up with Gartner. (In fact,
>even Gartner themselves have revised their year 2000 estimates.)
I don't even know what that means. Does it mean the data are in
flat files, accessible by CoBOL? Does it mean the data are in
databases accessible by CoBOL? Very little data are encapsulated
with CoBOL code.
| |
| Alistair 2007-06-07, 6:55 pm |
| On 7 Jun, 14:43, "Pete Dashwood" <dashw...@removethis.enternet.co.nz>
wrote:
> "William M. Klein" <wmkl...@nospam.netcom.com> wrote in messagenews:v5N9i.249145$oS7.209162@fe04.news.easynews.com...> If anyone is "interested" - you might want to check out the J4 "annual
>
>
>
> Sadly it isn't funny.
>
> I find it absolutely appalling that an official document, under the auspices
> of the official guardians of COBOL, can have a very important section of
> itself that is simple bullshit and hearsay.
>
> I refer, of course to Section 8, which is the only part of the document that
> would be of any interest to me (and probably a number of other people...)
>
> I reproduce it here, with my comments: (Quoted lines are prefixed with a
> single chevron)
>
>
> There are no discernable technical activities under this heading...
>
>
> Does it? Says who? I know a number of IT managers and none of them feels
> this way. I know of no sites which are undertaking new development in
> COBOL. I know of some who are re-engineering their existing COBOL.
>
>
> Yes, that seems to be the case, but would it hurt to give some sources for
> the figures? Even if the author simply said "In my opinion..." or "According
> to my observations" you could at least respect him/her for being honest.
> This kind of sweeping statement should be confined to Usenet where we expect
> bullshit, and not form part of an official report from a serious Authority.
>
>
> FACTS????!!!! I am reminded of a definition of the term I once heard:
>
> "Fact" is a little furry animal that lives at the bottom of the sea and
> strides around in seven league sea boots collecting fish farts to put in
> spirit levels. And that's a fact"
Nice definition (I'm going to start using it) but:
Unfortunately, to pour cold water on this definition, I would like to
point out that the only fish that has, as yet, been shown to fart is
in fact (every pun intended) Clupea harengus (the herring) which swims
in shoals near the surface of the sea. Therefore, the Fact would have
a very lean time collecting farts at the bottom of the sea.
Only one more comment (see below).
>
> "If you want to get a second opinion on the popularity of languages, Tiobe
> Software puts together an annual study of the popularity of programming
> languages, too. This survey is based on using Web search engines to find the
> phrases "Java programming," "COBOL programming," "C programming," and so on
> and averaging across the search engines. The average hits are counted up to
> give a ranking. This may not be scientific, but it is interesting. Card
> walloper languages like COBOL rank at number 18 (with 0.601 percent of hits)
> on the Tiobe chatter index, and RPG comes in at number 31 (with 0.238
> percent). Java, by contrast, comes in number one with 19.9 percent of hits,
> followed by C at 16.6 percent, C++ at 10.4 percent, Visual Basic at 8.9
> percent, PHP at 8.5 percent, and C# at 3.17 percent.:"
>
> If this is true, it would indicate that C# (a comparative Johnny-come-lately
> in the programming world) is over 5 times more popular than COBOL is... But
> I strongly doubt that there are 25 billion lines of C# being written every
> year (Ok, it is a much more powerful language, so you need less of it... :-)
>
Very interesting figures, Pete. I don't think that web page tags,
etc., can be used as a definitive indicator of the usage made of a
language (Befunge may figure more highly than Cobol but no-one uses it
for serious work) but they can, as you have, raise some serious
questions. Maybe Cobollers don't want to talk about it too much (it
must be a little like being in favour of the recently usurped
dictator).
| |
|
| William M. Klein wrote:
> If anyone is "interested" - you might want to check out the J4 "annual report"
> at:
>
> http://www.cobolstandard.info/j4/files/07-0096.htm
Well, you had question marks on the "for a laugh" part, but I didn't
really laugh at all. There is progress in there, but it's slow going.
It seems like maybe the processes that are in place are slow intentionally.
I'm certainly not knocking the efforts of anyone on that committee. To
change a language with new, useful features while ensuring that
40-year-old programs still compile and run as they did then, is an
immense task. With the few members they have, they're doing well.
It just seems that maybe they're using the waterfall approach, while
other languages are using RAD or Agile development. No sooner had I
bought "Learn Java 5 in 21 Days", Sun released Java 6!
I'm sure there are ways to do a lot of things that other languages do in
COBOL (yes, a good programmer can write FORTRAN in any language); it
just that while the committee has been figuring out how to do it, other
vendors have been giving it away. When a COBOL vendor *does* get it
implemented, it's thousands of dollars for a working copy. When I was
at my last assignment, we talked to Unisys and asked what people were
asking for. Were they asking for 2002-standard COBOL features? Nope -
they wanted JBoss, Tomcat, and a robust JDBC server. As it was, we were
exercising parts of their compiler that hadn't been exercised (I'm
extrapolating this from the number of fixes we initiated). It does
seem, as Mr. Dashwood has said many times, that the world has moved on.
The stats in section 8 seem a bit high - it's good for the language if
they're accurate, but I think they might be embellished.
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~~~~~
~ / \/ _ o ~ Live from Albuquerque, NM! ~
~ _ /\ | ~ ~
~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
~ Business E-mail ~ daniel @ "Business Website" below ~
~ Business Website ~ http://www.djs-consulting.com ~
~ Tech Blog ~ http://www.djs-consulting.com/linux/blog ~
~ Personal E-mail ~ "Personal Blog" as e-mail address ~
~ Personal Blog ~ http://daniel.summershome.org ~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~~~~~
GEEKCODE 3.12 GCS/IT d s-:+ a C++ L++ E--- W++ N++ o? K- w$ !O M--
V PS+ PE++ Y? !PGP t+ 5? X+ R* tv b+ DI++ D+ G- e h---- r+++ z++++
"Who is more irrational? A man who believes in a God he doesn't see,
or a man who's offended by a God he doesn't believe in?" - Brad Stine
| |
| don_fitzgerald@web.de 2007-06-09, 7:55 am |
| Pete,
without going into each point that you raise (not because I am lazy -
I just feel that they are not all relevant, and in my opinion, reflect
something other than objective comments on COBOL and Development in
general) some comments: (prefixed with "Dons Comment")
Pete Dashwood wrote:
> I find it absolutely appalling that an official document, under the auspi=
ces
> of the official guardians of COBOL, can have a very important section of
> itself that is simple bullshit and hearsay.
>
> I refer, of course to Section 8, which is the only part of the document t=
hat
> would be of any interest to me (and probably a number of other people...)
>
> I reproduce it here, with my comments: (Quoted lines are prefixed with a
> single chevron)
>
>
> There are no discernable technical activities under this heading...
>
nd[color=darkred]
>
> Does it? Says who? I know a number of IT managers and none of them feels
> this way. I know of no sites which are undertaking new development in
> COBOL. I know of some who are re-engineering their existing COBOL.
Dons Comment: we work with around 600 companies that use COBOL in
their IT. All of them are are doing ongoing COBOL development and
major maintenance. This past w , we met with 3 (for us new)
companies, working on diverse platforms, who are all designing new
COBOL applications.
>
>
> Yes, that seems to be the case, but would it hurt to give some sources for
> the figures? Even if the author simply said "In my opinion..." or "Accord=
ing
> to my observations" you could at least respect him/her for being honest.
> This kind of sweeping statement should be confined to Usenet where we exp=
ect
> bullshit, and not form part of an official report from a serious Authorit=
y=2E
Dons Comment: you only have to look at what the COBOL companies are
doing to see that this comment is correct. I dont know of any COBOL
manufacturer who is developing anything that companies out there are
not asking for - and this is primarily Web Interface work.
>
> FACTS????!!!! I am reminded of a definition of the term I once heard:
>
> "Fact" is a little furry animal that lives at the bottom of the sea and
> strides around in seven league sea boots collecting fish farts to put in
> spirit levels. And that's a fact"
>
> It would seem the author is operating on the same definition of a fact.
>
>
ons[color=darkred]
>
> Gosh, where have I heard this before?
>
>
> Gosh, where have I heard this before?
>
read[color=darkred]
>
> No, 100 billion of them are being retired... It's a fact... I just said
> it...
>
>
> And the guy who's doing it has severe carpal tunnel syndrome... This is
> such a horrific misquote it beggars belief. Gartner said (in year 2000, t=
hat
> they expected 5 billion lines of COBOL (notice they did NOT say "more tha=
n 5
> billion") to be written each year for the next 4 years. NOT every year f=
or
> as long as you like... Systems are being converted, COBOL programmers are
> retiring, it is highly unlikely that in 2007 there will be 5 billion lines
> of COBOL being written, but the fact is that nobody knows for sure. So why
> include unverifiable speculation in an official document, and claim that =
it
> is FACT? Exactly how does this improve the image and credibility of J4?
>
>
> It was once. 25 years ago. What really annoys me about this is that it is=
n't
> hard to find sources and they simply don't stack up with Gartner. (In fac=
t,
> even Gartner themselves have revised their year 2000 estimates.)
Dons Comment: Yeah, you are right on this. This definition of facts is
a very interesting one, and I don't think any one would be well
advised to take it seriously. I believe they are only trying to
justify their own roles - but that is also a subjective opinion from
my side. Perhaps a problem is that the only open systems manufacturer
I see referred to is Micro Focus, and the risk is that the only
standards that get addressed are those that match Micro Focus
objectives. But that is the fault of the other manufacturers.
>
> For example, (read the complete article at:
> http://www.itjungle.com/tug/tug121406-story03.html it is very
> interesting...):
>
> "If you want to get a second opinion on the popularity of languages, Tiobe
> Software puts together an annual study of the popularity of programming
> languages, too. This survey is based on using Web search engines to find =
the
> phrases "Java programming," "COBOL programming," "C programming," and so =
on
> and averaging across the search engines. The average hits are counted up =
to
> give a ranking. This may not be scientific, but it is interesting. Card
> walloper languages like COBOL rank at number 18 (with 0.601 percent of hi=
ts)
> on the Tiobe chatter index, and RPG comes in at number 31 (with 0.238
> percent). Java, by contrast, comes in number one with 19.9 percent of hit=
s,
> followed by C at 16.6 percent, C++ at 10.4 percent, Visual Basic at 8.9
> percent, PHP at 8.5 percent, and C# at 3.17 percent.:"
>
> If this is true, it would indicate that C# (a comparative Johnny-come-lat=
ely
> in the programming world) is over 5 times more popular than COBOL is... B=
ut
> I strongly doubt that there are 25 billion lines of C# being written every
> year (Ok, it is a much more powerful language, so you need less of it... =
:-)
>
Dons Comments: This is not very reliable. On this kind of "survey" you
would probably find Adolf Hitler's name appearing a heck of a lot more
often then Nelson Mandela's, but to draw the conclusion that Hitler is
more popular
? This is of course also nonsense, but no more so that the so-called
survey refered to above.
> It seems that the author, completely unable to research anything remotely
> probable, has decided to simply drop a 7 year old Gartner press release i=
nto
> what is arguably the most important section of the document.
>
> What REALLY is the future for COBOL and what part do J4 see themselves
> playing in it?
>
> "Er... dunno, but here's something that looks impressive... Let's just
> boilerplate some bullshit and head off on another boondoggle..."
>
to[color=darkred]
>
Dons Comment: Fortunately for the COBOL users, what is reflected here
is not reflected by the COBOL manufacturers activities. There is a lot
of activity out there in tools development around COBOL, and even if
compared to other languages it is not very high profile, it is, in my
opinion, going in the right direction. Integration. COBOL has for us
been an Integration Language for the last 10 years. Of course it won't
be there for ever, and the main objective can, in my opinion, only be,
to ensure those who have and are developing in COBOL can move their
application knowledge forward without throwing it all away just to
allow them to progress.
> These same users are voting with their feet as far as J4 is concerned, and
> who can blame them. If this document is a reflection of the Quality of the
> management at J4 there is absolutely no hope for COBOL.
Dons Comment: You probably have stated in ths forum what you would
expect from COBOL to make it something for you. For the sake of the
latecomers like myself, perhaps you would describe your
"requirements" ?
> I wish I could laugh at it.
>
> I can't.
>
> Pete.
regards
Don
| |
| Pete Dashwood 2007-06-09, 9:55 pm |
|
<don_fitzgerald@web.de> wrote in message
news:1181382599.317681.92110@q69g2000hsb.googlegroups.com...
Pete,
without going into each point that you raise (not because I am lazy -
I just feel that they are not all relevant, and in my opinion, reflect
something other than objective comments on COBOL and Development in
general) some comments: (prefixed with "Dons Comment")
OK.
Responses below.
Pete Dashwood wrote:
> I find it absolutely appalling that an official document, under the
> auspices
> of the official guardians of COBOL, can have a very important section of
> itself that is simple bullshit and hearsay.
>
> I refer, of course to Section 8, which is the only part of the document
> that
> would be of any interest to me (and probably a number of other people...)
>
> I reproduce it here, with my comments: (Quoted lines are prefixed with a
> single chevron)
>
>
> There are no discernable technical activities under this heading...
>
You ignored this?
>
> Does it? Says who? I know a number of IT managers and none of them feels
> this way. I know of no sites which are undertaking new development in
> COBOL. I know of some who are re-engineering their existing COBOL.
Dons Comment: we work with around 600 companies that use COBOL in
their IT. All of them are are doing ongoing COBOL development and
major maintenance. This past w, we met with 3 (for us new)
companies, working on diverse platforms, who are all designing new
COBOL applications.
Fair enough. So why isn't a comment to that effect included in the report?
What ARE some fo these Technical Activities that are going on in the COBOL
World and how is J4 involved in supporting and promoting them?
>
>
> Yes, that seems to be the case, but would it hurt to give some sources for
> the figures? Even if the author simply said "In my opinion..." or
> "According
> to my observations" you could at least respect him/her for being honest.
> This kind of sweeping statement should be confined to Usenet where we
> expect
> bullshit, and not form part of an official report from a serious
> Authority.
Dons Comment: you only have to look at what the COBOL companies are
doing to see that this comment is correct. I dont know of any COBOL
manufacturer who is developing anything that companies out there are
not asking for - and this is primarily Web Interface work.
We can agree a lot of current work is going on in web interfacing COBOL. (I
posted sample code for doing it to this very forum, a couple fo ws ago,
in response to some private, and one public, requests from users.
Nevertheless, my objection is to having something stated as a FACT without
citation or verifiabilty, whether I agree with it or not.
>
> FACTS????!!!! I am reminded of a definition of the term I once heard:
>
> "Fact" is a little furry animal that lives at the bottom of the sea and
> strides around in seven league sea boots collecting fish farts to put in
> spirit levels. And that's a fact"
>
> It would seem the author is operating on the same definition of a fact.
>
>
>
> Gosh, where have I heard this before?
>
>
> Gosh, where have I heard this before?
>
>
> No, 100 billion of them are being retired... It's a fact... I just said
> it...
>
>
> And the guy who's doing it has severe carpal tunnel syndrome... This is
> such a horrific misquote it beggars belief. Gartner said (in year 2000,
> that
> they expected 5 billion lines of COBOL (notice they did NOT say "more than
> 5
> billion") to be written each year for the next 4 years. NOT every year
> for
> as long as you like... Systems are being converted, COBOL programmers are
> retiring, it is highly unlikely that in 2007 there will be 5 billion lines
> of COBOL being written, but the fact is that nobody knows for sure. So why
> include unverifiable speculation in an official document, and claim that
> it
> is FACT? Exactly how does this improve the image and credibility of J4?
>
>
> It was once. 25 years ago. What really annoys me about this is that it
> isn't
> hard to find sources and they simply don't stack up with Gartner. (In
> fact,
> even Gartner themselves have revised their year 2000 estimates.)
Dons Comment: Yeah, you are right on this. This definition of facts is
a very interesting one, and I don't think any one would be well
advised to take it seriously. I believe they are only trying to
justify their own roles - but that is also a subjective opinion from
my side. Perhaps a problem is that the only open systems manufacturer
I see referred to is Micro Focus, and the risk is that the only
standards that get addressed are those that match Micro Focus
objectives. But that is the fault of the other manufacturers.
Personally, I have no problem with MicroFocus monopolising COBOL. I'd rather
see it in their hands than J4's.
>
> For example, (read the complete article at:
> http://www.itjungle.com/tug/tug121406-story03.html it is very
> interesting...):
>
> "If you want to get a second opinion on the popularity of languages, Tiobe
> Software puts together an annual study of the popularity of programming
> languages, too. This survey is based on using Web search engines to find
> the
> phrases "Java programming," "COBOL programming," "C programming," and so
> on
> and averaging across the search engines. The average hits are counted up
> to
> give a ranking. This may not be scientific, but it is interesting. Card
> walloper languages like COBOL rank at number 18 (with 0.601 percent of
> hits)
> on the Tiobe chatter index, and RPG comes in at number 31 (with 0.238
> percent). Java, by contrast, comes in number one with 19.9 percent of
> hits,
> followed by C at 16.6 percent, C++ at 10.4 percent, Visual Basic at 8.9
> percent, PHP at 8.5 percent, and C# at 3.17 percent.:"
>
> If this is true, it would indicate that C# (a comparative
> Johnny-come-lately
> in the programming world) is over 5 times more popular than COBOL is...
> But
> I strongly doubt that there are 25 billion lines of C# being written every
> year (Ok, it is a much more powerful language, so you need less of it...
> :-)
>
Dons Comments: This is not very reliable.
No, of course it isn't. Even the author said as much. Buit that was a much
honest statement than the sweeping one in the J4 document.
On this kind of "survey" you
would probably find Adolf Hitler's name appearing a heck of a lot more
often then Nelson Mandela's, but to draw the conclusion that Hitler is
more popular
? This is of course also nonsense, but no more so that the so-called
survey refered to above.
OK, this thread is ended, I win... :-) (Godwin's Law Section 1, sub para
3...)
> It seems that the author, completely unable to research anything remotely
> probable, has decided to simply drop a 7 year old Gartner press release
> into
> what is arguably the most important section of the document.
>
> What REALLY is the future for COBOL and what part do J4 see themselves
> playing in it?
Is this a secret? Or is there just such a lack of ideas that the author
couldn't think of anything?
>
> "Er... dunno, but here's something that looks impressive... Let's just
> boilerplate some bullshit and head off on another boondoggle..."
>
>
Dons Comment: Fortunately for the COBOL users, what is reflected here
is not reflected by the COBOL manufacturers activities. There is a lot
of activity out there in tools development around COBOL, and even if
compared to other languages it is not very high profile, it is, in my
opinion, going in the right direction. Integration. COBOL has for us
been an Integration Language for the last 10 years. Of course it won't
be there for ever, and the main objective can, in my opinion, only be,
to ensure those who have and are developing in COBOL can move their
application knowledge forward without throwing it all away just to
allow them to progress.
See, now that is opinion, expressed fairly and honestly. No issue with it.
Why couldn't the J4 document have equal fairness?
> These same users are voting with their feet as far as J4 is concerned, and
> who can blame them. If this document is a reflection of the Quality of the
> management at J4 there is absolutely no hope for COBOL.
Dons Comment: You probably have stated in ths forum what you would
expect from COBOL to make it something for you. For the sake of the
latecomers like myself, perhaps you would describe your
"requirements" ?
I'm past caring and have moved on. I used to program in COBOL, but you grow.
I started to think about responding to your request, but when I did so I
realised there is nothing COBOL could offer me that I actually want...
The paradigms are so different. I develop for an environment that COBOL was
never intended to cope with. Here are 10 considerations I must take into
account when selecting a programming language:
1. I don't want to maintain source code.
2. I write functionality encapsulated as web services or components.
3. I expect my applications to be web based, although I use the occasional
desktop as well.
3. I won't pay runtime fees, ever. (This is an insidious parasitism on my
imagination and talent. If I buy a product that helps me make things, that's
why I bought it. To have to keep paying every time I make something with it
(given that "making things with it" is its designed purpose) is just an
outrageous free ride on my energy and industry. Besides, I have no choice.
If I use it, I MUST use the runtime. It's like paying a fee to a bottle
manufacturer every time you fill it, and not being able to buy any other
fluid container. Or paying a fee to the manufacturer every time you put a
new bit into your power drill. What staggers me is that people actually buy
such a restrictive product. Not me.
4. I won't pay for a compiler. (I would, but those nice people at Microsoft
give me one for nothing.)
5. I want a supportive and extensive user community that is knowledgeable
and helpful. And I don't want to pay for it; I'll trade...
6. I won't pay for an IDE (Again, those nice people at Microsoft...OK, to be
fair, I was so impressed with the free VS 2005 Express, I DID pay for the
full product. Best money I ever spent on software. My productivity is 4
times what it was in COBOL...)
7. I want a language that is interoperable with other Class libraries and
languages, EASILY, and that I can deploy on any platform (UNIX, Windows,
Linux, MacOS) without having to spend half a day packaging it...
8. I want online help that works and is at my fingertips. In fact, I want
Intellisense...(Of course, I didn't know that until I saw it, but now you
would have to drag it out of my cold dead hand...)
9. I want high quality training materials that will allow me to educate
myself and learn at my own pace. (I would pay for them, but if they are
free...Wow!)
10. I want to be at the cutting edge, not the back end.
Some reasons/examples why I don't use COBOL any more:
1. I needed to be able to send email from an application. I decided to check
the web for sample code. The COBOL offerings were all tools or libraries
which varied in price from $29.99 to $105.00. The C# code was 8 lines and
was free. In less than 10 minutes I had the code working (and learned
something at the same time). There are 80,000 classes available through
DotNET. Total cost to me? Zero. Nada. Zilch... not one brass razoo.
2. I wanted to be able to validate an email address string. (Check it has
only one @ in it, and if a dot occurs in it, it occurs after the @, and that
the @ is present and has valid characters preceding and succeeding it)
COBOL INSPECTS were clumsy and ugly.
One line of code in C# (Regular Expression). Again, sample downloaded from
the Web and working in 5 minutes. (And again, I learned something...)
....
I could go on but it serves no purpose... My beef is not with COBOL; it
served us well for half a century. And it is also true that my move away
from it was prompted more by the treatment I received from a COBOL vendor,
than from any foolishness by J4. But bad thngs sometimes turn out to be
good; it is the best move I could have made and it has clarified for me why
it was time to move away from it anyway.
However, all of this is somewhat away from what we are discussing here.
I am genuinely interested in how J4 see the future role of COBOL and what
they plan to do about it. Instead, we get a steaming heap of bullshit about
how the language is flourishing, based on a 7 year old press release from a
company with a vested interest in the continued use of COBOL. Are we on
different planets, here?
Pete.
| |
| don_fitzgerald@web.de 2007-06-09, 9:55 pm |
| Hey Pete,
Are you a Microsoft salesman incognito ? :-)
Seriously though, I take many of your points on COBOL and comparisons
to Micrsosoft and licensing etc. as valid. What we all shouldn't
forget for even one minute is that Microsoft's (and any other company)
mission is also about making money. We work closely with Microsoft,
and they are very open (at least in our relationship) that their
objective is to sell licences for all the products they possibley can,
especially to ISVs.
As an aside, and not really related to this, I believe that the
Microsoft products have mostly become very good, are getting better
due to the competition that they face in the areas that they are
addressing oustide of the classical "Office" area, (although there as
well of course).
Anyway, I am working on understanding where you are coming from on the
whole COBOL issue. Maybe I will figure it out sometime.
In the meantime, I will follow your contributions with interest !
BTW: coming to France for the Rugby World Cup ?
Don
| |
| William M. Klein 2007-06-09, 9:55 pm |
| <much snippage>
but see below for one specific topic
--
Bill Klein
wmklein <at> ix.netcom.com
"Pete Dashwood" <dashwood@removethis.enternet.co.nz> wrote in message
news:5cvrk4F329bghU1@mid.individual.net...
>
<snip>
> Fair enough. So why isn't a comment to that effect included in the report?
> What ARE some fo these Technical Activities that are going on in the COBOL
> World and how is J4 involved in supporting and promoting them?
>
<snip>
> Personally, I have no problem with MicroFocus monopolising COBOL. I'd rather
> see it in their hands than J4's.
<snip>[color=darkred]
>
<snip>
****
Bill's comment.
I know the exact roles and rules for the various Standards bodies is NOT
something that people in this forum know or need to know - and in fact (IMHO)
they are part of the PROBLEM, but I did want to make it clear that,
J4's exclusive roles (today) are:
1) "design" revisions of the Standard to do what WG4 (the ISO working group)
TELLS them to do
2) draft "fixes" and "interpretations" of the existing ('02) Standard for the
international process to approve or disapprove
3) (for the J4-TAG which is limited to "US domiciled members") to set US
positions (or recommendations) when international votes, meetings, etc occur
J4 is *NOT* the group that "sets direction" or "selects" features or facilities
to be implemented.
This is why I (so often) post notes in this forum telling people to "contact
your local national standards body).
It is worth noting that (like member participation in J4), the number of
countries participating in COBOL (and ALL programming languages) development and
processing is decreasing. (For example, when I know that when Pete contacted the
New Zealand group, they indicated that they an "observer" country for COBOL and
not a "participating" country).
| |
| Pete Dashwood 2007-06-09, 9:55 pm |
|
"William M. Klein" <wmklein@nospam.netcom.com> wrote in message
news:w1Fai.67304$dg3.49084@fe10.news.easynews.com...
> <much snippage>
> but see below for one specific topic
>
> --
> Bill Klein
> wmklein <at> ix.netcom.com
> "Pete Dashwood" <dashwood@removethis.enternet.co.nz> wrote in message
> news:5cvrk4F329bghU1@mid.individual.net...
> <snip>
> <snip>
> <snip>
> <snip>
> ****
>
> Bill's comment.
> I know the exact roles and rules for the various Standards bodies is NOT
> something that people in this forum know or need to know - and in fact
> (IMHO) they are part of the PROBLEM, but I did want to make it clear that,
>
> J4's exclusive roles (today) are:
>
> 1) "design" revisions of the Standard to do what WG4 (the ISO working
> group) TELLS them to do
> 2) draft "fixes" and "interpretations" of the existing ('02) Standard for
> the international process to approve or disapprove
> 3) (for the J4-TAG which is limited to "US domiciled members") to set US
> positions (or recommendations) when international votes, meetings, etc
> occur
>
> J4 is *NOT* the group that "sets direction" or "selects" features or
> facilities to be implemented.
>
> This is why I (so often) post notes in this forum telling people to
> "contact your local national standards body).
>
> It is worth noting that (like member participation in J4), the number of
> countries participating in COBOL (and ALL programming languages)
> development and processing is decreasing. (For example, when I know that
> when Pete contacted the New Zealand group, they indicated that they an
> "observer" country for COBOL and not a "participating" country).
Thanks for the correction, Bill. I take your point that WG4 are the
Guardians of COBOL as far as the standard goes, and NOT J4.
However, on this occasion my issue is with a J4 document and specifically
with a section entitled: "Future Trends and Related Technical Activities"
If you are going to have such a section in an official report, then write
something meaningful in it, for Chrissake. If you have nothing to say, then
either put a statement like: "Future trends for COBOL are unclear at the
moment but we see...(and some of the activities that Don mentioned) or,
better still, omit the section altogether. Simply putting a heap of
boilerplate does the author, the committee, and the whole standards
authority a severe disservice.
Whatever small respect I ever had for the J4 and standards process is now
dissipated.
Pete.
| |
| Pete Dashwood 2007-06-09, 9:55 pm |
|
<don_fitzgerald@web.de> wrote in message
news:1181406713.476081.129140@p47g2000hsd.googlegroups.com...
> Hey Pete,
>
> Are you a Microsoft salesman incognito ? :-)
Not at all. I've been using Fujitsu COBOL ever since the VISOC fiasco.
>
> Seriously though, I take many of your points on COBOL and comparisons
> to Micrsosoft and licensing etc. as valid. What we all shouldn't
> forget for even one minute is that Microsoft's (and any other company)
> mission is also about making money. We work closely with Microsoft,
> and they are very open (at least in our relationship) that their
> objective is to sell licences for all the products they possibley can,
> especially to ISVs.
Well, that's partly my point. If someone is up front and honest, you can
deal with them (even if you may not be in agreement with all of their goals
and the methods they use to attain them.)
It certainly worked with me. Instead of spending several thousand dollars
with Fujitsu to buy DotNET COBOL for DotNET, Microsoft got a sale for VS
2005 and I got more than I could have dreamed of. They far exceeeded my
expectations... Why wouldn't I give repeat business to a company that does
that?
>
> As an aside, and not really related to this, I believe that the
> Microsoft products have mostly become very good, are getting better
> due to the competition that they face in the areas that they are
> addressing oustide of the classical "Office" area, (although there as
> well of course).
>
I have no complaints about their toolset; it is value for money.
> Anyway, I am working on understanding where you are coming from on the
> whole COBOL issue. Maybe I will figure it out sometime.
>
I'm sorry if it isn't clear. Here's some background...
I started programming computers in 1965 and writing COBOL in 1967. I did it
for decades and loved it (still do...). Even after my career progressed into
management and consultancy I still enjoyed programming and writing
applications, mainly in COBOL, but also other languages.
By the 1990s, still waiting for a new COBOL standard to replace the 1985 one
(which became a landmark), it became apparent to me that COBOL was in the
doldrums and the new industry trends were not being picked up by the
language or the community. Then Fujitsu released their OO COBOL and it was
good. Amazingly (to me, at least), the community simply rejected it. I could
understand the mainframe people being skeptical, and they had little
opportunity to use an OO compiler anyway, but there was fierce resistance to
even the idea of looking at new concepts.
There was an atmosphere of complacency and smug satisfaction that COBOL was
king, procedural programing was the way to go (OO was just a re-invention
of modular programming) and there was no need for anyone to learn anything
new, or change what they were doing in the slightest. There were plenty of
COBOL jobs on Jobserve and the contract market for COBOL was still buoyant,
just sliding off the peak it had enjoyed in the mid eighties.
I foresaw that many people would lose their jobs unless they upskilled
quickly, and I tried very hard to encourage people here to do so. I moved
my own career path from programming to management and consultancy at that
time, but also developed skills in OO, Java, and Project Management.
Suggestions here from me, that people look at OO and relational DBs were, in
general, met with scorn and sometimes vitriol. A very few of us got into OO
and realised the power of it. I moved on to components and ActiveX, usng
Fujitsu COBOL and thoroughly enjoying it, although I didn't make much money
at it :-) (I still needed my "proper job" to make a living...)
By the end of the 90s we were still waiting for a COBOL standard; there was
argument as to whether it would include OO or not, and the Network (which
was based almost exclusively around Java, a pure OO language) was starting
to seriously erode the mainframe powerbase. Acadaemia was already into OO
and component based design, and more and more Universities dropped COBOL
courses. There was a renewal of interest for the Millennium and again, many
people thought this would be enough to restore COBOL's fading star. It
wasn't of course, and there was still no sign of an official standard that
would provide direction and let us know whether COBOL was going to be viable
into the new century.
By now I was starting to understand that the Internet was going to change
everything irrevocably. I was building web sites and using components
written with Fujitsu COBOL, for CGI. It worked but it was not facile. There
was still a lot of stuff that needed embedded scripts for it to work
properly.
(As an aside, let me say that the web development I am currently undertaking
uses C# and ASP.Net exclusively. Web pages are simply pages written in ASP;
all of the "intelligence" is moved to a "code-behind" page (there is one for
each displayable page on the site), which is pure C# code (not script). As
such, the web site uses compiled code running on the server, not scripts
embedded in the client. This is much more secure and stable than the older
model, but it requires more round trips to the server. Moore's Law is taking
care of this and making the approach feasible.)
By 2005, it was apparent to me that the Net and OO had won the paradigm
battle. There is simply no place in today's world for a non-OO, procedural
based language, apart from some big sequential processing jobs, and
maintaining the legacy built up over forty odd years. The days when every
company had its COBOL shop are numbered; I predicted it would stop by 2015
but it may be much sooner than that. You say you are in touch with 600
companies who are still undertaking development in COBOL (and I believe you)
but I wonder how many of them see a 10 year future for that COBOL
development? They will be forced by market forces (they have to remain
competitive) to move away from COBOL.
So, summing up:
1. It is no longer viable to employ programmers to write code one line at a
time, and make changes to it whenever there is a change in policy or market
model. It simply costs too much (that's why it is being outsourced to the
third world, but even that has a limited lifetime, and is rapidly becoming
more expensive) and is too ponderous to build flexible, responsive systems.
This, more than anything else, spells the end of COBOL. (Objects and reuse,
functional programming, and agile or RAD development simply cream the old
waterfall; they are MUCH cheaper, faster, more powerful, and grow in
strength the longer you use them. They deliver functionality to end users
quickly and in a way that means change is welcomed, rather than resisted. No
contest.)
2. What is my position on COBOL? I have great affection for it. It fed and
clothed me for many years and gave me a lifestyle that has been thoroughly
enjoyable. But it is time to move on. I'd like to see it go with dignity. I
still have a pretty hefty investment in COBOL components so I won't be
throwing my COBOL compiler away any time soon (but I haven't moved it to my
current development platform either; all COBOL stuff is on a separate,
older, notebook...)
3. Why do I frequent a COBOL forum if I believe the language is at the end
of its useful life? Well, CLC is not JUST about COBOL. We discuss wide
ranging topics here and sometimes people need technical help. Apart from
that, I am genuinely interested to see what people who are still using COBOL
are doing with it, and maybe assist them with the inevitable transition they
must make at some point in the future. I realise, that for some, it may be a
few years off, but I have been here for more than a decade now and plan on
being here for some time to come...
I have earned the right to comment :-)
> In the meantime, I will follow your contributions with interest !
Good, then my time here is not wasted :-)
>
> BTW: coming to France for the Rugby World Cup ?
No, I don't think so. Not entirely sure, as my movements after July are not
certain. If I'm back in Europe at the time it is on, I would certainly try
and attend. France are currently touring NZ and were soundly thrashed by the
ABs in the first test last w. Having said that, and also declaring my
bias against things French, I give credit to France who played a very good
game of Rugby and were courageous in defence. There was at least one AB try
which, in my opinion (and I've watch the slo-mo many times) should not have
been awarded. Last night (in Wellington) the All Blacks again inflicted a
record defeat on France (61 - 10). I didn't see it, as I was otherwise
engaged, so I can't comment on what the French performance was like. The
strange thing is that now they are decidedly the underdogs, I'm starting to
feel some sympathy for them :-). It'll pass...:-)
Pete.
| |
| Alistair 2007-06-10, 7:55 am |
| On 9 Jun, 15:26, "Pete Dashwood" <dashw...@removethis.enternet.co.nz>
wrote:
> 2. I wanted to be able to validate an email address string. (Check it has
> only one @ in it, and if a dot occurs in it, it occurs after the @, and that
> the @ is present and has valid characters preceding and succeeding it)
>
Errr....you can have dots before the @ symbol. And be aware that upper
case is valid (and can not be safely translated into lower case)
before the @ symbol.
I hope that I am trying to teach my grannie to suck eggs and that you
wrote your bit as an abbreviated example.
| |
| Pete Dashwood 2007-06-10, 7:55 am |
|
"Alistair" <alistair@ld50macca.demon.co.uk> wrote in message
news:1181470793.874476.34360@p77g2000hsh.googlegroups.com...
> On 9 Jun, 15:26, "Pete Dashwood" <dashw...@removethis.enternet.co.nz>
> wrote:
>
>
> Errr....you can have dots before the @ symbol. And be aware that upper
> case is valid (and can not be safely translated into lower case)
> before the @ symbol.
>
> I hope that I am trying to teach my grannie to suck eggs and that you
> wrote your bit as an abbreviated example.
>
Yes, the code caters for that and you were correct in your assumption
regarding Grannies and eggs... :-)
(Nevertheless, well spotted...:-))
I'd post the code but no-one here is interested. We covered regular
expressions about a year ago and it stimulated no responses.
Although these expressions are mystically cryptic, the power of them is
truly awesome.
Pete.
| |
| James J. Gavan 2007-06-11, 6:55 pm |
| William M. Klein wrote:
> If anyone is "interested" - you might want to check out the J4 "annual report"
> at:
>
> http://www.cobolstandard.info/j4/files/07-0096.htm
>
Have a cry might be more like it. As you know I've just been talkin' to
the Canadian Standards to see what contributions they make to
programming languages :-
"As Chair of the Canadian Advisory Committee on Programming Languages
(CAC-JTC1-SC22), I will try to address your comments.
CAC-JTC1-SC22 advises Standards Council of Canada on matters relating to
Programming Languages and their environments. We currently are active in :-
C, Ada, C++, POSIX, Linux, and Fortran. We have no active members
attending meetings and helping us decide on issues as they relate to COBOL."
Interesting that FORTRAN is included, probably because it also now has
OO. Note neither Java nor C# get a look-in at ISO - the originators keep
a tight rein on their products.
What's the equivalent list for the States Bill ? Folks outside of N.
America, to which languages does your country contribute via ISO
committees ?
Jimmy
| |
| Richard Brady 2007-06-17, 6:55 pm |
| Pete Dashwood wrote:
[snip]
>
> I'd post the code but no-one here is interested.
Not quite true, Mr. Dashwood. At least one is interested.
> We covered regular
> expressions about a year ago and it stimulated no responses.
Stunned, perhaps? Unable to grasp the elegance? I perceive that a
COBOL programmer would try to determine how to accomplish the results in
COBOL (at least I would) and be overwhelmed.
> Although these expressions are mystically cryptic, the power of them is
> truly awesome.
>
> Pete.
>
I thank you for your insights.
Yet another Richard.
| |
| Rick Smith 2007-06-18, 3:55 am |
|
"Richard Brady" <rrllbrrady@worrlldnet.att.net> wrote in message
news:YRedi.95547$Sa4.35278@bgtnsc05-news.ops.worldnet.att.net...
> Pete Dashwood wrote:
> [snip]
>
> Not quite true, Mr. Dashwood. At least one is interested.
You do realize that this is a COBOL newsgroup and the
code is written in C#?
>
> Stunned, perhaps? Unable to grasp the elegance? I perceive that a
> COBOL programmer would try to determine how to accomplish the results in
> COBOL (at least I would) and be overwhelmed.
Given the regular expression:
[A-Za-z0-9._%-]+@[A-Za-z0-9.-]+\.[A-Za-z]{2,4}
this translates to a couple UNSTRING statements to
break the e-mail address into some substrings, some
class tests to validate the content of thsoe substrings, and
a few tests to catch other errors.
This is hardly overwhelming though it does take more than
one line, unless one is using COBOL on a POSIX-conforming
OS, in which case one should be able to call 'regcomp' with
the regular expression.
No C# required!
| |
| Pete Dashwood 2007-06-18, 3:55 am |
|
"Richard Brady" <rrllbrrady@worrlldnet.att.net> wrote in message
news:YRedi.95547$Sa4.35278@bgtnsc05-news.ops.worldnet.att.net...
> Pete Dashwood wrote:
> [snip]
>
> Not quite true, Mr. Dashwood. At least one is interested.
>
>
> Stunned, perhaps? Unable to grasp the elegance? I perceive that a COBOL
> programmer would try to determine how to accomplish the results in COBOL
> (at least I would) and be overwhelmed.
>
> I thank you for your insights.
>
> Yet another Richard.
Thank you for your response, Richard.
I was actually thinking about interfacing to the RegEx COM component used in
VB, so that COBOL could enjoy the same facility, but then I moved to C# and
the whole thing became unnecessary; C# has superb support for RegExs.
Here's the code for email validation that I'm using (It isn't mine and I
take no credit for it, although I have checked it out pretty thoroughly):
public static bool IsValidEmailAddress(string sEmail)
{
if (sEmail == null)
{
return false;
}
int nFirstAT = sEmail.IndexOf('@');
int nLastAT = sEmail.LastIndexOf('@');
if ((nFirstAT > 0) && (nLastAT == nFirstAT) &&
(nFirstAT < (sEmail.Length - 1)))
{
// address is ok regarding the single @ sign
return (Regex.IsMatch(sEmail, @"(\w+)@(\w+)\.(\w+)"));
}
else // I don't believe this is necessary but I left it in, in
deference to the original programmer. Pete.
{
return false; // this could be unconditional; if there is a
match the expression will return TRUE anyway...
}
The method checks for a single @ and then does the clever bit....
This single statement does the magic: return (Regex.IsMatch(sEmail,
@"(\w+)@(\w+)\.(\w+)"));
(The first @ is a C# convention that means you don't need to escape control
sequences in the string that follows; kind of like an absolute string
image...)without it he would have to write: "(\\w+)@(\\w+)\\.(\\w+)"));
Here's an English translation...
Match is TRUE, IF: any alphanumeric character (there must be at least 1)
precedes an "@", which is followed by any alphanumeric character (there must
be at least 1) preceding a period, with at least one alphanumeric character
succeeding the period (and this can include other groups of dots and
characters). The string must contain at least one dot following the @.
Probably appealing to the cryptographers in the forum :-)
Actually, like all shorthands, once you get to know some of the basic
symbols it becomes much clearer. The "\w+" above is itself a shorthand for
[a-zA-Z0-9] with the + denoting "at least one".
COBOLers might like to think on the equivalent logic required using INSPECT,
UNSTRING, or a PERFORM loop.
Here's a spec:
"A string must contain one, and only one "@" symbol. There can be any number
of alphanumeric characters preceding the "@", but there MUST be at least
one. Other characters can be ignored. (There can be dots, for example).
Succeeding the "@" symbol there must be at least one alphanumeric symbol
preceding one or more dots. A dot cannot be the final symbol in the string
and must always be "surrounded" by at least one alphanumeric character on
either side of it."
Pete.
| |
| Pete Dashwood 2007-06-18, 3:55 am |
|
"Rick Smith" <ricksmith@mfi.net> wrote in message
news:137bqa93d3t9kb4@corp.supernews.com...
>
> "Richard Brady" <rrllbrrady@worrlldnet.att.net> wrote in message
> news:YRedi.95547$Sa4.35278@bgtnsc05-news.ops.worldnet.att.net...
>
> You do realize that this is a COBOL newsgroup and the
> code is written in C#?
And you certainly realize, Rick, that a lot more than COBOL gets covered
here... :-)
People who are making the transition from COBOL to "something else" (and
there is an increasing number of them) are certainly interested in other
solutions. That doesn't mean they are not interested in COBOL; solutions are
not necessarily mutually exclusive...(I have a number of C# solutions that
still utilise COBOL, for example...)
>
>
> Given the regular expression:
> [A-Za-z0-9._%-]+@[A-Za-z0-9.-]+\.[A-Za-z]{2,4}
> this translates to a couple UNSTRING statements to
> break the e-mail address into some substrings, some
> class tests to validate the content of thsoe substrings, and
> a few tests to catch other errors.
Pretty trivial, huh?
Perhaps you'd like to post it? :-)
>
> This is hardly overwhelming though it does take more than
> one line, unless one is using COBOL on a POSIX-conforming
> OS, in which case one should be able to call 'regcomp' with
> the regular expression.
So POSIX has RegExs available to COBOL? That's interesting. As mentioned
earlier, I was considering getting the VB regEx engine (which is actually a
COM component) working with Fujitsu COBOL, but moving to C# meant I didn't
have to. In fact, moving to Perl, PHP, Ruby, Java, or just about ANYTHING
would have provided support for RegExs...
>
> No C# required!
No, my point was about RegExs, not about C# (although I really like using C#
:-))
Pete.
| |
| Richard Brady 2007-06-18, 9:56 pm |
| Rick Smith wrote:
> "Richard Brady" <rrllbrrady@worrlldnet.att.net> wrote in message
[snip]
> You do realize that this is a COBOL newsgroup and the
> code is written in C#?
>
Point well taken, Mr. Smith. Still, seeing code in other languages and
trying to determine how to accomplish the same thing in COBOL seems
reasonable in a COBOL newsgroup. I'm not necessarily advocating C# as
the best solution, heck, I rather dislike regular expressions; they are
so obscure. But I am interested.
So I'll try to curb my enthusiasm for non-COBOL.
> Given the regular expression:
> [A-Za-z0-9._%-]+@[A-Za-z0-9.-]+\.[A-Za-z]{2,4}
> this translates to a couple UNSTRING statements to
> break the e-mail address into some substrings, some
> class tests to validate the content of thsoe substrings, and
> a few tests to catch other errors.
The use of regular expressions here does seem more elegant than all the
substrings and tests.
>
> This is hardly overwhelming though it does take more than
> one line, unless one is using COBOL on a POSIX-conforming
> OS, in which case one should be able to call 'regcomp' with
> the regular expression.
Agreed. Perhaps "overwhelming" overstates the reason for no response.
> No C# required!
Well, ok. I should think parsing and testing an email address in
Fortran IV would be possible, too (As in no C# required). But I'm not
sure I'd enjoy the journey.
Thanks for your comments.
Yet another Richard
| |
| Richard Brady 2007-06-18, 9:56 pm |
| Pete Dashwood wrote:
[snip]
>
> I was actually thinking about interfacing to the RegEx COM component used in
> VB, so that COBOL could enjoy the same facility,
Which would only work for COBOL on a platform supporting VB.
> but then I moved to C# and
> the whole thing became unnecessary; C# has superb support for RegExs.
Why doesn't every language have support for RegExs? Nevermind.
> Here's the code for email validation that I'm using (It isn't mine and I
> take no credit for it, although I have checked it out pretty thoroughly):
>
> public static bool IsValidEmailAddress(string sEmail)
> {
> if (sEmail == null)
> {
> return false;
> }
>
> int nFirstAT = sEmail.IndexOf('@');
> int nLastAT = sEmail.LastIndexOf('@');
>
> if ((nFirstAT > 0) && (nLastAT == nFirstAT) &&
> (nFirstAT < (sEmail.Length - 1)))
> {
> // address is ok regarding the single @ sign
> return (Regex.IsMatch(sEmail, @"(\w+)@(\w+)\.(\w+)"));
> }
> else // I don't believe this is necessary but I left it in, in
> deference to the original programmer. Pete.
> {
> return false; // this could be unconditional; if there is a
> match the expression will return TRUE anyway...
> }
>
> The method checks for a single @ and then does the clever bit....
>
> This single statement does the magic: return (Regex.IsMatch(sEmail,
> @"(\w+)@(\w+)\.(\w+)"));
>
> (The first @ is a C# convention that means you don't need to escape control
> sequences in the string that follows; kind of like an absolute string
> image...)without it he would have to write: "(\\w+)@(\\w+)\\.(\\w+)"));
>
> Here's an English translation...
>
> Match is TRUE, IF: any alphanumeric character (there must be at least 1)
> precedes an "@", which is followed by any alphanumeric character (there must
> be at least 1) preceding a period, with at least one alphanumeric character
> succeeding the period (and this can include other groups of dots and
> characters). The string must contain at least one dot following the @.
Quite elegant. Thanks Mr. Dashwood.
> Probably appealing to the cryptographers in the forum :-)
>
> Actually, like all shorthands, once you get to know some of the basic
> symbols it becomes much clearer. The "\w+" above is itself a shorthand for
> [a-zA-Z0-9] with the + denoting "at least one".
>
> COBOLers might like to think on the equivalent logic required using INSPECT,
> UNSTRING, or a PERFORM loop.
And as Mr. Smith notes, a couple of tests. I'm imagining a couple of
ways to approach it in COBOL. Or perhaps, every COBOL implementation
needs to include a regular expression evaluator so we don't reinvent
that wheel repeatedly. It could even be in OOCOBOL.
> Here's a spec:
>
> "A string must contain one, and only one "@" symbol. There can be any number
> of alphanumeric characters preceding the "@", but there MUST be at least
> one. Other characters can be ignored. (There can be dots, for example).
> Succeeding the "@" symbol there must be at least one alphanumeric symbol
> preceding one or more dots. A dot cannot be the final symbol in the string
> and must always be "surrounded" by at least one alphanumeric character on
> either side of it."
>
> Pete.
Thank you, good sir. While I dislike Regular Expressions for their
obscurity, they are an elegant solution to many problems. But I would
find even COBOL code to solve this to be obscure. Few languages have
the parsing capability which seems to be provided by the RegEx
evaluator. Maybe Rexx, LISP, Python and suchlike. But my guess is that
the code would still be rather obscure.
Yet another Richard
| |
| Howard Brazee 2007-06-18, 9:56 pm |
| On Mon, 18 Jun 2007 14:42:49 GMT, Richard Brady
<rrllbrrady@worrlldnet.att.net> wrote:
>And as Mr. Smith notes, a couple of tests. I'm imagining a couple of
>ways to approach it in COBOL. Or perhaps, every COBOL implementation
>needs to include a regular expression evaluator so we don't reinvent
>that wheel repeatedly. It could even be in OOCOBOL.
I suppose any library based language could include anything we want.
Of course, learning libraries is a much vaster task than learning a
more tightly designed language.
| |
|
| Richard Brady wrote:
> Pete Dashwood wrote:
> [snip]
>
> Why doesn't every language have support for RegExs? Nevermind.
I don't know about the PC, but on the Unisys mainframe, it wouldn't be
too difficult to write a RegEx interface to a language that supported
it. (I'm guessing the C would have that library, or could be made to do
so.) Then, you could access it with regular COBOL.
01 regex-status pic 9(01).
88 regex-false value 0.
88 regex-true value 1.
01 regex-string pic X(1000).
01 regex-length pic 9(4).
01 regex-pattern pic X(100).
....
move [input e-mail] to regex-string
move [length of input e-mail] to regex-length
move [pattern match] to regex-pattern
call "RegExMatch"
using regex-string regex-length regex-pattern
regex-status
end-call
if regex-true
perform [whatever requires a valid e-mail address]
else
perform [invalid e-mail handling]
end-if.
It's still a few more lines, but would allow the flexibility of using
the libraries you normally couldn't access.
(You could avoid the length parameter if you trim all trailing spaces -
but, if you wanted to include some or all of them in the source string,
you'd be out of luck.)
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~~~~~
~ / \/ _ o ~ Live from Albuquerque, NM! ~
~ _ /\ | ~ ~
~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
~ Business E-mail ~ daniel @ "Business Website" below ~
~ Business Website ~ http://www.djs-consulting.com ~
~ Tech Blog ~ http://www.djs-consulting.com/linux/blog ~
~ Personal E-mail ~ "Personal Blog" as e-mail address ~
~ Personal Blog ~ http://daniel.summershome.org ~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~~~~~
GEEKCODE 3.12 GCS/IT d s-:+ a C++ L++ E--- W++ N++ o? K- w$ !O M--
V PS+ PE++ Y? !PGP t+ 5? X+ R* tv b+ DI++ D+ G- e h---- r+++ z++++
"Who is more irrational? A man who believes in a God he doesn't see,
or a man who's offended by a God he doesn't believe in?" - Brad Stine
| |
| Charles Hottel 2007-06-19, 7:55 am |
|
"Richard Brady" <rrllbrrady@worrlldnet.att.net> wrote in message
news:2swdi.97935$Sa4.6794@bgtnsc05-news.ops.worldnet.att.net...
> Rick Smith wrote:
>
> [snip]
>
> Point well taken, Mr. Smith. Still, seeing code in other languages and
> trying to determine how to accomplish the same thing in COBOL seems
> reasonable in a COBOL newsgroup. I'm not necessarily advocating C# as the
> best solution, heck, I rather dislike regular expressions; they are so
> obscure. But I am interested.
>
> So I'll try to curb my enthusiasm for non-COBOL.
>
> The use of regular expressions here does seem more elegant than all the
> substrings and tests.
>
> Agreed. Perhaps "overwhelming" overstates the reason for no response.
>
>
> Well, ok. I should think parsing and testing an email address in Fortran
> IV would be possible, too (As in no C# required). But I'm not sure I'd
> enjoy the journey.
>
> Thanks for your comments.
>
> Yet another Richard
Try RATFOR it makes FORTRAN into a C style language.
| |
| Pete Dashwood 2007-06-19, 7:55 am |
|
"Richard Brady" <rrllbrrady@worrlldnet.att.net> wrote in message
news:JRwdi.97991$Sa4.97336@bgtnsc05-news.ops.worldnet.att.net...
> Pete Dashwood wrote:
> [snip]
>
>
> Which would only work for COBOL on a platform supporting VB.
That would be any Windows platform :-)
As that is the market I develop for, it makes sense for me. I accept that it
wouldn't cover all bases.
I should add that, C#, because it is DotNET oriented, suffers no such
limitation. It will run on Unix, Linux, or any flavour of Windows. (I think
it is just a matter of time before interfaces from mainframe to DotNET/Mono
are available, but I don't know that to be so.)
>
>
> Why doesn't every language have support for RegExs? Nevermind.
>
>
> Quite elegant. Thanks Mr. Dashwood.
>
>
> And as Mr. Smith notes, a couple of tests. I'm imagining a couple of ways
> to approach it in COBOL. Or perhaps, every COBOL implementation needs to
> include a regular expression evaluator so we don't reinvent that wheel
> repeatedly. It could even be in OOCOBOL.
Imagine if we had had a responsive and efficient COBOL standards committee,
say, 15 years ago... RegExs could have been on the agenda for standard
COBOL. It might have helped...
(To be fair, it isn't the lack of facilities in COBOL that has doomed it;
rather the complete paradigm shift from procedural to OO. Even though COBOL
has OO facilities, they are not widely implemented or required by most
users. This is what has finished it. Even with outsourcing to the third
world, line by line program development is just too unwieldy and too
expensive. The re-use of code (components) and the object paradigm has
proven itself to be many times superior in responsiveness to change,
rapidity of development, less requirement for maintenance, and suitability
to the network.)
>
>
> Thank you, good sir.
:-) I have never liked being called "sir"... I held a temporary commission
in the NZ army during National Service :-) I think our NCOs had it right:
"Don't call me "Sir", there's no birdshit on my shoulder...".
There is some debate about my being "good" too... :-), but thanks for the
politeness. In a world where there is less and less of it, it is refreshing.
>While I dislike Regular Expressions for their obscurity, they are an
>elegant solution to many problems. But I would find even COBOL code to
>solve this to be obscure. Few languages have the parsing capability which
>seems to be provided by the RegEx evaluator. Maybe Rexx, LISP, Python and
>suchlike. But my guess is that the code would still be rather obscure.
>
Obscurity of code is one of the most compelling reasons I can think of for
encapsulation of functions. If a "black box" just works then HOW it does so
isn't really of such importance. Before we are besieged with mail asking
"What about when it fails?", I would point out the qualifier at the start of
the previous sentence. Obviously, components have to be thoroughly tested,
but they do what they are specced to do. Nothing more; nothing less. For
people used to maintaining source code, this is a very difficult concept to
get across... I've tried here on several occasions and usually failed... :-)
Again, it is the difference in paradigms that makes it difficult...
> Yet another Richard
We have had some quite illustrious (and even infamous :-)) bearers of that
name in this forum over the years :-)
Pete.
| |
| Roger While 2007-06-19, 7:55 am |
| Be aware of the limitations of regex.
I'll let you into a little secret.
We used to use regex in OC for the runtime component
of UNSTRING.
UNTIL we came across -
UNSTRING ... DELIMITED BY LOW-VALUE ...
:-)
Regex doesn't work too well with a null byte delimiter :-)
All usage of regex in the OC runtime has been removed :-)
Roger
"Pete Dashwood" <dashwood@removethis.enternet.co.nz> schrieb im Newsbeitrag
news:5donl1F35m8d8U1@mid.individual.net...
>
> "Richard Brady" <rrllbrrady@worrlldnet.att.net> wrote in message
> news:JRwdi.97991$Sa4.97336@bgtnsc05-news.ops.worldnet.att.net...
>
> That would be any Windows platform :-)
>
> As that is the market I develop for, it makes sense for me. I accept that
> it wouldn't cover all bases.
>
> I should add that, C#, because it is DotNET oriented, suffers no such
> limitation. It will run on Unix, Linux, or any flavour of Windows. (I
> think it is just a matter of time before interfaces from mainframe to
> DotNET/Mono are available, but I don't know that to be so.)
>
>
> Imagine if we had had a responsive and efficient COBOL standards
> committee, say, 15 years ago... RegExs could have been on the agenda for
> standard COBOL. It might have helped...
>
> (To be fair, it isn't the lack of facilities in COBOL that has doomed it;
> rather the complete paradigm shift from procedural to OO. Even though
> COBOL has OO facilities, they are not widely implemented or required by
> most users. This is what has finished it. Even with outsourcing to the
> third world, line by line program development is just too unwieldy and too
> expensive. The re-use of code (components) and the object paradigm has
> proven itself to be many times superior in responsiveness to change,
> rapidity of development, less requirement for maintenance, and
> suitability to the network.)
>
>
> :-) I have never liked being called "sir"... I held a temporary commission
> in the NZ army during National Service :-) I think our NCOs had it right:
> "Don't call me "Sir", there's no birdshit on my shoulder...".
>
> There is some debate about my being "good" too... :-), but thanks for the
> politeness. In a world where there is less and less of it, it is
> refreshing.
>
>
> Obscurity of code is one of the most compelling reasons I can think of for
> encapsulation of functions. If a "black box" just works then HOW it does
> so isn't really of such importance. Before we are besieged with mail
> asking "What about when it fails?", I would point out the qualifier at the
> start of the previous sentence. Obviously, components have to be
> thoroughly tested, but they do what they are specced to do. Nothing more;
> nothing less. For people used to maintaining source code, this is a very
> difficult concept to get across... I've tried here on several occasions
> and usually failed... :-) Again, it is the difference in paradigms that
> makes it difficult...
>
>
> We have had some quite illustrious (and even infamous :-)) bearers of that
> name in this forum over the years :-)
>
> Pete.
>
| |
| Pete Dashwood 2007-06-19, 7:55 am |
|
"Roger While" <simrw@sim-basis.de> wrote in message
news:f5802v$8co$00$1@news.t-online.com...
> Be aware of the limitations of regex.
I believe I am so aware :-)
> I'll let you into a little secret.
> We used to use regex in OC for the runtime component
> of UNSTRING.
> UNTIL we came across -
> UNSTRING ... DELIMITED BY LOW-VALUE ...
> :-)
>
> Regex doesn't work too well with a null byte delimiter :-)
I think one of us is missing something here. RegEx works fine with null
delimited, or even null embedded strings, PROVIDED you cater for nulls in
the RegEx expression. (You may need to include an escape...\0x00 if
embedded, or $ if terminated by null. $ actually represents the "null string
at the end of the string"; if you want just the end of the string itself,
specify \z). Some implementations of RegEx allow you to specify control
parameters to the RegEx engine, and one of these parameters is whether or
not strings for matching are to be null terminated. However, my experience
is with the MS RegEx engine (which some consider to be a perversion :-))
and the engine you were using may have been more limited...:-)
>
> All usage of regex in the OC runtime has been removed :-)
That's a pity. It is very powerful.
Well, I guess you folks have your reasons.
Personally, I think that reflects more of a lack of understanding RegEx (or
maybe using a limited engine) than it does on Regular Expressions in
general.
Pete.
| |
| Rick Smith 2007-06-19, 9:55 pm |
|
"Pete Dashwood" <dashwood@removethis.enternet.co.nz> wrote in message
news:5dpuatF34gd3gU1@mid.individual.net...
>
> "Roger While" <simrw@sim-basis.de> wrote in message
> news:f5802v$8co$00$1@news.t-online.com...
>
> I believe I am so aware :-)
>
>
> I think one of us is missing something here.
Yes, Mr Dashwood, you are! <g>
"regex" is the name of the header file used to include
the API (?) for a particular form of regular expressions
into C programs.
"RegEx" is, apparently, the function (or method) name
for processing a particular form of regular expressions
in C#.
"regex" is not the same as "RegEx".
You may be able to keep this clear in your mind if you
remember to prefix your knowledge with MVO
(Microsoft's Version Of); thus, rephrasing your following
statement, "[(MVO) regular expressions] works fine with
null delimited, ..."
> RegEx works fine with null
> delimited, or even null embedded strings, PROVIDED you cater for nulls in
> the RegEx expression. (You may need to include an escape...\0x00 if
> embedded, or $ if terminated by null. $ actually represents the "null
string
> at the end of the string"; if you want just the end of the string itself,
> specify \z). Some implementations of RegEx allow you to specify control
> parameters to the RegEx engine, and one of these parameters is whether or
> not strings for matching are to be null terminated. However, my experience
> is with the MS RegEx engine (which some consider to be a perversion :-))
> and the engine you were using may have been more limited...:-)
>
>
>
> That's a pity. It is very powerful.
>
> Well, I guess you folks have your reasons.
>
> Personally, I think that reflects more of a lack of understanding RegEx
(or
> maybe using a limited engine) than it does on Regular Expressions in
> general.
With all due respect Mr Dashwood, here you compare
a function name with a concept and do so poorly.
"RegEx" does not apply outside the language (C#) that
defines it; while "Regular Expressions in general" applies
.... well, generally, ... everywhere.
Consider this COBOL statement:
inspect mystring tallying zero-count for leading zeros
"leading zeros" is a regular expression, in general, as is
"delimited by low-value" in the earlier UNSTRING
statement.
Historically, regular expressions occurred as part of
compiler theory and, as such, have widely varying
representations depending on their use. Mr Dashwood,
you seem to have taken a narrow view of regular
expressions and restricted that view further by relying
on a particular implementation (Microsoft's Version Of)
regular expressions. Please open your mind! <g>
| |
| Pete Dashwood 2007-06-19, 9:55 pm |
|
"Rick Smith" <ricksmith@mfi.net> wrote in message
news:137g387h00alt56@corp.supernews.com...
>
> "Pete Dashwood" <dashwood@removethis.enternet.co.nz> wrote in message
> news:5dpuatF34gd3gU1@mid.individual.net...
>
> Yes, Mr Dashwood, you are! <g>
>
> "regex" is the name of the header file used to include
> the API (?) for a particular form of regular expressions
> into C programs.
>
> "RegEx" is, apparently, the function (or method) name
> for processing a particular form of regular expressions
> in C#.
>
> "regex" is not the same as "RegEx".
OK, point taken. But I was pretty clear about the fact that I was talking
about the MicroSoft implementation.
>
> You may be able to keep this clear in your mind if you
> remember to prefix your knowledge with MVO
> (Microsoft's Version Of); thus, rephrasing your following
> statement, "[(MVO) regular expressions] works fine with
> null delimited, ..."
I qualified that below the statement, rather than at the start, with the
phrase: "...However, my experience is with the MS RegEx engine (which some
consider to be a perversion :-)) and the engine you were using may have
been more limited...:-)"
Does any part of that NOT limit my discussion to MS?
I think you are letting your anti-MicroSoft bias cloud your judgement. You
certainly must have read the sentence, yet chose to ignore it and post a
diatribe about me confusing a function with a generic term (a very fine
point at best, given the context; it doesn't matter whether we are talking
functions or generically, as I had qualified my discussion to the MicroSoft
implementation and acknowledged that there are many other implementations of
Regular Expressions), and your statement "> "RegEx" is, apparently, the
function (or method) name
> for processing a particular form of regular expressions
> in C#." ...is only partially correct anyway. (It is also the function name
> used in VB).
>
> string
> (or
>
> With all due respect Mr Dashwood, here you compare
> a function name with a concept and do so poorly.
I don't think it matters. If I wanted to discuss the concept, I would have
done so. A quick search around the Web reveals a good number of
implementations of the concept. (Nearly every university has their own one,
and numerous software packages implement their own interpretation also. The
similarities far outweigh the differences.). That isn't the issue, and I
made it clear in the post you are referring to, and even in other posts
before that, that my experience of this concept is limited entirely to the
MS implementation.
Up front, and honest. (It is the truth :-))
Unlike some people (and I'm not just meaning "you") I don't see red when
MicroSoft is mentioned. (But I don't use their products without evaluating
them either, and I don't have shares in the company or any other vested
interest in promoting their products.) I use what works.
>
> "RegEx" does not apply outside the language (C#) that
> defines it; while "Regular Expressions in general" applies
> ... well, generally, ... everywhere.
>
I actually understood that before you laboured the point on it, Rick :-)
> Consider this COBOL statement:
>
> inspect mystring tallying zero-count for leading zeros
>
> "leading zeros" is a regular expression, in general, as is
> "delimited by low-value" in the earlier UNSTRING
> statement.
Sure. So? What bearing does it have on the use of nulls with regular
expressions in the MS implementation?
>
> Historically, regular expressions occurred as part of
> compiler theory and, as such, have widely varying
> representations depending on their use. Mr Dashwood,
> you seem to have taken a narrow view of regular
> expressions and restricted that view further by relying
> on a particular implementation (Microsoft's Version Of)
> regular expressions. Please open your mind! <g>
>
I don't think my mind is ever closed, on anything, but I do have opinions
about things. I review those opinions in the light of experience and update
them regularly.
Perhaps you could look to your own house, before declaring that mine needs
cleaning :-)
Pete.
| |
| William M. Klein 2007-06-19, 9:55 pm |
| "Pete Dashwood" <dashwood@removethis.enternet.co.nz> wrote in message
news:5dr8c2F367vg3U1@mid.individual.net...
<snip>
> Perhaps you could look to your own house, before declaring that mine needs
> cleaning :-)
>
> Pete.
>
JOKE:
What "clean your house"? I thought you used components and when part of your
house needed "cleaning" you just replaced it with another component (never doing
maintenance on existing parts).
--
Bill Klein
wmklein <at> ix.netcom.com
| |
| Rick Smith 2007-06-20, 3:55 am |
|
"Pete Dashwood" <dashwood@removethis.enternet.co.nz> wrote in message
news:5dr8c2F367vg3U1@mid.individual.net...
>
> "Rick Smith" <ricksmith@mfi.net> wrote in message
> news:137g387h00alt56@corp.supernews.com...
After further investigation, I found that "RegEx" (spelled
Regex in a C# function a couple days ago) is a class, or
whatever is is called in C#, and not a function name as I
stated above.
[color=darkred]
This assertion remains unchanged, however.
[color=darkred]
> OK, point taken. But I was pretty clear about the fact that I was talking
> about the MicroSoft implementation.
>
> I qualified that below the statement, rather than at the start, with the
> phrase: "...However, my experience is with the MS RegEx engine (which some
> consider to be a perversion :-)) and the engine you were using may have
> been more limited...:-)"
>
> Does any part of that NOT limit my discussion to MS?
Regardless of your expeience, to follow Mr While's
"Regex doesn't work ..." with your "RegEx works fine ..."
is a non sequitur that arises from "one of us is missing
something here." That is what I attempted to address.
> I think you are letting your anti-MicroSoft bias cloud your judgement. You
> certainly must have read the sentence, yet chose to ignore it and post a
> diatribe about me confusing a function with a generic term (a very fine
> point at best, given the context; it doesn't matter whether we are talking
> functions or generically, as I had qualified my discussion to the
MicroSoft
> implementation and acknowledged that there are many other implementations
of
> Regular Expressions), and your statement "> "RegEx" is, apparently, the
> function (or method) name
name[color=darkred]
>
in[color=darkred]
itself,[color=darkred]
or[color=darkred]
Rather than "function name", I should have used
"implementation".
[color=darkred]
> I don't think it matters. If I wanted to discuss the concept, I would have
> done so. A quick search around the Web reveals a good number of
> implementations of the concept. (Nearly every university has their own
one,
> and numerous software packages implement their own interpretation also.
The
> similarities far outweigh the differences.). That isn't the issue, and I
> made it clear in the post you are referring to, and even in other posts
> before that, that my experience of this concept is limited entirely to the
> MS implementation.
In "Regular Expressions in general", I took "in general"
to be somewhat broader than, say, the absence of any
qualifier or the qualifier "commonly" might have suggested.
If I recall correctly, and I could be mistaken, you claimed
to have done some work with compilers and my references
suggest that regular expressions have been used, regularly
and for some time, in compiler theory and development.
If that was the case, then you might have been exposed to
regular expressions long ago. Thus I had some reason to
believe that your experience with the concept "in general"
was not as limited as you state, above.
> Up front, and honest. (It is the truth :-))
>
> Unlike some people (and I'm not just meaning "you") I don't see red when
> MicroSoft is mentioned. (But I don't use their products without evaluating
> them either, and I don't have shares in the company or any other vested
> interest in promoting their products.) I use what works.
>
>
> I actually understood that before you laboured the point on it, Rick :-)
>
>
> Sure. So? What bearing does it have on the use of nulls with regular
> expressions in the MS implementation?
Nothing, but does follow from your earlier use of "in general".
>
> I don't think my mind is ever closed, on anything, but I do have opinions
> about things. I review those opinions in the light of experience and
update
> them regularly.
>
> Perhaps you could look to your own house, before declaring that mine needs
> cleaning :-)
Perhaps, I should take a view of "in general" that is not
so ... general? <g>
| |
| Pete Dashwood 2007-06-20, 3:55 am |
|
"William M. Klein" <wmklein@nospam.netcom.com> wrote in message
news:J8_di.257396$YG5.136395@fe07.news.easynews.com...
> "Pete Dashwood" <dashwood@removethis.enternet.co.nz> wrote in message
> news:5dr8c2F367vg3U1@mid.individual.net...
> <snip>
>
> JOKE:
>
> What "clean your house"? I thought you used components and when part of
> your house needed "cleaning" you just replaced it with another component
> (never doing maintenance on existing parts).
>
No, I have a cleaning Class... It is comprised of a number of extremely
valuable components; a housekeeper who has looked after my place for more
than 20 years (and whom I would not to wish to maintain or change in any way
:-) She does what is specced and the specs haven't changed... (anyway, she
wrote them... I wonder if that is intelligent software design... a component
that evaluates what needs doing and does it... Hmmmm....), and a turbo
charged cyclonic bagless vacuum cleaner that not only makes me laugh every
time she uses it, but also filters allergens and such as it works. (Not to
mention the "infrastructure" components that are kept in the laundry... and
simply replaced when used up. )
Of course, I COULD save money and do it all myself. At regular intervals, I
COULD get the besom out and destroy the Axminster, and beat the rugs with a
wicker beater, and take the laundry down to the local river for beating on
the rocks...in fact, I COULD integrate all of that with solving problems and
writing code, and HOPE that none of these activities would suffer from the
induced fatigue and lessened leisure time. (I suspect that the "regular
intervals" would become somewhat irregular, and nowhere near frequent
enough...)
Instead, I choose a more modern paradigm which has a number of beneficial
(and not immediately obvious) side effects... Like being able to go away for
a couple of years and come home to a spotless house with essentials in the
fridge and clean linen on the beds...(Not to mention the smile a regular
income puts on my housekeeper's face).
Taking your analogy... why would I keep on doing something over and over,
when I can create a component (once) that does it for me?
Pete.
| |
| Pete Dashwood 2007-06-20, 9:55 pm |
|
"Rick Smith" <ricksmith@mfi.net> wrote in message
news:137h6ukjstdb84d@corp.supernews.com...
>
> "Pete Dashwood" <dashwood@removethis.enternet.co.nz> wrote in message
> news:5dr8c2F367vg3U1@mid.individual.net...
>
> After further investigation, I found that "RegEx" (spelled
> Regex in a C# function a couple days ago) is a class, or
> whatever is is called in C#, and not a function name as I
> stated above.
It is indeed a Class (one of several concerned with Regular Expressions) in
the System.Text.RegularExpression namespace of the DotNET Framework Class
Library (FCL) but, not being of a pedantic nature, and realising what you
meant, I allowed your loose use of "function" as being near enough, didn't
correct you on it, and even used it myself for the sake of our
conversation....(I sometimes wish that people here would cut me the same
slack I cut them :-)). It doesn't matter, when what we were actually
discussing is the use of Regular Expressions with null terminated strings.
>
>
> This assertion remains unchanged, however.
>
>
> Regardless of your expeience, to follow Mr While's
> "Regex doesn't work ..." with your "RegEx works fine ..."
> is a non sequitur that arises from "one of us is missing
> something here." That is what I attempted to address.
No, I disagree. It is incorrect to state, without any qualification, that
Regex doesn't work with null terminated strings. I refuted it with a
specific example which DOES work with null-terminated strings. I then gave
examples of how you could get it to work with nulls in general. There is no
non-sequitur in that.
>
> MicroSoft
> of
> name
> in
> itself,
> or
>
> Rather than "function name", I should have used
> "implementation".
Well, don't beat yourself up. I understood what you meant :-).
>
> one,
> The
>
> In "Regular Expressions in general", I took "in general"
> to be somewhat broader than, say, the absence of any
> qualifier or the qualifier "commonly" might have suggested.
>
> If I recall correctly, and I could be mistaken, you claimed
> to have done some work with compilers and my references
> suggest that regular expressions have been used, regularly
> and for some time, in compiler theory and development.
Yes, I did work on a specific compiler (for COBOL) in the 1960s. (My work
consisted of disassembling it and patching it to do various things it wasn't
written to do. As it was in 17 passes, this was a fairly non-trivial task
and I wouldn't have even attempted to do it if my Boss hadn't inspired me by
writing an Operating System, then encouraging me to have a go at the
compiler...:-))
(I have been fortunate to have worked with some very clever people during my
reckless career...) Anyway, at that time I was not aware of compiler theory
or Regular Expressions (and I doubt if anyone else was either :-))... there
was no such thing as Computer Science (at least, not in NZ) and "best
practices" were still being established. You couldn't just walk to a
bookshelf and take down a tome on compiler writing. I had never encountered
state changes and transition diagramming until I did this task, and was
amazed at the elegance of the syntax scan in pass 1 which used these
techniques.
> If that was the case, then you might have been exposed to
> regular expressions long ago. Thus I had some reason to
> believe that your experience with the concept "in general"
> was not as limited as you state, above.
I first encountered Regular Expressions two years ago, when modifying the
Rational Toolset provided by IBM, in VB. The work I am currently doing in C#
for my AVS Web Site needed to do some complex searching and matching (the
validation of email addresses is just one requirement I have) so I read up
on them using an O'Reilly reference on C# ("C# in a Nutshell"), overviewed
some Web Pages (mostly from Acadaemia), and browsed some samples from a
MicroSoft forum. That's why I was careful to state that my understanding
applies to the MS interpretation. That is the total extent of my experience
with "Regular Expressions" in general, or specifically. I am satisfied that
they are a very powerful device for matching and processing strings. I am
also satisfied that the C# implementation (which is really DotNET FCL) is a
very comprehensive one and if it extends the standard, I really don't care
about that. It gives me a very powerful tool which I have already used to
good effect, and will certainly use in the future.
I really see no point in arguing this further, so I won't :-)
I appreciate you backing your statements with COBOL code, and I think that
code is worthy of exploration, and will be of use to many people here,
irrespective of our argument about Regular Expressions.
However, I am no way persuaded that there is equivalent power in 190 lines
of COBOL, to that contained in one single expression, using a Regular
Expression, whether you write it in C#, Java, C++, PHP, Perl, or anything
else that supports Regular Expressions.
Pete.
>
>
>
| |
| Howard Brazee 2007-06-20, 9:55 pm |
| On Tue, 19 Jun 2007 12:51:44 +1200, "Pete Dashwood"
<dashwood@removethis.enternet.co.nz> wrote:
>(To be fair, it isn't the lack of facilities in COBOL that has doomed it;
>rather the complete paradigm shift from procedural to OO. Even though COBOL
>has OO facilities, they are not widely implemented or required by most
>users. This is what has finished it.
Absolutely. No amount of committees, improvements, and upgrades
would have changed this.
| |
| Howard Brazee 2007-06-20, 9:55 pm |
| I had to look up regex when I saw it in this thread. I mainly use
regular expressions in editors that support them, often with macros.
I've never thought of them as being obvious enough for use in "real"
programming.
| |
| Rick Smith 2007-06-20, 9:55 pm |
|
"Pete Dashwood" <dashwood@removethis.enternet.co.nz> wrote in message
news:5dsnsfF34noa5U1@mid.individual.net...
>
> "Rick Smith" <ricksmith@mfi.net> wrote in message
> news:137h6ukjstdb84d@corp.supernews.com...
>
> It is indeed a Class (one of several concerned with Regular Expressions)
in
> the System.Text.RegularExpression namespace of the DotNET Framework Class
> Library (FCL) but, not being of a pedantic nature, and realising what you
> meant, I allowed your loose use of "function" as being near enough, didn't
> correct you on it, and even used it myself for the sake of our
> conversation....(I sometimes wish that people here would cut me the same
> slack I cut them :-)). It doesn't matter, when what we were actually
> discussing is the use of Regular Expressions with null terminated strings.
talking[color=darkred]
the[color=darkred]
have[color=darkred]
>
> No, I disagree. It is incorrect to state, without any qualification, that
> Regex doesn't work with null terminated strings. I refuted it with a
> specific example which DOES work with null-terminated strings. I then gave
> examples of how you could get it to work with nulls in general. There is
no
> non-sequitur in that.
The problem was not null terminated strings. The problem
was embedded null characters ("null byte delimiter"). You
recognized this earlier (later in this post) when you wrote
"RegEx works fine with null delimited, or even null
embedded strings ...". The qualification was implicit; that is,
it is public knowledge that Open Cobol is written in C
(the source code is available for download) and that regex
was used in Open Cobol, but is no longer in use; therefore,
the statement concerning regex was limited to the C language.
What you claim to be a refutation was what may be done
with C#.
I does not follow that a problem doing something in C
may be overcome by using techniques available in C#
and not available in C.
[snip][color=darkred]
nulls[color=darkred]
"null[color=darkred]
whether[ | | |