Future reuse of code

[Marco van de Voort]

Re: Future reuse of code

In article <FTgYa.45171$LD 6.941433@news0. telusplanet.net >, RH wrote:[color=blue]
>[color=green]
>> will decrease in usage over time, not increase. There is absolutely
>> no new serious development being done in either language. In 15
>> years, Pascal will probably be completely dead,[/color]
>
> This isn't quite true. Delphi is OO Pascal, and a very nice language I
> might add (the software engineer also wrote the C# language).
>
> It's taking a back seat to the more popular web-services oriented languages
> but it's still an excellent alternative to C++ and/or Visual Basic. And it
> runs on Linux.[/color]

Use the development version of www.freepascal.org, and you have a fair
chance of compiling non-GUI Delphi code to PPC systems. (Mac OS <any> not
ready yet. AIX<->SYSV abi problems)

[jce]

Re: Future reuse of code

"Peter E.C. Dashwood" <dashwood@enter net.co.nz> wrote in message
news:3f303cf7_4 @news.athenanew s.com...
[color=blue]
> Nope. Disagree strongly. The days of procedural code and the necessity to
> maintain it are nearly over. It is very wrong NOW to design systems around[/color]
a[color=blue]
> particular language.
> The days of the "Waterfall" and "One Language Wonder" system development
> are, thankfully, in rapid decline.[/color]

This is certainly an interesting perspective. Java has taken the mantra of
write once run-anywhere but I always wondered what made it so special back
in the day- and it wasn't long after that people decided that they could
utilize just the JVM (Net Rexx for example).

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.

JCE

[jce]

[OT : but *very* apropos] Re: Future reuse of code

Here is a classic gotcha from Software Development magazine that I consider
appropriate enough to consider sharing.. you are fortunate enough to have a
disclaimer on the online version...those of us who read this back then (and
are gullible) actually believed it for a moment :-)

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

You may have to register but you can make up a name...you could sign up for
the free magazine (maybe not in nz) but it's a pretty interesting magazine
that doesn't take long to flip through.

Here's the intro:
Once every decade or so, a technology comes along that changes the software
landscape, becoming an indispensable part of the developer's life. Although
just about every new software concept touts itself as something that will
"change the way we work," only a handful truly possess such far-reaching
consequences. One key advance in our field was object-oriented programming.
Another is the increasing level of abstraction in the tools that developers
use. What shape might the next advance take?

The R&D folks at Nihil Software believe they have the answer. Their
innovation is called Natural Language Design (NLD), an approach that enables
rapid construction of complex software systems using natural (spoken or
written) language to specify the program. Using this approach, and the
accompanying tools that Nihil has provided as reference implementations , you
can verbally describe the system you want to build and literally see it
constructed as you speak. That's right, you heard me, no programming.
Skeptical? Read on.

John (jce)

