Future reuse of code

[goose]

But then people write code thinking of only their own platform where
int is say 32 bits, and hand it to someone else whose int is 16 bits.
It does not work. It requires foresight and a macro to make that
code work on both platforms. It is thus foolish to claim C or C++
works naturally multiplatform. It requires extra effort.

the "work" (if it could be called that) that lazy programmers
do is the fault of the language ????

did you have you IQ tested recently ? do you even think at all ?

just because a programmer was too ill-trained in the language,
it does not mean the language is at fault.

Look at something like one of the GNU compilers which you would think
would naturally without ANY effort be platform independent. It has
ZILCH in the way of user interface. Then go look at the zillions of
config tweakings and macros you need to handle platform differences.

Think back a few years to all the near/far pointer crap you had to
deal with on Windows 3.1. That certainly did not port automatically
anywhere else.

that was (and still is) *not* part of the c standards. your knowledge
of near/far shows you to be someone who has worked with C before.
your lack of knowledge wrt to the standards (too many examples, but
i'll name 2 -> 1. you dont know that the standards guarantee int to
have minimum and maximum values. 2. you dont know that near/far are
*extensions* to a particular implementation) show that you have
been an incompetant C programmer in the past.

you cannot call yourself competent if you *ever* thought that near/far
was "standard C".

You are defending C++ as if you were defending your favoured football
team, with emotional loyalty, giving it imaginary virtues, and

not imaginary, but certainly it has the edge wrt to cross-platform-ness.
java doesn't even come close. yet it is *you* who insist that C is not
cross-platform, with not a single iota of evidence to back this up.

I, otoh, have backed up more than once my statements regarding
1. the size and possible values of an int.
2. the conformance issue wrt to a fully conformant implementation.
3. the portability of fully compliant C code.

imagining it would be impossible for it to be anything less than all
things to all people.

