A room between abstraction and reality 
Author Message
 A room between abstraction and reality

Quote:

> How does supporting nested structures create more problems
> than it solves?

> Abstraction (the "hidden way" you are discussing) is a very
> powerful tool for developing complex software.  While there
> are often performance benefits to working at very concrete
> levels, a good programming tool should allow the programmer
> to abstract away unnecessary details as desired.

> As best I can tell, NASM is very popular among many
> assembly language programmers because it is so
> "simple" (i.e., it doesn't have anywhere near the number
> of features, *that one has to learn about*, as MASM or
> TASM).  This is great for those who write short programs
> or only want to be bothered learning just enough assembly
> language to get a small job done.  However, once the
> programmer progresses beyond this phase a simple
> assembler like NASM begins to fail them (especially
> if that programmer comes from a HLL background and
> is used to employing abstraction to write better code).

> In various newsgroups I've seen people pushing NASM
> for many wrong reasons.  The comment above is a good
> example.  The original poster asked how to deal with
> nested structs in NASM.  Rather than simply replying
> "You can't, perhaps it's time to move up to a more
> powerful assembler." the response was "You shouldn't
> really be trying to do these powerful things in assembly
> language."  Quite frankly, this is a good way to convince
> someone to give up on assembly language and go back
> to C/C++ or some other HLL.

> Note that MASM, TASM, HLA, and other assemblers
> certainly allow you to nest structs (records), unions,
> classes, and other data type objects.  The correct
> response to the original post, therefore, is
> "you've reached the limits of NASM, it's time for you
> to progress on to a more powerful programming tool."
> Randy Hyde

__________________________________________________________

Sorry, i didn't answer this message previously (i simply
missed it).

Well, you missunderstood my position and you are much allowed
to, as i never was clear about this: i prefer writing assembler
than make phylosophia about it, but it is sometimes nessecary.

What i see every days is that the higher level abstraction is,
the greater confusion risky it is. And so i usually prefer the
going to lower level. But i do NOT mean that abstraction is bad
and that we should reject it. I simply see that when programmers
have put one finger in the HLL directions of the assemblers you
like, they are intirely mangled by it and seem unable to return
back to "true assembler" reality and simplicity. Excuse me for
"true assembler", i don't find any other expression for what i
mean: For me, the one pure assembler is actually ASM32, and i have
never considered MASM as an Assembler... Of course, with ASM32,
programming a PE is something i would never recommand to anyone
(though i did it).

_______________________________________________________________

When i begun SpAsm, NASM did already exist. If i'd been perfectely
satistied with it, i would never have begin writing mine. But,
actually, i considered it much much better than MASM. I didn't
choose to contribute to NASM because it is written in C and that
i would prefer stop any computer activity than write one line of
C. But:

1) It is open source and doesn't come from the devil camp!
   If you are not satisfied with it, it would be more intelligent
   and constructive to contribute to it instead of denigrate.

2) the fact that it is written in C (i hate C overall) doesn't
   mean that NASM is, by definition, bad. Its construction is very
   very clean; really a very good traditionnal job.

3) NASM syntax for data adressing (same as SpAsm) is the only
   consistent, solid, logical one.

4) NASM has been choosen by people who are writing ReactOS and by
   people who build Visual Assembler. So i feel less alone in my
   opinion. Are they all wrong and you right?

________________________________________________________________

You ironize about "the number of features, *that one has to learn
about*" in a way that makes us clearly see your position: You are
very proud (we already knew) of your knowledge and would desagrea
with a programming tool that would make it of lesser use. Well,
humain is like this. But, from a "professional programmer", this
is a very stange and inconsistent attitude.

When we write some app, don't have we all to make it as simple and
as friendly as possible for user? Don't we have to consider that, if
a common user of ower productions have some difficulties at learning
it, this is not because he is stupid: this is because we are wrong?

Sure you will agrea. Now, why sould it be the opposite for an Assembler.

For the programmer, the Assembler is an app. If this app need
"professional" no end studies, this app is simply BAD (not powerfull).

When i did implement macros in SpAsm i spent several months (yes, sir)
about studying what could ne the simpliest solutions for syntax. You
denigrate it because it doesn't include "conditionals" and "recursion",
(what i may add later) but you may have missed to see that one can know
everything of my macros syntax in twenty minutes, and easily remember
it one month later. And i am very proud of this.

There are not only professional programmers on the world and futur
doesn't
belong to them. A lot of good products are done by sunday-programmers
like
me. We need simple tools. Assembly langage by itself is VERY simple and
we
do not need fancyfull features that turn it a "professional toooool".
Futur is to "free programmers", just because future will be free or not.

(i am talking about "free of money" not of freedom, what is another
story.)

