Re: Catagories of Assembly Languages

From: Randall Hyde (randyhyde_at_earthlink.net)
Date: 10/03/04 

Date: Sun, 03 Oct 2004 06:14:21 GMT

"Herbert Kleebauer" <klee@unibwm.de> wrote in message
news:415F4885.E024C70F@unibwm.de...
>
>
> > Yes, and gun manufacturers are responsible for all firearm-related
> > homicides, cigarette manufacturers are responsible for all lung
> > cancer cases, spirit distillers are responsible for all drunk-driving
> > accidents, etc.. We've heard all these arguments before.
>
> Maybe you would change your mind if one of your children is
> killed through one of this examples.

No. I place the responsibility with the person who pulled the trigger,
drank and drove, or chose to smoke.

>
> Do you really not see the difference?

Yes, as a matter of fact, I do.
You think you know the only true way and you want to
force your decisions onto other people.

> You can tell the people
> what they have to do to maximize your profit, or you can tell
> them what to do because you care about them.

Telling them *how* they should behave, and preventing them
from behaving in a way that you don't like are two different
things. Perhaps *you* do not see the difference?

> Would you allow
> you 12 year old son to drink and smoke as much as he like
> because it is his own decision to do what ever he likes?

Most of us around here are mature enough to make our own
decisions. We don't need *you* playing "papa" for us.

> If
> you only care about your own success, you can create something
> like HLA and sell it as a tool for teaching assembly programming
> but if you would care about these people and try to really teach
> them assembly programming you would never use HLA.

Quite the contrary. HLA has proven *extremely* successful
as an assembly language teaching tool. It has made students
far more productive than they were when using tools like MASM
to write DOS applications in assembly.

But guess what? I'm not telling people they *have* to learn assembly
that way. I only offer them a different choice if learning traditional
assembly in a traditional fashion isn't quite as efficient as they'd like.
You, on the other hand, simply want to limit their options.

>
>
> > > And to create his very own language which nobody else understands
> > > is a bad decision.
> >
> > Yes. We should all be using FORTRAN today. No need to design
> > new languages.
>
> The design of a new language should be done by a group of
> experts but not every hobby programmer should create his
> private language.

Yes. Only the "elite" are qualified to do this.
Again, a very dictatorial attitude.
"Liberty" is the ability for *anyone* to use their creativity
to create whatever they want; whether or not you agree with
what they are doing.

>
>
> > If you create your own languages and this is a real problem for the
> > rest of the world,
>
> It is not a problem for the rest of the world, it is a problem
> for yourself. It is also not a problem for the rest of the
> world if you drink or smoke. So, if you don't care about other
> this is no problem at all. But if you care about other, then
> you should try to make it difficult for other to start drinking
> and smoking.

Difficult, perhaps. Impossible, no.
It *is* difficult for a beginner to create their own language using
macros in an assembly language development system like LuxAsm,
MASM, HLA, whatever. People have to learn quite a bit about
macros, parsing, code generation, etc., in order to pull this off.
A "beginner" is not going to be able to do this. By the time that
beginner gains enough experience to successfully achieve this,
why would you want to limit their capabilities?

>
>
> > Yep, some people could create some horrid "mini-languages" using
> > something like LuxAsm. Code that no one will want to read or
> > maintain.
>
> Yes, some people could get problems if you distribute drugs
> for free,
>
> > OTOH, they could also create the "next big thing" in
>
> but they could also be so inspired by the drugs to invent
> some great things. But I still think it is a bad thing
> to distribute drugs.

And it's a bad thing to let people drive cars (they can get in
accidents), it's a bad thing to let people eat fast food (they'll
get fat), and so on and so forth.

Face it, you're a control freak. You want to control everyone
else's life so the world fits into your little picture of how things
should be. In a sense, we're all like this. But some of us are
wise enough to realize that, in the long run, it's much better
to let people do as they choose, particularly when their choices
don't affect anyone else. Empowering assembly programmers
with decent tools that let them create applications the way
*they* want to, rather than the way some "programming on
the fringe" feels they ought to be written, doesn't place much
of a burden on society. :-)

>
>
> > > The liberty to choose between many options allows you to make
> > > many wrong decisions. It is maybe much better to restrict your
> > > liberty and don't allow you to make some of the worst decisions,
> > > at least if you are not a professional and can't foresee the
> > > consequences.
> >
> > Spoken like a true dictator.
>
> No, spoken like somebody who cares about other.

Cares? In what way?
In a way that you'd prevent them from doing their job the
way they want to do it? What arrogance! You actually think
you know best for everyone? Care all you want. Just keep
your cares to yourself. The rest of us are quite happen getting
good tools (like LuxAsm) that help us solve *our* problems.

>
>
> > Look, you can easily achieve this without burdening the tool.
> > The tool should have the flexibility to allow the programmer to
> > do whatever they want. For the beginners, for whom that freedom
> > could create problems, you limit their choices via the available
> > pedagogy.
>
> But as I said above, no professional programmer would use
> that tool. Now, if you limit the features of the tool for
> all people who ever use the tool, then, which sense does
> it make to implement this features?