"Peter E.C. Dashwood" <dashwood@enter net.co.nz> wrote in message
news:3f319c18_2 @news.athenanew s.com...[color=blue]
> TOP Post only.
>
> Dennis,
>
> I have believed for some years now that the lack of ARTIFICIAL[/color]
intelligence[color=blue]
> to generate systems can be compensated for (until it actually arrives[/color]
around[color=blue]
> 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[/color]
period[color=blue]
> of time or until the desired goal is attained.[/color]

[Peter E.C. Dashwood]

Re: Future reuse of code


"jce" <defaultuser@ho tmail.com> wrote in message
news:yEkYa.1784 5$K4.1012324@tw ister.tampabay. rr.com...[color=blue]
> "Peter E.C. Dashwood" <dashwood@enter net.co.nz> wrote in message
> news:3f303cf7_4 @news.athenanew s.com...
>[color=green]
> > Nope. Disagree strongly. The days of procedural code and the necessity[/color][/color]
to[color=blue][color=green]
> > maintain it are nearly over. It is very wrong NOW to design systems[/color][/color]
around[color=blue]
> a[color=green]
> > particular language.
> > The days of the "Waterfall" and "One Language Wonder" system development
> > are, thankfully, in rapid decline.[/color]
>
> This is certainly an interesting perspective. Java has taken the mantra[/color]
of[color=blue]
> write once run-anywhere but I always wondered what made it so special[/color]
back[color=blue]
> in the day- and it wasn't long after that people decided that they could
> utilize just the JVM (Net Rexx for example).
>
> However Java seems to fall into that "One Language Wonder" paradigm...when
> you say web service people reach for their Java/J2EE references.[/color]

Java, because of its innate OO support, mainly, is certainly a very useful
language for Web Support and Web Services. BUT, it is NOT "the only game in
town", any more than COBOL is "the only game in town" when it comes to
commercial application development. (Although, personally, I prefer COBOL
for this).

As I mentioned elsewhere, these days it is the Business functionality that
should drive the design (before someone else tries to remind me that not all
computer programming is about Business, let me say that ALL of my comments
are geared towards a commercial Business environment), with the language
best suited for providing that functionality being used to create the
functional components. I have used COBOL to create ActiveX components and
deployed them on the Web without problem. They can be "glued" with ASP or
Java or even JavaScript.

I am currently looking at SOAP to provide the XML layer so that some of
these can be deployed remotely as Web Services. It is ongoing effort and I
haven't completed it yet, but the early indications are that it is quite via
ble to create Web Services this way.
[color=blue]
> 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[/color]
as[color=blue]
> fast as I would have supposed.[/color]

This has to do with perception rather than reality. You are absolutely
correct that for many (most?) people when you mention "Web" they think
"Java". The reality is that, if you use a component based approach, the
source code of the components has no bearing on how they are deployed on the
Web, so they can be written in anything. Web Services will indeed abstract
away from a given language and .NET is a step in that direction.

It may just take a little while for the idea to become general...<G>.

Pete.

[Peter E.C. Dashwood]

Re: but *very* apropos] Re: Future reuse of code

LOL!

I enjoyed reading that...

I think "Nihil Software" was a bit of a giveaway... Maybe some of my posts
in the 90s inspired the author <G>.

I hasten to add that this is NOT what we were intending to do with Dulcinea.

Natural language interfaces are not SO hard to write (I wrote one for MS-DOS
that allowed people who didn't like the command line to communicate in
English.) It was distributed by a computer vendor in North Sydney as an
incentive to buy machines from him. He paid me $10 for every machine he sold
with it on...(It was called "IGOR" - Interactive Guide to On-line Running
<G>.) I did it because someone said it couldn't be done, and wasn't really
interested in it as a money maker.