You associate advanced features with "powerful programming tool"
designed
for important app writing, and low level with poor programming tool
designed for beginners demos, don't you? Right now, i can not yet make
an impressive demonstration of the opposite, but i surely will, when
SpAsm
will be over. Actually all people thing i am jocking when i say that
there
is no reason for Assembler be more difficult than Basic. I will prove, i
am
not jocking at all, in one year. I just didn't insist about it, because,
at
actual developpement state, i do not want to misslead beginner and
prefer
they go to NASM than email me for asking "why did it hang?"...

___________________________________________________________________________

Thanks again for your "critique" of SpAsm. I am still studying some
points
(particulary recursion for macros, that leaves me very uncertain...). I
have
just implemented the "typing overwrite by macros" (i suppose you
understand
what i mean). It works fine (though i still disaprove replacing the so
simple
and clear "B" by any stupid "char"). I am studying too an added
implementation
of "named local labels" under the form of:

MainLabel:
  ;
  ;;; blablabla
  ;


  ;
  ;;; blablabla
  ;

.Local_Label:

Still seams to me a very stupid idea. i have to think more... (how will
user know if it is long or short?...)

Bye. betov.



Thu, 31 Oct 2002 03:00:00 GMT  
 A room between abstraction and reality

Quote:

> Well, you missunderstood my position and you are much allowed
> to, as i never was clear about this: i prefer writing assembler
> than make phylosophia about it, but it is sometimes nessecary.

I absolutely agree with this as a programer.  Discussion of the
philosophy of tools is fun and it's good to understand what went
into the design of the tools, but for a programmer it just isn't
important compared to knowlege of how to use the tools.

However, it seems to me that this would be a critical subject for
the designers of those tools.

Quote:
> What i see every days is that the higher level abstraction is,
> the greater confusion risky it is. And so i usually prefer the
> going to lower level. But i do NOT mean that abstraction is bad
> and that we should reject it. I simply see that when programmers
> have put one finger in the HLL directions of the assemblers you
> like, they are intirely mangled by it and seem unable to return
> back to "true assembler" reality and simplicity. Excuse me for
> "true assembler", i don't find any other expression for what i
> mean: For me, the one pure assembler is actually ASM32, and i
have
> never considered MASM as an Assembler... Of course, with ASM32,
> programming a PE is something i would never recommand to anyone
> (though i did it).

While a tool would be expected to reflect the philosphy of it's
creator, if it's a good tool it won't restrict the user to that
philosophy.

Most (not all) of my assembly has been subroutines and functions
for HLL programs, or small tools such as TSRs.  I've seldom needed
more than a simple assembler.  But it's really nice to know those
other features are there when they're needed or if I just feel like
using them.  And I do use them.

In Masm (admittedly a complex assembler) you really don't have to
learn that many features to get started.  My first 8088 programs
were written with template directives stolen from other programs
and I just filled in the code.  I knew very little about the
directives.  I didn't even know what directives were available at
first.

Directives that you don't need and aren't aware of do not make
programming more complex until you need or want that added
complexity.

Quote:
> 1) It is open source and doesn't come from the devil camp!
>    If you are not satisfied with it, it would be more intelligent
>    and constructive to contribute to it instead of denigrate.

Phrases like "devil camp" make me wonder how much your "assembler
philosophy" is carefully thought out and planned and how much is a
knee jerk reaction to something you obviously hate.

Quote:
> 2) the fact that it is written in C (i hate C overall) doesn't
>    mean that NASM is, by definition, bad. Its construction is
very
>    very clean; really a very good traditionnal job.

See comment above.

Quote:
> 3) NASM syntax for data adressing (same as SpAsm) is the only
>    consistent, solid, logical one.

Right!  And Ford had a better idea.  And you can be sure if it's
Westinghouse.  And you're in good hands with Allstate.  :)

Quote:
> When we write some app, don't have we all to make it as simple
and
> as friendly as possible for user? Don't we have to consider that,
if
> a common user of ower productions have some difficulties at
learning
> it, this is not because he is stupid: this is because we are

wrong?

