Re: Devilish Debugging

On Tue, 26 Jun 2012 12:57:11 -0400, "Charles Hottel"
<chottel@xxxxxxxxxxxxx> wrote:


"SkippyPB" <swiegand@xxxxxxxxxxxxxxxxx> wrote in message
news:7ohju7pa081n2d87fj4rm53p896bu74ao6@xxxxxxxxxx
On Tue, 26 Jun 2012 12:32:55 +1200, "Pete Dashwood"
<dashwood@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote:

SkippyPB wrote:
On Mon, 25 Jun 2012 15:14:39 +1200, "Pete Dashwood"
<dashwood@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote:

Charles Hottel wrote:
<snip>>
Speaking of tools, I know that you know both Java and C# and that
you learned Java first. I am curious to know what made you pick C#
over Java for building your toolset and for general programming. My
reason for asking is that I am considering learning C#.

Both Java and C# are powerful and useful OO languages. (I still
think COBOL is the best of all the non-OO (procedural) languages.)

I've never really thought about this until you asked, Charlie, but
here are some things which were contributing factors:

1. At the time the Fujitsu (Alchemy) CIL generating compiler
(NetCOBOL for .Net) was released I already knew Java, having learned
it to assist me understanding OO COBOL. I had also been writing OO
COBOL for some years and was very keen to move this experience into
.Net. So, I was pretty excited about the new compiler offering.
Unfortunately when I tried to buy it I was treated with rudeness and
arrogance. It was like: "We are the only game in town so you can
have this if we are pleased to offer it to you..." although, not in
those words of course. As I didn't see that paying several thousand
dollars and begging to be allowed to purchase their software was a
viable option, I looked for alternatives. I could simply move to
Java but my client base is Microsoft and it would be a bit clumsy
(though quite feasible) writing Java applications for .Net.

Then I realised that C# had recently become available and after
watching the channel 9 video with Anders Hejlsberg discussing how he
came to invent the language (sadly, this doesn't seem to be
available any more - wish I had downloaded it) and the influences he
based it on, it looked like it might be worth investigating. By this
time I was totally persuaded about component based development, and
C# lends itself to that better than anything I know.

2. C# was free and easily available. (zero risk... if it turned out
to be unsuitable all that was lost was time.)

3. C# is less verbose than Java (not that Java is "verbose" but you
do less writing in C#)

4. I was committed to the .Net platform and C# was developed for that
platform. (Although it runs on just about anything, like Java)

5. Support and help while learning it are available for free with
excellent videos and a user community of millions. Sample code,
background explanations, video walkthroughs, and even "unofficial"
support from Microsoft employees all instantly available from the
Internet. (I had some problems understanding and using Interop
Services when I first started. I needed this to be able to reuse my
existing COBOL components with the new language. I posted to a forum
and a couple of Microsoft guys were very interested to see COBOL as
a candidate for Interop and very quickly showed me where my problem
was (It was in the COBOL compile options not in Interop Services...)
These days my legacy components in COBOL play nicely with components
in C# and I don't need a CIL generating compiler to achieve this.
(Sometimes a bad experience can have a good outcome...)

These days I really enjoy writing C# and it meets my needs perfectly.
Learning it has forced me to widen my horizons and I now understand
things I never did while using COBOL.

So, for me at least, it is a good result.

Pete.

I'm just about finished with those C# tutorials on-line. Between work
and being sick for a couple of months, it has taken me much longer to
get through them than I thought, but I like the language so far.

Sorry to hear you were ill, Steve.

It is the flu season here but as I hibernate in the Winter and become a
recluse I am at low risk... :-)


The
toughest thing will be to know what's available in all of the
pre-defined classes and knowing how to use name spaces and methods
properly.

I don't think you can. There are around 100,000 classes available in .Net
4.
This is why I've come to look at things in terms of FUNCTIONALITY rather
than CODE...

What I do, is design my application as components (functions) and then, if
I'm not sure how to do something I need in one of the functions in C#, go
get some sample code. This way you get exposed to different coding styles
and it helps understanding of the coding process grow. As components are
identified they get grouped into Classes and become Class methods within a
namespace. I usually have a paper model of each method with its
properties,
events, and process flow (unless it is fairly trivial and under 100
lines)
and I run use cases through the paper model before I even start to code.

