Future reuse of code

[goose]

Re: Future reuse of code

Roedy Green <roedy@mindprod .com> wrote in message news:<r2qnjv47q hjmtoib3k8lpe98 cfmlm3192j@4ax. com>...[color=blue]
> On 14 Aug 2003 06:02:20 -0700, ruse@webmail.co .za (goose) wrote or
> quoted :
>[color=green]
> >thats a lie again. C is cross-platform.
> >period.[/color]
>
> Don't be silly.[/color]

????
[color=blue]
> Look at any C code designed to run on many platforms.[/color]

yes, I am looking at a helluva lot of code I wrote.
[color=blue]
> It is riddled with macros to pull off the feat.[/color]

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

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

but the point is that java is supported on so *few* platforms, that
calling it platform-independant is ludicrous.
[color=blue]
>
> C is a portable assembler.[/color]

a nice quote i've seen before. luckily, its not true.
[color=blue]
>
> Making code run absolutely unmodified on all platforms and giving the
> same results would interfere with its use as a portable assembler.[/color]

non-sequiter ???
[color=blue]
>
> Have you written any cross platform C or Java?[/color]

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+verific ation 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 ...

[goose]

Re: Future reuse of code

Roedy Green <roedy@mindprod .com> wrote in message news:<mmbojvs87 5oftp6v7vgilnbl me09s0bihi@4ax. com>...[color=blue]
> On Thu, 14 Aug 2003 23:02:16 GMT, Kevin Easton
> <kevin@-nospam-pcug.org.au> wrote or quoted :
>[color=green]
> >People who *think* they need an exact-width type, rather than an
> >at-least width type, are usually wrong.[/color]
>
> 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.[/color]

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

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".
[color=blue]
>
> You are defending C++ as if you were defending your favoured football
> team, with emotional loyalty, giving it imaginary virtues, and[/color]

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.
[color=blue]
> imagining it would be impossible for it to be anything less than all
> things to all people.[/color]

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

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]

Re: Future reuse of code

Roedy Green <roedy@mindprod .com> wrote in message news:<3vdojvs3a sc4icm23agl41sf uhct80dpf7@4ax. com>...[color=blue]
> On Fri, 15 Aug 2003 01:21:55 GMT, Kevin Easton
> <kevin@-nospam-pcug.org.au> wrote or quoted :
>[color=green]
> >It is impossible to
> >write incorrect Java code?[/color]
>
> The difference in, that equivalent program in Java would either work
> or not work. It would give the same results on all platforms.[/color]

you eman "it would give the same results on the few platforms
that java supports", not "all platforms" ...
[color=blue]
> With
> the C version, you don't know if it works on other platforms until you
> test it.[/color]


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

goose

[goose]

Re: Future reuse of code

Roedy Green <roedy@mindprod .com> wrote in message news:<2peojvcoo efi2ns75l3on5mk r3rmomtr77@4ax. com>...[color=blue]
> On Fri, 15 Aug 2003 01:43:18 GMT, Kevin Easton
> <kevin@-nospam-pcug.org.au> wrote or quoted :
>[color=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.[/color]
>
> Straw man argument Kevin.[/color]

you dont have a leg to stand on. this is no straw man argument!!!
do you even know what that means ?
[color=blue]
>
> You made the silly assertion that ALL C code would run unmodified on
> any platform correctly. That is nonsense.[/color]

no. i think he made a statement to the effect that "all std-compliant
C code will run on and std-compliant implementation" .
[color=blue]
>
> I merely stated that writing cross platform code in C or C++ takes
> considerable effort.[/color]

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.
[color=blue]
> It does not happen as a natural side effect of
> coding the way it does in Java.[/color]

get off your java high horse, no one is attacking it, why are you
defending it ?
[color=blue]
> 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.[/color]

for the *last* time, "int x" means the *same* *thing* on all
std-compliant platforms, it does not mean *different* things.
[color=blue]
> To get 32
> bits on ALL platforms you have to use macros, and even then, there is
> no guarantee of support.[/color]

????
read the C std, and you will realise that sizes of datatypes are
*guaranteed*, not /suggested/.
[color=blue]
>
> You need to test separately, and you need a ton of compile time
> macros to make the magic work.[/color]

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

goose,

[Roedy Green]

Re: Future reuse of code

On Fri, 15 Aug 2003 01:49:11 GMT, Roedy Green <roedy@mindprod .com>
wrote or quoted :
[color=blue][color=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.[/color]
>
>Straw man argument Kevin.[/color]

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.



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

[goose]

Re: Future reuse of code

Chris Dollin <kers@hpl.hp.co m> wrote in message news:<bhg60c$1n v$1@murdoch.hpl .hp.com>...[color=blue]
> goose wrote:
>[color=green][color=darkred]
> >> Even the size of an int is not nailed down for heaven sake.[/color]
> >
> > yes it is, read the std.[/color]
>
> "At least 16 bits" doesn't count as "nailed down" for me.[/color]


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 "portabilit y"

[Jacob]

Re: Future reuse of code

goose wrote:
[color=blue]
> i showed plenty of evidence that this is not true (C, for example,
> targets many more platforms than java).[/color]

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]

Re: Future reuse of code


"goose" <ruse@webmail.c o.za> wrote in message
news:ff82ae1b.0 308150113.6703e 5dd@posting.goo gle.com...[color=blue]
> Roedy Green <roedy@mindprod .com> wrote in message[/color]
news:<2peojvcoo efi2ns75l3on5mk r3rmomtr77@4ax. com>...[color=blue][color=green]
> > On Fri, 15 Aug 2003 01:43:18 GMT, Kevin Easton
> > <kevin@-nospam-pcug.org.au> wrote or quoted :
> >[color=darkred]
> > >Is it possible to write non-portable code in C? Yes.
> > >
> > >Does it follow from this that it is impossible to write portable code[/color][/color][/color]
in[color=blue][color=green][color=darkred]
> > >C? No.[/color]
> >
> > Straw man argument Kevin.[/color]
>
> you dont have a leg to stand on. this is no straw man argument!!!
> do you even know what that means ?
>[color=green]
> >
> > You made the silly assertion that ALL C code would run unmodified on
> > any platform correctly. That is nonsense.[/color]
>
> no. i think he made a statement to the effect that "all std-compliant
> C code will run on and std-compliant implementation" .[/color]

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]