I think it depends on the intended user.  There are situations in
which a very simple assembler is useful.  I used A86 on my 95LX
palmtop when there wasn't room on it for any other programming
tools.  Now I use a 200LX with lots of room and I have Tasm but I
still keep A86 there for the occasional 5 to 10 line program.  (I'm
using A86 as an example because I know it and I don't know Nasm).

But for larger programs I use Tasm.  (Not Masm, because its an
older version and when I made this choice Masm didn't have local
labels and Tasm did).  I often don't use many features of Tasm, but
it's nice to have them there when I want them.

The assembler should reflect the philosophy of it's author but it
should allow me to work with my own philosophy and it should give
me the tools to do so.

I tend to get confused by too many levels of abstraction.  I don't
have a lot of deeply nested macros or many levels of equates.  I
never use the control structures in an assembler.  That makes
debugging too difficult.  I want to see disassemblies that resemble
what I wrote.

Like you, I prefer simplicity.  But I want to decide what
simplicity means to me and I want to be able to vary that decision
as needed.  I can't really do that if the assembler is too simple.

Barry



Thu, 31 Oct 2002 03:00:00 GMT  
 A room between abstraction and reality

Quote:


>> How does supporting nested structures create more problems
>> than it solves?

>> Abstraction (the "hidden way" you are discussing) is a very
>> powerful tool for developing complex software.  While there
>> are often performance benefits to working at very concrete
>> levels, a good programming tool should allow the programmer
>> to abstract away unnecessary details as desired.

>> As best I can tell, NASM is very popular among many
>> assembly language programmers because it is so
>> "simple" (i.e., it doesn't have anywhere near the number
>> of features, *that one has to learn about*, as MASM or
>> TASM).  This is great for those who write short programs
>> or only want to be bothered learning just enough assembly
>> language to get a small job done.  However, once the
>> programmer progresses beyond this phase a simple
>> assembler like NASM begins to fail them (especially
>> if that programmer comes from a HLL background and
>> is used to employing abstraction to write better code).

I think one of the most important things in NASM is the uniform, logical
syntax it uses, which (IMHO) often makes NASM code more readable.

- Show quoted text -

Quote:

>> In various newsgroups I've seen people pushing NASM
>> for many wrong reasons.  The comment above is a good
>> example.  The original poster asked how to deal with
>> nested structs in NASM.  Rather than simply replying
>> "You can't, perhaps it's time to move up to a more
>> powerful assembler." the response was "You shouldn't
>> really be trying to do these powerful things in assembly
>> language."  Quite frankly, this is a good way to convince
>> someone to give up on assembly language and go back
>> to C/C++ or some other HLL.

>> Note that MASM, TASM, HLA, and other assemblers
>> certainly allow you to nest structs (records), unions,
>> classes, and other data type objects.  The correct
>> response to the original post, therefore, is
>> "you've reached the limits of NASM, it's time for you
>> to progress on to a more powerful programming tool."
>> Randy Hyde

The correct response, IMHO, is, "You can do this, with the tools you have,
you just need to think about it in a different way."

- Show quoted text -

Quote:
>__________________________________________________________

>Sorry, i didn't answer this message previously (i simply
>missed it).

>Well, you missunderstood my position and you are much allowed
>to, as i never was clear about this: i prefer writing assembler
>than make phylosophia about it, but it is sometimes nessecary.

>What i see every days is that the higher level abstraction is,
>the greater confusion risky it is. And so i usually prefer the
>going to lower level. But i do NOT mean that abstraction is bad
>and that we should reject it. I simply see that when programmers
>have put one finger in the HLL directions of the assemblers you
>like, they are intirely mangled by it and seem unable to return
>back to "true assembler" reality and simplicity. Excuse me for
>"true assembler", i don't find any other expression for what i
>mean: For me, the one pure assembler is actually ASM32, and i have
>never considered MASM as an Assembler... Of course, with ASM32,
>programming a PE is something i would never recommand to anyone
>(though i did it).

I have to agree with you here.  For example, object orientation involves
ideas which bear no relation to any existing processor (that I know of).
Java, for example, is very object orientated, and I find it very hard to
understand.  I admit that some people think that OO makes programming
easier, but, IMHO, a programming language should focus on only two things:
code and data.

- Show quoted text -

Quote:
>_______________________________________________________________

>When i begun SpAsm, NASM did already exist. If i'd been perfectely
>satistied with it, i would never have begin writing mine. But,
>actually, i considered it much much better than MASM. I didn't
>choose to contribute to NASM because it is written in C and that
>i would prefer stop any computer activity than write one line of
>C. But:

>1) It is open source and doesn't come from the devil camp!
>   If you are not satisfied with it, it would be more intelligent
>   and constructive to contribute to it instead of denigrate.

>2) the fact that it is written in C (i hate C overall) doesn't
>   mean that NASM is, by definition, bad. Its construction is very
>   very clean; really a very good traditionnal job.

>3) NASM syntax for data adressing (same as SpAsm) is the only
>   consistent, solid, logical one.

>4) NASM has been choosen by people who are writing ReactOS and by
>   people who build Visual Assembler. So i feel less alone in my
>   opinion. Are they all wrong and you right?

Hear, hear.  IMHO, NASM is the best assembler.  I particularly agree with
point 3.  Also, NASM is available on several platforms.

- Show quoted text -

Quote:
>________________________________________________________________

