Dustin Cook <bughunter.dustin@gmail.com> Thou awful weak one. Thou
inbred serpent. Thou panderer. Thou murmurer. Ye peeped and ye pined:

> On Feb 25, 12:11 am, "Kadaitcha Man" <nntp.n...@gmail.com> wrote:
>>> </quote> childish code. No wonder they
>>> call it BASIC (read: code for children)
>
> Actually, it's not quiet basic.. See below, as I tear K-man to
> shreds
>
>> These days, with .NET there is no fundamental difference between
>> BASIC, C#
>> and J#, et al. Real differences lie only in how the code is required
>> to be
>> structured by the precompiler. Only a very short copy/paste
>> manoeuvre is
>> needed to convert .NET-based C# to Visual Basic or Visual Java, and
>> back
>> again.
>
> blah blah.

Fine opening defence of your **** code there, Dustfart; however bravado, bluster and bombast don't readilly hide diffidence.

> Any developer realizes this.. even you... shrug.

20-20 hindsight.

>> made with daubed faeces by captive orang-utans bored ****less from
>> nothing
>> else to do except swing in the trees and eat an endless supply of
>> bananas.
>>
>> "That's a simple programming thing
>> tho"http://groups.google.com.au/group/alt.comp.os.windows-xp/msg/616184df...
>>
>> The emphasis is on simple.
>
> So simple in fact, you missed it.. See below.

There's no need try and deflect by reinforcing the simplicity, Dustfart;
the damage has already been done.

>> So, on to a really rough and quick but professional critique of the
>> code
>> above... I was a professional software developer, now in management,
>> though
>> I still cut a lot of code just to keep up with the latest
>> advancements...
>>
>>
>>
>>> randomize
>>> a=rnd(0)
>>> a=a mod 1
>>> b=rnd(0)
>>> b=b mod 23
>>> death=b
>> ^^^^^^^^^^
>>> b=rnd(0)
>>> b=b mod 23
>>> runy=b
>>> b=rnd(0)
>>> b=b mod 23
>>
>> The variable named "death" indicates that the language is capable of
>> supporting variable names other than simple a, b, c. Code should
>> make use of
>> extended variable names with the intent of increasing the code's
>> ability to
>> self-document.
>
> True, that was sloppy on my part. I think I said the code was sloppy
> originally tho..

20-20 hindsight.

I bet when your code is peer-reviewed your stock response to the
peels of laughter is "that was sloppy on my part". You have had
code peer-reviewed, yes?

>> As another example of the woefully poor exploitation of variable
>> names...
>>
>>> ar=local
>>
>> ar might be short for "AR AR ME 'ARTIES!!!"
>>
>> Perhaps Dustfart fancies himself as a pirate on the high seas or
>> something.
>
> just lazy...

Just lazy, huh? More like you downright don't ****ing know what you're
doing. Of course, the rest of this post is aimed at proving exactly that
claim.

20-20 hindsight, btw.

>>> b=rnd(0)
>>> b=b mod 23
>>> death=b
>>
>> Three lines of code are used to do what can be done in one line...
>>
>> death = rnd(0) mod 23
>
> Ahh, but your wrong sir. This is Asic, it cannot be done in one
> line.

Admission to using **** to write **** noted.

>> The results are the same but the process is not. Dustfart's
>> amateurish and
>
> The results would be the same, If the language supported it in one
> statement like that.

20-20 hindsight.

