Future reuse of code

[Bent C Dalager]

Ahhhh, *now* I understand... thanks greatly, you... you poopie-head, you!

(did I do that right?)

I certainly appreciate the effort, but you could do with some work on
the execution

Cheers
Bent D

 

[Roedy Green]

- First there must be a Java implementation
- Second there must be a *full* java implementation.

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.

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.

Platform independent code happens naturally with almost no effort in
Java. It is requires considerable effort in C++. You can't convince
me otherwise because I have done both.

 

[Roedy Green]

People who *think* they need an exact-width type, rather than an
at-least width type, are usually wrong.

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.

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.

You are defending C++ as if you were defending your favoured football
team, with emotional loyalty, giving it imaginary virtues, and
imagining it would be impossible for it to be anything less than all
things to all people. 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.

 

[Peter E.C. Dashwood]

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. ;-)

I said that about IBM in 1984...<G>

(No, I didn't really... but they almost lost the company when they produced
a small computer that was universally available, dispelled a lot of the
"Myth and Magic" that surrounded computer technology at the time, and put
computing within the reach of everybody. Ironically, prior to that they had
behaved in a very bad way on numerous occasions and were perceived very much
as MicroSoft is today...the one time they did something really good and
noble, it pushed them into loss for the first time in decades...)

I know it is very fashionable to beat up MicroSoft, but if all of us were
fair and resonable, could put aside our consuming envy of the wealth of Bill
Gates, could forgive all the times we faced the Blue Screen Of Death (and
see it as part of the natural evolution of PC technology), I have a feeling
that we could then acknowledge that WITHOUT MicroSoft the World would be a
very different place.

Pete.

 

[WB]

Don't be silly. Look at any C code designed to run on many platforms.
It is riddled with macros to pull off the feat.

You can do a few simple things like parse the command line, open a
flat file in a platform independent way, but not even the size of int
is guaranteed unless you play some games with macros.

Well, no you can't open a file in a generic way. Opening a file on a PC
is different than opening a file on a mainframe. You need a special
library to do this:

#ifdef I370
#include <lcio.h>
#endif

Which works with the SAS C compiler.

Plus, all your variables and function names need to be 8 characters or
less, AND mixed case is ignored, so VarA and VARA are the same, thanks
to the mainframe linker.

At least it was a few years ago. Things may have chnaged since then....

 

[Kevin Easton]

Well, no you can't open a file in a generic way. Opening a file on a PC
is different than opening a file on a mainframe. You need a special
library to do this:

#ifdef I370
#include <lcio.h>
#endif

Which works with the SAS C compiler.

Plus, all your variables and function names need to be 8 characters or
less, AND mixed case is ignored, so VarA and VARA are the same, thanks
to the mainframe linker.

At least it was a few years ago. Things may have chnaged since then....

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

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

- Kevin.

 

[Roedy Green]

It is impossible to
write incorrect Java code?

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.

 

[Roedy Green]

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.

The Java version might not work either, but this is because of BUGS.
If the C version did not work, it would be because of FEATURES.

 

[Kevin Easton]

The Java version might not work either, but this is because of BUGS.
If the C version did not work, it would be because of FEATURES.

C code that assumes that int is 32 bit wide is BUGGY.

Is it possible to write non-portable code in C? Yes.

Does it follow from this that it is impossible to write portable code in
C? No.

- Kevin.

 

[Roedy Green]

Is it possible to write non-portable code in C? Yes.

Does it follow from this that it is impossible to write portable code in
C? No.

Straw man argument Kevin.

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

I merely stated that writing cross platform code in C or C++ takes
considerable effort. It does not happen as a natural side effect of
coding the way it does in Java. 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. To get 32
bits on ALL platforms you have to use macros, and even then, there is
no guarantee of support.

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

 

[Roedy Green]

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

Have not you had to fake missing 64 bit support in some C compiler?

 

[Stephane Richard]

Excellent points on your side as well Peter.

And indeed my comments below
--
Stéphane Richard
Senior Software and Technology Supervisor
http://www.totalweb-inc.com
For all your hosting and related needs

Thanks for the response, Stephane.

Some good points.

