Re: C# programmer wants to learn assembly?? plz help

<//\\\\o//\\\\annabee <"WINOS IS ***.">> wrote...
På Fri, 29 Dec 2006 21:35:31 +0100, skrev David Jones <ncic@xxxxxxxxxx>:

This argument is a fallacy. What happens if you already know the HLL
libraries inside and out?

If you do this, it is because you have created them. Or studied them like
I have, by rewriting them. By replacing them. Do you know the HLL
libraries in and out?

You completely missed my point. What you stated, which you have since
removed, is a logical fallacy: needing to learn something initially does
not mean it needs to be re-learned every time you use it, thus it has
practically zero amortized effect on the speed of development.


What happens if you never learned assembly
language before?

You become ignorant.

You *become* ignorant? Ignorance, like virginity, isn't something you
can gain -- you can only lose it.

So, yes, you are ignorant in the sense that you don't know something.
That is, in fact, the very definition of ignorance. You haven't really
said anything with that statement at all.


To talk about speed of development, you have to compare development
times for experts in that language, because EVERY language has some
initial cost for learning, even assembly.

The cost of learning asm, is to use from 20 to 40 diffrent instructions.
Those are all you need for most any applications. Yes you need to learn to
piece them together, but this is the same for any language. And it is much
easier in asm.

.... "but this is the same for any language". QED. You have to learn
the basic syntax in any language. How many keywords are there in C?
(about 30-40, depending on the implementation - C++ adds about 15 more)

Piecing them together might be easier for *YOU*, but not for most
people. While in school, I took a class that required using MIPS
assembly, and I was able to breeze through it, but the vast majority of
the students really struggled with it due to the extra attention to
detail that assembly requires. Assembly is far too tedious for most
people.


There are some areas where HLLs have a real significant advantage on asm,
and that is in doing math, because this can be tedious in asm, espesially
in the beginning. However, using the FPU even this is no big deal after
some initial practice. The FPU memonics looks strange, but once the rules
of their usage is learned, they start making imo lots of sense. I am now
talking from a beginner perspective, because i am one.

Actually, I've found the FPU pretty easy to use.


Wolfgang used to
say that he never used those, as he could do much faster without them. To
give you some indication as to who Wolfgang is, he is the man that gave me
his _slow_ version of an IntegerTostring function, that ran 16 times
faster then the one I made. It was also just a few lines, whereas mine was
two full pages of delerium.

IntegerToString? Several pages? Were you trying to optimize runtime
execution speed? Divide by 10, take the remainder and add '0'...
lather, rinse, repeat. For signed numbers, check the sign and NEG it if
needed before doing the division. What's so complicated?


Mine ran 4 times faster then the Delphi one. And mine was written by a
complete nuub. But wolfgang is kind of spesial case programmer, as he
learned from coding in HEX all by himself. HEX was he first "language".

You pretty much proved my point -- assembly is good when you need to
optimize for speed, but as for development speed.... how can writing a
2-3 page function be faster to develop than simply calling intToStr?


90% of my intial work in asm, run faster then my Delphi code. Without any
optimization done. It is all first time code. And it took much less time
to create.

.... perhaps because you really didn't know Delphi. And, perhaps you
were using Delphi to do something for which it isn't designed. For
example, trying to use Java to do COM programming (Windows) / hardware
access is foolish because it wasn't designed to do that, even though
it's technically possible.

Again, use the right tool for the job. Sometimes that means assembly.
Sometimes it doesn't.


Try to use a richedit object as a starting point for world class
texteditor. More complicated then to build it from scratch.
Scratchwriting
a texteditor in asm takes about 3 days. Expanding it into a worldclass
reusable word processor, takes another two months. At most. Moreover,
even
your first implementation will be WAY faster then any other editor in
existence. Without ANY kind of codeoptimization.

Because *all* text editors written in an HLL *must* be based on the
richedit control... Moreover, it takes even longer if you base it on a
button control! Those stupid slow HLLs! In assembly, you could *never*
base a text editor on the richedit control -- it would always be from
scratch.

I am not sure what you mean. If you want to scratchwrite, using a HLL is
particularly counterproductive.

What I mean is that you can do stupid things in either language, and you
can do smart things in either language. Using an HLL is not
counterproductive for writing things from scratch just because you claim
it is. Someone who is capable of writing from scratch in assembly can
do the same thing in an HLL.


Or maybe bad programmers can produce bad code in any language.

He will do better in assembly. In most cases, he will outperform a HLL
coder on the first attempt.

.... on the first attempt? Even assuming that assembly is easier to
learn than an HLL, that doesn't mean that someone who has learned both
is faster than assembly, nor that the code quality is better. In fact,
you would expect the code quality to be about the same, since the same
person wrote it.


