Re: why this assembly language is not good?


James Daughtry wrote:

have to accept that fact that your own code is unreadable, too.

When did this thread become a debate about RosAsm's readability?

When Rene started making ridiculous comments that apply equally well to
his own product.

Whether you're right or not, it's irrelevant, and seems like you're
trying to shift the focus from the OP's language to RosAsm.

No, just pointing out that Rene has no room to criticize when he's
making the same mistakes in RosAsm.

I can't
imagine why, as you would probably have some good suggestions about the
language in question as you and the OP seem to be doing the same thing:
turning asm into some kind of HLL.

I've made my comments about a/b's stuff in the past.


And how would we be able to "guess" that M1 is a local label? There is
no clue whatsoever at all in your own code that this is the case.
Someone has to *know* how relative local labels work in RosAsm to make
this connection. Why is this any different from what the OP is doing?
At least the OP's labels (if those are truly local labels) have a
syntactical hint that differentiates them from normal label syntax.

The difference is that RosAsm has documentation explaining, more or
less, how it works.

By itself, RosAsm is no more readable that this new language.
Rene may not have the manual, but he can certainly ask. To claim
something is unreadable because he (or you) is unfamiliar with the
language is a completely unfair attack.



The OP has offered no such information to the best
of my knowledge. He's simply assumed that we can find his chicken
scratch as intuitive as he does.

He has made a *very* good effort to explain the stuff when questions
are asked. Again, ignorance of the syntax no more implies that the
syntax is unreadable. That's true whether documentation exists or not.
The attacks by Rene were unfair. Particularly given the unreadable
syntax that RosAsm employs.



It belongs to *his* syntax.
It is amazing that you're criticizing his syntax. You've got stuff
that's just as bad in RosAsm. Look at the previous RosAsm macro for an
example.

Once again, this is not a debate about RosAsm,

But Rene is in no position to criticize, given he has made *similar*
choices. It doesn't matter if Rene has provided documentation. If
you've got to go to the documentation all the time to figure out what's
going on, the resulting syntax is unreadable.

and it seems
increasingly likely that you're just trolling.

Perhaps. But Rene is in no position to criticize. His coding style, and
RosAsm's syntax, is not a shining example.

I would much rather you
focus your insight on the topic at hand, the OP's syntax, rather than
childishly bashing RosAsm for no obvious reason other than to be
malicious.

I've already made my comments known on this in past threads. For your
benefit, as you weren't around back then, I've made it fairly well
known that I don't believe that an expression-based syntax (as this
product uses) is readable. Even a *good* implementation of such a
language (see www.terse.com) doesn't work for me.


Yes, learning the syntax of an assembler like RosAsm, which suffers
from this same problems, is an absurd waste of time. You said it, not
me.

Can you say straw man?

You should look up the meaning of the phrase "straw man argument".
Never mind, I'll provide it for you:

"Straw man arguments:Your opponent restates your argument inaccurately
and in a weaker form, then refutes the weaker argument as if it were
your own."

Please explain how this definition applies to the above statement.
Certainly I took Rene's statement and restated it. But there is nothing
inaccurate or weaker about it. What I have done is turned the tables on
him (and you, apparently). After all, you claim that if one *learns*
the syntax (e.g., by reading available documentation) then what would
normally be considered unreadable is now readable. By the same
argument, someone who bothers to *learn* this new syntax wouldn't make
all the obvious mistakes that Rene is making.





Then, what does "++i" mean?

Any programmer who has seen C would instantly know what this means. And
that's *far* more people that the number who would be able to read
RosAsm code.

Once again you add an irrelevant mention of RosAsm.

No, it's not irrelevant. I'm drawing a comparison of Rene's criticism
of this product against what Rene has done with RosAsm. It makes
perfect sense to mention RosAsm in that context.


However, you'll
notice that any programmer who has seen C will instantly be confused
that ++a means 'inc eax', but a++ means 'adc eax' and requires an
assignment operator *and* a second operand. This is hardly intuitive,
and I'm speaking from the standpoint of an experienced C programmer as
well as a beginner assembly programmer.