My comments below...



No. I'm not saying that. The "limits" of my view are bounded by BUSINESS (ie
commercial) application development. I don't know what will happen in
programming research labs (and, to be blunt, I'm not really
interested...hopefully, there will be some exciting developments, that will
eventually trickle through to commerce, but that isn't where my particular
personal interest lies.)

I have to say that this is exactly where my interest lies. Because
ultimately out of these labs will come out the new intelligent stuff that
you mentionned. But I know that this simulated knowledge based analysis
does exist, I've programmed one myself in one of my contracts...business
rules and knowledge saved in "intelligently designed databases" from which
it is possible to generate a whole process "program" based on the knowledge
incorporated in the knowledge base. There are teh so called expert system
wich are pushing their limits further and further away. The whole A.I.
industry is makign tremendous progress as well as robotics. now sure it's
possible to really push forward the "data processing" side of programming
and database related dtechnologies, SQL Server has introduced it's "natural
english query language" not perfect but a step in teh right direction to
incite non programmers to interrogate their own data based on teh business
knowledge that they have. I see that happening too . I guess I'm
saying that like in genetics, I wonder how good it is to see if we can do it
before we take the time to see if we SHOULD do it. if we push things to
extremes, how would you feel if a conputer was responsible for pushing the
red button to start WW3 ? no matter how much knowledge it may have to
evaluate a situation? I wouldn't feel too good about it. .....be
investing in nuclear shelters ASAP hehehe... It's ok to push it, it's not
ok to push it too far. Even at the scale of a user based programming
concept.

do amazed

I would agree with the above. The question is HOW we unleash this potential
in the future. I believe it won't be by Procedural code. (There are many
reasons for this... and I am NOT suggesting that NO-ONE will be writing
procedural code. It just won't be commercially viable to develop business
solutions in this way. In fact, it isn't even today. It's just that there
has been no alternative for 40 years...)

**** Well the first alternative there has been was the coming of the
BASIC language which was originaly mean as the "easy way out" or
"Programming for the rest of us" kind of system. And that's been so for a
while after it came out. Then cam procedural programming

About 12 years ago or so, a product called Clarion (database development
system) attempted to give application development a new twist....by
attempting to manage and develop an application from the same integrated
system with screen generators, report generators, query generators,
relationship generators a good complete package at the time. to no avail
however. Almost as if the user (or dare I say lesser programmer at the
time) wanted anything to change about the way you develop an application.

Later Borland dared to push the wall of user to developer as thin as it
could get with their "ObjectVision" development suit. even much less
programming and any kind of logical "way of thinking" was required. it was
as visual as it could get (back then) and the main thing you had to worry
about was that reporting formulas and input masks (along with validation
rules). Their motto was (not quoted but somewhat close) create an
application with your mouse. and that failed faster than you could get a
blue screen on windows (back then, that says all...hehehe).

**** And now CASE Tools are emerging, knowledge base concepts as well,
and we have yet to see how far these technologies can go in replacing
programmers. As a programmer, I would never use something that doesn't
give me 100% of the control of what I can do with it. As a user, that need
becomes secondary to those "results" you mention but at what price? How
much more is a user (commercial or not) willing to be responsible for if
everything fails because he was empowered to do it instead of a developer?

Corporately it's not a wise business decision. not yet anyways. and the
problem today is that no business want to invest in R & D .... they seem to
expect us, the programmer, to spend the long nights and weekends in front of
our systems...develop a revolutionary programming or user interaction
concept (give them all this free time weeks, months, years even) and if they
are interested then maybe they'll see what's left to do. How fast can a
commercial market expand itself when they aren't willing to pay for the
tools they need for their expansion? I see a circle forming itself here
.

No, that is pushing my argument beyond its limits and I couldn't defend such
a position. I am not speculating on the "whole computer industry", only
commercial systems development.

**** Good to hear, I pushed it that far to see your realm of application
scales

The question is whether those "programmers" will be human... We already have
computers that monitor computers. In heuristic systems, programs modify
themselves so fast that the only way to know what happened is to monitor it
with another computer. While this is outside the arena I have defined for my
speculation, it is interesting and fun to look at.