>You ironize about "the number of features, *that one has to learn
>about*" in a way that makes us clearly see your position: You are
>very proud (we already knew) of your knowledge and would desagrea
>with a programming tool that would make it of lesser use. Well,
>humain is like this. But, from a "professional programmer", this
>is a very stange and inconsistent attitude.

>When we write some app, don't have we all to make it as simple and
>as friendly as possible for user? Don't we have to consider that, if
>a common user of ower productions have some difficulties at learning
>it, this is not because he is stupid: this is because we are wrong?

>Sure you will agrea. Now, why sould it be the opposite for an Assembler.

>For the programmer, the Assembler is an app. If this app need
>"professional" no end studies, this app is simply BAD (not powerfull).

>When i did implement macros in SpAsm i spent several months (yes, sir)
>about studying what could ne the simpliest solutions for syntax. You
>denigrate it because it doesn't include "conditionals" and "recursion",
>(what i may add later) but you may have missed to see that one can know
>everything of my macros syntax in twenty minutes, and easily remember
>it one month later. And i am very proud of this.

>There are not only professional programmers on the world and futur
>doesn't
>belong to them. A lot of good products are done by sunday-programmers
>like
>me. We need simple tools. Assembly langage by itself is VERY simple and
>we
>do not need fancyfull features that turn it a "professional toooool".
>Futur is to "free programmers", just because future will be free or not.

>(i am talking about "free of money" not of freedom, what is another
>story.)

Free programmers = Free of money programmers = Penniless programmers?

- Show quoted text -

Quote:

>You associate advanced features with "powerful programming tool"
>designed
>for important app writing, and low level with poor programming tool
>designed for beginners demos, don't you? Right now, i can not yet make
>an impressive demonstration of the opposite, but i surely will, when
>SpAsm
>will be over. Actually all people thing i am jocking when i say that
>there
>is no reason for Assembler be more difficult than Basic. I will prove, i
>am
>not jocking at all, in one year. I just didn't insist about it, because,
>at
>actual developpement state, i do not want to misslead beginner and
>prefer
>they go to NASM than email me for asking "why did it hang?"...

In many ways, I think assembler is actually easier than BASIC (especially if
you include Visual Basic).  One of the great things about assembler is how
everything is so simple - (almost?) all instructions take the form:

<INSTRUCTION> [<OPERAND 1>[,<OPERAND 2>]]

This means you don't have to worry about the complicated syntax you find in
many HLLs, with all their brackets, semi-colons, etc.

Martin.

--
The higher,
The fewer.



Thu, 31 Oct 2002 03:00:00 GMT  
 A room between abstraction and reality


Quote:
> Well, you missunderstood my position and you are much allowed
> to, as i never was clear about this: i prefer writing assembler
> than make phylosophia about it, but it is sometimes nessecary.

I suspect that a good number of the people who frequent this
newsgroup, myself included, would certainly choose assembly
language if someone put a gun to our heads and said "henceforth
you can only use one language, choose now."

Quote:
> _______________________________________________________________

> When i begun SpAsm, NASM did already exist. If i'd been perfectely
> satistied with it, i would never have begin writing mine. But,
> actually, i considered it much much better than MASM. I didn't
> choose to contribute to NASM because it is written in C and that
> i would prefer stop any computer activity than write one line of
> C. But:

> 1) It is open source and doesn't come from the devil camp!
>    If you are not satisfied with it, it would be more intelligent
>    and constructive to contribute to it instead of denigrate.

NASM has three very endearing features:
(1) It is free.
(2) It is open source.
(3) The code is portable and the platform is portable (i.e, there
are versions for DOS, Win32, Linux...).

I started HLA in the early days of NASM.  Had I been able to
predict that it would have succeeded (rather than begin just
another loud proclaimation like so many OS projects appearing
in the *.asm.* newsgroups) I might have taken it seriously and
contributed to it rather than work on HLA.  OTOH, it is clear
that the NASM group wanted a "true assembler" (by your definition)
and not more abstraction.  So I probably would have been a thorn
rather than an aide to the project.

Quote:

> 2) the fact that it is written in C (i hate C overall) doesn't
>    mean that NASM is, by definition, bad. Its construction is very
>    very clean; really a very good traditionnal job.

> 3) NASM syntax for data adressing (same as SpAsm) is the only
>    consistent, solid, logical one.

Well, this is a very strong statement to make.  While I can certainly point
out some inconsistencies in MASM and, especially, TASM, I must admit
that I haven't used these other assemblers enough to make comments
about their consistent syntax.  I've given you a review of SpAsm's syntax
in a different thread, so I will not restart that thread here.

Quote:

> 4) NASM has been choosen by people who are writing ReactOS and by
>    people who build Visual Assembler. So i feel less alone in my
>    opinion. Are they all wrong and you right?

