Future reuse of code

[jce]

Re: Future reuse of code

"Peter E.C. Dashwood" <dashwood@enter net.co.nz> wrote in message
news:3f3abf9b_1 @news.athenanew s.com...[color=blue]
> It is normal and natural for programmers to see things from a programming
> perspective.
>
> What I am suggesting is bigger than that.
> I foresee a time when there will be no need for the "lower level"
> programming you are talking about, Bill.[/color]
What is a "lower level" programmer. The boundaries will shift but there
will still always be the lower level...maybe it's not a bit and byte
programmer but a trainer. It's still a form of programming. Even in a
sophisticated piece of adaptive software someone would have to provide the
learning environment - initially, until that role gets replaced and we move
along the escalator again. I still see this as a role of a "programmer "
more than an "end user" - though the lines may become blurry.
[color=blue]
> The job of building the tools will be complete. And "smart software" will[/color]
do[color=blue]
> the enhancements to it.[/color]
Don't forget the cost factor. It's still cheaper to pay a labourer 80c a
day to strip bark from wood for 10 hours than it is to maintain the
machinery to do it. Money will be the determining factor of what will and
won't happen - and soon after the class struggle. I assume the same to be
more true in IT - it already is happening....fr ee overtime is cheaper than a
good toolset.
[color=blue]
> There are already specialised tools and wizards to do specific jobs.
> (Network management, for instance). Programmers are not redeveloping these
> tools; you could argue that they are "complete". They work and do the job
> they are designed for. In fact, it would not be desirable to have
> programmers "fiddling" with them.[/color]

Will the same TCP/IP still be used used in 15 years? Can we still use the
same network management tools when routers are obsolete, switches aren't
what they used to be.

Hardware *still* drives software. Plug n Play never saved the day....I
don't see tools fixing themselves to work with the hardware unless there is
another operating environment layer...made by...

Another important thing you don't consider is the power of the hobbyist and
the yearning that some people have to do things.
People could all drive automatic cars. But they still opt for manual.
People could ride in buses that drop them off at the exact destination, but
people like to drive and do. The business world isn't shielded from this.
Success of tools is still dependent on their usage. Unless people all jump
high onto a new set I think 15 years is too short for anything dominant to
come along and shape the IT world you envision. Linux didn't happen because
of Redhat or IBM but because of the underlying support from regular workers.
[color=blue]
> I only have one lifetime and I cannot be an expert in everything. Sooner[/color]
or[color=blue]
> later it is necessary to trust someone else's experience.
> Your assumption that there will ALWAYS be a requirement for "low level"
> programmers to keep maintaining tools is, at best, arguable, at worst,[/color]
just[color=blue]
> dead wrong.[/color]
Not talking for Bill....maybe your view of "low level" is too narrow ;-)
[color=blue]
> Smart software will take on this role. Even if it isn't
> "intelligen t", this lack can be compensated for by keeping Humans in the
> loop. These Humans will be end Users, not technicians.[/color]
What happens when the end User cannot get the results he wants...who's he
gonna call?

User: "Give me X"..
I can give you a kinda X
User: "Give me X"
I can give you a kinda X
User: "Give me X"
I can give you a kinda X
User: "Hey tech geek..can you get this thing to give me X?"
User: "Hey, where'd you go....hey tech geek...."
User: "Hellooo?.. is anyone there...."
I can give you a kinda X, you still want it?

If I had to guess....Bill is too narrow and you're too wide....we'll get
something in between I'm sure (in 15 years!)

Last post on the matter - though I will no doubt keep reading :-)

JCE

btw: I hope you're a little wrong...because I still got to ride this out for
another few decades whilst you are relaxing on the shore somewhere.

[Stephane Richard]

Re: Future reuse of code

Are you saying that in 20 years, a programmer wont have the tools to make
his own programming language, his own OS should he or she decide to? And
they call that progress? I call it going backwards here. If this is what
I'm gonna face in 20 years, I'll be making endless copies of DOS Linux and
maybe OS/2 so that I have the choice to do what I want. (note that I didn't
mention Windows ;-)

