Re: RosAsm Team is Still Making Excuses


Beth wrote:
> wolfgang kern wrote:

>
> Randy read what you'd written in a "formal, technical" sense of
"newline"
> (as in the CR / LF characters)...when you were just being "casual,
> non-technical" in meaning "stuff it on the next line"...

Yep. And I figured that out several days ago, too.
It doesn't change the fact, though, that RosAsm *does* exhibit the
offensive behavior when you do something like this:

[b0: B$ 0]
[b1: B$ 0]

The semantics, not the syntax, are the important issue here.


> >
> > You better search for another point in RosAsm to pick on.
>
> Yes, in this case, RosAsm isn't really doing anything wrong...on a
personal
> level, you might find this all "weird" in the sense that it does not
match
> what you're "accustomed to" from other assemblers (and "HLL
pre-parser
> subshits" or "MASM is a compiler" or whatever form or classification
of
> tool you're using ;) and so forth...but it's not really "wrong"...as
> "unusual" is not "wrong" (indeed, if it's "unusual" in the good
sense, then
> it can be very "right" that it does not follow the "norm"...when the
"norm"
> is not actually the best that it should be :)...

With newlines this might not be the case, but with actual RosAsm
declarations, there is no reason to waste the space when a declaration
section contains only byte variables, e.g.,

[b0: B$ 0]
[b1: B$ 0]

Sure, it can be explained away in the documentation. And programmers
*can* overcome the default dword alignment. But it's stupid and doesn't
buy you anything (other than wasted space) for byte variables.


>
> No, the real things to pick on with RosAsm here is other
points...like the
> "automatic" way that all data goes in the data section and all code
in the
> code section ("never the twain shall meet" ;)...that you only can
declare
> these two sections...and this kind of thing...

That, though, is a different issue. The fact still remains that RosAsm
wastes space for no good reason. Thus far, the excuse given to me by
two RosAsmites is "it doesn't matter anyway, because I never use byte
variables." (For good reason, too!)

>
> Though, objectively, these points are, again, not a case of "wrong"
> exactly...but a case of "isn't that a bit limiting?"...in the
majority of
> cases, most programmers will have no need of anything different (on
this,
> Rene is correct that the "common case" would not have any "care" for
these
> points)...BUT this is a bit "inflexible"...a tool _MIGHT_ be used for
the
> "common case" BUT, really, it should also be capable for the "rare
case"
> too...after all, what if a RosAsm programmer finds they really have a
need
> to do something "rare" like this for their application? Being
incapable of
> these features means, well, they are forced to use some other tool to
do
> it...

You are absolutely correct in stating that this isn't "wrong" in the
sense that it generates incorrect code. But it does waste space,
gratuitiously. And that's just not something we would expect an
"assembler" to do.


> But, yeah, this isn't actually "wrong"...more a case of
> "inflexible"...which could lead to "being very annoying" in some
> situations...

It's not even a question of flexible vs. inflexible. After all, a
programmer *could* go in and explicitly set the alignment on every
declaration section. It's more a matter of convenience and human nature
(that is, humans are predisposed to choose the convenient path, even if
it's less efficient; a quick scan of existing RosAsm demo programs
suggests that this is certainly the case).


>
> And, on the "marketing" side of things, to not allow more precise
control
> of the sections but yet "sell" RosAsm as a "PE specific assembler"
might be
> construed as "misleading"...the PE file format itself allows this
kind of
> thing, if the programmer wants it...what we've really got is more
like a
> "PE common subset specific assembler"...which isn't a bad thing to
> have...but, well, a case of "trades description", if you know what I
> mean...just to not "mislead" people...

