Future reuse of code

[Peter E.C. Dashwood]

Paul,

I think you may be missing the fact that these are projects that are using
SourceForge products or are connected with SourceForge in some way.

While I support SourceForge in general, and Open COBOL in particular, the
SourceForge COBOL product is not yet robust enough for serious commercial
deployment (at least as far as I'm concerned; others may differ...).

Obviously, this perception, if it is shared by others would have an effect
on the number of projects using it that are reported on the link you posted.

It is very wrong to draw the conclusion that no COBOL (or PASCAL)
development is going on, based on this one set of statistics. I personally
know of three COBOL development projects happening at the moment.

Having said that, it would be foolish to pretend that the language is not in
decline, but I believe ALL procedural languages (not just COBOL) have a
lifetime of not more than around 15 years. (Hope I'm wrong...).

This is because it is becoming uneconomic and non-viable for companies to
maintain multi-lingual, multi-skilled IT departments. It is cheaper to
simply go the package route or outsource the whole function. I see a time
coming when "IT" will simply mean "Network support and maintenance" and in
house "programmming" will be done by end users, using standard tools that
will be smarter than those available today.

Pete.

(Top post...no more...)

 

[Bob Wolfe]

Sure:

http://sourceforge.net/softwaremap/trove_list.php?form_cat=160

Notice how many projects are in COBOL. Now look at the C, C++, Java
and Pascal numbers and go back to my original post.

1. Source Forge is a site dedicated to open software projects.....not
corporate software development.

2. Source Forge is a voluntary posting environment, not a
statistically valid, nor reliable source of information about what is
really happening in the data processing world.

In order to determine what is really happening in the data processing
world, one would need to conduct a statistically reliable and valid
survey of a cross section of government and industry.

The acid test, of course, is to compare against assembly language.
Its fair to say that assembly language isn't really a language at all
-- its just a bunch of macros for flipping 1's and 0's. You know a
language is dead or dying if people actually prefer assembly language
to using it.


Nah, just 20 years as a professional programmer viewing the landscape,
knowing people who work in COBOL, watching the rise and fall of Pascal
(having used it and switching over to C just like everyone else), etc.

Bob Wolfe
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
When replying by e-mail, make sure that you correct the e-mail address.
Check out The Flexus COBOL Page at http://www.flexus.com

 

[Alistair Maclean]

The acid test, of course, is to compare against assembly language.
Its fair to say that assembly language isn't really a language at all
-- its just a bunch of macros for flipping 1's and 0's.

Not true. As a one time assembler language programmer who still dabbles
I can state categorically that Assembler language is a true language,
just not as verbose as Cobol.

 

[Sudsy]

jce wrote:

However Java seems to fall into that "One Language Wonder" paradigm...when
you say web service people reach for their Java/J2EE references. They don't
view COBOL or PL/I, VB or anything else being viable in that arena. I was
under the impression that web services were the first step in abstracting
away from a language or implementation but it seems that isn't happening as
fast as I would have supposed.

I'm not convinced. If anything, CORBA and IDL provided the means to
access "legacy" applications. And why not? If they do the job then
isn't that a sterling example of code re-use?
Similary, the J2EE connector for CICS provides a bridge to an
architecture which is still emminently viable today. Why rewrite
an application which has been performing real-time processing for
decades? Talk about mature!
I enjoy witnessing the development of "glue" software which allows
the best of the past to be transparently connected to the web. Do
the users really care that the application is running under CICS
on a mainframe?
But then weren't mainframes supposed to have disappeared decades
ago? ;-)

 

[Joe]

Its fair to say that assembly language isn't really a language at all
-- its just a bunch of macros for flipping 1's and 0's.

That's a good description of ANY language.

 

[Harley]

TOP Post Only

Pete,

I understand your fervor for OO, but I hope you realize that OO systems are
probably easier to reverse engineer into a modeling tool.

It may be that the procedural people are still working, while the OO people
are displaced by new technology.

Funny, isn't it.

| TOP Post only.
|
| Dennis,
|
| I have believed for some years now that the lack of ARTIFICIAL
intelligence
| to generate systems can be compensated for (until it actually arrives
around
| 2020...<G>) by putting a Human (or Humans) in the loop.
|
| This was revealed to me in a blinding flash of insight (kind of like Saul
| on the road to Damascus <G>) when I was trying some new approaches to
| Project Management and instigated some RAD type workshops. The keys are
| INTERACTION and ITERATION. Do something, look at it, discuss it, evaluate
| it, change it, look at it again and repeat this process for a finite
period
| of time or until the desired goal is attained.
|
| It doesn't really matter how formal this is. As systems get smarter they
can
| take on more of the load. I postulated a "concept engine" some years ago
| that would "understand" concepts within fairly narrow boundaries (like a
| specific area of business, say, customer managment (CRM))and would be able
| to interact with a user and manage the customer base. The engine would
| recognise key words within the concept of customer, like NAME, ACCOUNT
| NUMBER, etc, would be aware of the transactions that Customers can be
| involved in (SALE, RETURN, etc), and would have its own Methods for doing
| things with the Customer base. (Ideally, it would be capable of writing
its
| own methods in response to gathered requirements, but that would be
further
| down the track...).
|
| Obviously, OO lends itself to this type of exercise as it really comes
down
| to a basic Customer class with Properties and Methods, that has a layer
(or
| layers) over it that can cause extensions to the base class for
requirements
| derived by interaction and iteration with a Human. ("Print me an
| invoice"..."You mean like this?" "No, I need the discount moved to here
and
| the Sales Tax in red." ..."OK, like this?" ..."Yeah, that's it...").
|
| It was to be called "Dulcinea" as it represented the goal of a Quixotic
| quest....<G>
|
| I was quite serious about going to build it, when I found out that it was
| already under way in India...<G>
|
| Never heard what happened, but I wouldn't be surprised to see such
software
| coming into the Market place in the next few years. There are many
| applications where such an engine could be applied.
|
| Pete.

 

[Peter E.C. Dashwood]

TOP Post Only

Pete,

I understand your fervor for OO, but I hope you realize that OO systems are
probably easier to reverse engineer into a modeling tool.

Yes, I think I understand what you're saying <G>.

I am not convinced that a "modelling tool" will be the answer. I believe it
goes further than that.

It may be that the procedural people are still working, while the OO people
are displaced by new technology.

I doubt that very much. I believe Procedural programming in general is in
its "Gotterdammerung"...

OO for me is only important insofar as it provides the key to component
building.

There are too many disadvantages in pure OO...lack of cross platform
Classes, difficulty in calling one set of classes from a language based on a
different Foundation, and so on. Simply by wrapping the objects as
components, all these disadvantages disappear and they can be dropped
anywhere. My fervor is for components, not OO, although I also believe that
OO is a superior model for programming than procedural.

I see it unfolding like this...

1. Procedural programming declines. (It takes too long and consequently
costs too much. We did it for decades because there was no other option; now
there is...)

2. The OO model gains acceptance. (OK, not in the Fortress, but the Fortress
will be isolated and bypassed...)

3. Component based systems are a logical extension of OO so I see things
gradually going that way (for the reasons I outlined above.)

4. As the component based design model becomes more accepted, packages will
become smarter, reuse will be the norm, and companies will no longer
maintain "computer programming" departments. Instead, smart users will use
smart software with simple "point and click" or vocal interfaces, to develop
smart business systems. Anything "difficult" will be outsourced, anything
tedious and expensive will be off-shore, and the IT department will be a
handful of Network nerds who will keep the whole infrastructure running
(using component based "smart" diagnostic tools...<G>)

5. Around 2020 there will be some major breakthroughs that will change the
whole way we use computers anyway. By then computers will be ubiquitous and
embedded in our daily lives. Everything will be "smart". There is talk of
smart earrings and jewellery (wearable cyberstuff)... you're at a party and
someone who you know you should know comes towards you...your earring
whispers their name and background and where you met them, the names of
their children and dog or whatever...Your "smart" glasses with their
embedded camera linked to your home system by wireless internet, retrieved
the information in the time it took the person to walk across the room.
Whimsical? Maybe today... not by 2020. And I don't see procedural
programming cutting it...

Funny, isn't it.

Depends on your point of view <G>. I'll be lying on the beach in the Bay of
Plenty (or pushing up daisies in some spot that is forever Godzone...) so I
can afford to find it amusing, but it won't be for a lot of people who
thought computer programming was going to be a great career...

Pete.

 

[goose]

Sure:

http://sourceforge.net/softwaremap/trove_list.php?form_cat=160

Notice how many projects are in COBOL. Now look at the C, C++, Java
and Pascal numbers and go back to my original post.

I'm dumbstruck by the profound lack of comprehension that is displayed
by that "proof" ...

how old are you, really ?
14 ?

The acid test, of course, is to compare against assembly language.
Its fair to say that assembly language isn't really a language at all
-- its just a bunch of macros for flipping 1's and 0's. You know a
language is dead or dying if people actually prefer assembly language
to using it.


Nah, just 20 years as a professional programmer viewing the landscape,
knowing people who work in COBOL, watching the rise and fall of Pascal
(having used it and switching over to C just like everyone else), etc.

20 years ? in 20 years the fall of cobol has been predicted
/how/ many times ?

goose,
cobol, the 30-year fad ...

 

[Joe Zitzelberger]

Sure:

http://sourceforge.net/softwaremap/trove_list.php?form_cat=160

Notice how many projects are in COBOL. Now look at the C, C++, Java
and Pascal numbers and go back to my original post.

The acid test, of course, is to compare against assembly language.
Its fair to say that assembly language isn't really a language at all
-- its just a bunch of macros for flipping 1's and 0's. You know a
language is dead or dying if people actually prefer assembly language
to using it.

I prefer assembly language to everything...what does that mean?

 

[Karl Heinz Buchegger]

I prefer assembly language to everything...what does that mean?

That you have too much time?

 

[Howard Brazee]

<howls of laughter> pull the other one sonnyboy, its got bells on

OK, I exaggerated. But it runs on a lot more platforms than anything else
without costing more.

 

[Marco van de Voort]

OK, I exaggerated. But it runs on a lot more platforms than anything else
without costing more.

Like e.g. gcc ? Think not.

 

[Tor Iver Wilhelmsen]

Like e.g. gcc ? Think not.

GCC the compiler is pointless without libraries, and libraries in
C/C++ differ between platforms. Java's libraries let you write complex
applications without a million #ifdef _LINUX_ or whatever.

 

[Marco van de Voort]

GCC the compiler is pointless without libraries,

Java is pointless without the connection between SWING and host OS.

C++ GUI libraries are pointless without connection between GTK and host OS.

I'm sorry, but I fail to see the difference.

and libraries in C/C++ differ between platforms. Java's libraries let you
write complex applications without a million #ifdef _LINUX_ or whatever.

You can do that in most other languages too. The native feel of the
application will suck in that case though. (and IMHO that is one of the
downsides of the Java SWING model)

 

[Howard Brazee]

The cost issue is separate from the portability issue, but exactly WHICH
platform currently supports Java that doesn't also have one or more COBOL
compilers available for it?

MacIntosh. (native)

I don't separate cost though. One big reason that CoBOL is hurting is that it
is relatively expensive.

 

[Tor Iver Wilhelmsen]

Java is pointless without the connection between SWING and host OS.

Java 2 Standard Edition (J2SE) defines a STANDARD library which
includes Swing, and AWT which it builds on. AWT has the native hooks
required.

C++ GUI libraries are pointless without connection between GTK and host OS.

Gtk+ is not part of C++ as such - it is one of *many* libraries which
*might* exist for your target platform.

I'm sorry, but I fail to see the difference.

The difference is that AWT and Swing are parts of J2SE, Gtk+ is not
part of C++.

You can do that in most other languages too. The native feel of the
application will suck in that case though. (and IMHO that is one of
the downsides of the Java SWING model)

I have seen more "native" Windows apps that break with Microsoft's
User Interface Guidelines (nice book to have as a reference) than what
the Windows L&F defaults to.

 

[Marco van de Voort]

Java 2 Standard Edition (J2SE) defines a STANDARD library which
includes Swing, and AWT which it builds on. AWT has the native hooks
required.

And what does that matter for this point? It still needs OS dependant code
somewhere. So do GUI libraries in other languages (like GTK, QT, you name it)

Gtk+ is not part of C++ as such - it is one of *many* libraries which
*might* exist for your target platform.

A C++ compiler is indeed not required to package GTK+. Maybe Java madatory
forces the compiler/VM developper to package Swing or AWT even.

The difference is that AWT and Swing are parts of J2SE, Gtk+ is not
part of C++.

An organisational detail IMHO. An all Java systems adhere to it currently?
They don't simply change to a different for "embedded" standard if it is not
easy?

I have seen more "native" Windows apps that break with Microsoft's
User Interface Guidelines (nice book to have as a reference) than what
the Windows L&F defaults to.

Me too. But that is not a reason for me to let my own applications degrade
to that level.

 

[goose]

OK, I exaggerated. But it runs on a lot more platforms than anything else
without costing more.

you are still exaggerating my friend. as a simple example (and to put the
slipper in , gcc targets about 6 of the 10 items on my original list
(which was unfortuantely snipped), with one which I know *FOR* *SURE* that gcc
does not target and 3 that I am not sure of, while java targets *NONE* of
the machines on the list.

now a combo of gcc + gtk targets everything that java + libs target, and
gcc *without* a gui lib targets even more than java does without its gui
libs.

lets say that you and me are sitting at virtually identical machines
(powerhouse type desktops with gobs of ram and processing power), with the
only difference between the machines being that you have a java dev. env. and
I have a full gcc (with source dev. env. with gtk for my gui.

lets say further that we have decided to a have a childish dicksize war with
each other, to see who can write code that will run as expected on the
greatest number of machines out there. I cross-compile where necessary,
or run gcc under cygwin to get the intended effect. you write java code
under whatever OS you want to.

who do you think will write a program that will run (recompiled if necessary)
on the greatest number of machines ?

ok, so your java code runs on x86, sparc, AIX (is java there yet ?) and
various other servers, while not rnuning on anything that has under
1Meg of RAM.

my gcc code will run on all of the above *and* on the embedded stuff that
uses 8051 code *and more*.

the end result is that if you are going to be stuck into a single vendor
just because you want the code to be portable, gcc seems to be the best
choice (with gtk where appropriate), not java.

goose,
extracting the urine ;-)

 

[Tom McGlynn]

MacOS (both flavors) is very Java-centric and without Cobol at the
moment.

A quick search Google search didn't seem to find any counterexamples.
One site, http://www.techiwarehouse.com/Cobol/, had
some interesting statements about COBOL though. No source is
given so take them with as much salt as you like. The one
that caught my eye was:

15% of all new applications (5 billion lines) through 2005 will be in COBOL.

I think that COBOL is probably alive and quite healthy. My guess is that
people extrapolate from the settings they are used to, but no programmer
or even any company can really span the very broad reach of programming
today: games, scientific, payroll, systems, embedded applications, communications,
financial, regulatory, manufacturing, military, ... are just a few areas
that come to mind which have completely different cultures and requirements.
Usenet participation is likely highly variables within these cultures so
the view from here is also highly biased.

My own take on this is that no language ever really dies, and until recently I'd
have suggested that the number of programmers programming in any given language
never decreases. However languages lose and gain total share as new fields
enter the marketplace. So Fortran still has a big chunk of the science market
and COBOL a similar chunk of the business market after more than 40 years,
but there are many, many more markets out there today, and other languages
have dominated there.

Regards,
Tom McGlynn

 

[Roedy Green]

are gullible) actually believed it for a moment

http://www.sdmagazine.com/documents/s=819/sdm0204f/

I think it could be doable within a certain problem domain, for
example setting up simple databases with data validation, report
generation.

The interactions need not be free form English. They could be fill in
the blanks or interactive questioning.