Namespaces seemed a bit strange when I first started but you soon get used
to it and it is really a useful way to collect similar related functions.

The coding process itself using Visual Studio is pleasant and I enjoy it.

If you are using forms in your application the forms tend to drive the
methods you will write, but I still use components either as methods or as
a
separate Class (if that particular functionality is likely to be useful
elsewhere.)

Apropos the topic, I have found that this approach has cut my debugging
significantly. I don't spend anything like the time I did on debugging and
the encapsulation of methods means that knock on and downstream errors are
a
thing of the past. If you use the Lego approach (and have made sure your
blocks do what they are supposed to) things just work a whole lot better.

Separation through interfaces means that objects can be quickly identified
if there is a problem and regression testing is something I no longer do.
If
the behaviour of a component (its methods...) is changed then only code
that
implements the new behaviour can be affected. Everythng else just works
like
it always has.



I do know javascript but not Java so I can't compare but C# isn't that
difficult to learn. Certainly easier to learn than IBM Assembler was
and RPG.

I may even try to write an application with C# once I'm finished and
I've acquired a decent reference book.


I've found the following books useful for getting to grips with things I
didn't know before like reflection, delegation, reference/value typing,
list
processing, collections, threading, asynchronous processing, and so on,
which are really "code related". After using C# for around 4 years now I
am
feeling pretty comfortable with all this stuff but I'm still learning and
some of the code I see just blows me away... :-):

"C# in a nutshell" (Peter Drayton and others) ISBN 0-596-00526-1 This one
is especially good for coming to grips with Regular Expressions but it
also
contains a lot of stuff actually generated by C# out of the .Net
Framework.
Obviously, that dates it a bit because .Net is expanding and there are new
Classes being added regularly.

"The C# programming Language" (Anders Hejlsberg and others) ISBN13
978-0-321-56299-9 I like the way this one has comments interspersed by the
various authors. It isn't so "readable" but is very useful for looking
stuff
up. I usually go here first to get the general idea then to one of the
other
books and the Internet for general background and discussion.

"Professional C# 2008" (Christian Nagel and others) ISBN13
978-0-470-19137-8
This is the one I use most. Very readable and nearly 1800 pages of well
written explanation. It covers everything I have wanted to know so far. I
bought the copy I have at a garage sale for $20; it is worth much more
than
that... :-)

HTH,

Pete.

Thanks for the book tips. I'll probably see what Amazon has available
pretty soon.

You mentioned "Regular Expressions". I remember that from one of the
tutorials. I'll have to review my notes!

Cheers,
--
<snip>

I am a fan of the books from Mike Murach Associates and they have some C#
books. I have not read any of them but I would probably start there:

http://www.murach.com/books/vba.htm


Yeah, I like their books as well. I have a CICS Desk Reference by
Murah that, although many years out of date, is still a good place to
look for syntax when those brain synapsis fail to fire. I also have
an MVS Assembler book by Murach. I'll take a look at the web site.

Regards,
--

////
(o o)
-oOO--(_)--OOo-

"I know the world isn't fair, but why isn't it ever unfair in my favor?"
-- Calvin & Hobbes (Bill Watterson)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Remove nospam to email me.

Steve
.

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: Cobol2Java: a Cobol to Java source code converter is available for evaluation
    ... If you were suggesting to use a C/C++ to Java tool that I may agree ... better because of being translated to a different language. ... Cobol is far from OO. ... many printers and page format as need at any time. ...
    (comp.lang.cobol)
  • Re: Hobby languages
    ... Because 100 out of 100 Java "programmers" have no idea what the ... English with someone whose native language is Swahili, ... of programming and requiring bloated resources. ... COBOL IS commonly found on the PCs of people who are interested in COBOL. ...
    (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: COBOL to Java conversion
    ... but also to change the language to be Java. ... I would be interested in knowing if anyone has seen a successful ... A significant size would be more than one million lines of COBOL code. ... "COBOL to Java is like a dog raised up on its hinder legs. ...
    (comp.lang.cobol)