Agreed. Defaulting to a form that wastes space, especially when (in
Rene's own words) "it only takes a few instructions to fix this" is
ludicrous.


>
> [ And, yes, on this point, I would and have criticised Randy that his
> choice of names in "Art of Assembly" and "High-Level Assembler" too,

The term "High Level Assembler" existed about two decades before HLA
came along. IBM had a product called "HLAsm". There was an Amiga (or
was it Atari ST assembler that went by the name "HLA". The book
"linkers and loaders" defines the term and describes high-level
assemblers from the 1960s. Whether or not you like the term, it has a
very long history. It it *amply* describes the product. It *is* a
high-level assembler.

> as
> they are equally "dubious"...again, not "wrong" strictly...but
"potentially
> misleading"...of course, the "Art of Assembly" thing is an echo of
Knuth's
> "Art of Computer Programming"...and, yes, Knuth _ALSO_ used his own
made-up
> assembly language for teaching...BUT, when a book starts with "Art
of..."
> then it's normally taken by most people in an "Hitchhiker's Guide to
the
> Galaxy" / "Encylopeadia Galactica" sense: An exhaustive reference on
all
> things assembly language...

Maybe my next book title will be "Hitchhiker's Guide to Assembly
Language" :-) (though, given the reviews of the movie, this might not
be such a great idea).

> note: I have no problems whatsoever with HLA
> being "an assembly language"...the problem there is that HLA is a
> _classification_...hence, we've got confusions like: "MASM is a HLA,
like
> HLA is a HLA"...all very "potentially confusing"...

HLA is a name. "high-level assembly" (no caps, spelled out) is a
classification.

> yes, I know: "Art of
> Assembly" is an echo of Knuth...and "HLA" has been used as a name by
others
> before you...but, arguably, they _ALSO_ shouldn't really have used
names
> like this either...

Apparently, they disagreed :-)


> as a half of the problems with the way people react to
> AoA and HLA is actually linked to "disappointment" from presuming -
from
> the names - that AoA and HLA are going to be one thing...and then
finding
> out they are not that...

While there are certainly a fair number of people who are concerned
about learning a "high-level" assembly language, and ask if they are
learning "real" assembly language, a much greater percentage of people
are very happy that they're learning something "higher level." Keep in
mind that the largest percentage of people learning assembly with HLA
and AoA are students who were not looking forward to learning assembly
at all. HLA's name gives them some comfort -- things are not going to
be as bad as they thought they would be. *That* is the primary
audience for HLA and AoA.

If I really wanted to make people around here happy, it would only take
about a day to write a special version of HLA that disables all the
HLL-like control structures. I could call the result "LLA" (Low-level
assembler). But do what end? All the RosAsm people would stick with
RosAsm, all the FASM people would stick to FASM, all the NASM people
would stick to NASM, all the MASM people would stick with MASM, and the
beginners would still chose HLA. BTW, this *is* an option I'm planning
on sticking in HLA v2.0, a "-LLA" command-line option that disables
HLL-like control structures; I'm planning on doing this to help
instructors enforce the fact that by the end of the term students
should *not* be using any HLL-like control structures).


> of course, Rene would still complain regardless
> because he just wants to attack and destroy anything and everything
that
> isn't RosAsm, for his "personal glory"

That goes without saying...


> ...but there'd be less "resistance"
> from others, if it were called "Introduction to assembly language for
HLL
> coders" or something...okay, that's a crap name, in fact...but,
Hopefully,
> you get my point..."Art of Assembly" _could_ lead advanced coders to
think
> "excellent! Randy - that well-known writer, who writes good stuff
like that
> 16-bit AoA - has written a new text for 32-bit coding"...and then,
when
> they see HLA in there, they get all "disappointed"...of course, that
does
> not mean that AoA and HLA are not good things...they are...but, it's
all
> about "expectations" and having those "expectations" dashed...

Except that AoA was not written for experienced coders. It was written
for beginners. I gave up on experienced coders within three week's of
HLA's release, when it was perfectly clear to me that few people would
be willing to spend the effort learning a new assembly language unless
they were forced into it (e.g., when switching OSes).

My goal is to teach beginners assembly language. That's what AoA is all
about.

> it
> "disappoints" those who got the total wrong end of the stick from the
> name...and once "disappointed", they take that disappointment out on
you:
> "Randy! This is terrible!"...what they really mean often is: "Randy!
This
> is not what I expected!"...which is partly their fault but also
partly
> because of these particular names you've chosen...

It has nothing to do with the names and everything to do with the fact
that I chose to use an assembler that is not the one that they already
know. You do realize that had I chosen MASM, I'd get complaints that
it's not NASM syntax? Had I chosen NASM, I would get complaints that
it's not FASM or MASM. Had I chosen Gas, well, can you imagine the
complaints? You can't win.

But keep in mind, AoA was written for, and HLA was designed for, people
who don't already know assembly language. That is, those who don't have
the expectations you're talking about. My goal is not to please those
who already know assembly language. My goal is to teach those who do
not already know assembly language. If someone has these expectations
you're describing, then chances are pretty good that they already know
assembly language and a particular syntax, so they are not my target
audience. IOW, their expectations don't matter much to me.



> in a sense, perhaps the
> fact that this never phased me because, like Shakespeare, I really do
> mentally think in the context of "a name is a name" and that a rose
does
> smell as sweetly, whatever the Hades you call it...you know, I
honestly
> don't give a flying crap about "names" in general...call it "banana"
and
> I'd still come and look at it in an objective sense in the context of
_what
> it is_, irrespective of the name...hence, as I say, the "crap names"
I
> never paid any attention to, anyway...problem is, that's part of my
"alien
> brain" mentality...most people, on the other hand, tend to very much
think
> of things in terms of "names", generally speaking (at least, from
what I
> can gather from how people talk...as I obviously don't "mind read" or
> anything ;)...very hung up on the "non-intertwingularity" of
> everything...me? Couldn't give a crap...a firm believer in the total
_LACK_
> of actual real "hierarchy" and such in reality...we humans just pop
things
> into "hierarchies" because our brains really aren't as fantastic as
we like
> to often pretend and, well, we need to "simplify" reality or we can't
> process it properly, with our "puny minds"...to temporarily sound
like some
> sort of alien from a sci-fi movie there, oh "puny mortal man"! ;)...
]

People who dislike the name "HLA" generally fall into two categories:

1. Those who are committed to another assembler and don't like the fact
that people are learning "HLA" (and not learning the assembler they
prefer).