Here's my view of things, from my point of view, so you can't sue me for
saying this...hehehe.

We haven't even begun to touch the tip of the iceburg into what we can do as
far as software development goes. And while microsoft seems to be amazed by
it's Windows, Where it's been, where it is now, and where's it's going to
be, since about 3 to 4 thousand programmers went into the making of Windows,
I'm not impressed by those results. This having been said, So far, all
we've done for all these decades, is make the computer do that we dont want
to do. (Hefty calculations, any repetitive tasks, games (not for the same
reasons of course :-). But we haven't even begun to tap into the potential
that's ahead of us.

To me What you are suggesting is that we let the others come up with the new
stuff, give the users the ability adjust/change what the user did through
the use of somewhat flexible modules, and that's it for the programmer? I'm
thinking much longer term than that. After this step of yours happens, do
you really think that everything will have been made that can be made in the
whole computer industry? I beg to differ, as this approach the the future
of computing is one of many thousands of avenues, and I'm not saying there's
only that way out of it, even if this ever gets made, it wont close the door
to the rest of the potentials that still are, to date, untouched.

But that's my vision of it, once your implementation exists and is stable,
do you think the users, ever so evolving as you say (which I do have to
agree that they are) will stay contended with this? that they wont want
more? Give a man an inch, he'll take foot, etc etc etc....I dont seen that
human behavior stopping anytime soon. To stop that human behavior, we might
as well stop populating since after 5 billion people we can safely assume
we've conceived every possible kind of human being? not at all :-). far
from it. And the same goes for programming. Your view is one of many
parralel views, views that will all equally evolve, each in their own
specific ways, each towards very specific and unique goals. And as long as
they are computers, there will be programmers. And programming languages
that will range from low level to high level. The way Pascal is adjusting
to the current reality of development, I dont fear that it can adapt to any
new programming concept we can throw at it. It's been doign great at
adapting thus far.

Remember, software development is not a user only oriented concept. :-) at
least not in my book.

And that's my 0.02 cents worth :-)....(ok maybe there's a couple dollars in
there instead :-).



--
Stéphane Richard
Senior Software and Technology Supervisor

http://www.totalweb-inc.com

For all your hosting and related needs
"Peter E.C. Dashwood" <dashwood@enter net.co.nz> wrote in message
news:3f38cfd6_3 @news.athenanew s.com...[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[/color]
COBOL[color=blue]
> 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...)
>
> They are the number of people who access the internet every day. (For the
> sake of this argument, I'll call them the "user base"...) They are not[/color]
about[color=blue]
> to become "computer programmers". Instead, they will demand better
> interfaces, smarter software, and MUCH better ways of developing computer
> systems than sequential Von Neumann code. Most of them are "smarter" and
> more "computer literate" than their prdecessors of even 10 years ago. They
> are not intimidated by computer technology, will happily interact with[/color]
smart[color=blue]
> software to achieve a result, and are not prepared to rely on and wait[/color]
for,[color=blue]
> remote, faceless, technocrats to provide them with computer solutions to
> business problems.
>
> The Marketplace calls the shots.
>
> We may have our own favourite Languages and we can poddle away in a corner
> somewhere cutting code for the fun of it, but the real world demands that[/color]
it[color=blue]
> get solutions. By 2015 a new generation of development software will see
> "programmer s" removed from the loop and end users interacting and[/color]
iterating[color=blue]
> with smart software until they get what they want.
>
> History will show that "computer programming" was a phenomenon of the[/color]
latter[color=blue]
> half of the 20th Century. (OK, I'll concede a couple of decades of this
> Century, MAYBE, it is early days yet... <G>)
>
> Procedural code is already into Gotterdammerung . It takes too long,[/color]
requires[color=blue]
> 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.
>
> For the last 5 decades Commerce and Industry (Scientific computing is a
> horse of different colour, and is excluded from this discussion...) have[/color]
had[color=blue]
> to put up with it because there was no other alternative. Now they don't.
> The advent of packages that actually work, with re-usable components that
> enable them to be easily tailored and deployed across different platforms
> are making Corporate Board members query the amounts being spent on[/color]
in-house[color=blue]
> IT. As fast as they get people trained they either leave or need new
> skills... Why bother? Why should an Insurance company spend $50,000,000 a
> year on in house IT when they could buy the service for $10,000,000?[/color]
(Their[color=blue]
> Business is Insurance, not IT...expenditur e of the scale we have seen
> traditionally, can no longer be justified. You have to sell a lot of
> policies to make $40,000,000...)
>
> The only thing that COULD save procedural coding of solutions would be if
> it priced itself back into the market. This MIGHT happen with offshore
> outsourcing, but it is unlikely.
>
> Bottom Line: Don't get smug about COBOL dying and PASCAL surviving; they[/color]
are[color=blue]
> on the same parachute and the ground is coming up....
>
> Pete.
>
>[/color]

[Stephane Richard]

Re: Future reuse of code

Quoted: " SQL Server for example has a "drag and drop" tool that allows
processing streams to be built in minutes. These same streams using
procedural code would take days."

funny, me in 15 years, I dont see microsoft in the picture. ;-)