I disagree, you have yet to address *any* of my other points, which
got snipped away (luckily, they are all archived for the world to
see that you say "even the size of an int is not guaranteed" and i
replied "yes it is, now you are more informed", and you *snipped*
that reply and stated yet again "even the size of an int is not
guaranteed" ...)

C is a portable assembler. That's where it
reigns supreme. Partly because of that distinction it NECESSARILY
can't be high level and highly platform independent.

thats where you are wrong. all of the points in that paragraph.
it isn't necessarily high-level, but it is *very* platform
independant ...

goose,
couple million java programmers in the world, roughly 10%
java software ?

 

[goose]

The difference in, that equivalent program in Java would either work
or not work. It would give the same results on all platforms.

you eman "it would give the same results on the few platforms
that java supports", not "all platforms" ...

With
the C version, you don't know if it works on other platforms until you
test it.

nope, you *do* know ... you write std C and it *will* work as expected
on *all* *ansi* *C* *implementations* ...

goose

 

[goose]

Straw man argument Kevin.

you dont have a leg to stand on. this is no straw man argument!!!
do you even know what that means ?

You made the silly assertion that ALL C code would run unmodified on
any platform correctly. That is nonsense.

no. i think he made a statement to the effect that "all std-compliant
C code will run on and std-compliant implementation".

I merely stated that writing cross platform code in C or C++ takes
considerable effort.

nope, it doesn't take effort, it takes knowledge. you have to *know*
that using "near" in your code makes it unportable. if you know, and you
still put it in, then you also wont expect to run that unportable code
(which is not std-c anymore) anywhere else.

The Dynamic C compiler comes to mind. it is a "c-like language", but
not *exactly* stc-C. so anything written in Dynamic C wont work
as expected on other platforms.

It does not happen as a natural side effect of
coding the way it does in Java.

get off your java high horse, no one is attacking it, why are you
defending it ?

You need to find third party
libraries supported on all your platforms. You need to generate
separate executables. You have to keep your wits about you realising
that int means different things on different platforms.

for the *last* time, "int x" means the *same* *thing* on all
std-compliant platforms, it does not mean *different* things.

To get 32
bits on ALL platforms you have to use macros, and even then, there is
no guarantee of support.

????
read the C std, and you will realise that sizes of datatypes are
*guaranteed*, not /suggested/.

You need to test separately, and you need a ton of compile time
macros to make the magic work.

for the last time, you *dont* need a ton of macros ...

goose,

 

[Roedy Green]

Straw man argument Kevin.

That is a straw man argument because I never asserted it was
impossible to write portable code in C.

Kevin is the one who asserted that ALL C code is naturally platform
independent and runs without modification on all platforms giving
correct results, a preposterous claim.


I don't believe my opponents have any interest in discovering truth.
They are interested only in the playing lawyer and one upmanship
games. This is too childish a debate to continue.

 

[goose]

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

true but it *does* guarantee /minimum/ values
(elsethread, I vitriolicly posted that it also
guarentees *maximum* values. this is, as many of you
must have replied as much by now, untrue).


goose,
with steam rising at the issue of "portability"

 

[Jacob]

i showed plenty of evidence that this is not true (C, for example,
targets many more platforms than java).

It is not only a matter of counting supported
platforms, but also a matter what you can
achieve *within* that platform.

C as a language is indeed portable, but a given
program written in C is typically not. It
include precompiled 3rd-party libraries,
machine dependent network access code and
user interfaces (for which no standard exist).

 

[Bob Jacobs]

Straw man argument Kevin.

you dont have a leg to stand on. this is no straw man argument!!!
do you even know what that means ?

You made the silly assertion that ALL C code would run unmodified on
any platform correctly. That is nonsense.

no. i think he made a statement to the effect that "all std-compliant
C code will run on and std-compliant implementation".[/QUOTE]

What's your definition of 'std-compliant' here? Do you mean conforming,
strictly conforming, or some other form of corresponding to the standard?
Are you talking about hosted or freestanding? Without a definition of
'std-compliant' in this context it's difficult to say whether the statement
made is correct or not.

 

[goose]

The big advantage is you have is Sun's licensing. Basically if its is
called J2SE you can COUNT on classes and methods being there, and
working in a standard way. EVERY J2SE has these.

and basically if an implementation says "ANSI-C" you can count
on all ANSI-C code running there.

I argued for a such standard class libraries back in 1986 October in
an article in Byte Magazine. It is huge help no matter where you go
to have the same interfaces to deal with. You are not starting from
scratch with different tools for every project. With Java they are
effectively built into the language. You can count on them just as
strongly as you can count on +. That is not true with C++. Chances
are any given tool WON'T be supported on a particular platform. Each
tool handles only a handful of platforms. J2SE handles EVERYTHING
that handled claims to be J2SE, which is basically any Java desktop or
bigger.

thats the point. any desktop or bigger. most of the computers you
use in everyday life are *not* desktops.

imagine a typical day in the life of an SA programmer (me:
wake up in the morning and switch the alarm-clock/radio/cd (embedded
processor in there), trundle into the kitchen and boil water for tea
in kettle(with no CPU ... yet!) and warm remains of pizza in microwave
(with embedded processor).

I have a shower, dress, switch the house-alarm(8051 processor) on, and
jump into the car(a bosch ignition system, embedded proc. there too),
turn the key and hear the faint whine of the fuel pump seconds before
engine turns, in order to provide enough pressure for the fuel injection
(which depends on an embedded proc. for correct timings).

the car starts and I'm 1km down the road when I hear the first "whoop"
of the anti-hijack siren(car alarm also has an embedded proc.) warning
me to press the hidden switch to prove that I did not hijack the car
or it will switch the car off *and* drain the battery in 30 seconds.

I get to work, slot my access card in the "reader" by the main gate,
the reader(embedded proc. there as well) recognises my card(embedded
atmel 8051 derivative smartcard) and opens the gate for me.

I park my car, lock it up and use the same card to open the main doors.
since I am the first in this morning, the office alarms(some PIC thing)
needs to be shut off, I do this via a control panel(another PIC) at
reception.

I *finally* get to my desktop, where I read mail and usenet the entire
day while pretending to work . this is where i *might* encounter
(no guarantee) java, but in the course of a normal day of work, i almost
never do.

I make my coffee in an expresso machine(no proc. afaik), and sit down
to make a few phone(embedded proc. there as well, because phones are
these fancy ones which can only talk to a certain switchboard which
also has en embedded proc.) calls.

at lunchtime i make my way to the cafe up the road, buy a sandwich
and pay by credit-card(no proc.). card gets swiped on a terminal
(either an nec v25 proc, a motorola hc11 or something proc. or in
this cafe, an x86 based terminal with 1meg RAM).

I make my way *back* to work and attempt to be blazingly efficient to
make up for lazing and reading usenet all morning . my *mobile* rings
and I talk to a client on my mobile(a motorola, an embedded proc.
this just *might* have a jvm, but i doubt it as i'm cheapskate wrt
to phones and just purchase the cheapest one that can make and receive
calls ...).

thats just an ordinary day as well ... i did not mention the embedded
devices that I program while at work (cos not everyone does so), nor
the ones I program at home in my spare time.

the number of desktopsin the world are dwarfed by the number of
embedded processors ... and java ports best from desktop to desktop.

like I originally said "java has its advantages, but portability isn't
one of them".

Platform independent code happens naturally with almost no effort in
Java. It is requires considerable effort in C++.

I've found it no effort at all (in C++ as well as C, although I never
brought up C++ or the portability of C++).

You can't convince
me otherwise because I have done both.

and you possibly think that you are unique in that regard ? lots of people
have "done" both.

but when it comes to sheer ubiquity, you *cannot*, at this moment in
time, beat C. for every single one of those embedded devices above,
should they need to communicate, will need a checksum routine.

I can write that checksum routine in plain std-C, assume a free-standing
conforming implementation and it will work on all ... you cant do that
ion java, yet.

Even better, when I *am* writing code for desktops or bigger, I can
/modularise/ everything so that platform-dependant code resides
all in a single file, so that porting my tic-tac-toe app to another
machine becomes as easy as recompiling the code for that architecture.


goose,
java is portable to, /maybe/ 10% of the worlds computers ?
you call that portable ???

 

[Mark Gordon]

I would agree out of date but not completely wrong. Ok, cheaper or
free packages have come available since Rogue Wave was the tool we
were using.

These packages themselves have to be tuned for each platform. If the
runtime does not exist for the platform you want you are SOL. They are
not universally available the way the Java class libraries are.
They are not part of the language. They come from various third
parties.

A large number of applications don't need any GUI and for those it does
not matter. A large number of servers don't have a GUI installed even if
one is available.

All you have done it fob the work of platform independence off on a
third party. The LANGUAGE is giving you precious little help.

The equivalent problem occurs with Java, but the language itself and
the standard class libraries isolate you from all that platform
specific code that had to be written.

Only if the JVM has been ported to the target platform, otherwise you
either have to change platform (something we forced on a number of
customers) or port Java to the target, a much larger task than just
porting a graphics library or providing some platform specific code to
interface to an existing graphics library on the target.

Coding for platform independence is something you can do in C++, but
it is not something that comes out in the wash automatically the way
it does in Java. It requires effort and third party libraries chock
full of platform dependent code.

It only requires third party libraries for some applications. There are
a large number of applications that either don't need anything beyond
the standard or only need something covered by another ubiquitous
standard.

 

[Mark Gordon]

The difference in, that equivalent program in Java would either work
or not work. It would give the same results on all platforms. With
the C version, you don't know if it works on other platforms until you
test it.

We can't run one of our Java applications on SCO 5.0.4 even with Java
installed and working. The reason is that the Java code uses features
only available in Java 1.4 but that version of Java is *not* available
for SCO 5.0.4, which was the OS most of our customers were running.

So, based on us having written a Java application which, by your
definition is platform independent, and then found it would not run on
the Java supporting platform that most of our customers used, you can't
tell whether your completely platform independent Java application will
run on all supported platform until you try it either.

BTW, SCO 5.0.4 only has Java 1.3 available.

 

[Mark Gordon]

It is not only a matter of counting supported
platforms, but also a matter what you can
achieve *within* that platform.

C as a language is indeed portable, but a given
program written in C is typically not. It
include precompiled 3rd-party libraries,
machine dependent network access code and
user interfaces (for which no standard exist).

Of all the C code I have written over the years, I've only worked on one
project that used either network code or a user interface. That one
program runs on a platform where a Java program a colleague wrote will
not run as well as all the platforms where we do run the java
application my colleague wrote.

Now try porting your Java application with a user interface to my AIX
4.3 box that does not have any GUI libraries installed whilst I run my
application in text mode.

 

[Peter E.C. Dashwood]

In the past we have had "user friendly" tools, and the user never used them.
It will be the same with system modeling.
There will be modeling "experts" who do the work.

Only if we use modelling.

Suppose they just build something like what they are after, and then refine
it until it does what they want? (See the sample dialogue I posted between a
Businessman and a computer). There are many classes of problem where it
ISN'T necessary to model. In fact, modelling is more properly a part of the
"design" school rather than the "evolve" school.

But, in the interests of a lively discussion <G>, let's say you're right on
that.

So the modeller does the model and works with the user and they jointly
refine it.

How long do you think it would be before the user is capable of doing the
modelling?

(In other words, he (the user) has learned how to do the modelling by
watching someone do it, in a context which he (the user) completely
understands because it is HIS application requirement that is being met.)

It will depend on how complex the modelling tool is, won't it?

This is where the smart software comes in. If the interface is simple and
intuitive, it won't take very long at all.

If you need a 2 month course in order to be able to use the modelling tool,
then we haven't really made much progress.

It is important to recognise that there is a difference between designing
something and then building it (as we currently do, for the most part), and
building something, then iteratively modifying the design until it does what
you want.

Traditionally this latter has been frowned on. It smacks of cardboard and
string and Mickey Mouse solutions. Anyone who's a Programmer will probably
have encountered the "hot shot" who comes in, sits down, and starts coding.
Produces the goods in a day, then when it falls over in production, he or
someone else spends 4 days debugging it because it wasn't "designed"...

Well, that is certainly a good argument for going the "design" approach. (As
a matter of fact, I endorse the "design" approach for manually written
program code...wouldn't argue against it because it has a long, successful,
track record...<G>)

But hold on a minute...we aren't talking about a Human producing code, or
debugging it, or maintaining it.

Instead it will be done by software that is smart enough to do it, using
libraries of known functions and components, selected in response to user
requirements that have been elicited and refined by INTERACTION between the
user and the software.

Only the FUNCTIONALITY needs to be focused on; NOT the programming. Under
these circumstances, the "evolve" method has some outstanding benefits. Not
the least of which is that a Programmer or technically adept "modeller" is
not required. (That may or may not be an advantage, depending on your point
of view, but from a cost accounting POV it is a huge advantage...)

In 15 years I believe we will see users developing their own computer
systems, interfacing with the spreadsheets and databases they are becooming
proficient with, using the evolutionary model methodology, and smart
software to do the "grunt" work.

Power to the People! (And, Freedom for Tooting!).

Pete.

 

[Howard Brazee]

You argument is flawed. Java is language + libraries, C/C++ is just
a language. If will have to find third party libraries to write
C/C++ applications anyway. If you choose portable libraries then
it takes the same effort to write portable code in C/C++ as it does
in Java.

If we are comparing how difficult it is to port, the advantage of knowing that
the libraries will be there is huge.

 

[Howard Brazee]

like I originally said "java has its advantages, but portability isn't
one of them".

Yep. That's what you said. I haven't seen any evidence on this thread that
you have convinced anybody that this is true.

 

[Marco van de Voort]

I've not done C++,

Only a bit. (pretty much the amount needed for Delphi compability. Basic
classes and such)

but I have done Pascal (had to use non-portable
features)

Like?

 

[Stephane Richard]

Let's see now.

in Java's history:

Java 1 and Java 2 are very different languages that try to look the same.

Between Java 2 1.3 and Java 2 1.4 there are discrepencies that can make code
execute differently or not work at all. As far as portable, what is
portable in it's definition?

"code that can be compile with little to no alterations to the code on
different plateforms. I think people are confusing portable and
multiplatform. Sure Java is Multiplatform. why? because Java runs
compiled on a lot of platforms. But at what cost? As long asn the java
creators keep on thinking with the same frame of thoughts as they are right
now, Java will:

1. Never be portable as they think that providing the whole platform with
their language is the only way to do things. Take the code to that
platform, the JVM, there is no way, by any definition of portable, that the
code to the jvm is portable or multiplatform. but the results of this code
are multi platform. or the same JVM would compile as is on anything you try
to compile on. Hence there's different JVM's to install on different
platforms. Think of it, JVM is, "dare I say", an OS inside the OS you run it
in. How can that be optimal and as fast as any other technic and
technology?

2. Never be as fast as most other languages...still today JVM and the JDK
lack in speed because there's so much things to do/consider/create different
as per the machine/platform it's running on.

3. The problem here isn't the language itself. Java's idea of a programming
language is pretty good, everything being an object makes for perhaps a
little bit clearer code, but then again, not on all aspects. The problem is
the way the language is implemented. The way you need the JVM (which runs
on top of your OS) to run java code where you need nothing but the OS on any
other languages to me those are the major flaws if the whole Java idium.
But the language IS fun to use. Maybe Java should be it's own OS instead of
a virtual machine running on top of any existing OS then it would cut that
"interface/intermediate" layer and end up faster, by design.

Again people, don't confuse portable code, and multiplatform applications
these are very distinct fields althought they both exist for the same cause
.

So as per the definition of portable, C is definitaly the strong winning.
As multiplatform Jave is better (as in simpler, but not necessarily better
in general than C (speed wise, resource wise and the likes) But C, with a
little bit more work (upfront as in at the beginning of the development
process) is many times faster and smaller.

 

[Howard Brazee]

3. The problem here isn't the language itself. Java's idea of a programming
language is pretty good, everything being an object makes for perhaps a
little bit clearer code, but then again, not on all aspects. The problem is
the way the language is implemented. The way you need the JVM (which runs
on top of your OS) to run java code where you need nothing but the OS on any
other languages to me those are the major flaws if the whole Java idium.
But the language IS fun to use. Maybe Java should be it's own OS instead of
a virtual machine running on top of any existing OS then it would cut that
"interface/intermediate" layer and end up faster, by design.

Everything choice involves costs and benefits. This "problem" is also Java's
biggest strength.

 

[Scott Moore]

Please stop crossposting this material to the Pascal groups. It has no
bearing on
the subject matter there.

Thank you.

 

[WB]

If it doesn't support fopen, then it's not a hosted C implementation.

Who said anything about fopen? You still use fopen, but MUST have the
additional include file, which adds support for the mainframe way of
doing things.

If it doesn't handle identifiers case-sensitively, then it's not a
conforming C implementation at all.

The mainframe C compiler is quite happy with long var names and mixed
case. It is the linker which falls over. Actually is only "sees" up to 8
characters, but does not complain at all. This leads to very interesting
behaviour :-((

Oh yes, I also forgot about tri-graphs:
[ becomes ??(
] becomes ??)
^ becomes ??\
~ becomes ??-


I ended up writing a converter which takes the original C code, and
converts it to something that will run on the mainframe. Yuck.

 

[Donald Tees]

The difference in, that equivalent program in Java would either work
or not work. It would give the same results on all platforms. With
the C version, you don't know if it works on other platforms until you
test it.

This is getting silly. You do not know if *any* program in *any* language
on *any* computer works until you test it.

Donald