Future reuse of code

[Karl Heinz Buchegger]

Re: Future reuse of code



Joe Zitzelberger wrote:[color=blue]
>
> In article <796f488f.03080 70114.4d2da92f@ posting.google. com>,
> qed@pobox.com (Paul Hsieh) wrote:[color=green]
> >
> > Sure:
> >
> > http://sourceforge.net/softwaremap/t...p?form_cat=160
> >
> > Notice how many projects are in COBOL. Now look at the C, C++, Java
> > and Pascal numbers and go back to my original post.
> >
> > The acid test, of course, is to compare against assembly language.
> > Its fair to say that assembly language isn't really a language at all
> > -- its just a bunch of macros for flipping 1's and 0's. You know a
> > language is dead or dying if people actually prefer assembly language
> > to using it.[/color]
>
> I prefer assembly language to everything...wh at does that mean?[/color]

That you have too much time? :-)

--
Karl Heinz Buchegger
kbuchegg@gascad .at

[Howard Brazee]

Re: Future reuse of code


On 8-Aug-2003, ruse@webmail.co .za (goose) wrote:
[color=blue][color=green]
> > Java has another huge advantage - it runs on anything without having to
> > spend more money.[/color]
>
> <howls of laughter> pull the other one sonnyboy, its got bells on :-)[/color]

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

[Marco van de Voort]

Re: Future reuse of code

In article <bh0evg$8t4$1@p eabody.colorado .edu>, Howard Brazee wrote:[color=blue]
>
> On 8-Aug-2003, ruse@webmail.co .za (goose) wrote:
>[color=green][color=darkred]
>> > Java has another huge advantage - it runs on anything without having to
>> > spend more money.[/color]
>>
>> <howls of laughter> pull the other one sonnyboy, its got bells on :-)[/color]
>
> OK, I exaggerated. But it runs on a lot more platforms than anything else
> without costing more.[/color]

Like e.g. gcc ? Think not.

[Tor Iver Wilhelmsen]

Re: Future reuse of code

Marco van de Voort <marcov@toad.st ack.nl> writes:
[color=blue]
> Like e.g. gcc ? Think not.[/color]

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

[Marco van de Voort]

Re: Future reuse of code

In article <uu18syunb.fsf@ broadpark.no>, Tor Iver Wilhelmsen wrote:[color=blue]
> Marco van de Voort <marcov@toad.st ack.nl> writes:
>[color=green]
>> Like e.g. gcc ? Think not.[/color]
>
> GCC the compiler is pointless without libraries,[/color]

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

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

I'm sorry, but I fail to see the difference.
[color=blue]
> and libraries in C/C++ differ between platforms. Java's libraries let you
> write complex applications without a million #ifdef _LINUX_ or whatever.[/color]

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

[Howard Brazee]

Re: Future reuse of code


On 8-Aug-2003, "William M. Klein" <wmklein@nospam .netcom.com> wrote:
[color=blue]
> The cost issue is separate from the portability issue, but exactly WHICH
> platform currently supports Java that doesn't also have one or more COBOL
> compilers available for it?[/color]

MacIntosh. (native)

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

[Tor Iver Wilhelmsen]

Re: Future reuse of code

Marco van de Voort <marcov@toad.st ack.nl> writes:
[color=blue]
> Java is pointless without the connection between SWING and host OS.[/color]

Java 2 Standard Edition (J2SE) defines a STANDARD library which
includes Swing, and AWT which it builds on. AWT has the native hooks
required.
[color=blue]
> C++ GUI libraries are pointless without connection between GTK and host OS.[/color]

Gtk+ is not part of C++ as such - it is one of *many* libraries which
*might* exist for your target platform.
[color=blue]
> I'm sorry, but I fail to see the difference.[/color]

The difference is that AWT and Swing are parts of J2SE, Gtk+ is not
part of C++.
[color=blue]
> You can do that in most other languages too. The native feel of the
> application will suck in that case though. (and IMHO that is one of
> the downsides of the Java SWING model)[/color]

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

