Future reuse of code

S

Scott Moore

Please STOP crossposting to comp.lang.pascal.ansi-iso. This thread
has nothing to do with that forum.

Thank you.
 
M

Marco van de Voort

On Sun, 17 Aug 2003 14:03:37 +0000 (UTC)


The HP Pascal I mentioned was *not* an embedded Pascal.

Neither is VC++, or BC.
Anyway, as far as I'm aware all C implementations support the same
mechanism for separate compilation of modules so you don't have the same
problem.

Hmm. Prototypes etc? Afaik K&R had no modules or prototypes at all, the
separate compilation were just externals, and parameters didn't even had
to match. (iow everything happened on linker, not langauge level)
The Texas Instruments implementation of C for the TMS320C1x/2X/5X was a
fully conforming implementation and even came with a copy of K&R2 as
part of the documentation set. This was at the same time I was dealing
with all those different Pascals...

K&R is no standard. ANSI is.
~>> which older language doesn't have that?
Pascal is IMHO worse because the original definition did not include
support for separate compilation of modules. For this reason (and
probably others) K&R C is more likely to compile on a modern compiler
that supports ANSI C than Pascal written for any of the compilers I
mentioned.

That's not true afaik (but I'm no expert, just from the old BSD days). Most
K&R code mismatches or omits parameters between declaration and compilation.
This was only fixed with the formal prototypes in some later standard.
This is irrespective of whether it was embedded or
non-embedded C or Pascal.

Embedded versions are often simplified, and therefore often base
on older versions. Judging the state of Pascal by those is a bit odd.
C & C++ are two distinct languages, yet you can link them relatively
easily...

C++ nearly includes C, even though they are formally separate languages.

Link compability is a compiler/linker thing anyway though, and has not much
to do with the language. At least if the language wants to remain portable :)
You probably mean that C++ and C FROM THE SAME VENDOR reasonably link well.

OTOH that is not a problem. Most Pascal compilers also link to C. They
probably also can link to eachother, only on a deeper level (directly
passing file handles instead of file descriptors etc)
So ANSI Pascal is largely irrelevant to the Pascal community ;-)

In practice yes. But the Borland group, while it far outnumbers ANSI, is
x86 (and often even x86/win32) centric. So if you go outside x86, you'll
encounter quite a lot of ansi.
I bet you can use a lot of conforming C code not written for the 8051 on
an 8051, since I bet there is a conforming implementation.

Maybe, but that would really strain those 256 bytes of memory.
I don't know about anyone else here, but I use the standard as a way of
ensuring that my code will run on multiple platforms with minimal
difficulty (I do have to use platform specific extensions in limited
areas) and not as an end in itself.

Yes. It is a very limited help of trying to verify that. But in practice,
the standard is often not enough to build an average application.
In C you can access most of the C code base whether it was originally
targeted for embedded or hosted environments. Obviously on an embedded
environment without a file system you can't use file oriented libraries,
but you could use some MD5 code written for a PC.

Quite a lot of code isn't very conforming (I can remember having to fix
nearly every program when I got an Alpha machine)

But except for that (and those original K&R code), you are somewhat right,
the problem is mroe that a fully standard C program is often trivial, and
no real app.

Something like that is nice to show to students, but not something for IRL.

But that doesn't mean (and I don't mean to imply) that the standard is
useless, on the contrary, I think the C situation *is* better.
I do think however the magnitude of the differences (specially when related
to standards) is severely overrated.
So do the majority of modern Pascal implementations support ANSI
standard Pascal?

