Future reuse of code

[Karl Heinz Buchegger]

Re: Future reuse of code



"Peter E.C. Dashwood" wrote:[color=blue]
>
> "Dr Engelbert Buxbaum" <engelbert_buxb aum@hotmail.com > wrote in message
> news:bha4np$9lm $00$1@news.t-online.com...[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. In 15
> > > years, Pascal will probably be completely dead, and the COBOL
> > > community will be reduced even from the size of today's community
> > > (human mortality alone will guarantee this.)[/color]
> >
> > This may be true for COBOL, but Pascal is very much alive and kicking,
> > in the form of Delphi/Kylix. I am currently writing Kylix software, most
> > of the cutting edge routines (that do the real work rather than the user
> > interface) are straight plug-ins of 15 year old Turbo-Pascal code. Now
> > with Borland going for cross-platform (Windozze/Unix) compatibility
> > there is no reason why Pascal should die in the foreseable future.[/color]
>
> There are 400,000,000 reasons why ALL procedural languages (including COBOL
> and PASCAL) should "die" in the not-too-distant future. (I don't know your
> definition of "foreseeabl e" but mine is around 20 years...)[/color]

.... and replaced by what?

In the early 80-es there was a hype on PROLOG: The japanese are working
with PROLOG and 10 years from now PROLOG will replace traditional procedural
computer languages completely. So, where is PROLOG today, 20 years later?

[snip a lot of interesting thoughts]
[color=blue]
> Bottom Line: Don't get smug about COBOL dying and PASCAL surviving; they are
> on the same parachute and the ground is coming up....[/color]

Procedural languages will be there for a long time. The languages may be different,
but still use the same principle. Knowing how to program in this paradigm will still
be the entry key to programming those languages. The rest is syntactic
sugar (simplified).

--
Karl Heinz Buchegger
kbuchegg@gascad .at

[Peter E.C. Dashwood]

Re: Future reuse of code


"Karl Heinz Buchegger" <kbuchegg@gasca d.at> wrote in message
news:3F38DA6F.E FFBF81B@gascad. at...[color=blue]
>
>
> "Peter E.C. Dashwood" wrote:[color=green]
> >
> > "Dr Engelbert Buxbaum" <engelbert_buxb aum@hotmail.com > wrote in message
> > news:bha4np$9lm $00$1@news.t-online.com...[color=darkred]
> > > Paul Hsieh wrote:
> > >
> > >
> > > > 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. In 15
> > > > years, Pascal will probably be completely dead, and the COBOL
> > > > community will be reduced even from the size of today's community
> > > > (human mortality alone will guarantee this.)
> > >
> > > This may be true for COBOL, but Pascal is very much alive and kicking,
> > > in the form of Delphi/Kylix. I am currently writing Kylix software,[/color][/color][/color]
most[color=blue][color=green][color=darkred]
> > > of the cutting edge routines (that do the real work rather than the[/color][/color][/color]
user[color=blue][color=green][color=darkred]
> > > interface) are straight plug-ins of 15 year old Turbo-Pascal code. Now
> > > with Borland going for cross-platform (Windozze/Unix) compatibility
> > > there is no reason why Pascal should die in the foreseable future.[/color]
> >
> > There are 400,000,000 reasons why ALL procedural languages (including[/color][/color]
COBOL[color=blue][color=green]
> > and PASCAL) should "die" in the not-too-distant future. (I don't know[/color][/color]
your[color=blue][color=green]
> > definition of "foreseeabl e" but mine is around 20 years...)[/color]
>
> ... and replaced by what?
>
> In the early 80-es there was a hype on PROLOG: The japanese are working
> with PROLOG and 10 years from now PROLOG will replace traditional[/color]
procedural[color=blue]
> computer languages completely. So, where is PROLOG today, 20 years later?
>
> [snip a lot of interesting thoughts][/color]

Yes, I remember the Japanese PROLOG push and the drive to develop the first
AI Operating System.

It certainly failed.

So did attempts to build a lacemaking machine in the late 18th century in
England. The received wisdom was that it was impossible because the process
of making lace was just too intricate.

It took countless attempts, ruined families, suicides, and 30 years, but the
machine is viewable today in the Lace museum in Nottingham.

To answer your very fair question (... and replaced by what?), I believe
that new methodologies for system development will arise in response to the
pressure from the Marketplace. I have already seen interesting departures
from traditional methods that achieved much faster results and were much
more flexible. The key to these approaches is a more RAD like process with
iteration and interaction by users. Currently, we have programmers and
"Quick Build" tools in the loop, but it is only a matter of time before
smarter software will take on these functions. Eventually, end-users will
interact with smart software to achieve what they want, and there will be no
programmer in the loop at all.

There is far too much on this to go into here (sorry, I know that sounds
like a cop out, but I have been writing on this subject for some years now
and have been using alternative approaches in the real world in industry
with results that are very encouraging.), but I will close by saying that
everything I am saying is simply extrapolation from what is happening NOW. I
claim no psychic powers, just good observation and a lifetime of experience
in IT.
[color=blue]
>[color=green]
> > Bottom Line: Don't get smug about COBOL dying and PASCAL surviving; they[/color][/color]
are[color=blue][color=green]
> > on the same parachute and the ground is coming up....[/color]
>
> Procedural languages will be there for a long time. The languages may be[/color]
different,[color=blue]
> but still use the same principle. Knowing how to program in this paradigm[/color]
will still[color=blue]
> be the entry key to programming those languages. The rest is syntactic
> sugar (simplified).[/color]

Well, time will tell...<G>

Pete.

[Howard Brazee]

Re: Future reuse of code


On 12-Aug-2003, "Peter E.C. Dashwood" <dashwood@enter net.co.nz> wrote:
[color=blue]
> I wonder why your response is so vitriolic?[/color]

Really?
[color=blue]
> I didn't set out to attack you.[/color]

Agreed.
[color=blue]
> Could you be a little sensitive to the truth of what I'm saying?[/color]

Isn't that human nature - when the truth hurts?

-----
By far the most irrational character on Star Trek was the one who always was
amazed when people acted like people.

[Howard Brazee]

Re: Future reuse of code


On 12-Aug-2003, "Peter E.C. Dashwood" <dashwood@enter net.co.nz> wrote:
[color=blue][color=green]
> > Bottom Line: I think we can safely award you the "troll of the week"[/color]
> award, with[color=green]
> > "don't panic" in nice friendly letters.[/color]
>
> Well, I always enjoyed the Hitchhikers Guide to the Galaxy, but I have never
> been a troll. You have no idea who you are dealing with <G>.[/color]

The set of trolls includes a large number of trouble makers. So we tend to
deny that what we're doing is trolling, when our purpose is noble.

But a statement designed to gain a response still qualifies. We need more
intelligent, useful trolling.

[Scott Moore]

Re: Future reuse of code

"Peter E.C. Dashwood" wrote:
[color=blue]
> There are 400,000,000 reasons why ALL procedural languages (including COBOL
> and PASCAL) should "die" in the not-too-distant future. (I don't know your
> definition of "foreseeabl e" but mine is around 20 years...)
>[/color]

Pascal is not any more purely procedural than C++. Last time I checked, C++
still had functions. If you want to insist that Pascal has not evolved since
1973, then you are going to insist on being wrong.

--
For most men, true happiness can only be achieved with a woman.
Also for most men, true happiness can only be achieved without a woman.
Sharp minds have noted that these two rules tend to conflict.....

[Roedy Green]

Re: Future reuse of code

On Tue, 12 Aug 2003 23:27:07 +1200, "Peter E.C. Dashwood"
<dashwood@enter net.co.nz> wrote or quoted :
[color=blue]
>Procedural code is already into Gotterdammerung . It takes too long, requires
>too much skill, is too inflexible (the accelerating rate of change in the
>Marketplace and in technology is another reason why it is doomed to
>extinction) and, overall, costs far too much.[/color]

What other options do we have?

1. OO -- also requires considerable skill.

2. FORTH where you create a language for solving problems in a
particular domain. The users of the language just string words
together. Usually only a handful of people understand how it works
under the covers.

3. Spreadsheets, where the emphasis is on relationships, not on
precise order of computation. The complexity is added gradually with
real life data used to test at every stage.

4. wizards, where you configure some generic application into a custom
app.

5. query by example.

6. training neural nets.


Spreadsheet logic is the one with the lowest threshold of technology
required to integrate it into Java. It should be possible to write
generic apps, e.g. a retail sales package, and have the customer or
someone with minimal skill, customise it with bits of spreadsheet
logic.

--
Canadian Mind Products, Roedy Green.
Coaching, problem solving, economical contract programming.
See http://mindprod.com/jgloss/jgloss.html for The Java Glossary.

[Roedy Green]

Re: Future reuse of code

On Tue, 12 Aug 2003 12:06:10 +0000 (UTC), Marco van de Voort
<marcov@toad.st ack.nl> wrote or quoted :
[color=blue]
>If you studied programming
>closer, you'd know that.[/color]

This is an interesting conversation. If you would spare the nasty
barbs it would also be enjoyable. Take your bitterness out on someone
who deserves it. I could suggest some politicians, but that would
start a flame war.


--
Canadian Mind Products, Roedy Green.
Coaching, problem solving, economical contract programming.
See http://mindprod.com/jgloss/jgloss.html for The Java Glossary.

[Marco van de Voort]

Re: Future reuse of code

In article <3f3908a5_6@new s.athenanews.co m>, Peter E.C. Dashwood wrote:[color=blue][color=green]
>>
>> On the contrary, specially for these kinds of users, sequential jobs are a
>> way of thinking that is normal to them.
>>[/color]
>
> Well, Marco, I wonder how long it is since you looked?[/color]

Well, I think I went to work today.
[color=blue]
> Software tools are already emerging that substitute iteration and
> interaction for sequential processes.[/color]

Sure, for certain limited domains, the actual engineering is done,
and there is a nice tool to customize that in several ways.

Useful? Certainly. Timesaver? sure. Potential to be universal? No way.
[color=blue]
> SQL Server for example has a "drag and drop" tool that allows processing
> streams to be built in minutes.[/color]

I've used laboratory controlling software which was nice in a lot of ways
too. It was truely useful, productive and IMHO the most important,
it avoided a lot of errors.

But I would never claim that such a thing could be generalized and replace
software engineering. They are problem-domain specific solutions, nothing
more.
[color=blue]
> These same streams using procedural code would take days.[/color]

Sure. But that doesn't spell the end of procedural programming.
[color=blue]
> What's more, if you get it wrong you can simply go to a graphic interface
> and change it.[/color]

I do that with sequential programming (Delphi) too. Tools for a specific
domain. It saves time (and equally important) makes the product somewhat
easier to maintain.
[color=blue]
> I have seen at least one Graphic design package that uses a
> similar principle. Non computer literate designers can easily manipulate
> these tools, interact with them, iterate their processes, until they
> achieve what they want.[/color]

Within very simple, limited borders. There is not one such tool that
replaces general programming (regardless of which paradigm you use)
[color=blue]
> Programming knowledge is NOT a requirement.[/color]

It is. Those environments are extended using normal programming, tackling
large projects still needs skill.

Those tools are just that, extra tools. Pretty comparable to fancy
runtime (and later classes-) libraries. None of them spelled the end
of programming either.

Hmm, I think that is a good description. Some extra tools to aid software
development, and allow a _user_ some customization.
[color=blue]
> Currently, tools like this are in their infancy. In 15 years we can expect
> significant improvement.[/color]

Well. Then exactly this is our point of disagreement. Please explain
why you think (and how do you envision that will happen) how you get
from domain-specific solutions (math,laborator y handling, db handling)
to general purpose programming.

This is also what annoyed me about your previous message. It is a message
of a believer. There is no reasoning behind it. You only "get" it when
you are a believer.
[color=blue][color=green]
>> increased also. I sometimes doubt if increased computer literacy actually[/color]
> kept[color=green]
>> up with the added computer tasks for the avg person.
>>[/color]
>
> The computer skills of the Business are rising very rapidly.[/color]

IT skills in using their own applications. Not in programming and
customization. In that department it got worse, especially in companies with
highly skilled (non-IT) technical people.

In the old days any beta-sciences student or graduate could do some
general purpose programming, usually they learned it so they could
program calculations. Nowadays they use mathlab, which is
absolutely great, but combined with faster machines requires less
programming skill to achieve the same result.
Which is good for them, but not for the level of programming knowledge
in a company.
[color=blue][color=green]
>> Yes, they want smug buzzword talking con-men to take advantage of them ?
>>[/color]
> No, they're getting pretty wise to that one too...in fact, most of us are.[/color]

If that were the case, I wouldn't get +/- 50-100 spams a day.
[color=blue][color=green]
>>
>> Exactly. So as long as my solution is good, and I can justify using a[/color]
> language,[color=green]
>> waht is the problem.
>>[/color]
> It isn't enough just to provide a solution; it has to be an acceptable
> solution.[/color]
[color=blue]
> That means using tools and methods the users are comfortable with.[/color]

I don't see why that would be the case? Its like a car mechanic who has to
fix a car with the tools an average person has in his house.
[color=blue]
> In 15 years they WON'T be comfortable with some old academic cobbling code
> together for a solution... By then they will have bypassed the need for
> coding and will be implementing their own solutions.[/color]

Amen:-) Still a little thin on reasons though.
[color=blue]
> That was the whole point of my argument. They are doing it already... More
> and more Business departments are gaining enough computer literacy to
> build their own systems using standard solutions like spreadsheets and
> databases.[/color]