> (It doesn't). It's asic, not quiet basic.
>
>> woefully inefficient code requires values to be moved left, right and
>> centre, then all the way back again before a result is obtained. I
>> use the
>
> Ouch, I don't think you realize how close asic really is to
> assembler...

1. Unsupported assertion. Claim fails.

2. ASIC is a BASIC compiler that includes a number of BASICA and QBASIC
commands, Dustfart. The ASIC instruction set does not contain any JMP, MOV,
NOP, CPL, JNZ, JZ, INC, DEC or any other assembler [sic] commands. So it is
beyond the reasonable mind to understand how it can be the case that anyone
other than you can appreciate just "how close asic really is to assembler
[sic]".

3. There is no assembler [sic] code in the crap you posted, Dustfart. It's
all ASIC BASIC. Every last ****ing byte and every last ****ing bit, all ASIC
BASIC. Nothing more. Nothing less.

<shouts right into Dustfarts ear>
WAKEY! WAKEY! HANDS OFF SNAKEY!

Why the assembler [sic] code straw-man, Dustfart? Got you by the scruff of
the neck, have I? Hmmm?

Assembler [sic] code is your straw-man to avoid the charges against you.
Nevertheless I will gleefully and wilfully attack your straw-man with gusto,
but only because doing so exposes you to even more justifiable accusations
of complete and utterly delusional ****wittery.

4. I will now proceed to show you just "how close asic really is to
assembler [sic]", Dustin...

First the assembler [sic]:

Name "SuckEggsDustin"
org 300H
JMP Start
String db "Hello, ****Nuts Dustfart!", 0DH, 0AH, 24H
Start: LEA DX, String
MOV DX, 09H
INT 21H
MOV AH, 0
RET

Now in ASIC

Print "Hello, ****Nuts Dustfart!";

As you can see, Dustin, I obviously do not realise "how close asic really is
to assembler" [sic] as much as you do.

> Your loss.

Yes, Dustin, even Blind Freddy can see "how close asic really is to
assembler" [sic]

Can you say "chalk and cheese"?

Do you mind if we revisit your claim that 'asic is really close is to
assembler' (a paraphrase) _after_ your psychotropic drugs have kicked in
and your acute hallucinatory-delusional episode is over, rather than
during the bad turn you're having? Thanks ever so much; there's a jolly
good chap.

>> word "amateurish" reservedly. I am bereft of sufficient one-word
>> superlatives to convey the idea of complete rubbish born of his
>> artless bumbling.
>>
>>> gosub check:
>>
>> Subroutines should only be used where there is a need to eliminate
>> repeated _larger_ segments of code. The subroutine named "check" is
>> called from only
>> two places in the entire ...ahem... "program", and it will cause the
>> compiler/run environment to beat on the processor; see a little
>> later about
>
> Actually, it won't. The assembler code is referenced via jmp
> statements in the executable.

lol - so what exactly do you think a JMP is? Something other than "assembler
[sic] code" referenced in the executable? And perhaps you meant assembly
rather than assembler, yes?

Sooooo.... "The assembler [sic] code is referenced via jmp statements in the
executable", is it? Hmmm?

That would be assembler [sic] code put there by the compiler, yes? You know,
"code" that you did not actually write. Oh, and the completely straw-man
assembler [sic] code that we're not actually dicussing because we're really
talking about the ASIC BASIC compiler that does not include support for
assembly language mnemonics, yes?

And since when has any "assembler [sic] code" statement been referenceable
in an executable, Dustfart?

JMP <--- That, Dustfart, is the mnemonic for an assembler [sic] JMP
statement.

E9 <--- That, Dustfart, is an unsigned hexadecimal opcode, which is
the result of compiling an assembler [sic] JMP statement.

-23 <--- And that is the very same opcode only in decimal.

So far, Dustfart, it has been established that you:

A) Claim 'asic is really close is to assembler' when the actual
reality is that it isn't

B) You habitually refer to assembly as assembler

C) You do not know the difference between an opcode and its mnemonic;
indeed, it is verifiably provable that you believe that the
mnemonics are referenced in the executable.

And you say you're a programmer, huh?

What other surprises do you have in store for your readers, Dustfart?

> It saves codespace, by writing code once

Repeat: That would be codespace used by assembler [sic] code put there by
the compiler, yes? You know, "code" that you did not actually write. That
is, the assembler [sic] code we're not discussing because we're actually
discussing your **** ASIC BASIC code, yes?

Do you know what GIGO syndrome is, Dustfart? Go on, take a leap to
google to do a search so can post your accurate reply here and look
reely reely kewl. You know you want to.

> if it's going to be used more than once, it should be a routine. Why
> repeat the same code?

DUH! So, why isn't it, Dustfart...?