--
Stéphane Richard
Senior Software and Technology Supervisor

http://www.totalweb-inc.com

For all your hosting and related needs
"Peter E.C. Dashwood" <dashwood@enter net.co.nz> wrote in message
news:3f3908a5_6 @news.athenanew s.com...[color=blue]
>
> "Marco van de Voort" <marcov@toad.st ack.nl> wrote in message
> news:slrnbjhm1i .2gg0.marcov@to ad.stack.nl...[color=green]
> > In article <3f38cfd6_3@new s.athenanews.co m>, Peter E.C. Dashwood wrote:[color=darkred]
> > >
> > > "Dr Engelbert Buxbaum" <engelbert_buxb aum@hotmail.com > wrote in[/color][/color][/color]
message[color=blue][color=green][color=darkred]
> > > news:bha4np$9lm $00$1@news.t-online.com...
> > >> Paul Hsieh wrote:
> > >>
> > >>
> > >> > COBOL and Pascal (the other groups you crossposted this message to)
> > >> > will decrease in usage over time, not increase. There is[/color][/color][/color]
absolutely[color=blue][color=green][color=darkred]
> > >> > 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[/color][/color][/color]
kicking,[color=blue][color=green][color=darkred]
> > >> in the form of Delphi/Kylix. I am currently writing Kylix software,[/color][/color]
> most[color=green][color=darkred]
> > >> of the cutting edge routines (that do the real work rather than the[/color][/color]
> user[color=green][color=darkred]
> > >> interface) are straight plug-ins of 15 year old Turbo-Pascal code.[/color][/color][/color]
Now[color=blue][color=green][color=darkred]
> > >> with Borland going for cross-platform (Windozze/Unix) compatibility
> > >> there is no reason why Pascal should die in the foreseable future.
> > >
> > > There are 400,000,000 reasons why ALL procedural languages (including[/color][/color]
> COBOL[color=green][color=darkred]
> > > and PASCAL) should "die" in the not-too-distant future. (I don't know[/color][/color]
> your[color=green][color=darkred]
> > > definition of "foreseeabl e" but mine is around 20 years...)[/color]
> >
> > Really? Please name and discuss them.
> >[/color]
> <G> I'm sure you know some of them personally...
>[color=green][color=darkred]
> > > They are the number of people who access the internet every day. (For[/color][/color]
> the[color=green][color=darkred]
> > > sake of this argument, I'll call them the "user base"...) They are not[/color][/color]
> about[color=green][color=darkred]
> > > to become "computer programmers".[/color]
> >
> > Indeed.
> >[color=darkred]
> > > Instead, they will demand better interfaces, smarter software,[/color]
> >
> > True
> >[color=darkred]
> > > and MUCH better ways of developing computer systems than sequential[/color][/color][/color]
Von[color=blue][color=green][color=darkred]
> > > Neumann code.[/color]
> >
> > On the contrary, specially for these kinds of users, sequential jobs are[/color][/color]
a[color=blue][color=green]
> > way of thinking that is normal to them.
> >[/color]
>
> Well, Marco, I wonder how long it is since you looked? Software tools are
> already emerging that substitute iteration and interaction for sequential
> processes. SQL Server for example has a "drag and drop" tool that allows
> processing streams to be built in minutes. These same streams using
> procedural code would take days. What's more, if you get it wrong you can
> simply go to a graphic interface and change it. I have seen at least one
> Graphic design package that uses a similar principle. Non computer[/color]
literate[color=blue]
> designers can easily manipulate these tools, interact with them, iterate
> their processes, until they achieve what they want. Programming knowledge[/color]
is[color=blue]
> NOT a requirement. Currently, tools like this are in their infancy. In 15
> years we can expect significant improvement.
>
>[color=green][color=darkred]
> > > Most of them are "smarter" and more "computer literate" than their
> > > prdecessors of even 10 years ago.[/color]
> >
> > Yes. They are not scared anymore. OTOH the requirements on them have[/color]
> severly[color=green]
> > increased also. I sometimes doubt if increased computer literacy[/color][/color]
actually[color=blue]
> 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=green][color=darkred]
> > > They are not intimidated by computer technology, will happily interact
> > > with smart software to achieve a result, and are not prepared to rely[/color][/color][/color]
on[color=blue][color=green][color=darkred]
> > > and wait for, remote, faceless, technocrats to provide them with[/color][/color]
> computer[color=green][color=darkred]
> > > solutions to business problems.[/color]
> >
> > 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=green][color=darkred]
> > > We may have our own favourite Languages and we can poddle away in a[/color][/color]
> corner[color=green][color=darkred]
> > > somewhere cutting code for the fun of it, but the real world demands[/color][/color]
> that it[color=green][color=darkred]
> > > get solutions.[/color]
> >
> > 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. That means using tools and methods the users are comfortable[/color]
with.[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. 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[/color]
systems[color=blue]
> using standard solutions like spreadsheets and databases. 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]
My[color=blue]
> guys often hit problems incorporating user developed backyard systems into
> the corporate IT strategy. But it improved, and with some guidance from us
> they were doing pretty good stuff when I left in April.
>
> 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...).[/color]
You[color=blue]
> just won't make a lot of money at it. It'll become a "cottage industry" by
> 2020...<G> The "boom" was in the late 70s to the early 80s. We wrote our[/color]
own[color=blue]
> tickets. The advent of the PC and the dissemination of computer skill to
> "everyone" killed the Golden Goose. Personally, I'm glad to see computer
> technology being utilised and within the reach of most people, but I'd be
> stupid to pretend it hasn't hit my pocket.
>[color=green][color=darkred]
> > > By 2015 a new generation of development software will see[/color][/color][/color]
"programmer s"[color=blue][color=green][color=darkred]
> > > removed from the loop and end users interacting and iterating with[/color][/color][/color]
smart[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[/color]
RAD[color=blue]
> environment, does not require telepathy. It does require good[/color]
communication.[color=blue]
> Your scorn is misplaced. Interaction and iteration enable HUMAN[/color]
intelligence[color=blue]
> to get in the loop, but does NOT require specific technical (i.e.
> programming) skill.
>
>[color=green][color=darkred]
> > > Procedural code is already into Gotterdammerung .[/color]
> >
> >[color=darkred]
> > > It takes too long, requires too much skill,[/color]
> >
> > 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...), 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. Leaving aside your intended slight, I[/color]
agree[color=blue]
> that programming does require skill, but it was you who turned my[/color]
statement[color=blue]
> into a separation between programming as a skill and programming as an[/color]
art.[color=blue]
> I said that "Procedural Coding" is in decline. That includes the Language
> and the Art...
>
> I wonder why your response is so vitriolic? I didn't set out to attack[/color]
you.[color=blue]
> Could you be a little sensitive to the truth of what I'm saying?
>[color=green]
> >[color=darkred]
> > > is too inflexible (the accelerating rate of change in the Marketplace[/color][/color]
> and[color=green][color=darkred]
> > > in technology is another reason why it is doomed to extinction) and,
> > > overall, costs far too much.[/color]
> >
> > 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]
if[color=blue]
> I[color=green]
> > see your description)
> >[/color]
> The typical response of the student. Are you saying that, without a
> reference, you would question whether there is an accelerating rate of
> change in computer technology?
>
> OK, Alvin Toffler, Moore's Law, and the fact that I have to get a new
> computer every 18 months...
>
> 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[/color]
Markets[color=blue]
> 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]
Thank[color=blue]
> goodness there are tools and systems that are addressing this need.
> (Client/Server, distributed networks, OOD and OOP are all paradigms that[/color]
are[color=blue]
> much more flexible than the traditional mainframe Waterfall methodology,[/color]
and[color=blue]
> coincidentally, none of them is tied to Procedural Coding...)
>
>[color=green][color=darkred]
> > > skills... Why bother? Why should an Insurance company spend[/color][/color][/color]
$50,000,000[color=blue]
> a[color=green][color=darkred]
> > > year on in house IT when they could buy the service for $10,000,000?[/color]
> >
> > Ah, but could they, and with the same secondary securities? Price is not[/color]
> the only[color=green]
> > point of competition.[/color]
>
> My figures are based on a real case. The Company concerned sold their IT[/color]
and[color=blue]
> leased it back. They did this when they had a bad year due to claims for
> floods and droughts. It is interesting that in the "good" years they took[/color]
no[color=blue]
> 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=green]
> >[color=darkred]
> > > The only thing that COULD save procedural coding of solutions would[/color][/color][/color]
be[color=blue]
> if[color=green][color=darkred]
> > > it priced itself back into the market. This MIGHT happen with offshore
> > > outsourcing, but it is unlikely.
> > >
> > > Bottom Line: Don't get smug about COBOL dying and PASCAL surviving;[/color][/color][/color]
they[color=blue]
> are[color=green][color=darkred]
> > > on the same parachute and the ground is coming up....[/color]
> >
> > 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[/color]
never[color=blue]
> been a troll. You have no idea who you are dealing with <G>.
>
> Pete.
>
>[/color]