That kind of limited hobbying always has happened.
[color=blue]
> The last place I worked (a major utility in the Midlands of England) there
> were more people in the Business with Computer Science degrees, than I had
> on my IT staff.[/color]

Hmm. My former employer, which was IT related, had more chemists (including
me) than people with CS degrees.
[color=blue]
>
> There is no problem. I never suggested there was one. You can go ahead and
> use procedural code for the rest of your natural life. (I intend to...). You
> just won't make a lot of money at it. It'll become a "cottage industry" by
> 2020...<G>[/color]

A well. We have religious freedom :-)
[color=blue][color=green][color=darkred]
>> > software until they get what they want.[/color]
>>
>> Sure. The telepathic kinds.[/color]
>
> The process of iteration, as you would know if you had ever worked in a RAD
> environment, does not require telepathy.[/color]

Very interesting. Why wouldn't I've worked in a RAD environment? Telepathy
again?
[color=blue]
> Your scorn is misplaced. Interaction and iteration enable HUMAN intelligence
> to get in the loop, but does NOT require specific technical (i.e.
> programming) skill.[/color]

While I think in retrospect that my tone might have been misplaced,
your second post confirmed my suspicious. You have a firm believe in
something, and really want to advocate that. However I don't find
much evidence, not even shallow ones.