He sold several hundred machines with it on, before Windows 3.1 came out and
blew it all away.... I received mail from people up to 2 years afterwards
saying how much they liked it. (If they asked IGOR about his life he would
give them my e-mail address, as well as an amusing tale of how he escaped
from Frankenstein's lab <G>)

The concept engine would have used a similar Natural Language simulation for
interaction with the User, but it would have no UNDERSTANDING of what the
language meant (apart from keywords which it would act upon).

Nowadays of course, there are some very good Natural Language interfaces and
they are quantum leaps beyond IGOR.

Don't let the fact that a magazine caught you with a hoax, persuade you that
such software will never be developed.

Thanks for posting it, John.

Pete.

"jce" <defaultuser@ho tmail.com> wrote in message
news:XOkYa.1784 7$K4.1019649@tw ister.tampabay. rr.com...[color=blue]
> Here is a classic gotcha from Software Development magazine that I[/color]
consider[color=blue]
> appropriate enough to consider sharing.. you are fortunate enough to have[/color]
a[color=blue]
> disclaimer on the online version...those of us who read this back then[/color]
(and[color=blue]
> are gullible) actually believed it for a moment :-)
>
> http://www.sdmagazine.com/documents/s=819/sdm0204f/
>
> You may have to register but you can make up a name...you could sign up[/color]
for[color=blue]
> the free magazine (maybe not in nz) but it's a pretty interesting magazine
> that doesn't take long to flip through.
>
> Here's the intro:
> Once every decade or so, a technology comes along that changes the[/color]
software[color=blue]
> landscape, becoming an indispensable part of the developer's life.[/color]
Although[color=blue]
> just about every new software concept touts itself as something that will
> "change the way we work," only a handful truly possess such far-reaching
> consequences. One key advance in our field was object-oriented[/color]
programming.[color=blue]
> Another is the increasing level of abstraction in the tools that[/color]
developers[color=blue]
> use. What shape might the next advance take?
>
> The R&D folks at Nihil Software believe they have the answer. Their
> innovation is called Natural Language Design (NLD), an approach that[/color]
enables[color=blue]
> rapid construction of complex software systems using natural (spoken or
> written) language to specify the program. Using this approach, and the
> accompanying tools that Nihil has provided as reference implementations ,[/color]
you[color=blue]
> can verbally describe the system you want to build and literally see it
> constructed as you speak. That's right, you heard me, no programming.
> Skeptical? Read on.
>
> John (jce)
>
> "Peter E.C. Dashwood" <dashwood@enter net.co.nz> wrote in message
> news:3f319c18_2 @news.athenanew s.com...[color=green]
> > TOP Post only.
> >
> > Dennis,
> >
> > I have believed for some years now that the lack of ARTIFICIAL[/color]
> intelligence[color=green]
> > to generate systems can be compensated for (until it actually arrives[/color]
> around[color=green]
> > 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[/color][/color]
Saul[color=blue][color=green]
> > 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,[/color][/color]
evaluate[color=blue][color=green]
> > it, change it, look at it again and repeat this process for a finite[/color]
> period[color=green]
> > of time or until the desired goal is attained.[/color]
>
>[/color]

[Paul Hsieh]

Re: Future reuse of code

> (Paul Hsieh) wrote:[color=blue][color=green]
> >COBOL and Pascal (the other groups you crossposted this message to)
> >will decrease in usage over time, not increase. There is absolutely
> >no new serious development being done in either language.[/color]
>
> Paul:
>
> I'm curious......ca n you provide me with a reference to the source of
> the above comment?[/color]

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.
[color=blue]
> Did you read that in a magazine article or was it a reference from a
> Gartner Group study?[/color]

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.

--
Paul Hsieh

http://www.pobox.com/~qed/

http://bstring.sf.net/

[Bat Guano]

Re: Future reuse of code

Paul Hsieh wrote:[color=blue][color=green]
>>(Paul Hsieh) wrote:
>>[color=darkred]
>>>COBOL and Pascal (the other groups you crossposted this message to)
>>>will decrease in usage over time, not increase. There is absolutely
>>>no new serious development being done in either language.[/color]
>>
>>Paul:
>>
>>I'm curious......ca n you provide me with a reference to the source of
>>the above comment?[/color]
>
>
> Sure:
>
> http://sourceforge.net/softwaremap/t...p?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.
>[/color]

ROFL. Are you suggesting Cobol used to score highly on that list?

[Peter E.C. Dashwood]

Re: Future reuse of code

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 "programmmi ng" will be done by end users, using standard tools that
will be smarter than those available today.

Pete.

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

"Paul Hsieh" <qed@pobox.co m> wrote in message
news:796f488f.0 308070114.4d2da 92f@posting.goo gle.com...[color=blue][color=green]
> > (Paul Hsieh) wrote:[color=darkred]
> > >COBOL and Pascal (the other groups you crossposted this message to)
> > >will decrease in usage over time, not increase. There is absolutely
> > >no new serious development being done in either language.[/color]
> >
> > Paul:
> >
> > I'm curious......ca n you provide me with a reference to the source of
> > the above comment?[/color]
>
> Sure:
>
> http://sourceforge.net/softwaremap/t...p?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.
>[color=green]
> > Did you read that in a magazine article or was it a reference from a
> > Gartner Group study?[/color]
>
> 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.
>
> --
> Paul Hsieh
> http://www.pobox.com/~qed/
> http://bstring.sf.net/[/color]

[Bob Wolfe]

Re: Future reuse of code

qed@pobox.com (Paul Hsieh) wrote:
[color=blue][color=green]
>> (Paul Hsieh) wrote:[color=darkred]
>> >COBOL and Pascal (the other groups you crossposted this message to)
>> >will decrease in usage over time, not increase. There is absolutely
>> >no new serious development being done in either language.[/color]
>>
>> Paul:
>>
>> I'm curious......ca n you provide me with a reference to the source of
>> the above comment?[/color]
>
>Sure:
>
> http://sourceforge.net/softwaremap/t...p?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.[/color]

1. Source Forge is a site dedicated to open software projects.....no t
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.
[color=blue]
>
>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.
>[color=green]
>> Did you read that in a magazine article or was it a reference from a
>> Gartner Group study?[/color]
>
>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.[/color]


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]