[Marco van de Voort]

Re: Future reuse of code

In article <ufzkbvpm7.fsf@ broadpark.no>, Tor Iver Wilhelmsen wrote:[color=blue]
> Marco van de Voort <marcov@toad.st ack.nl> writes:
>[color=green]
>> Java is pointless without the connection between SWING and host OS.[/color]
>
> Java 2 Standard Edition (J2SE) defines a STANDARD library which
> includes Swing, and AWT which it builds on. AWT has the native hooks
> required.[/color]

And what does that matter for this point? It still needs OS dependant code
somewhere. So do GUI libraries in other languages (like GTK, QT, you name it)
[color=blue][color=green]
>> C++ GUI libraries are pointless without connection between GTK and host OS.[/color]
>
> Gtk+ is not part of C++ as such - it is one of *many* libraries which
> *might* exist for your target platform.[/color]

A C++ compiler is indeed not required to package GTK+. Maybe Java madatory
forces the compiler/VM developper to package Swing or AWT even.
[color=blue][color=green]
>> I'm sorry, but I fail to see the difference.[/color]
>
> The difference is that AWT and Swing are parts of J2SE, Gtk+ is not
> part of C++.[/color]

An organisational detail IMHO. An all Java systems adhere to it currently?
They don't simply change to a different for "embedded" standard if it is not
easy?
[color=blue][color=green]
>> You can do that in most other languages too. The native feel of the
>> application will suck in that case though. (and IMHO that is one of
>> the downsides of the Java SWING model)[/color]
>
> I have seen more "native" Windows apps that break with Microsoft's
> User Interface Guidelines (nice book to have as a reference) than what
> the Windows L&F defaults to.[/color]

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

[goose]

Re: Future reuse of code

"Howard Brazee" <howard@brazee. net> wrote in message news:<bh0evg$8t 4$1@peabody.col orado.edu>...[color=blue]
> On 8-Aug-2003, ruse@webmail.co .za (goose) wrote:
>[color=green][color=darkred]
> > > Java has another huge advantage - it runs on anything without having to
> > > spend more money.[/color]
> >
> > <howls of laughter> pull the other one sonnyboy, its got bells on :-)[/color]
>
> OK, I exaggerated. But it runs on a lot more platforms than anything else
> without costing more.[/color]

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

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

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

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

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

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

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

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

goose,
extracting the urine ;-)

[Tom McGlynn]

Re: Future reuse of code

Joe Zitzelberger wrote:[color=blue]
> In article <8JRYa.2889$vo2 .511@newsread1. news.atl.earthl ink.net>,
> "William M. Klein" <wmklein@nospam .netcom.com> wrote:
>
>[color=green]
>>The cost issue is separate from the portability issue, but exactly WHICH
>>platform currently supports Java that doesn't also have one or more COBOL
>>compilers available for it?[/color]
>
>
> MacOS (both flavors) is very Java-centric and without Cobol at the
> moment.[/color]

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

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

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

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

Regards,
Tom McGlynn

[Roedy Green]

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

On Thu, 07 Aug 2003 04:44:39 GMT, "jce" <defaultuser@ho tmail.com>
wrote or quoted :
[color=blue]
>are gullible) actually believed it for a moment :-)
>
>http://www.sdmagazine.com/documents/s=819/sdm0204f/[/color]


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

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


--
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 Fri, 08 Aug 2003 08:47:14 -0400, Joe Zitzelberger
<joe_zitzelberg er@nospam.com> wrote or quoted :
[color=blue]
>
>I prefer assembly language to everything...wh at does that mean?[/color]

The great appeal of writing the core of my Forth/Abundance interpreter
in assembler was that I knew exactly what was going on in side down to
the bit level. Nothing was happening I did not know about. This
desire for microcontrol and perfection comes best from writing in
Assembler. The only idiots you have to swear at are the folk who
designed the instruction set.

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

[Dr Engelbert Buxbaum]