Except maybe that one story of a business department full of people
with CS degree's. Now that's surprising that they were more likely
to get something working using minimal and standard tools :-)
[color=blue][color=green]
>> Programming is what requires the skill. Not the language. If you studied[/color]
> programming[color=green]
>> closer, you'd know that.[/color]
>
> LOL! While I note that you are at a very reputable University (apparently
> learning to use procedural code...)[/color]

I'm still honorary member of my former universities computer club.
[color=blue]
> I can assure you I have studied programming for the whole of my working
> life (some 38 years - I started programming computers in 1965
> What were YOU doing then <G>?) not behind
> cloisters but in the real world.[/color]
[color=blue]
> Leaving aside your intended slight, I agree
> that programming does require skill, but it was you who turned my statement
> into a separation between programming as a skill and programming as an art.
> I said that "Procedural Coding" is in decline. That includes the Language
> and the Art...[/color]

Yet, except a firm believe that ordinary users with a few standarised
tools will replace them, you don't reveal much reasons.
[color=blue]
> I wonder why your response is so vitriolic?
>I didn't set out to attack you.[/color]

I've been on news for over a decade now. And on Fidonet before that. While
trolling and wild speculation presented as "truth" might seem innocent to
you, it doesn't to me. It poisons a group, and creates an unequal position
for discussion.

The problem is that you don't have to justify yourself in 15 years if you
are totally wrong, like you would in a company. It is nearly anonymous, easy
and safe, yet it still does damage.

(and btw, keep in mind nearly medium-longterm IT forecasts have been wrong
till now)

As said before Maybe I was to harsh, yet I still stand behind the original
intentions behind that message.
[color=blue]
> Could you be a little sensitive to the truth of what I'm saying?[/color]

Please don't degrade to amateur psychology. It's seriously flawed enough
already.
[color=blue][color=green]
>> And where are you references for that. You don't even say what it is up
>> against, except some vague references about software which is going to
>> emerge as a winner in 2015 (and which I assume is telepathic, at least if[/color]
> I[color=green]
>> see your description)
>>[/color]
> The typical response of the student.[/color]

Again a belittling comment. Try to argue with something more substantial
arguments.
[color=blue]
> Are you saying that, without a
> reference, you would question whether there is an accelerating rate of
> change in computer technology?[/color]

No. I question if it goes in the direction that you say it is. So not
IF there will be change, just if it is going to be the change you proclaim.
[color=blue]
> OK, Alvin Toffler, Moore's Law, and the fact that I have to get a new
> computer every 18 months...[/color]

Relates to programming how?
[color=blue]
> As for my knowledge of the Market place, I have worked in industry IT
> services all my life. It is axiomatic to me that the Business needs are
> accelerating and greater flexibility in response to changing and new
> Markets is required in IT today than was the case even 5 years ago. I
> don't need a text book to tell me this; my users are drumming it into me
> every day... I can SEE the need for flexibility in system design and
> implementation.[/color]