[Roedy Green]

Re: Future reuse of code

On 13 Aug 2003 09:22:24 -0700, ruse@webmail.co .za (goose) wrote or
quoted :
[color=blue]
>bottom line: code written in java runs on less platforms than code
>written in C.[/color]

Bottom line is the odds of a Java app running correctly without
modifications are much higher than a C program. C programs don't
nearly strictly enough specify the desired behaviour. To make code
that runs on many platforms you have to create a quite extensive set
of macros, one library for each platform.

Even the size of an int is not nailed down for heaven sake.

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

[James J. Gavan]

Re: Future reuse of code



Roedy Green wrote:
[color=blue]
> On 13 Aug 2003 09:22:24 -0700, ruse@webmail.co .za (goose) wrote or
> quoted :
>[color=green]
> >bottom line: code written in java runs on less platforms than code
> >written in C.[/color]
>
> Bottom line is the odds of a Java app running correctly without
> modifications are much higher than a C program. C programs don't
> nearly strictly enough specify the desired behaviour. To make code
> that runs on many platforms you have to create a quite extensive set
> of macros, one library for each platform.
>
> Even the size of an int is not nailed down for heaven sake.
>[/color]

Roedy,

Haven't been there but lived real close in Guildford at one stage -
reading you C and Java people, I feel like a Wimbledon spectator with my
head zinging from left to right as the opponents take a swipe at the
ball !