*Lots* of projects use NASM.  It is a popular product.  Especially among
those who write open source software or subscribe to the open source
philosophy (for obvious reasons), but it is also popular for reasons along
the line of what you're promoting with your "true assembler" philosophy:
it is very similar to older assemblers and takes less effort to master than
more complex products like MASM or TASM.  There is nothing "right" or
"wrong" about this;  it's just a fact.

HLA is not popular and I doubt it will become popular with those advanced
programmers who frequent this newsgroup because it involves learning a
new way to do things and most people (myself and yourself included) don't
want to spend our entire lives learning something new.  If HLA does become
popular, it will be a grassroots kind of thing, occuring because I manage to
convince some schools to use it in their assembler courses (where HLA
was intended to be used) and those students leave school knowing HLA.

Quote:

> ________________________________________________________________

> You ironize about "the number of features, *that one has to learn
> about*" in a way that makes us clearly see your position: You are
> very proud (we already knew) of your knowledge and would desagrea
> with a programming tool that would make it of lesser use. Well,
> humain is like this. But, from a "professional programmer", this
> is a very stange and inconsistent attitude.

Once again, I bring up the concept of language restrictability.
That is, is it possible to only have to learn a small portion of a language
in order to write reasonable programs or do you have to learn
an inordinate amount of "red tape" stuff in order to write simple programs?

One way to reduce the number of features one must learn is to reduce the
total number of features in the language;  this is certainly true.  The
problem
with that approach is that as people become more advanced they outgrow
the simple tools.

Now consider a language that provides lots of advanced features, none of
which are necessary in order to write simple programs.  A well designed
text or tutorial will avoid discussing these topics (at least in the early
sections)
and concentrate on those same features that are present in the simpler
product.
However, as the person becomes more advanced, they can move on to the
more advanced features without having to abandon the product.

Sadly, most people fight like mad to stick with the original tools they've
learned.
Once they've invested time in learning how to use a product, they will
refuse to
progress intellectually rather than switch to a new tool if it means
abandoning
what they've already learned.  Heck, *I'm* this way;  I doubt if many people
reading this post can claim they don't suffer just a little from this
problem.
This is the big problem I have with starting people out with DEBUG.  Once
they
learn it they want to stick with it (I know from experience on this, I once
used
DEBUG and I tried this "x86 Hypothetical Architecture" approach in Aoa, both
attempts to simplify things failed in the long run).

Incidentally, the "feature set" is not limited to the syntax of a particular
machine
instruction.  Every step of the way counts.  For example, with NASM or MASM,
there is no integrated IDE so the programmer gets to use their favorite text
editor.  That's one less thing for them to have to learn than if the program
includes
its own editor.  Now I'm not suggesting that having and IDE is bad (far from
it,
I support these things), but I'm just pointing out that there's more to
learn than
the syntax of just a few machine instructions.

Quote:

> When we write some app, don't have we all to make it as simple and
> as friendly as possible for user? Don't we have to consider that, if
> a common user of ower productions have some difficulties at learning
> it, this is not because he is stupid: this is because we are wrong?

> Sure you will agrea. Now, why sould it be the opposite for an Assembler.

If I didn't agree 100%, I would never have written HLA :-)
We just have different opinions about what makes something simpler
for the user.  Your view is to create a very simple product with a limited
feature set in order to reduce the learning curve.  This is not a bad
approach, just different than mine.  My approach is to provide a
feature-rich
product (including lots of "red tape") but leverage the students' existing
knowledge of HLLs.

If someone is learning programming completely from scratch and they
chose to learn assembly language as their first language, I would agree
that your approach is best.

Most students studying assembly language at the University level, however,
already know one or more HLLs.  I believe a better approach in their
case is to leverage their existing knowledge.  Thus far, experience seems
to be backing up this belief;  with time we will see if my approach is
better.

Quote:
> When i did implement macros in SpAsm i spent several months (yes, sir)
> about studying what could ne the simpliest solutions for syntax. You
> denigrate it because it doesn't include "conditionals" and "recursion",
> (what i may add later) but you may have missed to see that one can know
> everything of my macros syntax in twenty minutes, and easily remember
> it one month later. And i am very proud of this.

Conditional assembly is independent of macros and their syntax.
Likewise, recursion is an implementation detail and shouldn't affect
the syntax (unless you want to allow both non-recursive macro invocations
as well as recursive invocations, an interesting idea).

The basic syntax is easily learned;  that is certainly true.
But is

    [ MyMacro |
        instr1    |
        instr2    |
        ...
        instrN
    ]

really that much more easier to learn and use than is

    MyMacro  macro
                      instr1
                      instr2
                      ...
                      instrN
                      endm

I'm not saying MASM's syntax is better, I'm just questioning
how much easier your syntax is.  As I point out in the thread
on SpAsm, I *do* question the similarity in syntax between
macros, equates, and data declarations.

