A status rapport from LuxAsm list

From: '\\\\o//'annabee ('\\o//'annabee)
Date: 02/24/05 

Date: Thu, 24 Feb 2005 16:01:30 +0100

I havent read it in full yet. But I am reposting this from the luxasm
devil list, in case someone has no better to do than to read it. Here it
goes.

Bring lots of coffie

Send Luxasm-devel mailing list submissions to
luxasm-devel@lists.sourceforge.net

To subscribe or unsubscribe via the World Wide Web, visit
https://lists.sourceforge.net/lists/listinfo/luxasm-devel
or, via email, send a message with subject or body 'help' to
luxasm-devel-request@lists.sourceforge.net

You can reach the person managing the list at
luxasm-devel-admin@lists.sourceforge.net

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Luxasm-devel digest..."

Today's Topics:

    1. Re: Testing, testing...eins, zwei, drei... (Frank Kotler)
    2. Re: Testing, testing...eins, zwei, drei... (NoDot)
    3. Re: More "unification" and LuxAsm syntax (Beth)
    4. Fw: More "unification" and LuxAsm syntax (Beth)

--__--__--

Message: 1
Date: Wed, 23 Feb 2005 06:29:38 -0500
From: Frank Kotler <fbkotler@comcast.net>
Organization: N
To: luxasm-devel@lists.sourceforge.net
Subject: Re: [Luxasm-devel] Testing, testing...eins, zwei, drei...
Reply-To: luxasm-devel@lists.sourceforge.net

Beth wrote:

> Frank, if you can see this post then that means all should now be well
> and
> it would be useful if you could "force unsubscribe" the "hotmail"
> subscription address for me...otherwise, I'm going to get "double vision"
> on everything sent to the list...

Done... or attempted... how many of these do you see? :)

Good to have you back with us ("Welcome" to Sevag, too!)

Best,
Frank

--__--__--

Message: 2
Date: Wed, 23 Feb 2005 07:33:50 -0500
From: NoDot <nodot@ulmail.net>
To: luxasm-devel@lists.sourceforge.net
Subject: Re: [Luxasm-devel] Testing, testing...eins, zwei, drei...
Reply-To: luxasm-devel@lists.sourceforge.net

Beth wrote:
> This is obviously a test of the new subscription to the list once
> more...

You're on.

> Frank, if you can see this post then that means all should now be well
> and
> it would be useful if you could "force unsubscribe" the "hotmail"
> subscription address for me...otherwise, I'm going to get "double vision"
> on everything sent to the list...

What's wrong with that. I still have everything sent to my Yahoo account
too. That way I *know* I didn't miss anything. (I probably should
unsubscribe soon, though.)

> *tap* *tap* Testing...testing...1, 2...1, 2, 3...
> Can y'all hear me at the back there? :)

Loud and clear.

> Beth :)

P.S. I prefer the '@ulmail.net' address ending. 

-- 
The above was written by NoDot.
Visit the Website of NoDot:
<www.geocities.com/nodot1989/>
--__--__--
Message: 3
From: "Beth" <BethStone21@hotmail.NOSPICEDHAM.com>
To: <luxasm-devel@lists.sourceforge.net>
Date: Thu, 24 Feb 2005 01:25:25 -0000
Subject: [Luxasm-devel] Re: More "unification" and LuxAsm syntax
Reply-To: luxasm-devel@lists.sourceforge.net
Frankie say:
> Ro wrote:
> > Why is it[too much "minimalism"] not a good thing?
>
> Bcs t's hrd 2 rd. And now you've got Wannabee doing it too!
> His last reply to you was "." - I guess that's positive, but
> if he'd *really* liked it, he would have said "!" :)
>
> As I said, this *is* a matter of opinion, but I think you'll
> find that "most people" prefer a little more "visual clue"
> than the extremely "terse" styles provide.
Yes; But, well, look at my average post length...does it look like I suffer
 from the "TXTrs" disease of stunted linguistical growth and maturity? ;)