Try to use a Delphi Grid object as s startingpoint for mapping a 5000 by
5000 interactive checkgrid. Impossible. Its way to slow. You must
rewrite
from scratch.

You mean using the wrong tool for the job makes things worse? That's
amazing.

Its a grid. It does not have any other functionality, but to be a starting
point for "gridded" classes. And it is useless. At the time, I really
needed it to work for that, and it promises to work for it. It took
several seconds to update the screen each time it was painted. In other
words : useless.

Yeah, so it was the wrong tool for the job. Does one bad control indict
all HLLs as being useless?


Try to use a Delphi UDP/TCP object for writing a network application.
What
you could have asked Yeoohs to do in two days, will take you weeks, and
much headaches if you try to use that stupid TCP/UDP class. Because,
once
you app requires some functionality for which that objects was not
intended, you must procceed past that object or class, into the bare
winsock apis. Or you could wait around for the next release of Delphi,
and
hope that they have seen the problems, and offered some solution for
you.

So, if you write a network application in assembly, you don't use any
pre-existing libraries? (Hint: the calls into the OS are similar to the
calls into a library. Or are you accessing the network card's hardware
directly?)

You missing the point. This class takes on the beautiful lie that it
"hides" the "nitty gritty" stuff from you. "It makes your coding easy". It
fails patetically for all cases except the ten liner superfacial
demonstration. Good work, it fools the project managers, and the bosses.

So? If you code in an HLL, are you *forced* to use it? Remember,
you're talking about the difference between a programmer using one
LANGUAGE versus another.

Besides, let's say Delphi is a really bad language with a poor runtime
and equally poor libraries. How does that mean that Lisp is also? And
C? And Ada? And all other HLLs?


Rewriting the OS functionalty _is_ possible, by creating a devicedriver,
but I am an application programmer, not an OS coder. I am also relativly
new to assembly codeing. Writing drivers is a huge enough area for having
a spescial interrest in it. (its my guess anyway). If I did that, I could
probably not have time left for writing the things I want to write.

It would take too long to write everything that gets executed? If only
people could take code that others had written and use it somehow....

But we can't use libraries. Libraries == HLLs == bad.


Writing "from scratch" as you put it can be done in any language, not
just assembly.

It will be much easier in asm. I have proven it to myself. If you tell me
by which device I could prove it to others, please let me know.

Again, it may be easier for *YOU*, but it's not easier to the vast
majority of people.

Here's a counter-example: let's say you need to verify that an email
address in a string has the format something@xxxxxxxxxxx? (string +
'@' + string + '.' + string, with only one @ in the string) See how
long it takes you to write it in assembly.

Then compare to ECMAScript: /^[^\s\@]+\@[^\s\@]+\.[^\s\@]+$/.test(str)

Guess which one would take longer for me to write.... (hint: if I wrote
the code above while I was typing my reply, the ECMAScript version
didn't take too long -- show me the equivalent with RosAsm, please)

I'm not saying assembly doesn't have its benefits: it's just not always
the best tool for solving a particular problem.


Certain implementations can have faster runtime
performance in assembly, but that doesn't preclude a somewhat slower-at-
runtime implementation in an HLL from being developed faster, calling
the OS functions directly just as assembly does. (Many HLLs allow you
to do this - not sure about Delphi, though.)

I am not talking only about execution times. I am mostly talking about the
speed of coding, and the speed of bugsfixes, and the _accuracy_ of those.
Allthough there are a few exceptions, in general, a beginners
implementation of a program in asm will outperform any attempt with any
HLL on earth.

Why do you keep talking about beginners? Productivity is only a real
factor for people who already know their language. Beginners will
*ALWAYS* be slow, no matter what the language. Or do you suggest that
an assembly beginner can outperform an HLL expert?


So, why would you want to scratchwrite an editor? Because you want the
ease of use that comes from understanding how it works. Because you want
to use it, in a way that specifically suit your application. Because of
one of a million reasons that the original authors could not imagine
that
you wanted to use it for. And because once done, _YOU_ are now in charge
of it.

So, basically, you've argued that writing things from scratch is better
than force-fitting something not intended for the job into doing what
you want.

Yes.

You're really just proving Herbert's argument for him: use
the correct tool instead of force-fitting one tool for all uses.

I understand what you are saying. The problem is that you dont understand
what you are saying. I _am_ using the correct tool allready.

If you understand what I'm saying, then surely you realize that "using
the correct tool instead of force-fitting one tool for all uses" implies
using one tool for all uses means you're not always using the correct
tool.

David
.

Quantcast