For the uninitiated it really is difficult to balance the truth between
your opposing camps. Is there anywhere, but anywhere, where the observer
can get a reasonably unbiased balanced view of pros and cons per
language ?

Of course I could suggest if you have a real problem, use OO COBOL <G>.

BTW - took a very quick look at your Java Glossary, and noted your
reference to lack of FIFO and LIFO in Java lists. Surely that can't be a
big deal, possibly cloning your own list class. Although
collections(lis ts) are included in both Fujitsu and Micro Focus versions
of OO COBOL - our J4 Standards Committee currently has collections as an
on-going topic at the moment. I doubt we'll finish up with a collection
specifically geared to FIFO/LIFO. I can handle it quite easily at
present from either an Ordered or SortedCollectio n :-

*>FIFO
move 1 to MyIndex
invoke MyCollection "at" using MyIndex returning anElement

*>LIFO
invoke MyCollection "size" returning lsSize
*> above gives total elements
*> then I can do either of the following :-

invoke MyCollection "at" using lsSize returning anElement
*> OR
move lsSize to MyIndex
invoke MyCollection "at" using MyIndex returning anElement

If you haven't got what you want - James Gosling's fault. (He was born
in Calgary).
Guess he should have checked the Smalltalk hierarchy more closely before
he sat down to re-invent the wheel <G>.