Sure, but you practically argue that this will replace software engineering.
[color=blue]
> Thank goodness there are tools and systems that are addressing this need.
> (Client/Server, distributed networks, OOD and OOP are all paradigms that
> are much more flexible than the traditional mainframe Waterfall
> methodology, and coincidentally, none of them is tied to Procedural
> Coding...)[/color]

We'll see. I consider OOP to be procedural programming too btw.
[color=blue]
> My figures are based on a real case. The Company concerned sold their IT and
> leased it back. They did this when they had a bad year due to claims for
> floods and droughts.[/color]

That's organisational detail.
[color=blue]
> It is interesting that in the "good" years they took no
> action. Try telling a Board of Directors faced with a huge cash flow
> requirement, that "Price is not the only point of competition". Even if
> you're right (and I don't disagree with the statement) you will not help
> your career...[/color]

Mine is practice too, everytime I argue on price, they come with "support"
(which they never use, and won't get), "security" (better large than
small company) etc.
[color=blue]
> award, with[color=green]
>> "don't panic" in nice friendly letters.[/color]
>
> Well, I always enjoyed the Hitchhikers Guide to the Galaxy, but I have never
> been a troll. You have no idea who you are dealing with <G>.[/color]

One of the joys of usenet:-)

[jce]

Re: Future reuse of code

"Marco van de Voort" <marcov@stack.n l> wrote in message
news:slrnbjico8 .dqv.marcov@toa d.stack.nl...[color=blue]
> In article <3f3908a5_6@new s.athenanews.co m>, Peter E.C. Dashwood wrote:[color=green][color=darkred]
> >>[/color]
> > Well, Marco, I wonder how long it is since you looked?[/color]
> Well, I think I went to work today.[/color]
Did you ask people whether "sequential jobs are a way of thinking that is
normal to them" or are you telepathic too?
[color=blue]
> But I would never claim that such a thing could be generalized and replace
> software engineering. They are problem-domain specific solutions, nothing
> more.[/color]
Maybe not software engineering as it evolves...but as it exists now and in
parts, probably. Software will be around for a while...so there will be
software engineers.....b ut I was told my grandfather kept saying "machines
will build cars....humbug! ".
[color=blue]
> Within very simple, limited borders. There is not one such tool that
> replaces general programming (regardless of which paradigm you use)[/color]
But it will replace large sections of general programming.... in every
paradigm. I haven't written a math library recently.....I don't write gui
components much ...I don't write messaging software...I don't even have to
write my own storage/retrieval system...but I thought we were talking about
Software Engineering which is not exactly programming is it.
[color=blue][color=green]
> > Currently, tools like this are in their infancy. In 15 years we can[/color][/color]
expect[color=blue][color=green]
> > significant improvement.[/color][/color]
In 1903 they flew for the first time...in 1969 came the 747 and we are still
using the 747....Time brings improvement but it's only grows with demand or
reward in the risk-reward stakes. If there is no reward then no one will do
anything. The world is littered with tools - there are tens of commercial
vendors with profiling, generating, visual assistance and yet not one of
them lets you get by without understanding what it is you are doing...many
are listed as pre-reqs for jobs because they aren't just <pick em up and use
em>.
Without uniform acceptance tools will improve but not replace software
skills. The skills may evolve and get better tuned or apt to deal with new
products - be faster, more flexible.....My car is essentially a souped up
model-T ;-)
[color=blue][color=green]
> > The computer skills of the Business are rising very rapidly.[/color][/color]
I believe in the escalator principle...
Tools get developed to replace complex manual type function......
Those doing the manual function are replaced with the more technical
developers to setup the automated process.
Tools get developed to replace the complex automated type setup with a neat
gui tool
Those setting up the complex automated type function are replaced by the gui
experts who had special training....
ad infinitum...

The people at the bottom get off....the higher paid get on the top and ride
down...
The key is to make the journey last until you're 55.
[color=blue][color=green][color=darkred]
> >> Yes, they want smug buzzword talking con-men to take advantage of them[/color][/color][/color]
?[color=blue][color=green]
> > No, they're getting pretty wise to that one too...in fact, most of us[/color][/color]
are.[color=blue]
> If that were the case, I wouldn't get +/- 50-100 spams a day.[/color]
And you read them? or are you pretty wise to that one and delete them?
[color=blue][color=green]
> > The last place I worked (a major utility in the Midlands of England)[/color][/color]
there[color=blue][color=green]
> > were more people in the Business with Computer Science degrees, than I[/color][/color]
had[color=blue][color=green]
> > on my IT staff.[/color][/color]
The escalator already started there then ....