> a=rnd(0)
> a=a mod 1
> b=rnd(0)
> b=b mod 23
> death=b
> b=rnd(0)
> b=b mod 23
> b=rnd(0)
> b=b mod 23
> a=rnd(0)
> a=a mod 23

"if it's going to be used more than once, it should be a routine. Why repeat
the same code?"

BWAHAHAHAHAHAHAHAHA!

Don't tell me. Let me guess...

"just lazy..."

Of course, an utter lack of capability on your part has nothing to do with
it at all, right?

>> strings. Given what I say a later about strings inside loops, the
>> "check"
>> subroutine is not just entirely superfluous, it is detrimental to the
>> efficient execution of the code.
>
> Ehhhehh.. Heh, the code is written in asic. I don't think you quiet
> understand what asic is.

Dustfart, you need a seriously hard kick in the reality glands. First of
all, compilers produce output in a predictible manner. That is to say, when
you put your garbage code into the compiler, what comes out is, lo and
behold, compiled garbage. A BASIC compiler will not fix your crap,
inefficient code, Dustfart; it will only produce a crap, inefficient
program.

Secondly, Dustfart, let us assume, for the sake of supposition only, that
everything I have written, plus all the evidence placed before you to
refute your insane lies is 100 percent pure, unadulterated, irrefutable
bull****. Yes, let us assume that everything I have written is 100%
techno-poppycock.

So, Dustfart, based on that assumption, do you believe that your readers are
more inclined to fall for the techno-gobbledegook bull**** than they are,
say, to fall for the delusional ramblings of an utterly inept ****wit who
puffs up his horribly sunken chest and declares, "it's not quiet [sic]
basic... I will tear K-man to shreds blah blah. Your loss. Ehhhehh..
Heh, the code is written in asic. I don't think you quiet [sic] understand
what asic is"?

>>> b=b mod 23
>>> death=b
>>> b=rnd(0)
>>> b=b mod 23
>>> runy=b
>>> b=rnd(0)
>>> b=b mod 23
>>
>>> if death=runy then
>>> a=rnd(0)
>>> a=a mod 23
>>
>> Some variable modulus 23 is used 4 times in 10 lines. Setting aside
>> that the code segments use 3 lines where one line will do, the whole
>> rnd(x) mod 23 should have been a candidate for conversion into a
>> subroutine, then discarded as a candidate because it would probably
>> require just as many processor cycles to jump and return as it would
>> to calculate the modulus of two simple numbers inline. I doubt
>> Dustfart's capacity to have ever considered that at all. I suppose
>> soon enough we'll see if his hindsight is operating at a perfect 20-20.
>
> Pure lazyness on my part.

If lazyness is a euphemism for incompetence then we agree.

> The entire rnd code could have been
> converted to a subroutine, but it has to occur in that order. Asic
> doesn't understand multiple statements/actions per line.

Your first admission to using **** to write **** was sufficient, Dustfart.
There's no need to keep going over your old self-inflicted wounds and
re-opening them to let your blood drain out all over the carpet, you know.
You'll only piss your mother off. You do still live with your mother, yes?

>>> for y=1 to 24
>>> a$=a$+"+-"
>>> next y
>>
>> The code is very badly written and grossly inefficient. Any
>> programmer worth
>> the designation of "programmer" should know that strings are, more
>> often
>> than not, immutable in BASIC, which means that once a value has been
>> assigned a string variable the value cannot be extended without
>> moving the
>> original to a new place, destroying the original variable then
>> moving the
>> new value from its temporary place and into a newly reserved block in
>> memory.
>
> You don't actually do much with assembler do you?

If you really mean assembly, Dustfart, then the answer is not any more, no.
The days of actually _needing_ to write code down at the bare metal level to
get a simple task done are long gone. Of course, I readily admit I've
forgotten a truckload about assembly language, but, and it's a big but, what
I do remember of assembly language is more than enough to run rings around
you and your "assembler [sic] code" and your ****BASIC to show you up for the
lying, contemptible and inept buffoon that you are.