I might add I can invoke both C and Java, with COBOL classes written to
support invoking Java. I have no need at the moment as I have rich
support of collections and GUIs built into the product.

One comment that came up here in this thread early on was "Use the right
tools for the job", not necessarily those exact words, but a point made
often in the COBOL group. Somebody of course nodded sagely at this pearl
of wisdom. Not always, but more often than not, that phrase translates
to "Use the free or cheapest tools you can get to do the job". Can't
knock people for that attitude, but I do wish they would come on in an
'honest' mode.

"Using the right tool" - here's one that came up recently from Brazil
in my Tech Support group. "How can I emulate an on-line Help file where
you key in some characters and then the entry is highlighted in the
Listbox ?".

Quite naturally a support person suggested, "Go to this site
www.xxxxx.com and check out their OCX". I thought, "I betcha that's
possible in COBOL". It is. It was a piece of cake. Micro Focus has
values for Windows events, and it looked like some four were
possibilities. All I had to do was a quick test of the four to get the
one which would immediately trigger an event based on a single
keystroke.

Problem solved ! Having done that as an interest exercise, I can already
see where it can be RE-USED in real applications.

With so many COBOLers using old, effective and established (mainfrme)
compilers, without any OO, naturally there's a whole daffy of people who
automatically address problems through C or Java, or whatever.

Note, none of the above has anything to do with the proselytizing of
components by Pete. Dashwood - I'm talking about REALLY using OO COBOL !

Jimmy, Calgary AB

[goose]

Re: Future reuse of code

Bat Guano <bat.guano@talk 21dotcom> wrote in message news:<vjl1mqp4n 28d4f@corp.supe rnews.com>...[color=blue]
> goose wrote:[color=green]
> >
> > but java is only available for platforms that are big enough to run
> > it.
> >[/color]
>
> big like my mobile phone?[/color]

whats your point ? that java rnus on your mobile phone ?

<NEWS FLASH> C probably targets that too </NEWS FLASH>

and it also targets many that java does not run on ?

so what exactly *is* your point ? java runs on a *fraction*
of platforms that C targets.


does your mobile have under a K of ram ?

thought not

goose,
java code isn't as portable as C code.

[goose]

Re: Future reuse of code

Richard Plinston <riplin@Azonic. co.nz> wrote in message news:<bhebrr$k7 4$1@aklobs.kc.n et.nz>...[color=blue][color=green]
> > In article <vjl1mqp4n28d4f @corp.supernews .com>, Bat Guano wrote:[color=darkred]
> >> goose wrote:
> >>>
> >>> but java is only available for platforms that are big enough to run
> >>> it.[/color][/color]
>
> There is Waba which is a JVM for smaller machines such as Palm and CE PDAs.
> There is even a version for MS-DOS, one for GameBoy, and a version for TI
> Calculators.
>
> (see http://www.wabasoft.com )[/color]

you miss the point. not only does C also target all the platforms
that java does, it targets a whole lot more as well.

goose,
following the one true brace style :-)