Re: Future reuse of code

In message <796f488f.03080 70114.4d2da92f@ posting.google. com>, Paul Hsieh
<qed@pobox.co m> writes[color=blue]
>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.[/color]

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.
[color=blue]
>--
>Paul Hsieh
>http://www.pobox.com/~qed/
>http://bstring.sf.net/[/color]

--
Alistair Maclean

[Joe]

Re: Future reuse of code

In article <796f488f.03080 70114.4d2da92f@ posting.google. com>,
qed@pobox.com says...
[color=blue]
> 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.[/color]


That's a good description of ANY language.

[Harley]

Re: Future reuse of code

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.

"Peter E.C. Dashwood" <dashwood@enter net.co.nz> wrote in message
news:3f319c18_2 @news.athenanew s.com...
| 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]

Re: Future reuse of code


"Harley" <dennis.harleyN oSpam@worldnet. att.net> wrote in message
news:mjAYa.9164 5$0v4.6223858@b gtnsc04-news.ops.worldn et.att.net...[color=blue]
> TOP Post Only
>
> Pete,
>
> I understand your fervor for OO, but I hope you realize that OO systems[/color]
are[color=blue]
> probably easier to reverse engineer into a modeling tool.
>[/color]
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.
[color=blue]
> It may be that the procedural people are still working, while the OO[/color]
people[color=blue]
> are displaced by new technology.
>[/color]

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

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...
[color=blue]
> Funny, isn't it.[/color]

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.[color=blue]
>
> "Peter E.C. Dashwood" <dashwood@enter net.co.nz> wrote in message
> news:3f319c18_2 @news.athenanew s.com...
> | 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[/color]
Saul[color=blue]
> | 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,[/color]
evaluate[color=blue]
> | 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[/color]
able[color=blue]
> | 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[/color]
doing[color=blue]
> | 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[/color]
was[color=blue]
> | 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.
>
>
>[/color]

[goose]

Re: Future reuse of code

qed@pobox.com (Paul Hsieh) wrote in message news:<796f488f. 0308070114.4d2d a92f@posting.go ogle.com>...[color=blue][color=green]
> > (Paul Hsieh) wrote:[color=darkred]
> > >COBOL and Pascal (the other groups you crossposted this message to)
> > >will decrease in usage over time, not increase. There is absolutely
> > >no new serious development being done in either language.[/color]
> >
> > Paul:
> >
> > I'm curious......ca n you provide me with a reference to the source of
> > the above comment?[/color]
>
> Sure:
>
> http://sourceforge.net/softwaremap/t...p?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.
>[/color]

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

how old are you, really ?
14 ?

[color=blue]
> 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.
>[color=green]
> > Did you read that in a magazine article or was it a reference from a
> > Gartner Group study?[/color]
>
> 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.[/color]


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

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

[Joe Zitzelberger]

Re: Future reuse of code

In article <796f488f.03080 70114.4d2da92f@ posting.google. com>,
qed@pobox.com (Paul Hsieh) wrote:[color=blue]
>
> Sure:
>
> http://sourceforge.net/softwaremap/t...p?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.[/color]

I prefer assembly language to everything...wh at does that mean?