Either that or Borland. Borland is proprietary, but so dominant that smaller
vendors (TMT,VP) follow it, and it also has following in the open source
community.
Both VC++ and gcc can compile ANSI standard C (I don't know Keile C51)
so as long as you keep your implementation specific code isolated

Sure, but that was not what I said. I said the compilers can't compile
an average program from the other.
(sometime I always try to do) then the bulk of your code will compile
and run correctly on both.

And be fairly trivial.
One major difference, almost all C compilers produced for a long time
have been able to compile ANSI standard C, I don't think the same can be
said about Pascal.

No, and probably never will. I don't dispute that. I'm just saying it is
overrated.
My experience was that *no* Pascal module compile on any compiler other
than the one it was written on because it would fail as soon as you
reached the line indicating it was a module rather than a program or as
soon as it referenced any other module, whichever came first.

Well, that is not my experience. The borland versions (generations is a
better world) are backward compatible till 1985, and ansi pascal is pretty
close to compability with even J&W pascal.
Windows has Posix compatibility layers, depending on what you want.

Sure. But that is not ansi isn't it?
also has GTK available if you want a common graphics handling code
between Windows and Unix.

(GTK on windows sucks, but)

GTK is also not exclusive to C. Actually the RAD of the pascal compiler I use
uses GTK on Unix platforms (but native winapi on win32)

Delphi does something similar, but uses QT.
As I say, I don't know Kiele, but it is possible to have code that can
be compiled by both VC++ and gcc. Look at Berkeley DB for one example.

I can also craft Pascal code accepted by (nearly?) every compiler, so what's
the difference?

(well, there actually is. The string handling of that code
will be clumsy. char ident[x] based like C, and that is not how you use
strings usually under Pascal)
 
J

Joe Zitzelberger

Mark Gordon said:
What if the JVM has not been ported to the processor you are using? Can
you find a JVM for any of the following processors?

Z80
6502
8051
TMS320Cxx

just to name 4 families of processor off the top of my head all of which
are used in *current* projects.

Even if you ported the JVM it would run like a snail on tranquilisers.

I used the Pascal byte code system, precursor and work-alike to modern
Java, on the 6502 and Z80. And yes, it did run like a snail on
tranquilisers. For that matter, so did highly tuned assembler and
compiled C.

Anyone who wants to license a reference implementation from Sun can do
so for $150,000, IIRC, and write a very think hardware layer to get Java
on thier chip/os.

There are also clean room clones available...
Also we had to upgrade from SCO 5.0.5 to SCO 5.0.6, something I'm told
was painful, on several customer sites in order to be able to run a
specific Java application. Java 1.4 is not available for earlier version
of SCO and was not available at that time for AIX, which another of our
customers uses.

I've not played with SCO for a while (1997 to be exact), but a minor
release ought not prevent you from running Java 1.4? What happened when
you installed it on 5.0.5?

As have the people talking about processors where the JVM is not
available.

A brief search of Google shows at least one JVM product targeted at the
6502, specifically C64, from mts.com. And a JIT compiler/runtime
targeted at Z80/6502 from Stanford. Also a hardware boost for th
6502/65816 family from Fawcett.

That is the first results page. I'm not sure what any of the statuses
are.

One program I wrote in C for an embedded system was debugged by me on a
Silocon Graphics workstation by running the code natively (not in an
emulator or simulator). All I had to do was replace the two functions
that talked to the hardware with one function to read test data and
another to interface to a graphics library and display the results.
The debugged code then ran perfectly on the embedded system without any
further changes.

Some companies actually hold code reviews to ensure that code is well
written, and obstreperous abstrads like be *do* reject code and insist
on it being rewritten if the job has not been done properly.

I think that is a great approach, but I also think it is a rarity to
have such reviews held. In my experience, "portability" usually means
running on all versions of Windows, or, at a streach, all versions of
Windows and some Linux. Something as trivial as endianess (because the
whole world really runs on Intel, doesn't it) is almost universally not
considered.
 
A

Alan Balmer

If we don't hear from each language, may we assume that particular language
doesn't have all the necessary tools ???? <G>

No, but you could assume not everyone wants to play your game.
 
J

James J. Gavan

Alan said:
No, but you could assume not everyone wants to play your game.

Why assume a game was being played ? It was a legit question, what techniques do
you use within your language to handle such a problem - I'm not 'voting' for one
outcome - a genuine enquiry as to how OO programmers would handle such, from the
features they have in their respective languages.

Please don't read into the message an alternative meaning. (If I had a hidden
agenda, be damned sure I would have asked the question in a very different
fashion).

Jimmy
 
M

Mark Gordon

Neither is VC++, or BC.

Both VC++ nor BC (if you mean what I think you mean) *can* compile ANSI
C, so they support my point.
Hmm. Prototypes etc? Afaik K&R had no modules or prototypes at all,
the separate compilation were just externals, and parameters didn't
even had to match. (iow everything happened on linker, not langauge
level)

K&R did not have prototypes, however the specification *did* allow for
the separate compilation of modules. That was standardised by C89.
However the language *did* specify that you could compile separate
modules (even having an extern keyword for specifying that an object
was external). It just does not specify how you invoke *any* of the
tools.

The original definition of Pascal did *not* specify any support separate
modules and provided no mechanism for specifying that an object was
external, so any support for separate compilation of modules was an
extension.
K&R is no standard. ANSI is.

The second edition (K&R2) is for ANSI standard C and is one of the most
commonly used and recommended reference books for it.
That's not true afaik (but I'm no expert, just from the old BSD days).
Most K&R code mismatches or omits parameters between declaration and
compilation. This was only fixed with the formal prototypes in some
later standard.