[Roedy Green]

Re: Future reuse of code

On Thu, 14 Aug 2003 05:33:07 GMT, "James J. Gavan" <jjgavan@shaw.c a>
wrote or quoted :
[color=blue]
>
>Haven't been there but lived real close in Guildford at one stage -
>reading you C and Java people, I feel like a Wimbledon spectator with my
>head zinging from left to right as the opponents take a swipe at the
>ball ![/color]

If you want to write cross platform code in C++ you have to buy a
rather expensive cross platform library, something like Rogue Wave.
C++ or C out the box is far from being cross platform. What you can
do is write code that can be tweaked to run on another platform, or
you can create a set of macros to make the same code base run on one
or two platforms. However the C and C++ are not naturally
multiplatform. They are lower level languages. That is why they are
used for JNI when you want to get personal with the OS.

C is much more cross platform in the Unix world, but when you throw in
Windows and the Mac, you pretty well have to start from scratch. With
C and C++ you interface directly with the OS. With Java there is a
buffering layer of standard class libraries.

The language wars are for the most part kid nya nya games. You need
both C++ and Java for different things. There are not many places
where you would you would use pure C now instead of C++, perhaps a
device driver or some code to fit in an embedded device.

It is like arguing which is better a wrench or a screwdriver.



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

[goose]

Re: Future reuse of code

Roedy Green <roedy@mindprod .com> wrote in message news:<roamjvo4d 52gcapjdtbd5dte l3l8gfegu2@4ax. com>...[color=blue]
> On Thu, 14 Aug 2003 05:33:07 GMT, "James J. Gavan" <jjgavan@shaw.c a>
> wrote or quoted :
>[color=green]
> >
> >Haven't been there but lived real close in Guildford at one stage -
> >reading you C and Java people, I feel like a Wimbledon spectator with my
> >head zinging from left to right as the opponents take a swipe at the
> >ball ![/color]
>
> If you want to write cross platform code in C++ you have to buy a
> rather expensive cross platform library,[/color]

thats a lie, gtk is cross-platform *and* free.
[color=blue]
> something like Rogue Wave.
> C++ or C out the box is far from being cross platform.[/color]

thats a lie. I can write a non-trivial program that will compile
with any C (where the hell did i mention C++?) compiler out-the-box,
and compile on all c89/90 compilers.
[color=blue]
> What you can
> do is write code that can be tweaked to run on another platform, or
> you can create a set of macros to make the same code base run on one
> or two platforms.[/color]


you can do that *also*, but its not your only option.
[color=blue]
> However the C and C++ are not naturally
> multiplatform.[/color]

thats another lie, C was standardised, afaik, *because*
of its ubiquity.
[color=blue]
> They are lower level languages. That is why they are
> used for JNI when you want to get personal with the OS.[/color]

and break what little portability that java offers ?
[color=blue]
>
> C is much more cross platform in the Unix world,[/color]

thats a lie again. C is cross-platform.
period.
[color=blue]
> but when you throw in
> Windows and the Mac, you pretty well have to start from scratch.[/color]

yet another lie. gtk compiles on both platforms, afaik.
[color=blue]
> With
> C and C++ you interface directly with the OS.[/color]

yet another lie. show me even *one* std C function that
binds your code directly to the OS.

just one.
[color=blue]
> With Java there is a
> buffering layer of standard class libraries.[/color]

its strange that you nkow so little yet you post so much.
what do you do for a living anyway ?
lawyer ?
[color=blue]
>
> The language wars are for the most part kid nya nya games.[/color]

I certainly agree. however it does irk me that you so blatantly *lie*
so *many* times in a single post.
[color=blue]
> You need
> both C++ and Java for different things.[/color]