[color=blue]
> While I think in retrospect that my tone might have been misplaced,
> your second post confirmed my suspicious. You have a firm believe in
> something, and really want to advocate that. However I don't find
> much evidence, not even shallow ones.[/color]
I don't find much in the way of evidence that you've presented *against* it
either.
The idea of a generalized tool is way out there (2015 isn't that long).
There are sure to be major inroads into large chunks of the IT industry. If
people latch onto a successful tool and it gains support then it could be
looked at in other areas. It depends on how the rich would benefit.
[color=blue]
> I've been on news for over a decade now. And on Fidonet before that. While
> trolling and wild speculation presented as "truth" might seem innocent to
> you, it doesn't to me. It poisons a group, and creates an unequal position
> for discussion.[/color]
I don't see the Troll here. He provides way too much useful input to groups
to be a "troll". When you crosspost you get to get input from all the
groups...most people are too busy being useful contributors in *all* groups.
[color=blue]
> The problem is that you don't have to justify yourself in 15 years if you
> are totally wrong, like you would in a company. It is nearly anonymous,[/color]
easy[color=blue]
> and safe, yet it still does damage.[/color]
What damage does it do? More or less than off shoring...more or less than
war...more or less than enron...more or less than pension decreases...mor e
or less than the rising cost of insurance...mor e or less than the wealthy
become more so.....It's an opinion he has..Let him share it. It's
interesting...w e can discuss it and decide for ourselves if it's crap. I
don't need you to protect me from anything.
[color=blue]
> As said before Maybe I was to harsh, yet I still stand behind the original
> intentions behind that message.[/color]
Just be nicer about it...else you get *plonked* and no one hears you then.
Your perfectly valid and salient points become valid and silent.
[color=blue][color=green]
> > Could you be a little sensitive to the truth of what I'm saying?[/color]
> Please don't degrade to amateur psychology. It's seriously flawed enough
> already.[/color]
He's not degrading to amateur psychology..he' s telepathic remember...:-)
[color=blue][color=green]
> > The typical response of the student.[/color]
> Again a belittling comment. Try to argue with something more substantial
> arguments.[/color]
You started it....ha ha
[color=blue][color=green]
> > Are you saying that, without a
> > reference, you would question whether there is an accelerating rate of
> > change in computer technology?[/color]
> No. I question if it goes in the direction that you say it is. So not
> IF there will be change, just if it is going to be the change you[/color]
proclaim.
Ok - so your defense is that nothing has worked before? What if we put the
date to 2050...does that change anything? The only major flaw I see in his
argument is (a) the scale with which Peter sees this occurring - ubiquitous
and (b) the time frame....I have no evidence or justification for this
position.
[color=blue][color=green]
> > As for my knowledge of the Market place, I have worked in industry IT
> > services all my life. It is axiomatic to me that the Business needs are
> > accelerating and greater flexibility in response to changing and new
> > Markets is required in IT today than was the case even 5 years ago. I
> > don't need a text book to tell me this; my users are drumming it into me
> > every day... I can SEE the need for flexibility in system design and
> > implementation.[/color]
> Sure, but you practically argue that this will replace software[/color]
engineering.
It will replace LARGE aspects of software engineering.... the need for PMs,
the RA role will change, therefore the SE position will have to go with it
and most of the tasks will be automated.
[color=blue]
> Mine is practice too, everytime I argue on price, they come with "support"
> (which they never use, and won't get), "security" (better large than
> small company) etc.[/color]
That's organizational detail ;-)

JCE

[Peter E.C. Dashwood]

Re: Future reuse of code

Marco,

a good and fair response.

You have me down as a "believer"; I'm not. Neither am I trying to evangelise
ONE point of view.
(Been in this game to long...seen it all come and go...however, that does
not blind me to emerging trends and the fact that there is no requirement
for the future to be exactly like the past; because something failed in the
past doesn't mean it will not succeed the next time someone tries it (with
more knowledge and experience)).

I really don't mind if people disagree with what I'm saying. (At worst, the
ideas presented will have made them think; at best, they will have enjoyed
my post.)

But I am capable of extrapolating from observation and I have a track record
of being fairly right about it.

My comments are sincere but they are intended to stimulate, not to wound.
And if I am wrong at the end of the day, then I'll be embarrassed and glad
about it.

I am not seeking to "poison" this or any other group. The free exchange of
ideas (even where it is from "Trolls" who are seeking simply to "stir"
things) can only be beneficial to groups of people who have the intelligence
and vision to recognise what is important, and are capable of making their
own judgements on what is posted.

Unfortuately, the reasoning and observation behind my arguments is more
lengthy than can easily be accommodated in this particular forum. Also, my
comments are confined to commercial computer programming and not other
specialised areas of cyber development.(Li ke Chemical Engineering...< G>)

I had a look at your web site and see you are a proponent of Delphi and
PASCAL. (Both excellent languages and I have programmed in both of them,
although not extensively.) I guess this explains your reaction to my post.
It is not a comforting thought that the Languages we love have a limited
commercial lifetime, but that should not blind us to what is happening in
the Marketplace. (There are many COBOL programmers who are dismayed and
bewildered as they see the erosion of their traditional power base, too. My
advice has been to extend their skill set, but perhaps I should have said:
"Get an Accountancy or Business Management qualification.. .".)

The fact is that there are forces at work in the Marketplace that are
driving the "traditiona l" methods of developing commercial computer systems
into the ground. The Market wants computing "de-skilled" to the point where
end users can get the results they need without necessity for detailed
technical expertise. (My bet is that they will get it...). The Business
Functionality and the ability to support it in a rapidly changing
environment are paramount. Tools and Methods are emerging that have the
capability to deliver this within a reasonable (say, 15 years...) timeframe.

I respect your right to disagree, but I maintain my position.

Pete.

TOP POST - nothing further below here.