2. Those who hate the whole idea of assembly language and see a name
like "HLA" as a way of tricking people into learning assembly language
(you can usually spot these people, 'cause they often use phrases like
"HLA is an oxymoron" in the same sentence as "no one uses assembly
anymore.").

Neither of these two groups of people are my target audience, so I
don't care if they don't like my name :-)


>
> Anyway, I _have_ been telling Randy to calm down on the
criticisms...I too
> think RosAsm is basically crap...that is my opinion, which people
may, of
> course, freely disagree with...but, you know, that, in itself, is NOT
a
> justification for exaggerating or just arbitrarily insulting it or
> Rene...

Well, as Rene has begun to criticize you and the LuxAsm project, I
notice that your responses are quite similar to mine. After you've put
up with this for a couple more years, come back and tell me about how I
ought to behave in this manner.

The truth is, every now and then Rene's outrageous nonsense *has* to be
challenged. Ignoring him doesn't work. I generally keep him in a kill
file for a couple of months at a time and then review his posts with
Google to keep tabs on the guy. Alas, propaganda is one of those things
that if it doesn't get challenged, people start to believe it. So it
must be challenged on occasion.

And besides, the really good news is that while I keep him busy
defending RosAsm, he doesn't have much time to attack LuxAsm :-)



> "decorum" should still always prevail whatever...things should still
> be "objective" and pick on, yes, the _actual points_ of
criticism...reason
> numero uno why, basically, I think hutch's posts are such embarassing
> childish nonsense...even if I generally agree with his assessment of
RosAsm
> on occasion, this, in itself, is not justification - as he regularly
does -
> to prance around like a constipated loon, being an embarassingly
childish
> dickhead about everything...

Again, if you let such a wound fester, the infection only gets larger.
Believe me, I would love nothing more than to be able to ignore Rene
and his insignificant product. But to do so would be dangerous. There's
nothing to fear from his product -- nobody is using it -- but it is
important to make sure that no one takes his posts seriously.
Personally, I think Steve (Hutch) is going about the "anti-Betov"
campaign in the wrong way, but Steve is right about one thing, unless
Rene get's countered, he just keeps going on and on. And the only thing
that has *ever* shut him up is when everyone gets sick of his nonsense
and fights back.


>
> I _WILL_ always pick up on Rene when he talks crap...but I do not
actually
> have a problem with him at all...after all, people who talk crap are
> interesting and often amusing (I probably shouldn't "encourage"
anyone but,
> truth is, a "crap talker" is more interesting than a "non-talker" or
a
> "boring talker"...but, as I say, that is NOT an encouragement for
everyone
> to start talking lots of crap all the time (even if I sometimes
myself am
> the "perfect role model" for that ;)...the _MOST_ interesting person
is the
> "tell it like it is" talker, of course...genuinely so ;)...

As I said, he has an insignificant product and he would be an
insignificant voice were it not for the fact that some *new* people do
occasion to visit here now and then.


>
> It's a matter of "taste" - to get back to the main point - often, in
> fact...you know, some people prefer it when there's no "default" and
they
> have to explicitly put it in every time and are "comfortable" only
when
> it's written there in black and white (which, by the way, is actually
often
> what I most prefer myself :)...others like the "automatic defaults"
that
> "save typing"...as you can probably tell by my posts, I honestly do
not
> give the slightest crap about "saving typing"...it really just
doesn't seem
> in the slightest bit "important" to me at all...who cares? Typing
isn't the
> biggest worry by any stretch...

*You* might think that typing is not a big problem :-)

However, look at the RosAsm example code, most people just go with the
default case. Given that (according to Rene) it's just a *few*
statements to change the default to something more reasonable, why
doesn't he do this?


>
> Indeed, to me, a programmer afraid of typing seems a bit like a
skydiver
> who's afraid of heights or a writer who's got a "phobia of words" or
> something equally silly like that...

Of course you would say that :-)

It isn't just typing, though. It's thinking. If they have to think
about what they're doing every time they open up a new declaration
section, that's tiresome. Perhaps they should be thinking. But if
you're going to have some abstraction present (as Rene does), the
abstraction should produce the best possible results under all
circumstances.


>
> Also, "less characters" does not necessarily mean "less typing"
> overall...and it can be a "false economy" to be too abruptly short,
at
> times...for example, if you need lots of instances of the same
structure -
> very possible when doing OOP or something like that - then being able
to
> "typedef" that structure once (which will be slightly "more typing"
but
> only a few characters and only once on the first "definition") and
then
> only need to refer to its name to make more instances...which will
end up
> far "less typing" than having to type out each instance in full again
and
> again...a kind of "more haste, less speed" thing...plus, using data
types
> would very often remove the need for "dword ptr" or "dword" or "D$" -
which
> would save a few more characters for the "less typing" thing - even
if it
> made the data declarations slightly shorter...the relationship
between
> "number of characters" and "less typing" isn't always as simple or
obvious
> as that...

Yes, there is a difference between readability and writeability.
Cheers,
Randy Hyde

.

Quantcast