You will note the phrase 'writing code down at the bare metal level',
Dustfart. If you really want to fool more than just yourself into believing
that you're a programmer of at least equal repute to coprophilic orang-utans
swinging upside down from treetops in Indonesia then you might like to steal
the phrase and start tossing it around a bit. Please, don't thank me. I'm
here to help...

Sort of.

Continuing on... the days of PEEK and POKE and hand-crafting ASCII
characters in a string to create code that can be executed with a jump to
a VARPTR are also long gone. I understand that geriatric commands like those
went West at around the same time VIC-20 BASIC went South. That would be what,
Dustfart, two and a half decades ago? Closer to three, perhaps?

> Well anyways, when
> asic compiles the binary, the resulting assembler code assigns

No, Dustfart. The assembler [sic] code is the input to the compiler, not the
output. Look, Dustfart, honestly, if you're so desperate to fool someone
other than yourself into believing you know your **** you should at least try
to get the idea of input and output sorted first. Ok?

> 80characters of memory for each string variable I use. Regardless of
> whether or not I use all of the space, the location of the variable is
> known the whole time my code is running. Nothing need be, moved.
> Overwritten as you wish, but moved, not unless you want too. If you
> don't like this design, you may wish to take it up with Asics author,
> I'm unable to evade this limitation myself.

You are also unable to evade your callow inpetitude, Dustfart. Seeing as
you still don't understand that assembler [sic] code is input, not output,
I hope you'll also appreciate it as the reason for my not addressing the
rest of your hogwash.

>> In the loop above, the compiler (I assume compiler, surely he's not
>> daft enough to use interpreted BASIC. Is he?), is forced to move the
>> contents of the variable into a transient location, free up the formerly
>> reserved memory location, create a new reserved location, then move the
>> contents from transient storage to the new location no less than 24 times
>> in a row. Each of the twenty four executions are repeated for every time
>> the code loops through the controlling while/wend construct. It is utter
>> ****e; it is not
>> code.
>
> Nope, Nope, Nope Nope, I have more of those.

You have more of what? Utter ****e? Why am I not surprised?

> That's not what's occuring in the resulting assembler binaries generated
> by the compiler. If it was a real HLL language, it might do that, but it
> doesn't have such capabilities.

HLL language, eh? That's HLL language as in high level language language,
yes?

Can you say "inept redundancy", Dustfart?

The primary attribute of a high level language language [sic], Dustfart, is
that code written in a high level language language [sic] is readable, in
English-like form.

I challenge you to show how the following pile of steaming ****e approaches
anything remotely resembling a mid level language language [sic], never mind
a high level language language [sic]:

> randomize
> a=rnd(0)
> a=a mod 1
> b=rnd(0)
> b=b mod 23
> death=b
> b=rnd(0)
> b=b mod 23
> runy=b
> b=rnd(0)
> b=b mod 23
>
> if death=runy then
> a=rnd(0)
> a=a mod 23
> runy=a
> endif
> ent$=chr$(13)

Go on, show it.

<hack>

> There ya go, enjoy!

Posting vast tracts of the manual is not only pointless, but doing such a
thing will not make your case. You see, Dustfart, /you/ have to make /your/
case, and so far you have spectacularly failed to make any case other than
my own, viz you're a total ****wit; a loser; a no-hoper; an inept and
worthless sack of giblets of no value to anyone except the undertaker.

Not to mention that I have ASIC v5 and the manual sitting quietly on my
hard disk anyway.

+--------------------------------------------------------------------+
| |
| A S I C (tm) 5.00 |
| "Its Almost Basic" |
| |
| Copyright (c) 1994 |
| by |
| 80/20 Software |
| All Rights Reserved |

The problem for you, Dustfart, is, and at risk of being seen to be boasting,
I know my ****, whereas even a portrait of Helen Keller could see that you
do not.