"Marco van de Voort" <marcov@stack.n l> wrote in message
news:slrnbjico8 .dqv.marcov@toa d.stack.nl...[color=blue]
> In article <3f3908a5_6@new s.athenanews.co m>, Peter E.C. Dashwood wrote:[color=green][color=darkred]
> >>
> >> On the contrary, specially for these kinds of users, sequential jobs[/color][/color][/color]
are a[color=blue][color=green][color=darkred]
> >> way of thinking that is normal to them.
> >>[/color]
> >
> > Well, Marco, I wonder how long it is since you looked?[/color]
>
> Well, I think I went to work today.
>[color=green]
> > Software tools are already emerging that substitute iteration and
> > interaction for sequential processes.[/color]
>
> Sure, for certain limited domains, the actual engineering is done,
> and there is a nice tool to customize that in several ways.
>
> Useful? Certainly. Timesaver? sure. Potential to be universal? No way.
>[color=green]
> > SQL Server for example has a "drag and drop" tool that allows processing
> > streams to be built in minutes.[/color]
>
> I've used laboratory controlling software which was nice in a lot of ways
> too. It was truely useful, productive and IMHO the most important,
> it avoided a lot of errors.
>
> But I would never claim that such a thing could be generalized and replace
> software engineering. They are problem-domain specific solutions, nothing
> more.
>[color=green]
> > These same streams using procedural code would take days.[/color]
>
> Sure. But that doesn't spell the end of procedural programming.
>[color=green]
> > What's more, if you get it wrong you can simply go to a graphic[/color][/color]
interface[color=blue][color=green]
> > and change it.[/color]
>
> I do that with sequential programming (Delphi) too. Tools for a specific
> domain. It saves time (and equally important) makes the product somewhat
> easier to maintain.
>[color=green]
> > I have seen at least one Graphic design package that uses a
> > similar principle. Non computer literate designers can easily manipulate
> > these tools, interact with them, iterate their processes, until they
> > achieve what they want.[/color]
>
> Within very simple, limited borders. There is not one such tool that
> replaces general programming (regardless of which paradigm you use)
>[color=green]
> > Programming knowledge is NOT a requirement.[/color]
>
> It is. Those environments are extended using normal programming, tackling
> large projects still needs skill.
>
> Those tools are just that, extra tools. Pretty comparable to fancy
> runtime (and later classes-) libraries. None of them spelled the end
> of programming either.
>
> Hmm, I think that is a good description. Some extra tools to aid software
> development, and allow a _user_ some customization.
>[color=green]
> > Currently, tools like this are in their infancy. In 15 years we can[/color][/color]
expect[color=blue][color=green]
> > significant improvement.[/color]
>
> Well. Then exactly this is our point of disagreement. Please explain
> why you think (and how do you envision that will happen) how you get
> from domain-specific solutions (math,laborator y handling, db handling)
> to general purpose programming.
>
> This is also what annoyed me about your previous message. It is a message
> of a believer. There is no reasoning behind it. You only "get" it when
> you are a believer.
>[color=green][color=darkred]
> >> increased also. I sometimes doubt if increased computer literacy[/color][/color][/color]
actually[color=blue][color=green]
> > kept[color=darkred]
> >> up with the added computer tasks for the avg person.
> >>[/color]
> >
> > The computer skills of the Business are rising very rapidly.[/color]
>
> IT skills in using their own applications. Not in programming and
> customization. In that department it got worse, especially in companies[/color]
with[color=blue]
> highly skilled (non-IT) technical people.
>
> In the old days any beta-sciences student or graduate could do some
> general purpose programming, usually they learned it so they could
> program calculations. Nowadays they use mathlab, which is
> absolutely great, but combined with faster machines requires less
> programming skill to achieve the same result.
> Which is good for them, but not for the level of programming knowledge
> in a company.
>[color=green][color=darkred]
> >> Yes, they want smug buzzword talking con-men to take advantage of them[/color][/color][/color]
?[color=blue][color=green][color=darkred]
> >>[/color]
> > No, they're getting pretty wise to that one too...in fact, most of us[/color][/color]
are.[color=blue]
>
> If that were the case, I wouldn't get +/- 50-100 spams a day.
>[color=green][color=darkred]
> >>
> >> Exactly. So as long as my solution is good, and I can justify using a[/color]
> > language,[color=darkred]
> >> waht is the problem.
> >>[/color]
> > It isn't enough just to provide a solution; it has to be an acceptable
> > solution.[/color]
>[color=green]
> > That means using tools and methods the users are comfortable with.[/color]
>
> I don't see why that would be the case? Its like a car mechanic who has[/color]
to[color=blue]
> fix a car with the tools an average person has in his house.
>[color=green]
> > In 15 years they WON'T be comfortable with some old academic cobbling[/color][/color]
code[color=blue][color=green]
> > together for a solution... By then they will have bypassed the need for
> > coding and will be implementing their own solutions.[/color]
>
> Amen:-) Still a little thin on reasons though.
>[color=green]
> > That was the whole point of my argument. They are doing it already...[/color][/color]
More[color=blue][color=green]
> > and more Business departments are gaining enough computer literacy to
> > build their own systems using standard solutions like spreadsheets and
> > databases.[/color]
>
> That kind of limited hobbying always has happened.
>[color=green]
> > The last place I worked (a major utility in the Midlands of England)[/color][/color]
there[color=blue][color=green]
> > were more people in the Business with Computer Science degrees, than I[/color][/color]
had[color=blue][color=green]
> > on my IT staff.[/color]
>
> Hmm. My former employer, which was IT related, had more chemists[/color]
(including[color=blue]
> me) than people with CS degrees.
>[color=green]
> >
> > There is no problem. I never suggested there was one. You can go ahead[/color][/color]
and[color=blue][color=green]
> > use procedural code for the rest of your natural life. (I intend to...).[/color][/color]
You[color=blue][color=green]
> > just won't make a lot of money at it. It'll become a "cottage industry"[/color][/color]
by[color=blue][color=green]
> > 2020...<G>[/color]
>
> A well. We have religious freedom :-)
>[color=green][color=darkred]
> >> > software until they get what they want.
> >>
> >> Sure. The telepathic kinds.[/color]
> >
> > The process of iteration, as you would know if you had ever worked in a[/color][/color]
RAD[color=blue][color=green]
> > environment, does not require telepathy.[/color]
>
> Very interesting. Why wouldn't I've worked in a RAD environment? Telepathy
> again?
>[color=green]
> > Your scorn is misplaced. Interaction and iteration enable HUMAN[/color][/color]
intelligence[color=blue][color=green]
> > to get in the loop, but does NOT require specific technical (i.e.
> > programming) skill.[/color]
>
> While I think in retrospect that my tone might have been misplaced,
> your second post confirmed my suspicious. You have a firm believe in
> something, and really want to advocate that. However I don't find
> much evidence, not even shallow ones.
>
> Except maybe that one story of a business department full of people
> with CS degree's. Now that's surprising that they were more likely
> to get something working using minimal and standard tools :-)
>[color=green][color=darkred]
> >> Programming is what requires the skill. Not the language. If you[/color][/color][/color]
studied[color=blue][color=green]
> > programming[color=darkred]
> >> closer, you'd know that.[/color]
> >
> > LOL! While I note that you are at a very reputable University[/color][/color]
(apparently[color=blue][color=green]
> > learning to use procedural code...)[/color]
>
> I'm still honorary member of my former universities computer club.
>[color=green]
> > I can assure you I have studied programming for the whole of my working
> > life (some 38 years - I started programming computers in 1965
> > What were YOU doing then <G>?) not behind
> > cloisters but in the real world.[/color]
>[color=green]
> > Leaving aside your intended slight, I agree
> > that programming does require skill, but it was you who turned my[/color][/color]
statement[color=blue][color=green]
> > into a separation between programming as a skill and programming as an[/color][/color]
art.[color=blue][color=green]
> > I said that "Procedural Coding" is in decline. That includes the[/color][/color]
Language[color=blue][color=green]
> > and the Art...[/color]
>
> Yet, except a firm believe that ordinary users with a few standarised
> tools will replace them, you don't reveal much reasons.
>[color=green]
> > I wonder why your response is so vitriolic?
> >I didn't set out to attack you.[/color]
>
> I've been on news for over a decade now. And on Fidonet before that. While
> trolling and wild speculation presented as "truth" might seem innocent to
> you, it doesn't to me. It poisons a group, and creates an unequal position
> for discussion.
>
> The problem is that you don't have to justify yourself in 15 years if you
> are totally wrong, like you would in a company. It is nearly anonymous,[/color]
easy[color=blue]
> and safe, yet it still does damage.
>
> (and btw, keep in mind nearly medium-longterm IT forecasts have been wrong
> till now)
>
> As said before Maybe I was to harsh, yet I still stand behind the original
> intentions behind that message.
>[color=green]
> > Could you be a little sensitive to the truth of what I'm saying?[/color]
>
> Please don't degrade to amateur psychology. It's seriously flawed enough
> already.
>[color=green][color=darkred]
> >> And where are you references for that. You don't even say what it is up
> >> against, except some vague references about software which is going to
> >> emerge as a winner in 2015 (and which I assume is telepathic, at least[/color][/color][/color]
if[color=blue][color=green]
> > I[color=darkred]
> >> see your description)
> >>[/color]
> > The typical response of the student.[/color]
>
> Again a belittling comment. Try to argue with something more substantial
> arguments.
>[color=green]
> > Are you saying that, without a
> > reference, you would question whether there is an accelerating rate of
> > change in computer technology?[/color]
>
> No. I question if it goes in the direction that you say it is. So not
> IF there will be change, just if it is going to be the change you[/color]
proclaim.[color=blue]
>[color=green]
> > OK, Alvin Toffler, Moore's Law, and the fact that I have to get a new
> > computer every 18 months...[/color]
>
> Relates to programming how?
>[color=green]
> > As for my knowledge of the Market place, I have worked in industry IT
> > services all my life. It is axiomatic to me that the Business needs are
> > accelerating and greater flexibility in response to changing and new
> > Markets is required in IT today than was the case even 5 years ago. I
> > don't need a text book to tell me this; my users are drumming it into me
> > every day... I can SEE the need for flexibility in system design and
> > implementation.[/color]
>
> Sure, but you practically argue that this will replace software[/color]
engineering.[color=blue]
>[color=green]
> > Thank goodness there are tools and systems that are addressing this[/color][/color]
need.[color=blue][color=green]
> > (Client/Server, distributed networks, OOD and OOP are all paradigms that
> > are much more flexible than the traditional mainframe Waterfall
> > methodology, and coincidentally, none of them is tied to Procedural
> > Coding...)[/color]
>
> We'll see. I consider OOP to be procedural programming too btw.
>[color=green]
> > My figures are based on a real case. The Company concerned sold their IT[/color][/color]
and[color=blue][color=green]
> > leased it back. They did this when they had a bad year due to claims for
> > floods and droughts.[/color]
>
> That's organisational detail.
>[color=green]
> > It is interesting that in the "good" years they took no
> > action. Try telling a Board of Directors faced with a huge cash flow
> > requirement, that "Price is not the only point of competition". Even if
> > you're right (and I don't disagree with the statement) you will not help
> > your career...[/color]
>
> Mine is practice too, everytime I argue on price, they come with "support"
> (which they never use, and won't get), "security" (better large than
> small company) etc.
>[color=green]
> > award, with[color=darkred]
> >> "don't panic" in nice friendly letters.[/color]
> >
> > Well, I always enjoyed the Hitchhikers Guide to the Galaxy, but I have[/color][/color]
never[color=blue][color=green]
> > been a troll. You have no idea who you are dealing with <G>.[/color]
>
> One of the joys of usenet:-)[/color]