Actually, it was a++=0, not a++0. That makes a big difference. But
don't expect me to support this expression style as readable. I made
the decision that expression-based syntax was not all that readable
probably 15 years ago. There simply aren't enough "operator" symbols
one can use to do this properly. As for the comparison against C,
consider "<<". What does that have to do with "less than"? Nothing at
all, obviously. Same reasoning applies to "++" versus "++=". It's just
something that has to be learned.

Now let's compare that against RosAsm's insane use of symbols (e.g.,
within macros). What does "|" mean? What does "&0" mean and why is it
different than "&&0". Same sorts of arguments about unreadability.
Rene's real big on using meaningful names (e.g., criticizing "atoi" and
claiming it ought to be called "AsciiToInt"). So why all the cryptic
symbols in his own language? Why not use meaningful names, or at least
a common set of symbols, like other assemblers do?




Then, in the second "B*i==" , what is the value of "B",

In the RosAsm statement "mov B$i 0" what is the value of "B"?

I would read the documentation to find out. Speaking of which, can you
point me to the equivalent documentation of the OP's language?

This newsgroup. He seems quite good about answering such questions. And
when his language has been hacked around for as long as RosAsm has
been, I would expect decent documentation to be available. But this is
a work in progress, so such expectations are unreasonable.


Then writing multiple Statements on a single Line -which is a
very good thing, massively encreasing the readability- requires
having separators,

Actually, having multiple statements per line massively *decreases* the
readability. This was figured out way back before 1975 when I first
started writing programs. Where have you been all these years?

As with any feature, disciplined use determines effectiveness. If you
pick a bunch of statements and put them all on the same line, yes, it
can be confusing. If you choose two or three statements that are very
closely related, judicious use of this feature can improve clarity.

No, they don't. Again, look at all the C/C++ code out there. C/C++
certainly allows one to do this. How often do you see multiple
statements per line in *well-written" C/C++ code? Almost never, that's
how often. If it's really a useful concept, I'd think that you'd see it
more often.

That's not to say that there are *never* times that multiple statements
per line would be okay. But it's rare.


It was figured out way back before 1975 that sloppy use of *any*
feature can easily result in hard to read code, and I believe that it's
been common knowledge for much longer that blind adherance to a
guideline is foolish.

Again, where is all the code that demonstrates the "good" use of
multiple statements per line. You just don't see it in modern code.

Just because it's usually best to keep one
statement per line doesn't mean it always is, and you're acting like
attempting it is a sin, which it isn't.

Again, where is all the code...
Have you *looked* at the RosAsm source code? Can you defend that style?



The same concept applies to code. You want to minimize the width of
each source line so people can quickly scan the code. Of course you
*can* go overboard, so please don't make the obvious (and completely
stupid) response of one token per line. But the bottom line is that one
statement per line is *more* readable than multiple statements per
line.

Actually, experience has proven that a healthy middle ground is more
effective than either extreme.

Again, *where* is all the example code out there in the world that
makes effective use of multiple statements per line. As I've said
already, people figured out that this is a *bad thing* well over 30
years ago.


Strict one statement per line programs
may not be as clear as programs that use the feature judiciously.

Again, where are all these programs that use this feature judiciously?
I've looked at a lot of source code over the years. And other that some
early microcomputer BASIC code and RosAsm source files, I've *rarely*
seen this feature used in *any* code, much less code that I would
consider readable.

Likewise, programs that go overboard with the feature lose the clarity
gained.

What "clarity" is this? Defend your premise that putting multiple
statements per line adds clarity. Where are the URLs with research to
back up such a claim? About the only examples I've seen in my life
where one could make an argument for this are statements like "if( expr
) return;" or "if(expr) break;" (and, technically, these are actually
*single* statements, not multiple statements, though that's some real
nit-picking).


Your argument reminds me of the goto war. Someone says that
goto is evil, and shows the most horrid example of spaghetti code to
prove their point. Practical examples, on the other hand, give one a
completely different conclusion.