Prototypes were added with the ansi standard, but
extern int foo();
extern int bar;
were valid ways of declaring function foo() and variable bar without
defining them, thus allowing them to be defined in another module. The
original definition of Pascal had no such feature.
Embedded versions are often simplified, and therefore often base
on older versions. Judging the state of Pascal by those is a bit odd.

All the embedded C compilers I have used implemented the full
specification for a free-standing implementation. All of the Pascals,
including those that were *not* targeting embedded systems, used
non-standard, non-portable mechanisms for allowing access to symbols
defined in separately compiled modules.
C++ nearly includes C, even though they are formally separate
languages.

No, C++ will report diagnostics and probably abort compilation when
trying to compile a *lot* of ANSI standard C. For example, if the result
of a malloc call is not cast C++ will reject it where as not casting it
is the recommended approach in C.
Link compability is a compiler/linker thing anyway though, and has not
much to do with the language. At least if the language wants to remain
portable :) You probably mean that C++ and C FROM THE SAME VENDOR
reasonably link well.

The C++ standard explicitly defines some of how the linking of C and C++
is to be handled, such as the 'extern "C"' stuff you see in a lot of
headers. The C standard cooperates to the extend of guaranteeing a way
of identifying at compile time whether a file is being compiled as C or
C++ to allow you to share header files.
OTOH that is not a problem. Most Pascal compilers also link to C. They
probably also can link to eachother, only on a deeper level (directly
passing file handles instead of file descriptors etc)

However, there is no way defined to specify that external objects are
external C objects, unlike with C++. There is also no way to include a C
header file from a Pascal source file.
In practice yes. But the Borland group, while it far outnumbers ANSI,
is x86 (and often even x86/win32) centric. So if you go outside x86,
you'll encounter quite a lot of ansi.

Whatever processor you will find a lot of ANSI standard C, even for the
x86/DOS/Win world.
Maybe, but that would really strain those 256 bytes of memory.

I just checked, and version 7 of C51 claims ANSI conformance.
Yes. It is a very limited help of trying to verify that. But in
practice, the standard is often not enough to build an average
application.

I've written large C applications for real world problems as part of my
job where only a small amount of isolated code was implementation
dependant.

As part of my current job I work on an application with a few hundred
thousand lines of code which are slowly being migrated from K&R C to
ANSI standard C whilst also being maintained and further developments
done. The bulk of the implementation specifics are in a separate library
allowing *all* of the business logic to be written in either K&R C (for
the old stuff) or standard C89 for the new stuff. So that is probably a
few hundred thousand lines of C that will eventually all be written to
C98 and a *much* smaller amount of implementation specific code which
is steadily shrinking as we do a progressive rewrite.
Quite a lot of code isn't very conforming (I can remember having to
fix nearly every program when I got an Alpha machine)

But except for that (and those original K&R code), you are somewhat
right, the problem is mroe that a fully standard C program is often
trivial, and no real app.

Something like that is nice to show to students, but not something for
IRL.

As I say, I work on large *real* applications using standard C for 90%
(or more) of my work. Therefor it is useful for *real* work on *large*
projects.
But that doesn't mean (and I don't mean to imply) that the standard is
useless, on the contrary, I think the C situation *is* better.
I do think however the magnitude of the differences (specially when
related to standards) is severely overrated.


Either that or Borland. Borland is proprietary, but so dominant that
smaller vendors (TMT,VP) follow it, and it also has following in the
open source community.

So, you still can't share code with embedded systems. I can and *have*
done so for *real* work on *complex* applications.
Sure, but that was not what I said. I said the compilers can't compile
an average program from the other.