[Thomas A. Li]

Re: Future reuse of code

Don't forget Java reflection. It is possible to pull out function/method
signature from binary.
Java and C# include reflection and therefore make them self-contained.
Both Java and C# binary file are targeted for virtual machine.

I think for reuse of code, OO based Java or C# code will be the first
option.

Thomas



"Roedy Green" <roedy@mindprod .com> wrote in message
news:luiriv8e90 7s59abtkoqjt7sc 016am9nve@4ax.c om...[color=blue]
> On 3 Aug 2003 19:02:14 -0700, james.cameron@b indereng.com.au (James
> Cameron) wrote or quoted :
>[color=green]
> > I suspect something like C would be the best based
> >on comments[/color]
>
> C is already disappearing. For longevity you want to pick something
> that is popular, and that is rising in popularity.
>
> Java is a pretty safe bet. Even if it dies the code is quite vanilla
> and should be easy to port to whatever replaces it.
>
> --
> Canadian Mind Products, Roedy Green.
> Coaching, problem solving, economical contract programming.
> See http://mindprod.com/jgloss/jgloss.html for The Java Glossary.[/color]

[Georgie]

Re: Future reuse of code

> The fact is that there are forces at work in the Marketplace that are[color=blue]
> driving the "traditiona l" methods of developing commercial computer[/color]
systems[color=blue]
> into the ground. The Market wants computing "de-skilled" to the point[/color]
where[color=blue]
> end users can get the results they need without necessity for detailed
> technical expertise. (My bet is that they will get it...). The Business
> Functionality and the ability to support it in a rapidly changing
> environment are paramount. Tools and Methods are emerging that have the
> capability to deliver this within a reasonable (say, 15 years...)[/color]
timeframe.[color=blue]
>
> I respect your right to disagree, but I maintain my position.
>
> Pete.
>[/color]
I agree those market forces are busy. But being quiet new in the traditional
Mainframe Cobol, SE business (6 years) and also programming in VB.NET(1
year). I believe that to achieve that goal will be very difficult. It means
users will need to be skilled at their usual job and also able to configure
their IT tools. I've worked in seven companies and I can't imagine them
doing that now. Perhaps in 15 years but it'll require a new approach on
training.
Btw, I've got that accountancy and business degree and moved on to IT (my
hobby since the days of the C64 and the Amiga). My last projects were not
maintenance and/or change projects, but completely new applications
developed in COBOL II running under CICS. The one I'm applying for within 2
hours is also completely new. The company is a world leader in it's
business.