Well see we have windows that's so fast at screwing itself that there IS NO
way to know what happened? is that a close enough adjacent frame of
thought? hehehe...sorry I had to throw that in there. I've heard of those
here and there in my many A.I. readings, and indeed this is good for the
user oriented approach. No user will spit on doing less and getting more
done in the process. even me as a programmer, if I can take Rational
Rose...Give it my frame of mind and it gives me a framework on which I can
build and finalize it's functionality, I dont see why i would spit on that
myself. However, that goes for as long as it gives me full access to what
it did and full permission to change any part of it. There will always be
people (even in the business/commercial and user oriented concepts) that
will want all the rights and all the permissions and tehre will always be
people that quite symply dont need it. the "in between" of these 2 extremes
is what will shift towards one side or another, and probably shift back and
forth until the end of times ...

I see a time when some programs will attain a result (based on trial and
error and a program modifying itself several trillion times within a few
minutes) where it will not be (humanly) possible to know HOW it arrived at
the solution. We'll just be thankful we HAVE a solution. There will be no
way of knowing whether the solution is optimum. The best we could do is run
the program again and hope for a shorter result...

Ahh but then, how will they get the shorter result? Wait for a faster PC to
arrive? or get the system to reevaluate itself? I always say the short
distance between two points isn't a straight line, it's teleportation.
.....How many more business knowledge with the computer need, compared to
what already has (which was initialy supposed to be enough to come up with a
solution to the original problem) in order to do it faster, in less steps,
etc etc....Take the tower of hanoi, 14 steps I believe is the shortest
possible number of steps to solve it. What will tell the future computer
that it was supposed to stop at 14? if we have the knowledge that 14 moves
is in there but all the magnificant A.I. believes it can do it in less and
tries to find a solution it never will find..."endless loop" Take the film
War games, where they whole faith of humanity was a race against time
between two processes running on the same computer? a global thermal
nuclear war simulation and a game of tic tac toe? and the game of tic tac
toe won?

This means a computer will attain a result and NO-ONE will know HOW it did
it.

As a Programmer, you may find this an exciting prospect, or you may find it
terrifying. (personally, I'm in the former category). No matter how you feel
about it, it will happen (has already, actually...).

**** As I mention it's exciting in one category only.. and different
categories of terrifying in the rest of them . I think the 3 laws of
robotics, the ones created by Azimov should indeed be translated and applied
to the computing industry.

Your statement regarding computers and programmers may be suspect.
**** Suspect? as in?

I have tried to give you some return on your investment...<G>

**** and indeed you have, but now, I am yet another couple dollars ahead of
you ...

**** I must say I do enjoy exchangings thoughts and views with you, I think
we'll both come out winners in the end. which I hope doesn't arrive
anytime soon

 

[ghl]

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.

Roedy, please rethink this. Anyone coding while thinking an int is 32 bits
or 16 bits is coding wrong. An int is a type, and a type defines a variable
that can contain a specified range of values. That is, a type specifies the
range of values that the named area in memory can contain. An int is defined
in C/C++ as a named area in memory that can contain the values -32768 thru
32767. It has no implied "length" or number of bits. This is different from
Java, where the creators decided to define BOTH the range of values of a
type AND the implementation memory usage.

But in C, a program designed to use an int is only guaranteed that the
memory area will be sufficient to handled the range of values of an int,
regardless of the actual number of bits used. A program written using an int
works for that variable on any standards compliant C compiler.

 

[Kevin Easton]

Straw man argument Kevin.

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

No, I didn't. You must have me confused with someone else (I jumped in
to this thread after seeing the post about fixed size ints).

I merely stated that writing cross platform code in C or C++ takes
considerable effort. It does not happen as a natural side effect of
coding the way it does in Java. 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. To get 32
bits on ALL platforms you have to use macros, and even then, there is
no guarantee of support.

No, again, to get 32 bits on all platforms you just have to use long
int.

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

You really don't.

