Re: Productivity



FYI,
The current Micro Focus product for .NET development comes with both the
"traditional" (GUI) MF IDE *and* VisualStudio 2005 development. It is up to the
programmer which is "most" convenient for them. (I tend to run "simple"
ANSI/ISO conforming NON-OO, non-dotNET programs, so the old IDE works fine for
me. If I were developing "real" Windows applications, I suspect, that I would
switch over.

--
Bill Klein
wmklein <at> ix.netcom.com
"Pete Dashwood" <dashwood@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:4v33ipF1a006cU1@xxxxxxxxxxxxxxxxxxxxx
I've been doing a lot of thinking about productivity lately. (Of course
thinking about something doesn't necessarily make you more productive, but you
hope that it improves the quality of the end product.)

Just as an exercise and without any particular bias, I recently finished
rewriting a COBOL application that originally took six weeks to develop. (This
includes design, writing, testing/debugging). The design took around 4 days,
say, take a week off for design, and it took 5 weeks to develop.

It was rewritten in C# and DotNET in 5 days.

Given that I am a newbie in C#, but am no slouch when it comes to COBOL, I was
at a loss to explain this.

1. Having developed it once, it is true that I now understand the whole thing
a lot better.
2. Part of the 5 days for the C# development was spent doing video tutorials
on C#.
3. Some of the things that took a fair bit of effort in OO COBOL were easy in
DotNET.

But despite all of that, it is quite obvious that my productivity in Visual
Studio 2005 is MUCH better than my productivity using the Fujitsu IDE.

This made me think about tools.

VS 2005 provides an Interactive Development Environment that is simply years
ahead of any other development environment I have ever worked in (on both
mainframes and PCs).

Colour coding of code, rollaway windows that you can pin down when you want
them or send to a tab when you don't, intuitive context sensitive tooltips,
having all your defined variables available for selection at the moment you
want to reference them, having all methods, events and properties for the
object you are referencing available as you type, along with help tooltips for
any you select, ...all of these things collectively add up to MAJOR
productivity improvements. There's no flipping through a listing (or opening
other windows on the data division) to check variable names. No wondering or
having to check parameter lists to methods. No syntax errors; you simply can't
make them. No spelling errors...(Keywords are inserted for you and variables
are selected from lists as you begin typing the name). You can view or hide
any section of code at any time. Online contextual help is instantly available
for any method you want to use. If you don't know what methods are available
(always part of the problem when you start learning something), they are
organised by type so you can browse them instantly.

But.most importantly of all, the environment is NOT focused on code
development. It is pure event driven programming. You DON'T start by writing
IDENTIFICATION DIVISION (or its equivalent). You design what you want and the
code for the events is placed into the right contexts for you. All of the
housekeeping, fixed context, and overhead is hidden (unless you WANT to see
it). You focus totally on your application and what you want to happen when
events occur in it.

I find myself wondering how much quicker I could have built COBOL apps if I
had had this kind of development environment.

I understand that Fujitsu DotNET COBOL comes with this environment. It costs
several thousand dollars (if you can get them to sell it to you...I couldn't).

Visual C# Express comes with the same environment and is a FREE download.
(This has been so for nearly two years now. I wouldn't be surprised if they
stop it soon...) MicroSoft WANT you to use their products. They are confident
(and with good reason) that, once you experience this environment, you will
want to upgrade to Enterprise version and support multiple teams all working
in it. (The enterprise version also supports source control).

There are over 400 FREE video tutorials on C# available on the web, thousands
of code snippets and samples, and a positive and upbeat user community which
is growing daily.

(What am I doing here... :-))

After a couple of months evaluating alternatives to COBOL, I am satisfied that
C# and Java between them have everything I need. Visual Studio is simply the
icing on the cake. I don't need to write off my existing investment in COBOL,
as DotNET runs my existing COBOL components as unmanaged code. (This will do
until I need to replace them, if I need to replace them.) I have been finding
ways to minimize COBOL maintenance for some years now, and components achieve
this. I simply use C# as the glue to hold them together.

So, it looks like I will be winding down my COBOL development.

The tools for cutting edge development are MUCH better and cheaper than COBOL.
It remains useful for batch development, which is what it was invented for,
and where we came in...

Forty years of writing it.

Guess it's time for a change... :-)

Pete.















.



Relevant Pages

  • Re: Productivity
    ... Visual Studio 2005 is MUCH better than my productivity using the Fujitsu ... I really scorned VB for many years seeing it as being "kiddie programming". ... productivity shot through the roof when we began using it for our COBOL ...
    (comp.lang.cobol)
  • Re: Productivity
    ... Studio 2005 is MUCH better than my productivity using the Fujitsu IDE. ... Our productivity shot through the roof when we began using it for our COBOL code development. ... All of the housekeeping, fixed context, and overhead is hidden. ... I do know that there are tools that really integrate Windows with it (such as the ability to map drives to mainframe program files, interactive debug execute on the mainframe from the PC). ...
    (comp.lang.cobol)
  • Productivity
    ... Given that I am a newbie in C#, but am no slouch when it comes to COBOL, I ... it is quite obvious that my productivity in Visual ... VS 2005 provides an Interactive Development Environment that is simply years ... them or send to a tab when you don't, intuitive context sensitive tooltips, ...
    (comp.lang.cobol)
  • Re: PL/I Advantages
    ... The reason in COBOL's case, is that the USE of COBOL in IBM mainframe shops is ... processing" that is NOT available in COBOL (for productivity purposes) without ... As far as tools available for IBM Pl/I mainframe application development, ...
    (comp.lang.pl1)
  • Re: How would you do this?
    ... Standard and IBM hasn't implemented USAGE BINARY-CHAR or any other BINARY-xxx ... The best way to do this in Enterprise COBOL is to say ... returns a "32-bit map" with information about what environment a program is ... Use the LE "bit manipulation" routines? ...
    (comp.lang.cobol)