Quote:

> There are not only professional programmers on the world and futur
> doesn't
> belong to them. A lot of good products are done by sunday-programmers
> like
> me. We need simple tools. Assembly langage by itself is VERY simple and
> we
> do not need fancyfull features that turn it a "professional toooool".
> Futur is to "free programmers", just because future will be free or not.

> (i am talking about "free of money" not of freedom, what is another
> story.)

I don't particularly buy into the "sofware should be free" attitude.  I have
spent (personally) tens of thousands of dollars on software and I have
sold my own software as well.  If you want to give away your software,
that's great;  I've certainly given away a lot of mine.  I do, however,
reject
the notion that programmers are bad if they decide to sell their software.
People's creations are their own to do with as they please.  Even applying
peer pressure (to give stuff away) to those who would like to sell their
work
is inethical IMHO.

Ultimately, I believe the future is *not* free because sooner or later
people
are going to want just a little more for their efforts than ego
gratification.

Quote:
> You associate

...

read more »



Fri, 01 Nov 2002 03:00:00 GMT  
 A room between abstraction and reality



Quote:



> > Well, you missunderstood my position and you are much allowed
> > to, as i never was clear about this: i prefer writing assembler
> > than make phylosophia about it, but it is sometimes nessecary.

> I suspect that a good number of the people who frequent this
> newsgroup, myself included, would certainly choose assembly
> language if someone put a gun to our heads and said "henceforth
> you can only use one language, choose now."

I'd choose Norwegian, x86 assembly would be my 2nd choice. Would you believe
me if I had said HLA?

T



Fri, 01 Nov 2002 03:00:00 GMT  
 A room between abstraction and reality

Well  I'm not really programming in assembly, just looking into it for
perspective and overview.  My current project would not allow branching off
into a new area.

But, does anyone have a freeware 32-bit linker for a pieced together
downloaded Masm? That would seem to be a quick step for someone.

(Then, just compelled to mention that Intel has IA-64 information up on
their web site. They have an assembly syntax convention that would allow
creation of assemblers for IA-64 and they have math libraries in assembly
for use.)

Quote:

> > > Well, you missunderstood my position and you are much allowed
> > > to, as i never was clear about this: i prefer writing assembler
> > > than make phylosophia about it, but it is sometimes nessecary.

> > I suspect that a good number of the people who frequent this
> > newsgroup, myself included, would certainly choose assembly
> > language if someone put a gun to our heads and said "henceforth
> > you can only use one language, choose now."

> I'd choose Norwegian, x86 assembly would be my 2nd choice. Would you
believe
> me if I had said HLA?

> T



Fri, 01 Nov 2002 03:00:00 GMT  
 A room between abstraction and reality

Quote:
>>Good for them. But what if you want to make some money ?
>>Most likely under windows, and you'd have to be just a little bit crazy or
>>over-zealous to do that without linking to the .libs. (er... unless they
>>are
>>using Walk32 perhaps)
>Well, yeah, there might be something in that. I haven't made too much money
>out of my shareware program, I admit, but I don't think that's because I
>failed to link to the libs; it's because if you write programmer's tools,
>you're competing with an awful lot of free stuff. I was working on it for
>five years before I even hooked up to the internet, never mind link to the
>libs. So doing everything by hand is a habit I can't shake off.

__________________________________________________________________________

I am not sure i understand the first upper intervention but:

- Working with LIBs is nothing but a lazy fashion. We can do easily
  without.

- Programmers who use LIBs for win32 api calls are in the rets of MASM!
  SpAsm usage for it is:

  call 'ThisDLL.ThatFunction'

  and that's all >>> no lib needed, no declaration of any kind. and there
  no magical at it. Calling APIs is really simple if the assembler do its
  job.

- LIBs ensure you on one point: You can be sure that, in many cases, you
  are going to take a truck to carry a strawberry.

- LIBs are black boxes. If you like black boxes, why not HLL?...

________________________________________________________________________

Do you know how many marvelous graphical editors have been written from the
start of early PC? Sometimes several per month!!!

Do you know how many graphical editors will be now written in Linux world?
answer = 0!!! because nobody will be stupid enough to write something out
of the good open source one they have. Instead, if someone wish to do
something, he will contribute for some add.

This is a great side effect of open source. We no longer write for NOP.

_______________________________________________________________________

Money or not money:

Did programmers even earn the money or musicians earn the money? No:
Bill earns, the great music companies earn. The culture in future world
will be free of money. (software is a part of culture, just like book
editing). All this doesn't mean that artistes, creators, programmers will
have to live without money:

- we can earn more money with a free products than with a commercial ones.
  (this would be a too long discussion...)