However, comparing C with Java is not comparing apples with apples.
ANSI C is more portable than Java in that ANSI C code will compile and
run unmodified on more platforms - but then ANSI C is a much less rich
language than Java (in particular, it doesn't contain specific network
or windowing support). If you want to have a language as rich as Java,
you must use C-augmented-with-libraries - for example,
C-plus-Berkeley-Sockets has networking support, but the concordant
payoff is that it is less portable than plain ANSI C.

- Kevin.

 

[Kevin Easton]

[...]

....and one more thing...

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

It's true that writing portable code in C requires that you know what
you're doing, and that because the language doesn't force incorrect code
to fail, you don't always get a lot of help from smoke-tests - but
that's true of coding in C generally, and is (I would consider) a
seperate issue.

- Kevin.

 

[Bent C Dalager]

However, comparing C with Java is not comparing apples with apples.
ANSI C is more portable than Java in that ANSI C code will compile and
run unmodified on more platforms

One interesting feature with Java is that while the VM stays the same
across platforms (ignoring MIDP and its like), they have introduced
varying environments that cause a few of the same problems for Java
portability (across environments) as C has for its portability across
platforms. As an example, if I want my Java app to be able to run both
as a normal application and as a Java Web Start application, I must
have conditional code for opening a file. If it's a regular app, I
just use JFileChooser/FileInputStream but if it happens to be running
within a Java Web Start security constrained environment, I need to
use the jnlp file open services to do the same (and be prepared that
the user might turn down the request).

It's a bit ironic that Sun couldn't find a cross-environment solution
to this

Cheers
Bent D

 

[Marco van de Voort]

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.

.... If a platform supports GTK, it supports GTK ...

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.

For the record: I like having something like Java/SWING combination on the
shelf for special purposes. However for me for normal use the disadvantages
of are bigger than the advantages. (non native feel, versionites, speed etc,
less portable)

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

Again, nice ideals, but are those chances actually lower than the chance
that J2SE exists on that platform? Don't think so..

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.

However that makes J2SE much more bloated and one-size-fits-all, which
actually hampers portability.

Platform independent code happens naturally with almost no effort in
Java. It is requires considerable effort in C++. You can't convince
me otherwise because I have done both.

Me too for the opposite

 

[Peter E.C. Dashwood]

Jimmy,

your post raised a few questions.

Perhaps you could elucidate...?

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(lists) 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 SortedCollection :-

How can a queue (FIFO) and a stack (LIFO) be implemented with an ORDERED or
SORTED Collection?

By definition, these collections have to be UNORDERED or UNSORTED.

I certainly hope J4 are not going to overturn the accepted concepts of queue
and stack in order to implement these collection types. But then, nothing
they did would surprise me...

*>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

What about retrieving subsequent members of the queue or stack?

Are you actually removing the members by retrieving them?

If you are, then the code posted will certainly work, but only so long as no
members arrive in the interim...

If you are not, then the code posted will only succed for the first member
of the queue or the last member of the stack.

Usually stacks and queues are dynamic structures with members being stored
and retrieved constantly, at random intervals.

Methods to manage them would need to be a bit more substantial than simply
getting the first member of a queue or the last member of a stack

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>.

Is he "REALLY using OO COBOL"...?

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 free or cheapest tools you can get to do a job is quite distinct
from using the best tools available to do the job.

If you can't afford to use the "right" tools for the job I don't see any
dishonesty in saying so.

Eiter way, it doesn't alter the fact that using the right tools for the job
(rather than making whatever tools you have fit the job) is a preferred
strategy.

"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".

As you don't quote the OCX site, we can't judge for ourselves whether the
suggested component was appropriate or not.

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.

Trapping a Windows or keyboard event is feasible in any language that deals
with GUI development. What makes COBOL (even OO COBOL) MORE "right" for this
than VB, C, C++, or Java?

People who used the recommended OCX component wouldn't care what language
they embedded it in, and they have the same re-use advantages that you
realised by doing it in COBOL.

The point here is that components transcend languages.

(That is one reason why I personally consider them a better solution...)

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 !

This is a total non sequitur. What has my support of components got to do
with anything you posted? The implication seems to be that by opting for a
component based approach, I am not "REALLY" using OO COBOL.

That is unfair and uncalled for.