Re: Future reuse of code

Paul Hsieh wrote:

[color=blue]
> 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.

[goose]

Re: Future reuse of code

"Howard Brazee" <howard@brazee. net> wrote in message news:<bh8k02$dr 8$1@peabody.col orado.edu>...[color=blue]
> On 9-Aug-2003, ruse@webmail.co .za (goose) wrote:
>[color=green]
> > who do you think will write a program that will run (recompiled if necessary)
> > on the greatest number of machines ?[/color]
>
> Greatest number of machines.
>
> I don't think someone writing a business application cares about, say
> stoplights. But stoplights are machines with computer programs in them.
>
> So the question should be - which language gives me an advantage in reaching
> more prospective paying customers for my product with the least cost to me?[/color]

the original statement (which was snipped) was
----[color=blue]
>[color=green][color=darkred]
> > > Java has another huge advantage - it runs on anything without having to
> > > spend more money.[/color]
> >
> > <howls of laughter> pull the other one sonnyboy, its got bells on :-)[/color]
>
> OK, I exaggerated. But it runs on a lot more platforms than anything else
> without costing more.[/color]
----

I have already pointed out that this is not true.
[color=blue]
>
> If my application runs best on big iron, that may be CoBOL. (Good for me, that
> is my native programming language).
> If my application is to show me on my hand held which golf club I need for my
> next shot (according to my past history, a map of the course, and the GPS
> satellite), then CoBOL isn't a good choice.
>
> But if I am wanting to create a program that all of the students in a university
> can use to interface with the campus's computers - I can assume most of them can
> already run my XML and Java code.[/color]

and yet creating a std C program would not only get you that, it would also
get you a fairly snappy application *and* leave you open in the future
to be able to support those people who have machines that are not
capable of running java (certain designer palmtop-types) to *also*
interface with the campus machines.

java doesn't *buy* you anything extra in terms of portability.
The only relatively *portable* way I can think of is when writing
applets for web-pages (note: /relatively/). as long as the browser
has a java runtime environment, of course.

Java does have its advantages. Portability isn't one of them.

hth
goose,
I feel very strongly about the "while" loop. I suggest we take
it hostage to demand the release of the "goto" ;-)

[Marco van de Voort]

Re: Future reuse of code

In article <3f38cfd6_3@new s.athenanews.co m>, 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]

Really? Please name and discuss them.
[color=blue]
> 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 about
> to become "computer programmers".[/color]

Indeed.
[color=blue]
> Instead, they will demand better interfaces, smarter software,[/color]

True
[color=blue]
> and MUCH better ways of developing computer systems than sequential Von
> Neumann code.[/color]

On the contrary, specially for these kinds of users, sequential jobs are a
way of thinking that is normal to them.
[color=blue]
> 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 severly
increased also. I sometimes doubt if increased computer literacy actually kept
up with the added computer tasks for the avg person.
[color=blue]
> They are not intimidated by computer technology, will happily interact
> with smart software to achieve a result, and are not prepared to rely on
> and wait for, remote, faceless, technocrats to provide them with computer
> solutions to business problems.[/color]

Yes, they want smug buzzword talking con-men to take advantage of them ?
[color=blue]
> 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 it
> get solutions.[/color]

Exactly. So as long as my solution is good, and I can justify using a language,
waht is the problem.
[color=blue]
> By 2015 a new generation of development software will see "programmer s"
> removed from the loop and end users interacting and iterating with smart
> software until they get what they want.[/color]

Sure. The telepathic kinds.
[color=blue]
> Procedural code is already into Gotterdammerung .[/color]

[color=blue]
> It takes too long, requires too much skill,[/color]

Programming is what requires the skill. Not the language. If you studied programming
closer, you'd know that.
[color=blue]
> 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]

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 I
see your description)
[color=blue]
> 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]

Ah, but could they, and with the same secondary securities? Price is not the only
point of competition.
[color=blue]
> 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 are
> 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" award, with
"don't panic" in nice friendly letters.