Georgie.

[Peter E.C. Dashwood]

Re: Future reuse of code


"Georgie" <kriweed@yahoo. com> wrote in message
news:3f3a0ee2$0 $282$ba620e4c@r eader0.news.sky net.be...[color=blue][color=green]
> > The fact is that there are forces at work in the Marketplace that are
> > driving the "traditiona l" methods of developing commercial computer[/color]
> systems[color=green]
> > into the ground. The Market wants computing "de-skilled" to the point[/color]
> where[color=green]
> > end users can get the results they need without necessity for detailed
> > technical expertise. (My bet is that they will get it...). The Business
> > Functionality and the ability to support it in a rapidly changing
> > environment are paramount. Tools and Methods are emerging that have the
> > capability to deliver this within a reasonable (say, 15 years...)[/color]
> timeframe.[color=green]
> >
> > I respect your right to disagree, but I maintain my position.
> >
> > Pete.
> >[/color]
> I agree those market forces are busy. But being quiet new in the[/color]
traditional[color=blue]
> Mainframe Cobol, SE business (6 years) and also programming in VB.NET(1
> year). I believe that to achieve that goal will be very difficult.[/color]

Yes, it will. However, we have been working on it for nearly 50 years now...

(The fundamental goal of commercial computing has been to have computers
that are capable of "understand ing" Business needs and meeting them, in a
manner that would enable a Business User (or Users) to identify and design
the system and "explain" what is needed to the computer, in as simple a
manner as possible, without need for in depth technical skills. It is
interesting to me that COBOL was one of the first attempts to achieve this,
with the Conference on Data Systems Languages in 1959 even foregoing
commercial advantage on the part of some of the contributors, for the
greater good of the Business community. This is why it rankles me so much
that the Language has since been hijacked by ANSI for commercial gain,
despite the protestations that this is a non-profit organization... Don't
start me...<G>)

There are indications that it CAN be achieved. However, you are correct that
it will be difficult and many Mainframe COBOL sites will be dragged kicking
and screaming into it (or will find themselves outsourced to India...) We
had some interesting threads recently in comp.lang.cobol where the reasons
for what I call "Fortress COBOL" were explored. Adoption of new technology
is probably hardest on the mainframe sites, where there is a very long
tradition of doing things a certain way. (The fact that this way has NEVER
worked satisfactorily, has left Users disappointed and disheartened with IT,
and that there are now better ways, seems to be lost on some IT
departments...)

If you would like to see the background for my thoughts on this please take
this link:

https://www.aboutlegacycoding.com/Archives/V3/V30501.asp

[color=blue]
>It means
> users will need to be skilled at their usual job and also able to[/color]
configure[color=blue]
> their IT tools.[/color]

Well, I see it as our job (as IT professionals) to make sure the tools are
so user friendly, the Users can concentrate on their usual job without
having to become "computer programmers" (It would not be possible for the
expanding User base to all become computer programmers anyway, even if they
had the inclination to, which they don't...)

I guess what I'm saying is that if we do our job properly, we won't have a
job in 15 years...<G>

Actually, the nature of our work will change so that it isn't strictly
true, but the elements of truth are there...

[color=blue]
> I've worked in seven companies and I can't imagine them
> doing that now. Perhaps in 15 years but it'll require a new approach on
> training.[/color]

Yes, absolutely. There are some very innovative approaches on training and
self-education in the pipeline. The advent of technologies like DVD and the
interactive extensions of it will certainly change auto-education.
[color=blue]
> Btw, I've got that accountancy and business degree and moved on to IT (my
> hobby since the days of the C64 and the Amiga). My last projects were not
> maintenance and/or change projects, but completely new applications
> developed in COBOL II running under CICS. The one I'm applying for within[/color]
2[color=blue]
> hours is also completely new. The company is a world leader in it's
> business.
>[/color]
Glad to hear you are productively employed and enjoying it, George. Hope it
stays that way for you. It looks like you have a "fall back" position
already established if it comes to it. A wise move...

Pete.

[docdwarf@panix.com]

Re: Future reuse of code

In article <3f3a398d_5@new s.athenanews.co m>,
Peter E.C. Dashwood <dashwood@enter net.co.nz> wrote:

[snip]
[color=blue]
>(The fundamental goal of commercial computing has been to have computers
>that are capable of "understand ing" Business needs and meeting them, in a
>manner that would enable a Business User (or Users) to identify and design
>the system and "explain" what is needed to the computer, in as simple a
>manner as possible, without need for in depth technical skills.[/color]

This, to me, screams for the implementation for the DWIM (Do What I Mean)
command.

DD

[Jirka Klaue]

Re: Future reuse of code

docdwarf@panix. com wrote:[color=blue]
> In article <3f3a398d_5@new s.athenanews.co m>,
> Peter E.C. Dashwood <dashwood@enter net.co.nz> wrote:
>
> [snip]
>[color=green]
>>(The fundamental goal of commercial computing has been to have computers
>>that are capable of "understand ing" Business needs and meeting them, in a
>>manner that would enable a Business User (or Users) to identify and design
>>the system and "explain" what is needed to the computer, in as simple a
>>manner as possible, without need for in depth technical skills.[/color]
>
> This, to me, screams for the implementation for the DWIM (Do What I Mean)
> command.[/color]

And this immediately leads to the need of the DWI_S_M command. :-)

Jirka