Re: Cobol for Visual sutdio



"Michael Wojcik" <mwojcik@xxxxxxxxxxx> wrote in message
news:ge9tvl22feu@xxxxxxxxxxxxxxxxxxxx
Pete Dashwood wrote:

It is a problem with the COBOL language so neither of them can implement
it
(even if they wanted to...) Things like reflection

Reflection works just fine. Why wouldn't it?

Yes, I was wrong about that. I realised after I wrote it, reflection is a
function of the FCL not the language.

I made this error because I use it with C# and find it very useful, so I
came to associate it with the language, rather than the Framework.

I see no point in debating the languages. I like C# it serves my needs
better than COBOL did, that's enough for me.


and LINQ

Not implemented in our .NET COBOL, true, but there's no reason why it
would be particularly more difficult than, say, EXEC SQL, which we
have and does work. ADO.NET works, and LINQ is just syntactic sugar
for ADO.NET.

No, it isn't. You may dismiss it as such but I am finding (and I'm still
exploring it) that the possibilities with LINQ are phenomenal. There is no
comparison either, between having something integrated directly to the
language where it can be typed and delegated, and having to access it via an
API. Embedded SQL is simply primitive by comparison.

Personally, I'm not particularly impressed with LINQ. It's cute, but
it doesn't add much to the expressiveness of the language.

I strongly disagree, but I agree it is a matter of opinion and yours is
every bit as valuable as mine :-).


It's
certainly not innovative (in the .NET space) the way WCF is, or the
way F# is, or the way IronRuby is.

I haven't used F# or Ruby and I am still looking at WCF as a replacement for
COM+. I therefore am not qualified to comment.

are two very
important ones that come to mind immediately. There are others.

OK, name some.

I see no real point in doing this, but <sigh> OK.... I have all of the
following at my fingertips when I use C#, and I pay nothing for the
privelege. Neither do I have to pay licence fees to deploy them. Some of
them I could "simulate" in COBOL but it is unwieldy and verbose.

Proper support for Object Oriented programming (COBOL support is good, but
it was never inherent in the language as it is in C# and Java. Inheritance,
encapsulation, polymorphism, and interface based programming are implemented
more easily and better in C# than in COBOL), Lambda functions, delegation,
covariance, contravariance, automatic documentation generation in XML,
ClickOnce deployment (maybe available to .NET COBOL through VS), custom
attributes, better array handling, user defined conversions, user defined
typing, enumerations, better collections, better iterations (foreach),
operator overloading... and I'm going to add LINQ back to the list as well,
because I really rate it :-)

I want to deal with objects, and I want to do it in the .NET framework. (I
have covered elsewhere WHY I think layers and objects are important...)

How could COBOL (for me...) be a better choice than C#? (let's not forget
that the Framework itself is written in C#...)

Michael, I wasn't looking for a pointless argument and I have responded only
because you (quite fairly) asked me to.

We all have our preferences regarding languages. Mine are based on what I'm
trying to achieve. Layers and objects.

I haven't used MicroFocus' implementation of COBOL for .NET, but, given that
the MicroFocus products I HAVE used in the past were excellent, I have no
reason to believe that it is NOT a good product.

My objections to the MicroFocus implementation are that it is expensive
(both to buy and to deploy), I can get the same functionality (plus more)
for free from MicroSoft (and even if I fork out for the Full Monty MS
products, I still pay less than a third of what I would pay for your .NET
COBOL compiler, and notice that, while you have asked me to note things I
can do in C# that I can't do in COBOL, there has been no suggestion of you
showing me things I can do in .NET COBOL that I CAN'T do in C#... :-)).

Whether we like it or not, COBOL as a language is in its twilight anyway.
The World has voted with its feet.

I spent decades making a living with COBOL, have much affection for the
language, but I realise its time is over.

The people I deal with are telling me they want out of COBOL. Small
businesses need a migration path that will not cost them an arm and a leg.

Given those criteria, free products from MicroSoft are a very attractive
alternative.

Pete.
--
"I used to write COBOL...now I can do anything.


.

Relevant Pages

  • Re: Java compatibility issues (WAS: MF having issues?)
    ... language it can do most of what C, C++, and Java can do. ... 2002 COBOL standard addresses that, but having a standard is a far ... Some flavours do have libraries. ... On the IBM mainframe we have Language Environment but it does ...
    (comp.lang.cobol)
  • Re: GoTo in Java
    ... were a year or two down the track and everybody was very happy with OCaml. ... > language switch would pay off in faster development (due in part to ... COBOL as a scripting language for .NET. ... Compare this with COBOL programmers discussing Java... ...
    (comp.lang.cobol)
  • Re: COBOLs Influence on C
    ... Cobol is the only language that has this problem. ... sure that the libraries containing ANYTHING that might be called are on ... And that is one reason why installations have Local Standards... ...
    (comp.lang.cobol)
  • Re: Java is becoming the new Cobol
    ... """If you're a Java developer, now's the time to invest in new ... It is even truer for COBOL developers. ... The question then is: Is Java just another fad language in the range: ... Sometimes it appears they'll use whatever the Fad Language Of The Month Club sent last ...
    (comp.lang.cobol)
  • Re: Wang COBOL alive and well as Wang VS makes a comeback
    ... I fought to the last to keep COBOL at least peripherally in the ... will be the next language du jour... ... This contributes to the stability of programming efforts ... level of COBOL to another can be as big a deal as migrating across platforms ...
    (comp.lang.cobol)