You're exactly right. But how often is the use of a goto a *good* thing
in a program? I can provide a few examples where using a goto *will*
produce more readable code. But the bottom line is that I probably use
four or five gotos in a HLL like C every year. Given the amount of
C/C++ code I write, that's pretty damn rare in my book. I'll be more
than happy to accept that a similar number of cases of the
"multi-statement lines" situation would produce more readable code.
It's certainly possible, but *very* rare. Again, look at the RosAsm
source code some time. Defend that style.



I think you're too biased to make an objective argument, but I will
readily admit that when one isn't comfortable with one's ability to use
a feature intelligently, it's better to err on the side of caution.
Hence, one statement per line.

Again, *where* is all the code that demonstrates how much more readable
code can be when you cram multiple statements per line? You're making
excuses to try and defend a bad practice without backing up your
claims.


If multiple statements per line were more readable, you'd see that
technique used in programs whose languages support that feature
(including most modern HLLs). The absence of such examples should clue
you in.

I do see it used, and I use it where it makes sense. Just because you
see an absence, doesn't mean there is one.

Yeah, right. All the books on programming style and software
engineering are all wrong. All the code out there that avoids this
style do so because those programmers are ignorant.

You say that it is being used. Provide the links to such use. Again,
I've yet to see this feature used much in code that I would consider
readable. I'd love to see you provide examples the demonstrate new ways
this feature can be used to make code more readable. And I mean that.
I'm really interested in seeing ways that *really* make the code more
readable.


In short, as you have been told many times, inventing private
Syntaxes like yours may be programming fun, but is definitively
absurd to try to inflict to the other, as long as you will
always be the only one able to read this.

Then why did you create your own private syntax for RosAsm.

Every assembler supports some "private" syntax that's different in one
way or another from every other assembler, so your comment is largely
irrelevant.

Then again, so is Rene's. Isn't that the point?
Rene is the king of making insults out of irrelevant comments.


Or with line noise, as was done in RosAsm. :-)

Yet more pointless bashing. At least we expect that kind of behavior
from Betov, but I would expect you to act a little more professional.

Sorry, but after having to put up with six year's of Rene's nonsense, I
quit being charitable. When he attacks someone or makes a nonsensical
statement, I'm more than happy to call him on it.

It's possible to take criticism, even very hostile criticism like
Betov's, with a certain measure of grace. You've failed miserably.

You're really new around here, aren't you? Go check out the archives.
It took about three years of constant attacks. But after a while I
finally said "enough is enough" and I refuse to put up with his crap
anymore. Go back and check it out. For the longest time I even
*supported* the RosAsm project, despite constant attacks from Rene. And
don't think that I'm alone on this. Rene has pulled the same stunt with
people like Steve Hutchesen (Hutch) and Edgar (Donkey). He has a knack
for really pissing people off. As such, he (and his product) are going
to get called whenever he makes attacks such as the one in this thread.
Cheers,
Randy Hyde

.

Relevant Pages

  • Re: why this assembly language is not good?
    ... When did this thread become a debate about RosAsm's readability? ... So you would force someone to have a shining example of perfect syntax, ... RosAsm, of course. ... RosAsm is no more readable that this new language. ...
    (alt.lang.asm)
  • Re: why this assembly language is not good?
    ... So you would force someone to have a shining example of perfect syntax, ... promote) in RosAsm. ... Given that Rene ... RosAsm is no more readable that this new language. ...
    (alt.lang.asm)
  • Re: why this assembly language is not good?
    ... When did this thread become a debate about RosAsm's readability? ... When Rene started making ridiculous comments that apply equally well to ... trying to shift the focus from the OP's language to RosAsm. ... ignorance of the syntax no more implies that the ...
    (alt.lang.asm)
  • Re: The Advantage of Macros
    ... pseudo-HLL constructs by the majority of RosAsm programmers? ... but this has no relationship with the language syntax. ... to objectively measure readability of various syntaxes, ...
    (alt.lang.asm)
  • Re: Betovs notation
    ... That might apply to RosAsm... ... >:)) You just give the reason why an Assembler should NEVER ... That's not Nasm syntax, maybe it's LuxAsm syntax... ... > the readability, ... ...
    (alt.lang.asm)