Berkeley DB (the one used to drive the Amazon web site, amongst others)
is built using gcc for Linux and VC++ for Windows. Maybe that is a well
written program rather than an average program.

The application I work on, several hundred thousand lines of code, used
to be built for Windows using VC++, for Linux using gcc and for HPUX,
SCO, AIX and Solaris using the standard compilers from the relevant OSs.
This is using the *same* source files in all cases. It is also software
that my company earns millions from annually.

I changed this to standardising on gcc because I wanted to and gcc is
available for all the targets we want to support.
And be fairly trivial.

Do you think an applications several hundred thousand lines long is
trivial? Or Berkeley DB which is used to power a lot of major web sites?
Or software for performing real time analysis of video data which I
debugged by running natively on a workstation before running
*unchanged* in an embedded system?
No, and probably never will. I don't dispute that. I'm just saying it
is overrated.

Well, standard C is very useful for us C developers for writing *major*
applications.

If, on the other hand, I wand to quickly knock up a toy GUI applications
I'll reach for VC++, Delphi or similar and sod portability.
Well, that is not my experience. The borland versions (generations is
a better world) are backward compatible till 1985, and ansi pascal is
pretty close to compability with even J&W pascal.

I know that Borland Pascal is vastly different from any other Pascal
I've used (I forgot to mention having used Turbo Pascal 5.5 and Borland
Pascal).

So you have one manufacturer providing backwards compatibility with it's
own products, other trying to hit this moving target and some compilers
that aren't quite ansi compliant. Whereas for C we have almost every
compiler written since the early 90s supporting standard C.
Sure. But that is not ansi isn't it?

So you keep your hooks to it isolated in one module. Then you have a few
percent of your code to rewrite and the bulk of it standard. I know, I
*do* this on *large* projects.
(GTK on windows sucks, but)

GTK is also not exclusive to C. Actually the RAD of the pascal
compiler I use uses GTK on Unix platforms (but native winapi on win32)

Delphi does something similar, but uses QT.

I didn't say that you could not interface to cross-platform graphics
libraries from Pascal. I was pointing out that the libraries not being
part of C was not a major problem.
As I say, I don't know Kiele, but it is possible to have code that
can be compiled by both VC++ and gcc. Look at Berkeley DB for one
example.

I can also craft Pascal code accepted by (nearly?) every compiler, so
what's the difference?

(well, there actually is. The string handling of that code
will be clumsy. char ident[x] based like C, and that is not how you
use strings usually under Pascal)

So you have to use a sub-set of Pascal where as I have the whole of C
available to me.