It seems not only "concise" is being confused for "short" but so is
"minimal"...allow me to clarify:
"Concise" = "information tightly packed; High expressiveness in short
distance"
"Minimal" = "least necessary; Redundency removed"
"Short"   = "occupies small distance"
For example, though not as extensive or comprehensive at its fuller cousin,
the "Oxford Concise Dictionary" is _NOT_ a small or short book...indeed, it
occupies a volume similar to a Bible alongside on my bookshelf (and that's
with the dictionary using a _smaller font_, abbreviations and wasting no
space on "white space" in any of the entries at all, than the Bible does
too ;)...
If "concise" actually meant the same as "short" or "small" then the "Oxford
Concise Dictionary" (and, well, these people _should_ know better than most
what English words mean, considering who they are and what the publication
itself is ;), then the title would be a lie...as it is one of the least
"short-ish" books on my entire bookshelf...in fact, only the UNICODE
reference book is larger (but then this one gigantic book, covering all
characters in the entire UNICODE range, across hundreds of languages and
scripts)...
And "minimal" neither means "short" either...I visited an art exhibition by
the "minimalist art" movement and the actual pieces of artwork were among
the largest I've ever seen (the American ex-billboard painter James
Rosenquist earns the "biggest" award, though, because in switching from
billboard painter to a "pop artist", he did _NOT_ decide to reduce the
scale of his artworks at all...indeed, they got _bigger_...only one room in
the entire exhibition could house his work which had to be lifted through
the roof by a crane and, even then, placed at a slanted angle because it
was longer than the room's length that it couldn't be placed flat against
the wall, even then..."big" does not sum up how stupidly massive this
"painting" was...the scale of his work has to be seen to be believed...this
other famous one by him -
http://www.guggenheim.org/exhibitions/rosenquist/highlights3_lg.html - for
instance, is 83 feet in length and 10 foot tall!! ;)...
There was a large block covered in mirrors, taller than a person, cubed
(that is, "taller than a person in all three directions of space"...indeed,
it was a perfect cube so each side was the same length, of course ;), as an
example...VERY BIG stuff...the point in such "minimalism" is not that the
artwork is "small" or "short" but that it is "free of
extraneousness"...that is, it was just a large block whose sides were
mirrors...that's it...nothing more to it...
I give not a crap for "short"...indeed, to be "minimal" might even
sometimes require _writing more_...I don't know about Rene's or Ro's
"minimal" but my "minimal" has NOTHING to do with "length" but everything
to do with _semantics_...when I mean "minimal", I mean "free of
redundency", "absent of extraneousness", "least required normalised form"
and so forth...it is a _qualitative_, not quantitative measure...
For example, if I took a 83 foot long canvas - like Mr.Rosenquist - and
painted it completely red and then drew a single white line across
it...this would be "minimalist" but it would not be "short" nor
"small"...it is a reference, if you like, to the "amount of details" or the
"complexity", NOT to its "size"...indeed, it's quite possible that, in some
circumstances, making things "simpler" and "minimalist" in that regard,
could even lead to the overall "size" getting bigger...due to,
interestingly enough, a lack of "conciseness"...are we getting that these
words are NOT "synonyms" yet? ;)...
Clean, clear, simplicity is what I'm after with "minimalism"...I give NOT a
single crap about "saving typing"...this is a trivial concern...what
matters with programming - where all the bugs and maintenance nightmares
and such stem from - is _COMPREHENSION_...two basic devices aid human
comprehension: "Divide and conquer" and "keep it simple, stupid!"...you'll
note that "blocks" is the "divide and conquer"...the other component is to
attempt to keep everything as "simple" as possible...the "UNIX philosophy"
of creating _SINGULAR-PURPOSE_ utilities...you know, "echo" just echoes
back whatever command line it's given...that's it...that is "minimal"...no
"bells and whistles", no "complex features" nor anything of that kind...it
just does _ONE_ job and does it well and does it _simple_...
Solving big problems by making them a series of "simple small
problems"...each easy to solve...work your way through them and the "big
problem" is equally easily solved...
This is in contrast to the opposing concept of making a monolithic tool
with 97,000 "features", each of such complexity you need a PhD in that
specific feature to even begin to understand how to use it, then proposing
that "big and complex solutions require big and complex tools"...Bzzt!
Wrong answer...the whole problem in the first place is "big and
complex"...adding on more "big and complex" makes it _HARDER_ to solve
because now you've got twice as much "big and complex" to work your way
through...on the contrary, the tool should pursue "minimal" that it does
not itself become "part of the problem"...and it should help to "break
down" the "big problem" into "a series of smaller, simpler problems"
because those are each much easier to deal with and, thus, aids dealing
with the "big problem"...
Note: Much of the design for LuxAsm that I've provided _IS_ based on the
"large-scale" problem...this is with reason...as I'm sure Randy can confirm
(he knows these kind of things usually :), projects manifest new and
difficult additional problems when they go "large-scale"...it is not simply
"small program but slightly larger"...because the "size" begins to outweigh
the capacity of the human mind to naturally deal with (there is no shame in
this: It's the way all human beings are wired up...some more than others
but it is an essential trait we all share...scientists estimate that it's
something akin to roughly a "limit" of 7 different concepts can be
consciously wielded by the human mind simultaneously...thereafter, you've
got to start relying on "memory recall" and that's where problems start to
develop...indeed, _some_ people are better at this than others BUT, at some
point, _everyone_ will hit their "limits")...also, large projects tend to
be "team projects", due to, of course, trying to get something so "big and
complex" done by some "deadline"..."team interaction" brings in new
problems again...blah-blah-blah...
"OOP" is a typical common solution used...it does the "divide and conquer"
thing..."encapsulates" the parts to "separate" and "decouple"...to break
the "interdependencies" between "modules / objects"...thus, allowing each
part to be its own _SMALLER_ "little problem" that's more easily
solved...this, indeed, is, in fact, the "WHY?" when it comes to OOP...
As an example, I have my little bookshelf here...I just throw the books
onto the shelf in any old order because it's just one shelf of books (an
"essentials" kind of deal: a Bible, a dictionary, a thesaurus, a "word
origins" book, a maths textbook and then a bunch of programming
books...indeed, if you like, this is "minimal" again...I do have more books
elsewhere but for this "handy reference" shelf, I select the "minimal"
amount of "essential references" and put them on this shelf for "easy
access" while working away at my desk here)...this works because this is
"small project" stuff...the shelf is hardly long nor are there a great many
books on it...so, there's no need to "order" them because it takes no time
to scan across the shelf to find the book I want...
BUT, consider the same situation in the "big and complex" arena: A large
city public library...tens of thousands of books, all across large and
varied "topics"...with potentially millions of "borrowers" to keep track
of...can you see a New York public library adopting the same "hackerish"
attitude to ordering and keeping track of their books? Er, no...that just
wouldn't work...wouldn't work at all...
So, when the "bookshelf" problem enters into the "big and complex" arena,
then the "system" changes..._NEEDS_ to change or the "problem" is going to
become "undesirable", if not "impossible"...hence, books are categorised
with "category numbers" (the "dewy decimal system"...not to be confused
with the "duodecimal system", which is a different topic I also like to
talk about ;)...they are ordered alphabetically on the shelves...they are
divided into "fiction" and "reference" and so forth...when people borrow
the books, then they are stamped and the details scanned into a computer
system to keep track of all the books and borrowers...and if you do
something _short_ of this kind of system, then you're not being "big" nor
are you being "clever" because it'll bite you on the bum...you know, a
person coming into the library asks you if you have a book about "Fishing"
by J.R.Hartley (sorry, there's an "in-joke" there that only Brits will get
;)...and, well, there's tens of thousands of books just randomly scattered
on the bookshelves because you couldn't be bothered to "sort" them and just
threw them in any old order onto the shelves...finding that particular book
amongst the shelves and shelves of books...well, best tell the potential
book borrower: "I think you'd better come back in two weeks...it'll take
about that long to go through each book one by one until I find the
specific one"...and then, when you do find it, you hand it to the borrower,
who walks out without giving any details of who he is or when he should
bring it back or anything...unsurprisingly, the books in the public library
slowly "vanish" one by one, as people just take them away and never bring
any of them back...and, hey, you can't do anything about it, really,
because you've not been keeping track of what books you did have, what
books have been "borrowed", who borrowed them or anything...
You couldn't seriosuly run a large public library like that...but, on the
other hand, for my small little bookshelf next to me here, this is
perfectly fine...I don't really need to sort them alphabetically or give
them "category numbers"...there's only about 20 or so books here in
total...it's just _one_ bookshelf, hardly a "public library"...and there is
only _ONE_ "borrower" of the books and that's me...and I don't take them
out of the room (so, yeah, I sometimes don't put them back on the shelf
after I'm done but they won't leave the room and will just be sitting on
the desk here...so, the next day, I'll pick them up and put them back on
the shelf again :)...and if I did ever "borrow" them to a friend...well,
it's a "one-off" kind of thing to someone I already know...I'll just be
able to remember that, anyway...and, as a friend, they'd generally be no
problems about them giving it back...indeed, they'd probably remind me that
I lent them the book when they bring it back rather than the other way
around...
So, it's perfectly okay not to have any great "system" in place for a small
personal bookshelf like this...but it's NO WAY AT ALL to run a large public
library (say, that of New York City's larger public libraries...or the
Library of Congress or the British Library, for that matter :)...
The "big and complex" problem is often _NOT_ simply the "small problem just
made bigger"...new problems develop, new elements come into play...the
"search for a particular book" is easy and fast when there's only 20 books
but it becomes a non-trivial problem when we're talking tens of thousands
or hundreds of thousands of publications...you _DON'T_ really want to be
doing that kind of "search" by hand, yes? ;)...
And listening to the typical assembly language "myths", we can cut a very
direct "pattern" right through them: "assembly language is complex"...ummm,
no...in isolation of individual machine instructions, it's not
"complex"...on the contrary, instructions like "AND" and "OR" are _Boolean
logic_...based on the _MINIMUM_ practical Turing machine of using
_binary_...basically, from one perspective, the universe itself doesn't
come any more "simpler" than this...
So, what is the _real_ complaint when people say "assembly language is
complex"? Ah, well...though individual machine instructions are the very
definition of "simplicity", you need a lot of them to do anything useful
and they "interplay" with one another...EFLAGS carries around a "context"
that effects instructions so you can't look at an instruction in isolation
(for example, the most obvious is that an "if" in HLLs is one simple
statement but it's "multi-part" in assembly language...do each comparison,
set the flags then do a conditional jump on those flags...indeed, the CPU
can only do "simple" things and, thus, our more higher-level "complex"
requirements of "a spread***" has to broken down and broken down and
broken down until, indeed, it reaches a level comparable to Boolean logic
and, well, you really _CAN'T_ break anything down much further than that! I
don't just mean in programming terms, I mean _UNIVERSALLY_ you can't break
anything down much further than that...this is about the most minimal
"Turing machine" that's at all possible to create...well, there's "unary"
instead of "binary" and "unary operators" only...but that's the only thing
"lower" and it isn't a practical way to go about things at all (indeed,
_can_ you make a Turing machine with unary and only unary operators? Anyone
know the theory better than I? If possible, it's "only just" so and you
certainly can't get any lower, in any kind of capacity)...you can't have
"zero-nary", it's illogical :)...
Anyway, yes...so, the problem isn't really "complex" in the sense that the
instructions or such are "complex"...they are, in fact, the very definition
of "simple"...it's the "large-scale problem"...there's _LOTS OF IT_ and it
all "interacts"..._THAT_ is what's "complex"...hence, mark one down for
"large-scale"...
Another "myth": "assembly language is not practical for writing complete
applications"...again, why? I mean, if you can write small programs and
routines in ASM then wouldn't a complete project simply be "more of the
same but bigger"? Ah, no...as we've established with the "public library"
example, this isn't necessarily so...that when things get "big and
complex", the problem itself develops new facets, more "problems" rear
their ugly heads and so forth...again, this is "large-scale" behind the
complaint...
"Assembly language is impossible to maintain"; Again, why exactly? It's
simple when looking at the machine instructions themselves...so, it's got
to be this "big and complex" thing again...but, this time, from the
"interaction" point-of-view...if you like, "too much is going on!! HELP!!"
is the order of the day...it is _exceeding_ the limits of typical human
thinking...those "global variables" are getting too numerous...the code is
turning into a "jungle" of mnemonics and, increasingly, the more you look
at it, the less you feel you're understanding anything...
The underlying problem is "large-scale"...because most assemblers - in
terms of language _AND_ "support" _AND_ how they work - are targetted at
_ONE_ source file (though Rene does not pretend otherwise with "monofile
programming" that he's _delibrately_ targetting such things, the truth is
that most NASM and MASM programs are _ALSO_ "monofile programming" out
there...you know, you _CAN_ perhaps make "libraries"...but, well, hands up
who's actually done so and does so regularly? Well, we know Randy has done
it...but anyone else? Note: My point isn't that it's not possible - on the
contrary, it's _very_ possible - but is anyone actually making _regular
use_ of that possibility? Ah, now that's a different matter
altogether...generally, no, they are not...and, from that perspective,
there is one small "saving grace" for Rene that at least he isn't trying to
"pretend" otherwise...ironically, his "clips file" is a _step backwards_ -
in my opinion, anyway - but it can't be criticised too harshly from the
point-of-view that his RosAsm do actually _USE_ this mechanism...this
cannot always be said for the "more advanced" BUT "rarely, if ever, used"
library support features on other assemblers)...they are targetted at
being, as Rene puts it, "a C-side tool" (that is, an "accompanying tool"
for C language development, not "sea-side tool", as in a bucket and spade
for building sandcastles, even if it does sound similar ;)...
Indeed, it's even going as far as "self-fulfilling prophecy" in that the
tools are only catering for "C-side tool" stuff because they
_pre-determine_ that ASM is only good for such things...
And none of this is missed on me in making my LuxAsm proposals..."blocks"
introduce "divide and conquer"...keeping things "minimal"...the "seamless
development" of the IDE and the associated "incremental" and "feedback"
mechanisms to get us there...the "tight integration" (yet, true to "UNIX
philosophy" as best as possible, it is composed of _singular-purpose_
"utilities"...the IDE simply - like GCC or HLA - "streamlines" the process
by calling the utilities in order...but they are actually individual
"singular purpose" modules running the show "behind the scenes"...using the
command-line interface, this'll be more obvious :)...and I'm proposing
centring on "libraries" as a central "hub" for development to work
around...
Unapologetically, I'm directly chasing after solutions for the
"large-scale" problem...this is, ultimately, the true problem not only with
acceptance and usage of assembly language...but is the central problem in
_PROGRAMMING IN GENERAL_ too...software is becoming increasingly more
difficult to deliver within "schedules", that "shortcuts" are being sought
and this is where "bloat" is coming from...in a sense, I bet that not every
Microsoft programmer is "ignorant" of the issue of "bloat" or likes it or
anything (I mean, _someone_ in Microsoft's employ is an assembly coder too
because they do code at this level and MASM, in fact, is still maintained
because they _DO_ make some use of assembly language internally that they
continue to develop and maintain MASM for themselves...they don't make any
money from it anymore...Borland pulled out because that's not possible
anymore...and even Microsoft - I mean, this is Microsoft, after all! -
don't charge any money for it...a case of "we need this as an internal
development tool BUT might as well make it publicly available, if it
encourages people to write code for Windows and perhaps migrate to VC++ or
something" :)...
Crack the "large-scale" nut and _THIS_ is the best way to "kill bloat" and,
if assembly shall ever be "reborn", then it's by such mechanisms...to
tackle the root cause of all the "complaints"...
Of course, I won't succeed...LuxAsm will only be a "half solution" for
these issues (I Hope and intend it to be a _BETTER_ "solution" that
currently exists but, no, no kind of "miracle"...I have no snake oil to
sell...I mean, the world is full enough of salespeople lying about "Utopia"
already, yes? But, if you want a hammer, then I'm intending to make it the
toughest, shiniest, most useful hammer around...it'll be a good tool...but
the "magic" is supplied by the _PROGRAMMER_...always was, always is and
always will be...let's put those "shampoo adverts" about Utopia to one
side, yes? ;)...I have no "delusions of grandeur" about that...it's too big
a problem for that...but it's one "baby step" on the road toward that
goal...the "next generation" will Hopefully pick up the gauntlet and
"evolve" it all some more...
Hence, "minimalism", as I mean it, fits into this picture: "divide,
simplify, conquer" then "repeat as necessary" (the one phrase on a shampoo
bottle that I _am_ subscribing to ;)...it does not mean "short"...whether
it'll be "short" or not completely depends on how "big and complex" this
project using LuxAsm is going to be...but the "minimalism" means that when
"breaking into small, manageable chunks", those individual chunks are
_easy_ problems to solve...
To remove the extraneous complexity...to eliminate the "redundency"...a
tool should _GET OUT OF THE WAY_ - be "unnoticable" - if it's _REALLY_
doing its job properly...hence, that "seamless development" / "incremental"
/ "feedback" thing isn't a "gimmick" for me...on the contrary, it's very
important and central...with "seamlessness", combined with "minimalism"
("clear", "crisp", "clean", "obvious", "uncomplicated", etc.) and then
"divide and conquer" modularity...well, _THAT_ is what I'm chasing after...
And, as I've said, things like "assemble speed" are "more haste, less
speed" red herrings...waiting for the compiler is NOT the "priority"
problem here at all...indeed, modern compilers and assemblers rip through
source code incredibly quickly...the problem is not the speed at which they
do it, the problem is the amount of source code that they are required to
deal with...you know, the problem is that underlying "big and complex"
source code issue and, in fact, "assemble speed" is almost trying to "cover
over" and "patch up" this problem...speed it up to almost "pretend" that
the problem isn't there...that's why I'm proposing "incremental",
"feedback" and "seamless development" because the root problem has never
really been how fast the compiler can process the source code but the
"start / stop" unseamless (or should I say "unseemly" instead? ;) nature of
development...the way that authors ain't getting "feedback" until a while
later in the development process...
I hate advertising...I don't believe in "gimmicks"...every proposal has a
_reason_ and some "thinking" behind it...okay, perhaps not the best
thinking always or reasons people don't agree with...but it's not
arbitrary...it all fits into a bigger "jigsaw"...
I've done as much "hacking" as the next...I'm not anywhere near wolfgang,
of course - is anyone? - but I have looked through those "hex codes" in the
Intel manuals (for an assembler, in fact...but now LuxAsm will be that
assembler :)...and I've done OOP stuff in HLLs too...not that this is a
cirriculum vitae (for those that don't speak a foreign language: a
resume'...sorry, Stephen Fry, but it's a great joke that I had to borrow it
there ;)...but my point is that I _don't_ want to put "HLLisms" in there
nor add "data typing" in the "core" nor put in "automatic this" or
"behind-the-scenes that"...indeed, NASM's "no red tape" mantra I am taking
to heart...it won't "please all the people all the time" but I'm trying to
delicately tread the "middle path" and "unify" all these things...tackle
the "large-scale" that plagues the entire industry, in a small little way
for at least assembly language...and, well, "trust me, I know what I'm
doing" (ummm, perhaps a bad quotation seeing as Frank Drebin didn't, in
fact, have the slightest clue what he was doing...but, well, perhaps I
don't either...but I think I do :)...
Beth :)
--__--__--
Message: 4
From: "Beth" <BethStone@UnlimitedMail.org>
To: <luxasm-devel@lists.sourceforge.net>
Date: Thu, 24 Feb 2005 01:27:31 -0000
Subject: [Luxasm-devel] Fw: More "unification" and LuxAsm syntax
Reply-To: luxasm-devel@lists.sourceforge.net
[ Just passing on this from the newsgroup...haven't sorted out the new
Email to be the "default" for cross-posting to the mailing-list and posting
to the group at the same time as yet :) ]
----- Original Message -----
From: "Beth" <BethStone21@hotmail.NOSPICEDHAM.com>
To: <luxasm-devel@lists.sourceforge.net>
Sent: Thursday, February 24, 2005 1:25 AM
Subject: Re: More "unification" and LuxAsm syntax
> Frankie say:
> > Ro wrote:
> > > Why is it[too much "minimalism"] not a good thing?
> >
> > Bcs t's hrd 2 rd. And now you've got Wannabee doing it too!
> > His last reply to you was "." - I guess that's positive, but
> > if he'd *really* liked it, he would have said "!" :)
> >
> > As I said, this *is* a matter of opinion, but I think you'll
> > find that "most people" prefer a little more "visual clue"
> > than the extremely "terse" styles provide.
>
> Yes; But, well, look at my average post length...does it look like I
suffer
> from the "TXTrs" disease of stunted linguistical growth and maturity? ;)
>
> It seems not only "concise" is being confused for "short" but so is
> "minimal"...allow me to clarify:
>
> "Concise" = "information tightly packed; High expressiveness in short
> distance"
> "Minimal" = "least necessary; Redundency removed"
> "Short"   = "occupies small distance"
>
> For example, though not as extensive or comprehensive at its fuller
cousin,
> the "Oxford Concise Dictionary" is _NOT_ a small or short book...indeed,
it
> occupies a volume similar to a Bible alongside on my bookshelf (and
that's
> with the dictionary using a _smaller font_, abbreviations and wasting no
> space on "white space" in any of the entries at all, than the Bible does
> too ;)...
>
> If "concise" actually meant the same as "short" or "small" then the
"Oxford
> Concise Dictionary" (and, well, these people _should_ know better than
most
> what English words mean, considering who they are and what the
publication
> itself is ;), then the title would be a lie...as it is one of the least
> "short-ish" books on my entire bookshelf...in fact, only the UNICODE
> reference book is larger (but then this one gigantic book, covering all
> characters in the entire UNICODE range, across hundreds of languages and
> scripts)...
>
> And "minimal" neither means "short" either...I visited an art exhibition
by
> the "minimalist art" movement and the actual pieces of artwork were among
> the largest I've ever seen (the American ex-billboard painter James
> Rosenquist earns the "biggest" award, though, because in switching from
> billboard painter to a "pop artist", he did _NOT_ decide to reduce the
> scale of his artworks at all...indeed, they got _bigger_...only one room
in
> the entire exhibition could house his work which had to be lifted through
> the roof by a crane and, even then, placed at a slanted angle because it
> was longer than the room's length that it couldn't be placed flat against
> the wall, even then..."big" does not sum up how stupidly massive this
> "painting" was...the scale of his work has to be seen to be
believed...this
> other famous one by him -
> http://www.guggenheim.org/exhibitions/rosenquist/highlights3_lg.html -
for
> instance, is 83 feet in length and 10 foot tall!! ;)...
>
> There was a large block covered in mirrors, taller than a person, cubed
> (that is, "taller than a person in all three directions of
space"...indeed,
> it was a perfect cube so each side was the same length, of course ;), as
an
> example...VERY BIG stuff...the point in such "minimalism" is not that the
> artwork is "small" or "short" but that it is "free of
> extraneousness"...that is, it was just a large block whose sides were
> mirrors...that's it...nothing more to it...
>
> I give not a crap for "short"...indeed, to be "minimal" might even
> sometimes require _writing more_...I don't know about Rene's or Ro's
> "minimal" but my "minimal" has NOTHING to do with "length" but everything
> to do with _semantics_...when I mean "minimal", I mean "free of
> redundency", "absent of extraneousness", "least required normalised form"
> and so forth...it is a _qualitative_, not quantitative measure...
>
> For example, if I took a 83 foot long canvas - like Mr.Rosenquist - and
> painted it completely red and then drew a single white line across
> it...this would be "minimalist" but it would not be "short" nor
> "small"...it is a reference, if you like, to the "amount of details" or
the
> "complexity", NOT to its "size"...indeed, it's quite possible that, in
some
> circumstances, making things "simpler" and "minimalist" in that regard,
> could even lead to the overall "size" getting bigger...due to,
> interestingly enough, a lack of "conciseness"...are we getting that these
> words are NOT "synonyms" yet? ;)...
>
> Clean, clear, simplicity is what I'm after with "minimalism"...I give NOT
a
> single crap about "saving typing"...this is a trivial concern...what
> matters with programming - where all the bugs and maintenance nightmares
> and such stem from - is _COMPREHENSION_...two basic devices aid human
> comprehension: "Divide and conquer" and "keep it simple,
stupid!"...you'll
> note that "blocks" is the "divide and conquer"...the other component is
to
> attempt to keep everything as "simple" as possible...the "UNIX
philosophy"
> of creating _SINGULAR-PURPOSE_ utilities...you know, "echo" just echoes
> back whatever command line it's given...that's it...that is
"minimal"...no
> "bells and whistles", no "complex features" nor anything of that
kind...it
> just does _ONE_ job and does it well and does it _simple_...
>
> Solving big problems by making them a series of "simple small
> problems"...each easy to solve...work your way through them and the "big
> problem" is equally easily solved...
>
> This is in contrast to the opposing concept of making a monolithic tool
> with 97,000 "features", each of such complexity you need a PhD in that
> specific feature to even begin to understand how to use it, then
proposing
> that "big and complex solutions require big and complex tools"...Bzzt!
> Wrong answer...the whole problem in the first place is "big and
> complex"...adding on more "big and complex" makes it _HARDER_ to solve
> because now you've got twice as much "big and complex" to work your way
> through...on the contrary, the tool should pursue "minimal" that it does
> not itself become "part of the problem"...and it should help to "break
> down" the "big problem" into "a series of smaller, simpler problems"
> because those are each much easier to deal with and, thus, aids dealing
> with the "big problem"...
>
> Note: Much of the design for LuxAsm that I've provided _IS_ based on the
> "large-scale" problem...this is with reason...as I'm sure Randy can
confirm
> (he knows these kind of things usually :), projects manifest new and
> difficult additional problems when they go "large-scale"...it is not
simply
> "small program but slightly larger"...because the "size" begins to
outweigh
> the capacity of the human mind to naturally deal with (there is no shame
in
> this: It's the way all human beings are wired up...some more than others
> but it is an essential trait we all share...scientists estimate that it's
> something akin to roughly a "limit" of 7 different concepts can be
> consciously wielded by the human mind simultaneously...thereafter, you've
> got to start relying on "memory recall" and that's where problems start
to
> develop...indeed, _some_ people are better at this than others BUT, at
some
> point, _everyone_ will hit their "limits")...also, large projects tend to
> be "team projects", due to, of course, trying to get something so "big
and
> complex" done by some "deadline"..."team interaction" brings in new
> problems again...blah-blah-blah...
>
> "OOP" is a typical common solution used...it does the "divide and
conquer"
> thing..."encapsulates" the parts to "separate" and "decouple"...to break
> the "interdependencies" between "modules / objects"...thus, allowing each
> part to be its own _SMALLER_ "little problem" that's more easily
> solved...this, indeed, is, in fact, the "WHY?" when it comes to OOP...
>
> As an example, I have my little bookshelf here...I just throw the books
> onto the shelf in any old order because it's just one shelf of books (an
> "essentials" kind of deal: a Bible, a dictionary, a thesaurus, a "word
> origins" book, a maths textbook and then a bunch of programming
> books...indeed, if you like, this is "minimal" again...I do have more
books
> elsewhere but for this "handy reference" shelf, I select the "minimal"
> amount of "essential references" and put them on this shelf for "easy
> access" while working away at my desk here)...this works because this is
> "small project" stuff...the shelf is hardly long nor are there a great
many
> books on it...so, there's no need to "order" them because it takes no
time
> to scan across the shelf to find the book I want...
>
> BUT, consider the same situation in the "big and complex" arena: A large
> city public library...tens of thousands of books, all across large and
> varied "topics"...with potentially millions of "borrowers" to keep track
> of...can you see a New York public library adopting the same "hackerish"
> attitude to ordering and keeping track of their books? Er, no...that just
> wouldn't work...wouldn't work at all...
>
> So, when the "bookshelf" problem enters into the "big and complex" arena,
> then the "system" changes..._NEEDS_ to change or the "problem" is going
to
> become "undesirable", if not "impossible"...hence, books are categorised
> with "category numbers" (the "dewy decimal system"...not to be confused
> with the "duodecimal system", which is a different topic I also like to
> talk about ;)...they are ordered alphabetically on the shelves...they are
> divided into "fiction" and "reference" and so forth...when people borrow
> the books, then they are stamped and the details scanned into a computer
> system to keep track of all the books and borrowers...and if you do
> something _short_ of this kind of system, then you're not being "big" nor
> are you being "clever" because it'll bite you on the bum...you know, a
> person coming into the library asks you if you have a book about
"Fishing"
> by J.R.Hartley (sorry, there's an "in-joke" there that only Brits will
get
> ;)...and, well, there's tens of thousands of books just randomly
scattered
> on the bookshelves because you couldn't be bothered to "sort" them and
just
> threw them in any old order onto the shelves...finding that particular
book
> amongst the shelves and shelves of books...well, best tell the potential
> book borrower: "I think you'd better come back in two weeks...it'll take
> about that long to go through each book one by one until I find the
> specific one"...and then, when you do find it, you hand it to the
borrower,
> who walks out without giving any details of who he is or when he should
> bring it back or anything...unsurprisingly, the books in the public
library
> slowly "vanish" one by one, as people just take them away and never bring
> any of them back...and, hey, you can't do anything about it, really,
> because you've not been keeping track of what books you did have, what
> books have been "borrowed", who borrowed them or anything...
>
> You couldn't seriosuly run a large public library like that...but, on the
> other hand, for my small little bookshelf next to me here, this is
> perfectly fine...I don't really need to sort them alphabetically or give
> them "category numbers"...there's only about 20 or so books here in
> total...it's just _one_ bookshelf, hardly a "public library"...and there
is
> only _ONE_ "borrower" of the books and that's me...and I don't take them
> out of the room (so, yeah, I sometimes don't put them back on the shelf
> after I'm done but they won't leave the room and will just be sitting on
> the desk here...so, the next day, I'll pick them up and put them back on
> the shelf again :)...and if I did ever "borrow" them to a friend...well,
> it's a "one-off" kind of thing to someone I already know...I'll just be
> able to remember that, anyway...and, as a friend, they'd generally be no
> problems about them giving it back...indeed, they'd probably remind me
that
> I lent them the book when they bring it back rather than the other way
> around...
>
> So, it's perfectly okay not to have any great "system" in place for a
small
> personal bookshelf like this...but it's NO WAY AT ALL to run a large
public
> library (say, that of New York City's larger public libraries...or the
> Library of Congress or the British Library, for that matter :)...
>
> The "big and complex" problem is often _NOT_ simply the "small problem
just
> made bigger"...new problems develop, new elements come into play...the
> "search for a particular book" is easy and fast when there's only 20
books
> but it becomes a non-trivial problem when we're talking tens of thousands
> or hundreds of thousands of publications...you _DON'T_ really want to be
> doing that kind of "search" by hand, yes? ;)...
>
> And listening to the typical assembly language "myths", we can cut a very
> direct "pattern" right through them: "assembly language is
complex"...ummm,
> no...in isolation of individual machine instructions, it's not
> "complex"...on the contrary, instructions like "AND" and "OR" are
_Boolean
> logic_...based on the _MINIMUM_ practical Turing machine of using
> _binary_...basically, from one perspective, the universe itself doesn't
> come any more "simpler" than this...
>
> So, what is the _real_ complaint when people say "assembly language is
> complex"? Ah, well...though individual machine instructions are the very
> definition of "simplicity", you need a lot of them to do anything useful
> and they "interplay" with one another...EFLAGS carries around a "context"
> that effects instructions so you can't look at an instruction in
isolation
> (for example, the most obvious is that an "if" in HLLs is one simple
> statement but it's "multi-part" in assembly language...do each
comparison,
> set the flags then do a conditional jump on those flags...indeed, the CPU
> can only do "simple" things and, thus, our more higher-level "complex"
> requirements of "a spread***" has to broken down and broken down and
> broken down until, indeed, it reaches a level comparable to Boolean logic
> and, well, you really _CAN'T_ break anything down much further than that!
I
> don't just mean in programming terms, I mean _UNIVERSALLY_ you can't
break
> anything down much further than that...this is about the most minimal
> "Turing machine" that's at all possible to create...well, there's "unary"
> instead of "binary" and "unary operators" only...but that's the only
thing
> "lower" and it isn't a practical way to go about things at all (indeed,
> _can_ you make a Turing machine with unary and only unary operators?
Anyone
> know the theory better than I? If possible, it's "only just" so and you
> certainly can't get any lower, in any kind of capacity)...you can't have
> "zero-nary", it's illogical :)...
>
> Anyway, yes...so, the problem isn't really "complex" in the sense that
the
> instructions or such are "complex"...they are, in fact, the very
definition
> of "simple"...it's the "large-scale problem"...there's _LOTS OF IT_ and
it
> all "interacts"..._THAT_ is what's "complex"...hence, mark one down for
> "large-scale"...
>
> Another "myth": "assembly language is not practical for writing complete
> applications"...again, why? I mean, if you can write small programs and
> routines in ASM then wouldn't a complete project simply be "more of the
> same but bigger"? Ah, no...as we've established with the "public library"
> example, this isn't necessarily so...that when things get "big and
> complex", the problem itself develops new facets, more "problems" rear
> their ugly heads and so forth...again, this is "large-scale" behind the
> complaint...
>
> "Assembly language is impossible to maintain"; Again, why exactly? It's
> simple when looking at the machine instructions themselves...so, it's got
> to be this "big and complex" thing again...but, this time, from the
> "interaction" point-of-view...if you like, "too much is going on!!
HELP!!"
> is the order of the day...it is _exceeding_ the limits of typical human
> thinking...those "global variables" are getting too numerous...the code
is
> turning into a "jungle" of mnemonics and, increasingly, the more you look
> at it, the less you feel you're understanding anything...
>
> The underlying problem is "large-scale"...because most assemblers - in
> terms of language _AND_ "support" _AND_ how they work - are targetted at
> _ONE_ source file (though Rene does not pretend otherwise with "monofile
> programming" that he's _delibrately_ targetting such things, the truth is
> that most NASM and MASM programs are _ALSO_ "monofile programming" out
> there...you know, you _CAN_ perhaps make "libraries"...but, well, hands
up
> who's actually done so and does so regularly? Well, we know Randy has
done
> it...but anyone else? Note: My point isn't that it's not possible - on
the
> contrary, it's _very_ possible - but is anyone actually making _regular
> use_ of that possibility? Ah, now that's a different matter
> altogether...generally, no, they are not...and, from that perspective,
> there is one small "saving grace" for Rene that at least he isn't trying
to
> "pretend" otherwise...ironically, his "clips file" is a _step
backwards_ -
> in my opinion, anyway - but it can't be criticised too harshly from the
> point-of-view that his RosAsm do actually _USE_ this mechanism...this
> cannot always be said for the "more advanced" BUT "rarely, if ever, used"
> library support features on other assemblers)...they are targetted at
> being, as Rene puts it, "a C-side tool" (that is, an "accompanying tool"
> for C language development, not "sea-side tool", as in a bucket and spade
> for building sandcastles, even if it does sound similar ;)...
>
> Indeed, it's even going as far as "self-fulfilling prophecy" in that the
> tools are only catering for "C-side tool" stuff because they
> _pre-determine_ that ASM is only good for such things...
>
> And none of this is missed on me in making my LuxAsm proposals..."blocks"
> introduce "divide and conquer"...keeping things "minimal"...the "seamless
> development" of the IDE and the associated "incremental" and "feedback"
> mechanisms to get us there...the "tight integration" (yet, true to "UNIX
> philosophy" as best as possible, it is composed of _singular-purpose_
> "utilities"...the IDE simply - like GCC or HLA - "streamlines" the
process
> by calling the utilities in order...but they are actually individual
> "singular purpose" modules running the show "behind the scenes"...using
the
> command-line interface, this'll be more obvious :)...and I'm proposing
> centring on "libraries" as a central "hub" for development to work
> around...
>
> Unapologetically, I'm directly chasing after solutions for the
> "large-scale" problem...this is, ultimately, the true problem not only
with
> acceptance and usage of assembly language...but is the central problem in
> _PROGRAMMING IN GENERAL_ too...software is becoming increasingly more
> difficult to deliver within "schedules", that "shortcuts" are being
sought
> and this is where "bloat" is coming from...in a sense, I bet that not
every
> Microsoft programmer is "ignorant" of the issue of "bloat" or likes it or
> anything (I mean, _someone_ in Microsoft's employ is an assembly coder
too
> because they do code at this level and MASM, in fact, is still maintained
> because they _DO_ make some use of assembly language internally that they
> continue to develop and maintain MASM for themselves...they don't make
any
> money from it anymore...Borland pulled out because that's not possible
> anymore...and even Microsoft - I mean, this is Microsoft, after all! -
> don't charge any money for it...a case of "we need this as an internal
> development tool BUT might as well make it publicly available, if it
> encourages people to write code for Windows and perhaps migrate to VC++
or
> something" :)...
>
> Crack the "large-scale" nut and _THIS_ is the best way to "kill bloat"
and,
> if assembly shall ever be "reborn", then it's by such mechanisms...to
> tackle the root cause of all the "complaints"...
>
> Of course, I won't succeed...LuxAsm will only be a "half solution" for
> these issues (I Hope and intend it to be a _BETTER_ "solution" that
> currently exists but, no, no kind of "miracle"...I have no snake oil to
> sell...I mean, the world is full enough of salespeople lying about
"Utopia"
> already, yes? But, if you want a hammer, then I'm intending to make it
the
> toughest, shiniest, most useful hammer around...it'll be a good
tool...but
> the "magic" is supplied by the _PROGRAMMER_...always was, always is and
> always will be...let's put those "shampoo adverts" about Utopia to one
> side, yes? ;)...I have no "delusions of grandeur" about that...it's too
big
> a problem for that...but it's one "baby step" on the road toward that
> goal...the "next generation" will Hopefully pick up the gauntlet and
> "evolve" it all some more...
>
> Hence, "minimalism", as I mean it, fits into this picture: "divide,
> simplify, conquer" then "repeat as necessary" (the one phrase on a
shampoo
> bottle that I _am_ subscribing to ;)...it does not mean "short"...whether
> it'll be "short" or not completely depends on how "big and complex" this
> project using LuxAsm is going to be...but the "minimalism" means that
when
> "breaking into small, manageable chunks", those individual chunks are
> _easy_ problems to solve...
>
> To remove the extraneous complexity...to eliminate the "redundency"...a
> tool should _GET OUT OF THE WAY_ - be "unnoticable" - if it's _REALLY_
> doing its job properly...hence, that "seamless development" /
"incremental"
> / "feedback" thing isn't a "gimmick" for me...on the contrary, it's very
> important and central...with "seamlessness", combined with "minimalism"
> ("clear", "crisp", "clean", "obvious", "uncomplicated", etc.) and then
> "divide and conquer" modularity...well, _THAT_ is what I'm chasing
after...
>
> And, as I've said, things like "assemble speed" are "more haste, less
> speed" red herrings...waiting for the compiler is NOT the "priority"
> problem here at all...indeed, modern compilers and assemblers rip through
> source code incredibly quickly...the problem is not the speed at which
they
> do it, the problem is the amount of source code that they are required to
> deal with...you know, the problem is that underlying "big and complex"
> source code issue and, in fact, "assemble speed" is almost trying to
"cover
> over" and "patch up" this problem...speed it up to almost "pretend" that
> the problem isn't there...that's why I'm proposing "incremental",
> "feedback" and "seamless development" because the root problem has never
> really been how fast the compiler can process the source code but the
> "start / stop" unseamless (or should I say "unseemly" instead? ;) nature
of
> development...the way that authors ain't getting "feedback" until a while
> later in the development process...
>
> I hate advertising...I don't believe in "gimmicks"...every proposal has a
> _reason_ and some "thinking" behind it...okay, perhaps not the best
> thinking always or reasons people don't agree with...but it's not
> arbitrary...it all fits into a bigger "jigsaw"...
>
> I've done as much "hacking" as the next...I'm not anywhere near wolfgang,
> of course - is anyone? - but I have looked through those "hex codes" in
the
> Intel manuals (for an assembler, in fact...but now LuxAsm will be that
> assembler :)...and I've done OOP stuff in HLLs too...not that this is a
> cirriculum vitae (for those that don't speak a foreign language: a
> resume'...sorry, Stephen Fry, but it's a great joke that I had to borrow
it
> there ;)...but my point is that I _don't_ want to put "HLLisms" in there
> nor add "data typing" in the "core" nor put in "automatic this" or
> "behind-the-scenes that"...indeed, NASM's "no red tape" mantra I am
taking
> to heart...it won't "please all the people all the time" but I'm trying
to
> delicately tread the "middle path" and "unify" all these things...tackle
> the "large-scale" that plagues the entire industry, in a small little way
> for at least assembly language...and, well, "trust me, I know what I'm
> doing" (ummm, perhaps a bad quotation seeing as Frank Drebin didn't, in
> fact, have the slightest clue what he was doing...but, well, perhaps I
> don't either...but I think I do :)...
>
> Beth :)
>
-- 
http://TheWannabee.org
Quantcast