Re: Survey

randyhyde@xxxxxxxxxxxxx écrivait news:1117633095.359750.278570
@g49g2000cwa.googlegroups.com:

>
>
> Betov wrote:
>>
>> > or do you think it has an advantage over HLLs?
>>
>> Assembly is faster to write, easier to maintain,
>> and way more readable than any HLL.
>
> If it's so much easier to maintain, how come you still haven't fixed
> that bug in the symbol table management code that causes your assembler
> to crash? That one's been outstanding for a year or so, now.

Because i can't fix bugs that do not exist.

:)

>> There is nothing that an HLL could do, that an
>> Assembler could not do, but there are many things
>> that an HLL cannot do, that an Assembler can do.
>> HLLs mask and limit Assembly. Nothing else.
>
> There are a couple of things HLLs can do that an assembler cannot -
> implement the same algorithm with far fewer lines of code in many
> cases; create portable code that recompiles across different
> architectures;

Mythology.


> produce readable code that a large percentage of the
> programming population can read. That's why people use HLLs, if you
> hadn't figured that out.

C, for example, is utterly unreadable.

For the higher level Languages, what i call readability
is a concept that do not even exist. A Source is readable
when you know what it is doing, and i do not expect that
any Basic Programmer, for exampe, could have any idea of
what the Basic is doing with his Source. I recently took
a look at several Basic Sources, and quite frankely, i was
terrified by the incredible complexity of this Language,
and overall, by the incredible confusions introduced directly
be the language itself. For example, i saw one, declaring a
simple Dialog directly in the Source, and mixing the Dialog
Data and the Dialog Code in a way that really... stucked me.
How do want a user to know what he is doing, with such a
disasterful state of the Language?


>> Assembly is a Language without limitation, where
>> the programmer can define the level of HLL he
>> likes to use, whereas the HLLs can only, at best,
>> offer a more or less decent direct Inline Asm.
>
> Almost all HLLs are "Turing Comlete." Therefore, in terms of power,
> they are all equivalent. It might be *easier* to do something in one
> language versus another, but in terms of power, most languages (LLL or
> HLL) are equivalent in terms of power.

You have not defined the word "power".


> The real question is "how easy is it to achieve something?" Certainly,
> there are many operations that are much more easily achieved in
> assembly language than in a HLL. But the reverse is more often true.
> Often, it takes far *less* work to achieve a desired result in a HLL
> than in assembly.

Impossible. The only cases when some HLL can offer something
that _looks_ faster to do, to a user, are cases of Wizards,
1) this has zero relationship with the Language bu 100% with
the RAD/IDE, and 2) There is no reason why Asm could not have
the same Wizards.


>> Assembly is the elected language for Strategy
>> Optimization, because the Programmers _knows_,
>> by definition what he is doing.
>
> Choosing a better algorithm ("strategy optimization") is independent of
> the language. *Implementing* that algorithm can be language-dependent,
> but choosing better algorithms generally is not. Every "optimization"
> you've bragged about in this newsgroup (such as reading in the Win32
> equates list into your assembler system so that you don't have to
> process those symbols at assembly time) can be done in *any* language,
> not just assembly. In general, assembly does not make choosing a better
> algorithm any easier or more difficult.

You are not qualified to discuss about this. Learn first
Assembly. Then, maybe, you will have acces to Strategy
Optimization.

:)

By the way, i would not use the word "algorithm" when
talking of Strategy Optimization, as this one is, first,
the art of _not_ doing.


Betov.

< http://rosasm.org >





.

Relevant Pages

  • Re: Evolution
    ... > inline assembler and larger parts by linking to an assembler ... in the HLL. ... language, particularly in smaller projects. ... > or two instructions if you ...
    (alt.lang.asm)
  • Re: Thinking assembly?
    ... This is one part of thinking in assembler to me. ... > algorithm and implement it in the higher-level language. ... you can't merely go back the HLL code to obtain ...
    (alt.lang.asm)
  • Re: The HLL Temptations
    ... What relationship between these facts and the Language. ... but that's better than waiting for you to write it in assembler. ... Assembly being there before the HLL, the job of proving anything should be on the HLL side. ... Then they're translated to assembler, or whatever, but no-one defines programming problems and solutions in assembler; that limits the solution to a single architecture. ...
    (alt.lang.asm)
  • Re: The HLL Temptations
    ... For functional programming; Lisp. ... > contemplate doing in assembler; ... you will learn one Language for each problem. ... full HLL instead of doing it as an Assembly-Assembler ...
    (alt.lang.asm)
  • Re: Accessing Command-line text
    ... a nice example that speed is made by the algorithm and not by the hardware. ... my routine that find factorial ) should be faster because use 1 ... my assembler doesn't support floating point instructions, ... "geeks language is better than all". ...
    (alt.lang.asm)