- there exist some interresting possibility to make ower softwares supported
  by capitalistic companies (just like they support sport for their own
  image). Very few programmers tryied this (i have seen only one exemple) but
  we should, one day, construct some commercial association (with a paid
  publicist at the head) to organise this for programmers who need money.

On the other side:

- there are poor people around the world. We MUST give them free access
  to culture.

- Many programmers (like me) write just for fun and do not want any money,
  glory or anything. At the end, irritating "shareware" will desapear
  because free open source will be the best quality software available.

Bye. betov



Sat, 02 Nov 2002 03:00:00 GMT  
 A room between abstraction and reality


Quote:

> - Working with LIBs is nothing but a lazy fashion. We can do easily
>   without.

Well, there is no question that using libraries saves effort.  If you want
to call that
lazy, then I'll have to agree with you.  We can do without libraries, but I
question
the injection of the word "easy" here.  Perhaps we are talking about
different
things when we use the term "LIB" (I suspect you are being far more
restrictive
in your definition than I am).

Quote:

> - Programmers who use LIBs for win32 api calls are in the rets of MASM!
>   SpAsm usage for it is:

>   call 'ThisDLL.ThatFunction'

>   and that's all >>> no lib needed, no declaration of any kind. and there
>   no magical at it. Calling APIs is really simple if the assembler do its
>   job.

While it is slick that SpAsm incorporates syntax that automatically links
in the definitions for the win32 libraries, what happens if the library file
is just a third party supplied library?  I don't know enough about the
PE file format or how SpAsm operates to venture a guess, maybe you
could explain this.  For example, suppose I have supplied a standard
suite of string functions in a file "string.lib" or "string.obj".  How do I
call these routines in SpAsm?

Quote:

> - LIBs ensure you on one point: You can be sure that, in many cases, you
>   are going to take a truck to carry a strawberry.

Yes, the price of saving some effort during software development by using
"standardized" libraries is that you wind up linking in a generalized
routine
that often does far more than you really need;  hence the code will be
larger
and probably slower as well.  Anyone who has written a Delphi "Hello World"
program and wound up linking in a large percentage of the VCL can attest
to that.

However, the marvelous thing about assembly language is not that it forces
you to give up libraries, but that it gives you the option to use them or
not
use them.  If you need tiny code or very fast code, you're free to write the
whole thing yourself.  If you need to get it written as quickly as possible
and
there are reasons you need (or want) to work in assembly language, calling
some standardized library routines is definitely going to help move things
along.

Quote:

> - LIBs are black boxes. If you like black boxes, why not HLL?...

In many projects the level of detail varies in different parts of the
program.
Some code (like initialization code, user interface code, etc.) doesn't have
to
be blazing fast, compact, or need the intricate control provided by assembly
language.  Other parts have to be finely hand tuned and take careful
advantage
of the underlying architecture.

Sometimes, you can mix HLLs and assembly, sometimes it's most convenient
to stick in pure assembly.  However, forcing the assembly programmer
to "reinvent everything from scratch" on every project severely limits the
size
of the projects that are humanly possible in assembly language.  This is why
most people like black boxes even if they don't want to use a HLL.  It lets
them abstract unnecessary details away when they aren't important.

Another reason black boxes are important is for performance.  Consider
someone who has written a finely-tuned string library.  Your average
programmer isn't going to worry about all the details behind a powerful
STRLEN (string length) routine everytime they write a program that computes
a string length.  Hence, their solution is probably not going to be optimal.
OTOH, if that same programmer links in a well-written STRLEN routine,
they will immediately reap the benefits of someone else's effort.  They only
want to compute the length of a string, why should they have to know the
intricate details of how this works?  Instead, they can concentrate on their
on local problem, of which STRLEN is probably only a minor issue.

Quote:

> ________________________________________________________________________

> Do you know how many marvelous graphical editors have been written from
the
> start of early PC? Sometimes several per month!!!

> Do you know how many graphical editors will be now written in Linux world?
> answer = 0!!! because nobody will be stupid enough to write something out
> of the good open source one they have. Instead, if someone wish to do
> something, he will contribute for some add.

> This is a great side effect of open source. We no longer write for NOP.

Do you know how many operating system projects start up each month :-)

Quote:

> _______________________________________________________________________

> Money or not money:

> Did programmers even earn the money or musicians earn the money? No:
> Bill earns, the great music companies earn. The culture in future world
> will be free of money. (software is a part of culture, just like book
> editing). All this doesn't mean that artistes, creators, programmers will
> have to live without money:

Hmmm....
I thought Metallica was making some money.  Why else did they
sue Napster? :-)

Quote:

> - we can earn more money with a free products than with a commercial ones.
>   (this would be a too long discussion...)

Well, I haven't made too much money with commercial or free products :-)
So I'm not in a real good position to debate this issue :-(.
When you figure out how to make lots of money on free software, let me
know so I can do it too!