Re: Future reuse of code

Roedy Green <roedy@mindprod .com> wrote in message news:<d9bojvkeu 50eebvd7dk3i7v7 mqcq1qnsur@4ax. com>...[color=blue]
> On Thu, 14 Aug 2003 23:29:07 +0000 (UTC), Marco van de Voort
> <marcov@stack.n l> wrote or quoted :
>[color=green]
> >- First there must be a Java implementation
> >- Second there must be a *full* java implementation.[/color]
>
> 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.[/color]

and basically if an implementation says "ANSI-C" you can count
on all ANSI-C code running there.
[color=blue]
>
> 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.[/color]

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".
[color=blue]
>
> Platform independent code happens naturally with almost no effort in
> Java. It is requires considerable effort in C++.[/color]

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++).
[color=blue]
> You can't convince
> me otherwise because I have done both.[/color]

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]

Re: Future reuse of code

On Thu, 14 Aug 2003 22:15:48 GMT
Roedy Green <roedy@mindprod .com> wrote:
[color=blue]
> On Thu, 14 Aug 2003 11:53:51 +0100, Mark Gordon
> <spamtrap@fla sh-gordon.me.uk> wrote or quoted :
>[color=green]
> >
> >Completely wrong. I[/color]
>
> 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.[/color]

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

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

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

[Mark Gordon]

Re: Future reuse of code

On Fri, 15 Aug 2003 01:32:00 GMT
Roedy Green <roedy@mindprod .com> wrote:
[color=blue]
> On Fri, 15 Aug 2003 01:21:55 GMT, Kevin Easton
> <kevin@-nospam-pcug.org.au> wrote or quoted :
>[color=green]
> >It is impossible to
> >write incorrect Java code?[/color]
>
> 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.[/color]

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

[Mark Gordon]

Re: Future reuse of code

On Fri, 15 Aug 2003 12:03:12 +0200
Jacob <jacob@yahoo.co m> wrote:
[color=blue]
> goose wrote:
>[color=green]
> > i showed plenty of evidence that this is not true (C, for example,
> > targets many more platforms than java).[/color]
>
> 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).[/color]

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

[Peter E.C. Dashwood]

Re: Future reuse of code


"Harley" <dennis.harleyN oSpam@worldnet. att.net> wrote in message
news:Ef3%a.1014 23$0v4.7002733@ bgtnsc04-news.ops.worldn et.att.net...[color=blue]
>[/color]
<snip>
[color=blue]
> In the past we have had "user friendly" tools, and the user never used[/color]
them.[color=blue]
> It will be the same with system modeling.
> There will be modeling "experts" who do the work.
>[/color]
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]

Re: Future reuse of code


On 15-Aug-2003, alx54321@yahoo. com (John D.) wrote:
[color=blue]
> 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.[/color]

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

[Howard Brazee]

Re: Future reuse of code


On 15-Aug-2003, ruse@webmail.co .za (goose) wrote:
[color=blue]
> like I originally said "java has its advantages, but portability isn't
> one of them".[/color]

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