I have not mentioned C++
[color=blue]
> There are not many places
> where you would you would use pure C now instead of C++, perhaps a
> device driver or some code to fit in an embedded device.[/color]

true, but if you wanted to write a crc algorithm that worked
*everywhere*, you'd write in in pure C.
[color=blue]
>
> It is like arguing which is better a wrench or a screwdriver.[/color]


no no, it is me pointing out that
a) java is not platform independant, it depends on the java
platform.
b) the java platform only runs on a fraction (i dunno, say 1%?)
of computing machines out there.
c) There is a C compiler for just about every computing
machine in the world. I'd certainly be interested to here
which machine supports java but not C.

You are destroying your credibility with so many lies in a single
post.

If you *really* thought those things, well, then ... now you
know more (e.g. you know that std C is not tied to the OS).

but if you were merely ignorant and neglected to look up the
facts, then I'd have to say that you should do your bloody
homework instead of making an ass of yourself.

goose,
at least now you are more informed, are you not ? no more *myths*
about C ?

[Chris Dollin]

Re: Future reuse of code

goose wrote:
[color=blue][color=green]
>> Even the size of an int is not nailed down for heaven sake.[/color]
>
> yes it is, read the std.[/color]

"At least 16 bits" doesn't count as "nailed down" for me.

--
Chris "electric hedgehog" Dollin
C FAQs at: http://www.faqs.org/faqs/by-newsgrou...mp.lang.c.html
C welcome: http://www.angelfire.com/ms3/bchambl...me_to_clc.html

[WB]

Re: Future reuse of code

Karl Heinz Buchegger wrote:
[color=blue]
> Do you have some links on that subject?[/color]

http://mindstorms.lego.com/eng/products/ris/rissoft.asp

You use a GUI to drag/drop programming elements. They stick together to
create a behaviour for your robot. If/Else/Loops are all supported.

Oh, just to throw fuel on the fire, there IS a Java VM available. Do a
Google search on: lego robot java

There is also a C like language called NQC (Not Quite C).

:-))

[jce]

Re: Future reuse of code

><NEWS FLASH> C probably targets that too </NEWS FLASH>

<SIGH>We *get* your point </SIGH>
[color=blue]
> goose,
> java code isn't as portable as C code.[/color]

By the way, I would say that Java on a wireless phone or PDA is more
portable than a stoplight.
I don't believe I could get the latter through customs.

JCE

[Bent C Dalager]

Re: Future reuse of code

In article <bhg685$97i$1@p anix1.panix.com >, <docdwarf@panix .com> wrote:[color=blue]
>
>If the statements in question are the result of mere ignorance then they
>lack the intentionality which is required of a lie... or am I missing
>something?[/color]

You seem to be missing the fact that it was a flame. Logic and correct
use of vocabulary are non-issues in that context.

Cheers
Bent D
--
Bent Dalager - bcd@pvv.org - http://www.pvv.org/~bcd
powered by emacs

[Howard Brazee]

Re: Future reuse of code


On 14-Aug-2003, ruse@webmail.co .za (goose) wrote:
[color=blue]
> the bottom line is that
> (now read this slowly, so that it sinks in)
> *code* *written* *in* *java* *will* *be* *portable* *to*
> *fewer* *platforms* *than* *code* *written* *in* *C*.[/color]

Programs as written will run without change when moved to a different platform?
[color=blue]
> do you argue that ??? you'd be incredibly stupid and/or
> brain damaged to argue that point.[/color]

There are other options besides your insulting ones. But when someone is into
that type of insulting, whether he has anything useful to contribute gets
overlooked.

[Howard Brazee]

Re: Future reuse of code


On 13-Aug-2003, "Peter E.C. Dashwood" <dashwood@enter net.co.nz> wrote:
[color=blue]
> I foresee a time when there will be no need for the "lower level"
> programming you are talking about, Bill.[/color]

We will no longer need to program by moving wires around?

Or we will no longer need to program in machine language?

Or we will no longer need to program using assembler?


Been there, done that.