No, you didn't say "no professional programmer." You said
"a professional programmer."
Once you say "no..." the statement is patently false.
Professional programmers use tools like these all time.
Just because, in your limited experience, you don't see this
doesn't mean that professional programmers aren't using these
tools. Indeed, the *vast* majority of professional assembly
programmers use MASM. And it has many of the capabilities
that you claim no professional programmer would use. And
those professional programmers are *using* those facilities.

>
>
> > And don't define your own functions/procedures/subroutines while your
> > at it. And don't define your own data types, either.
>
> There is a big difference between the use of a language (to define
> subroutines and data structures) and the definition of a new
> language.

We are talking about using macros to extend the language, remember?
Try looking up "Embedded Domain Specific Languages" sometime.
That's exactly what you can create by "using a language" that has
appropriate features (e.g., HLA and, presumably, LuxAsm).

>
> Let's use the keyboard as an example. There are a few different
> layouts, QWERY in US or QWERTZ in Germany, but most letters
> are at the same position so it is no big problem to use the
> PC of somebody else. Now suppose, that keyboards wouldn't
> have a predefined layout but every user can specify his preferred
> key <-> letter assignment. In this case you will have big
> trouble if you have to use the PC of somebody else.

There's a problem with your analogy. People can't simply
"read a keyboard layout document" and use the new keyboard.
They can, however, read a header file with macro definitions
and easily determine how those macros operate in the code
(within weeks or months of training to become proficient).
At least, if they are half-way competent, they can.

>
> If a program is written in a widely known language, then it
> is much easier to understand the program than if the program
> is written in a self defined language.

Again, defining control structures to extend a "language"
is really no different than extending that language via
functions, subroutines, procedures, macros, and user-defined
data types.

The fact that I can sit down and write my own versions of
all the C standard library routines, with completely different
semantics, surely demonstrates that I can do just as much
evil with function definitions as I could with control structure
definitions. Conversely, by applying decent software engineering
techniques, I can make a program more readable by creating
specialized control structures (in a language that allows this)
just as I can make a program more readable and maintainable
using custom written functions. Yep. It takes experience to
know when to do this, how to do it properly, etc., etc., but
that's no different than writing functions or creating user-defined
data types.

>
>
> > Language designers should concentrate on providing facilities that
> > are useful to *good* programmers rather than worrying about
> > how *poor* programmers might abuse those features.
>
> Language DESIGNERS should choose a proper syntax for the
> language and not allow the USER to completely redesign
> the language.

They will never be able to completely redesign the language :-)
But they should be able to extend it. After all, that was the
original purpose for subroutines, to extend the capabilities of
programming languages. That's why users were given the
ability to create user-defined data types -- to extend the language.
You don't see anyone complaining about how USERS shouldn't
be able to create their own data types, do you?

> This means, the HL constructs have to be
> built into the compiler and not to be loaded as macro
> definitions which easily can be changed by the user.
> (But don't forget, it isn't an assembler any more.)

First of all, who says that the language constructs have to
be high-level? Maybe I want to create a "jump on overflow
or equal" statement in my assembly language (because a
particular application I'm writing uses that particular construct
quite a bit). Maybe I just want to create a set of IFE, IFNE,
IFLT, IFGT, IFLE, IFGE, etc., statements that do a JNcc
around a block of statements. This is all low-level stuff.

Second, why should the user be limited to the macros that
the language designer builds into the language? Experts or
otherwise, language designers don't get everything right (if they
did, we'd all be using the "one perfect language" today).
Users should have the ability to extend their languages
as they see fit for their applications. This concept is nothing
new, btw, languages like Lisp have been around a long time
and have supported this capability. Modern languages like
Haskell and Dylan provide this capability today (in HLLs
and VHLLs). It's only reasonable that an assembler,
like LuxAsm, could provide this capability, too.
Cheers,
Randy Hyde

Relevant Pages

  • Re: Arrrrrrrrrrrrggggg!!
    ... >> appropriated Language for the task. ... > implementing an assembler (nearly anybody in the software ... >> valid alternative to the HLLs. ... > Here you need an experienced assembly programmer (who is ...
    (alt.lang.asm)
  • Re: Python or PHP?
    ... > every language here and there more ways to do something. ... The best the programmer can do, as you imply, is to ... parse out into proper perl expressions. ... > lists, dictionaries, etc. etc. ...
    (comp.lang.python)
  • Re: Library Design, the script kiddies nightmare.
    ... If this will do the job, fine but you would not use it in an assembler ... design which is a different category to cross language comparison. ... It also entails cross language support with the overhead of the larger ... programmer but a good programmer to a bad programmer: ...
    (alt.lang.asm)
  • Re: Python or PHP?
    ... >> every language here and there more ways to do something. ... The best the programmer can do, as you imply, is to ... I am curious of a list of extraneous methods in Perl (more about the ... I just had a glance on Python, ...
    (comp.lang.python)
  • Re: What is different with Python ?
    ... You studied it after python, ... In assembler details are simply more explicit. ... When I wrote in an high level language ... In assembler, the programmer has ...
    (comp.lang.python)