I also have implementation specific extensions for the small percentage
of the code (normally under 10% on the applications I've dealt with)
that requires it.
 
J

Joe Zitzelberger

I used the Pascal byte code system, precursor and work-alike to modern
Java, on the 6502 and Z80. And yes, it did run like a snail on
tranquilisers. For that matter, so did highly tuned assembler and
compiled C.

Anyone who wants to license a reference implementation from Sun can do
so for $150,000, IIRC, and write a very think hardware layer to get
Java on thier chip/os.

That is a lot of money to spend compared to the cost of a C
implementation and it probably still won't help you for all the target
I mentioned.[/QUOTE]

It is a lot of money. But the last time I checked 45-odd OS vendors
(SCO being one of them) has spent it to enable a JVM and Standard Java
(J2SE) on their OS. You are looking to use a tiny, underpowered, way
out of date chip and asking for future reuse in 10 years. It just isn't
going to happen -- the 6502, even with the billion-plus that have been
sold is not good for much more than controlling a stop light these days.

The origin of this thread was someone looking for a language to
(re)write an enterprise application in with an eye to being able to use
it in 10 years.

For the same reasons that I don't worry about being able to run
Enterprise Cobol and DB2 on an IBM-7090 machine -- I don't think it is
overly reasonable to worry about running a full featured JVM on a 30
year old version of a 65xx or Z80 chip.

I can say with great certainty that there are no enterprise data centers
running on any of the afore mentioned chips. Not even any desktops
anymore.

Taking 20K for the JVM when you have a limited memory space could be a
problem. It would not run on the systems where we only had 8K of ROM and
2K of RAM.

Embedded is a different world from enterprise, but given the cost of a
6502 (about USD$0.25 when I last checked 10 years ago) and the cost of
20k of RAM (even less), I'm not certain I would lose sleep over it
unless i was shipping a huge number of units.

Still, as you pointed out -- the snail on Qualudes looks quite zippy. I
would think that given the limited memory space and the slow processor
speed that you would not want any library code and would want everything
hand-tuned.

One of the reasons I recommend Java as 'portable' for non-embedded use
is the vast, standard, binary-compatible library that is available in
every installation. C/C++ doesn't have anything like that very rich
library availabe on every non-embeded computer from lowly palmtop to
huge mainframe. Where such libraries do exist for C/C++ they require at
the very least a recompile of the application (best case) or a very
serious rework of several things followed by plenty of debugging (usual
case) in order to move code across OS/machine combinations.

And finally, there is no C/C++ compiler and library that is completely
compatible over the 45ish platforms that Java is. I'm not even sure
there is a C/C++ library that is a complete as the J2SE, though perhaps
I have missed some.
Real reviews are mandated on projects for the military and for safety
critical projects. -and-
The application I am currently working on is several hundred thousand
lines of code and it runs on both big and little endian machines and
both Windows and a variety of Unix derivatives.

For the binary files the original author just chose one endianness and
wrote some code to explicitly read the files as bytewise as that
endianness.

I'm glad to hear that you do the reviews on the safety and military
projects, but you are in the minority. Take any Micro$oft product
(please) -- does their rate of fatal flaws make you think they do
reviews of any sort?
 
D

Dr Engelbert Buxbaum

Peter E.C. Dashwood wrote:

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. By 2015 a new generation of development software will see
"programmers" removed from the loop and end users interacting and iterating
with smart software until they get what they want.

Sounds like something big, clumpsy, slow and limited to some narrow set
of tasks, that one could just as well do without.
Procedural code is already into Gotterdammerung. It takes too long, requires
too much skill, is too inflexible (the accelerating rate of change in the
Marketplace and in technology is another reason why it is doomed to
extinction) and, overall, costs far too much.

I have a different experience. Whenever I have a complicated data
evaluation task, I write a little pascal program to parse the data
(which sometimes come in a strange format out of lab equipment) and do
the necessary calcualtions. I keep a library of common task like
integrating statistical distributions and the like, which can be
recycled.

This is frequently easier than using a spreadsheet for that purpose,
which was supposed to be the easy solution for people who can not or do
not want to programm.

Such programs can be quick and dirty jobs with the charme of a
Unix-filter, as I am the only one using them. For that reason I am even
disappointed by the development that Delphi/Kylix has taken over the
last 10 years: Bigger, more complicated and worse documented. It may
help profesional programmers who need to make nice user interfaces. But
little guys like me who just need a job done were better off with good
old Turbo Pascal.
 
P

Peter E.C. Dashwood

JC said:
Hollerith Cards at dawn??
LOL! I guess that would be quite appropriate, however, I refuse to engage in
a battle of wits with someone who is completely unarmed...<G>

Pete.
 
A

Alan Balmer

<top-posted on purpose>

Hey, guys, please remove comp.lang.c from your distribution list. We
have our own brand of flames, and yours are off-topic.
 
A

Alan Balmer

Why assume a game was being played ?

It was a legitimate deduction from those portions of your
mini-flamefest which are visible from comp.lang.c. I, for one, would
appreciate it if no more of this thread were visible from c.l.c.
Surely the other four newsgroups you cross-posted to are a wide enough
audience?
 
L

LX-i

Alan said:
<top-posted on purpose>

Hey, guys, please remove comp.lang.c from your distribution list. We
have our own brand of flames, and yours are off-topic.

If goose is going to post in ours, we're going to post in yours. ;)


--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~ / \ / ~ Live from Montgomery, AL! ~
~ / \/ o ~ ~
~ / /\ - | ~ (e-mail address removed) ~
~ _____ / \ | ~ http://www.knology.net/~mopsmom/daniel ~
~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
~ I do not read e-mail at the above address ~
~ Please see website if you wish to contact me privately ~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
P

Peter E.C. Dashwood

Alan,

I have nothing more to say that needs to be cross posted (either on-topic or
off-topic) and I'm sorry if these very short posts bothered you.

Just as a matter of interest, is this a moderated forum? I was under the
impression that the language forums are unmoderated and uncensored.

If I'm wrong about this, I sincerely apologize.

Either way, I'm unlikely to post here again.

Pete.
 
G

Grinder

Such programs can be quick and dirty jobs with the charme of
a
Unix-filter, as I am the only one using them. For that reason I am even
disappointed by the development that Delphi/Kylix has taken over the
last 10 years: Bigger, more complicated and worse documented. It may
help profesional programmers who need to make nice user interfaces. But
little guys like me who just need a job done were better off with good
old Turbo Pascal.

I hear what you are saying -- it is true of so many
environments.

As for Delphi, though, I've found it simple to create projects
that don't use any additional libraries -- that accounts for
about half of my Delphi projects. Tidy (but not necessary
tiny) console applications that rarely break 50k. To each his
own, but I don't want to give up my windows IDE, even if I'm
not programming a windowed application.

....just an unsolicited two cents.
 
S

Scott Moore

Please stop crossposting to comp.lang.pascal.ansi-iso. This topic is not
relivant to that group.

Thank you.
 
M

Marco van de Voort

I hear what you are saying -- it is true of so many
environments.

As for Delphi, though, I've found it simple to create projects
that don't use any additional libraries -- that accounts for
about half of my Delphi projects. Tidy (but not necessary
tiny) console applications that rarely break 50k. To each his
own, but I don't want to give up my windows IDE, even if I'm
not programming a windowed application.

Bloodshed Dev Pascal (site: bloodshed.net). this is a Windows IDE on top of
the Free Pascal compiler, and that IDE is programmed in Delphi, and source
is available.
 
G

gary drummond

LX-i said:
What? COBOL is obsolete? I guess OO and .NET are obsolete too... ;)