I don't really mind whether you think I do so or not, and it is just one of
the tools I use, but I have been using it long enough that I was able to
post an analysis and explanation of it to an ASP based Web site, at a time
when you were assuring the COBOL community that "nobody understands OO
COBOL".
(Here's the link, in case you've forgotten...:
http://www.aspalliance.com/aldotnet/examples/coboldotnet.aspx)
The same link also contains the advice regarding "best tools for the job"
which you were so dismissive of above...)

Now your understanding has advanced to the point where you know how to
handle some Windows events in it...

Keep going...eventually you may learn how to build components with it...

If that happens, maybe we can talk.

Pete.

 

[John D.]

I merely stated that writing cross platform code in C or C++ takes
considerable effort. It does not happen as a natural side effect of
coding the way it does in Java. 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. To get 32
bits on ALL platforms you have to use macros, and even then, there is
no guarantee of support.

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 you really need to enforce int range then it can be easily done
with typedefs (int16, int32, int64). It is just one macros buried in the
project config file. Besides, if the libraries you chose are portable
then they already define types consistent accross platforms.

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

You need to test on separately even Java applications because of
differences in JavaVM implementations from different vendors/different
platforms. If you encounter these differences you are pretty much stuck
since there are no compile-time macros to help you.

 

[goose]

Don't be silly.
????

Look at any C code designed to run on many platforms.

yes, I am looking at a helluva lot of code I wrote.

It is riddled with macros to pull off the feat.

I dont seem to find macros designed to do that ... what
do you think the problem is ? me not being able to see
that "of course C cant run on many platforms without
macros" or you not being well-trained enough to know about
even the C standards ???

You can do a few simple things like parse the command line, open a
flat file in a platform independent way, but not even the size of int
is guaranteed unless you play some games with macros.

dammit!!!

yet another lie!!!! the values you can hold in an int are *guaranteed*.
do you *understand* what that means ??? is english your 2nd language ?
do you have problems with comprehension ????

i'll repeat:
the minimum and maximum values of an int are *the* *same* on every
conforming implementation!!!

You certainly can't write to a gui without some cross platform library
which is not part of C. Java is in a quite different position. The
standard class libraries are everywhere Java is supported.

but the point is that java is supported on so *few* platforms, that
calling it platform-independant is ludicrous.

C is a portable assembler.

a nice quote i've seen before. luckily, its not true.

Making code run absolutely unmodified on all platforms and giving the
same results would interfere with its use as a portable assembler.

non-sequiter ???

Have you written any cross platform C or Java?

I've written cross-platform C code, not cross-platform java ...

(cross-platform java is an oxymoron).

a trivial example is a tic-tac-toe library. a set of functions
that allow to users to *play* the game and decides who wins.

I can post the source (have nowhere to host it), so that you can use
it in *your* application. thus far I've had it compiled and working
for :
point of sale machines.
an atm
a credit-card-swipe machine.
a smartcard reading+verification terminal.
normal PC's using windows, linux and bsd
the hitec C compiler for the PIC 16f877
the CCS compiler for the PIC 18f542

I've no doubt that it will also compile successfully
on the sun enterprise servers, on the 4-way xeon boxes
from ibm.

i *think* it will compile with avr-gcc, and for most
of the other 8051 variants, I haven't tried as my knowledge
wtr 8bit MCU is confined PIC (about to change, though.

would you like to write a library that plays tic-tac-toe ?
we'll see on how many places it will run unmodified, ok ?
you *can* decline this, but doing so means that you must
stop spouting bs about how "C is not cross-platform" ...

ok ?

if the stoplights down the road from where I live
run PICs, it would be possible (with *no* changes to the
"business logic" that actually *plays* the game) to
*play* tic-tac-toe using the red/green/orange/
east-facing/west-facing/north-facing/south-facing combinations
available to repesent the 3x3 board!

now *thats* cross-platform ...

yes. the same source code *unmodified* will run on those
stoplights *and* on a resource intensive server.

the reason, of course, is because I built it as a *library* !
go on, build your library that will run *everywhere* and show me
I'm wrong about cross-platform-ness wrt to java and C.


goose,
C ? Portable assembler ? please ... i feel nauseous enough
already ...