>> It would have been far more efficient to simply declare a variable
>> with...
>>
>> SomeVar$ = "+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-..."
>>
>> But I suppose that would deny Dustfart the bragging rights on
>> knowing how to execute a simple For...Next loop.
>>
>>> if a$="K" then
>>> ...
>>> endif
>>
>> Still on the subject of sloppy, inneficient coding; at compile time,
>> the
>> compiler will not be able to work out how or where to allocate a
>> home for
>> the simple "K" string literal. The job will therefore be left to
>> runtime,
>> where, of course, execution will be slowed while the run environment
>> works
>> out what to do with it. A far more efficient and elegant method
>> would be...
>>
>> SomeVar$ = "K"
>> ...
>> ...
>> If SomeOtherVar$ = SomeVar$ Then
>> ...
>> EndIf
>>
>> In fact...
>>
>> If NOT ((SomeOtherVar$ <> SomeVar$) AND (SomeOtherVar$ <>
>> YetAnotherVar$))
>> Then
>> ...
>> EndIf
>>
>> ...would be just as quick as, if not actually quicker than, the
>> mess
>> Dustfart made; the correct word is wrote but his crap is not worthy
>> of such
>> a word. A not equal operation requires less processor cycles than an
>> equal
>> operation. With a properly structured If...Then clause, there would
>> be no
>> need for the dog's breakfast below:

Dustfart, old chap. All the text has been ****ed up by your reply. Did
you write your own newsreader too?

Carrying on... I note that you replied to yourself ten minutes after making
the reply I am replying to. I've given you the doubt of the benefit and am
assuming you're not actually so mad (yet) as to talk to yourself. Are you?

The text from your reply to yourself has been copied and pasted below. I
believe we need to keep this as neat and tidy as possible. Lord knows, if
your scatterbrain is allowed to run riot we'll never get anything sorted,
eh, least of all the most fundamental of all programming concepts; viz the
difference between input an output.

>>>> for y=1 to 24
>>>> a$=a$+"+-"
>>>> next y
>
> I'd like to show you a couple of other ways of doing the same
> thing.
>
> a$=string$(24,"+-")
>
> that will do the same as the code above and below.

So, Dustfart, why didn't you do that the first time around?

Don't tell me. Let me guess...

Sheer laziness?

Downright sloppiness?

No! I know! "For a very good reason, which I wouldn't understand."

How good am I doing with these guesses, hey? Give me some feedback,
here, ok?

> a$="+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-"
>
> another way
>
> a$="**** k-man"
> kmanshouse=varptr(a$)
> ourhouse=defseg(0)
> x=1
> y=kmanshouse
> while x<25
> poke y,27
> x=x+1
> y=y+1
> wend
>
> and another
>
> a$="**** k-man"
> kmanshouse=varptr(a$)
> ourhouse=defseg(0)
> x=kmanshouse
> y=x+24
> for z=x to y
> poke z,27
> next z

Oh, wow! Dustfart! That assembler code [sic] is so beautiful! It brings
tears to my eyes.

Tears of ****ing laughter. There you are, bragging and waffling on, not
unlike a demented chimpanzee with habañero-induced diarrhoea tearing a
new arsehole in its backside, about assembler [sic] code and still
you're posting ****BASIC. **** me dead. Can you honestly get any more
pathetic, Dustfart?

> the end result is the same, but the code generated isn't. Now, you
> wouldn't understand why this would be considered useful to someone
> like me, but I suspect 4Q might get the idea behind it. This is how
> things are done in Asic k-man,

Dustfart, you always fall into the trap of seriously under-estimating your
detractors. Of course I understand why that would be considered useful to
someone like you... you're a ****ing spaghetti coder at best. An inept one
at that.

> 4Q has mislead you concerning what asic is and isn't.

Ok, your bad turn obviously isn't over yet. When you finally snap out of
the most recent of your ever increasingly frequent acute
hallucinatory-delusional episodes, would you mind posting at least a tiny
bit of evidence to show that 4Q and I have exchanged any conversation,
including even a simple barb in, say, oh... the last three or four months?
There's a jolly good chap.

--
alt.usenet.kooks - Pierre Salinger Memorial Hook, Line & Sinker:
September 2005, April 2006, January 2007.

"Now I know what it is. Now I know what it means when an
alt.usenet.kook x-post shows up."
AOK in news:ermdlu$nli$1@registered.motzarella.org