Well, if they are working, in several years they won't even compile
the original source!

I purchased M$ Pascal for a college class, but the extra code to handle
text was larger than the code for the class assignment. M$ used non-ANSI
formats. The same for C and C++. I had to buy Borland to use it at home
for classroom assignments. M$ changed the C/C++ so much I couldn't use
it a year later ($300 down the tubes). From the thread, it sounds like
VB is in the same condition.

I can still compile and execute my COBOL programs from 15-30 years ago,
and have ported them to Microfocus and Fujitsu, with very little effort.

Whatever language you pick, if M$ has the standard implementation, it
WILL change, based on marketing impact and not functionality or
industry/ANSI standards.

Gary

Post to the group, this email address is forwarded to (e-mail address removed)
or userid=gdrumm at ont dot com to contact me direct.
 
D

Dave Thompson

On Fri, 15 Aug 2003 01:25:48 GMT, Kevin Easton
If it doesn't support fopen, then it's not a hosted C implementation.
True. As detailed in other responses.
If it doesn't handle identifiers case-sensitively, then it's not a
conforming C implementation at all.
True in C99, to which *very* few implementations (so far) conform, but
in C89 (6.1.2) they "may restrict the significance of an _external
name_ (an identifier that has external linkage) to six characters and
may ignore distinctions of alphabetical case for such names. [footnote
reference to 6.9.1 future language directions, which categorizes this
as obsolescent, meaning that it might be deleted in the future, as
indeed it was.] These limitations on identifiers are all
implementation-defined [meaning they must be documented]."

I don't know whether it is in fact still needed, or a good idea, on
the current descendants of OS/360 (or CMS?), and yes it is certainly a
pain in the wazoo, but it is conforming.

Note this is for *external* identifiers; static=internal-to-file
(really translation unit = preprocessed file) and local names, and
preprocessor macros, are 31 characters dualcase in C89 and 63 in C99,
but except for macros in system or projectwide headers these don't
normally present much difficulty in keeping names unique.


- David.Thompson1 at worldnet.att.net
 
J

Joona I Palaste

goose <[email protected]> scribbled the following
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

Do you know of implementations of C that run in under a K of RAM, then?

--
/-- Joona Palaste ([email protected]) ---------------------------\
| Kingpriest of "The Flying Lemon Tree" G++ FR FW+ M- #108 D+ ADA N+++|
| http://www.helsinki.fi/~palaste W++ B OP+ |
\----------------------------------------- Finland rules! ------------/
"Normal is what everyone else is, and you're not."
- Dr. Tolian Soran
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,744
Messages
2,569,483
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top