Quote:

> - there exist some interresting possibility to make ower softwares
supported
>   by capitalistic companies (just like they support sport for their own
>   image). Very few programmers tryied this (i have seen only one exemple)
but
>   we should, one day, construct some commercial association (with a paid
>   publicist at the head) to organise this for programmers who need money.

What about programmers who need *lots* of money.  Hey, I want to be rich.
Just because you're willing to work cheap doesn't mean that everyone else
is so inclined.  Quite frankly, someone is going to make money off this
stuff.
Your scheme will make the people who run the association a lot of money
at the expense of the programmers (Red Hat, anyone?).  However, I am
so out of tune with the Free Software Movement, and this discussion is
*way* off topic for this newsgroup, so I'll stop right here.

Quote:

> On the other side:

> - there are poor people around the world. We MUST give them free access
>   to culture.

Why MUST we do anything?
I hate to come off sounding politically incorrect, but you're suggesting
that I be
enslaved for the benefit of the poor people around the world.  Why is this
any
better than the situation that exists today?

Quote:

> - Many programmers (like me) write just for fun and do not want any money,
>   glory or anything. At the end, irritating "shareware" will desapear
>   because free open source will be the best quality software available.

I write software for fun and I write software for money.
I can guarantee this, if the money stops coming in I will have to start
washing dishes, hauling garbage, or something else and the free/fun
stuff I do will have to be curtailed.

While a point could probably be made that generic software (e.g.,
operating systems, word processors, databases, etc.) might wind up
being free some day, what about all the "real-world" applications out there?
Whose going to write (for free, open source) the foot measurement software
I'm currently working on?  Who's going to develop (for free) the custom
keyboard
software drivers my company needs?  The open source movement doesn't
address this type of software.
Randy Hyde



Sat, 02 Nov 2002 03:00:00 GMT  
 A room between abstraction and reality
Quote:
> I write in Assembler from Amstrad 1512 times. I have NEVER used any
de{*filter*}.
> This
> is why i do not talk of de{*filter*}s. The problem is "how to find what is
wrong at
> run time.
> I do not know actually how i will implement this in SpAsm, but i am
convinced i
> will be
> able to do it without external de{*filter*}; and so forth without any need of

LIBs.

What kind of Amstrad ?
I spent much time with my 464 and 6128+ using Z-80;  happy days.
No, I didn't use a de{*filter*}, but I would have if I had one.

Quote:
> 1) i have enough money.

(if that is possible!)  lucky you !

Quote:
> 2) i don't care if someone else makes money or not.

> 3) Open source is, any case, the future because, simply, nobody will pay
for
>     something he can get for free. On the other hand, evolution of open
source
>     will propose much much better apps than commercial ones because open
>     source is "long life" and doesn't stop with the first author...
Another
> thing is
>     that software is a part of culture and that culture in future world
will no
> more
>     belong to a minority but will be available for everyone. If not, i
would
> simply
>     be the end of any culture.

>     This is not great sentiment in "correct political attitude". I do not
feel
> "correct"
>     at many points of view. The world story is always destroying itself
and
> reconstructing
>     itself. Open source, and, so forth, "working for free" is the only way
to
> destroy
>     great company hold up on culture. I do not see any other choice. When
Win 3
>     was released and Bill decided that i was no longer allowed to write in
> assembler,
>     i just have had to stop. Now, he is going to stop, and that's good.

> betov.

How long has open source existed ?

Has it taken over yet ?

Juz



Thu, 07 Nov 2002 03:00:00 GMT  
 A room between abstraction and reality

Quote:

>What kind of Amstrad ?
>I spent much time with my 464 and 6128+ using Z-80;  happy days.
>No, I didn't use a de{*filter*}, but I would have if I had one.

Ah yes, those were the days... I'm surprised you didn't have a de{*filter*}.
Perhaps your programming skills were good enough for you not to need to buy
one?  IIRC, there was one on the disk that came with the reprint of the
Firmware Guide.

Martin.



Mon, 11 Nov 2002 03:00:00 GMT  
 
 [ 10 post ] 

 Relevant Pages 

1. virtual REALITY - more REALITY

2. Subroutine, lambda abstraction, tacit form

3. ST stack abstraction: objects/boxing etc.

4. Data Abstraction

5. abstraction and encapsulation (Re: Will Java kill C++?)

6. Leaky Abstractions: what we knew

7. Re-writing abstractions, or Lambda: the ultimate pattern macro

8. Is abstraction needed for application?

9. Full Abstraction for PCF

10. Lambda abstractions in C++ vs. Scheme

11. Abstraction in SML

12. Abstraction facilities and source-level optimizations

 

 
Powered by phpBB® Forum Software