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

<//\\\\o//\\\\annabee <"WINOS IS ***.">> wrote...
På Sat, 30 Dec 2006 03:56:29 +0100, skrev David Jones <ncic@xxxxxxxxxx>:

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

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)

Hillerious. C in itself, is NADA. its the standard IO library and about
1000s of other libraries that makes C what it is. Defining c without a
library is just that: Hillerious.

I find it rather interesting that, on the one hand, you condemn HLLs for
needing to learn the libraries and claim ASM is easy because it has only
a few building blocks, then, when it comes time to write code in ASM,
you rely on pre-written libraries.

What's really hillarious (note the spelling) is that you think you have
to use all the 1000s of libraries to write C programs. You can write a
great deal using just stdio, and a Windows app really only /needs/ the
runtime.


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.

All programming is tedious. Theres is no way to escape that. Not for c
programmers, nor for asm programmers. If you say "cant use such and such
library in asm" then I could agree to some extent. Only in fact you can
use such and such library, also in asm. You can use high amounts of C
libraries in asm, or you can use small amounts.

See note above. Your condemnation of HLLs in your earlier post boiled
down to a condemnation of its libraries, then you turn around and
suggest you can use them yourself.


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?

Giveme a break. It was my first intotstring. Btw, how come most c
programmers are so clever, but most all c programs still look so pathetic?

Hey, it was *your* example. You're the one who claimed that asm
beginners can outperform HLL experts.

And most c programmers aren't clever, either. In fact, most programmers
in /any/ language aren't very good with it. That's not a condemnation
of a particular language, though.


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?

It is not. In this spesific case you are correct. But you must not make
the mistake of generalizing a spesific insignificant experience, of one
who was learning asm at the time, to all of the now 1000s written routines
since then. I have written over 120000 lines of asm code, since then,
probably more. Out of theese, 80000 lines are reuseable librarycode.

LOL! Don't generalize a specific instance?!? That's pretty much all
you did in the post I originally applied to!

Moreover, I would like to point out that you claim something is *always*
the case, which means a single counter-example refutes it. I can claim
that all prime numbers are odd, which is true for over 99% of them, but
this claim is false because of only a single counter-example: 2.


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.

Forced to use it? No, I guess not. Thats why I do assembly programming
now. But say, if you wrote 100000 lines of code with it, and then found
that 2 of the major components you used for 4 years, no longer can hold
what jobs you give it.... It must be rewritten or the project stops. Is
this a moment of glory for the HLL? What if you want to upgrade your
devtool, and find that because of changes to the compiler, half of your
code dealing with integers are broken. Is this a victory?

How is this a language issue? Can't you also write hundreds of
thousands of lines of code in assembly based on a library and then find
that it doesn't work?


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?

Delphi is a very good HLL language that compares favorable againt C. Lisp,
i dont know. Ada? dont know. If we compare C++ and Delphi, they are for
all practical conseptual purposes identical, except for syntaxdiffrences.

I can make general assumtions about HLLs based on the fact that they all
are abstrations upon the real thing.

Lisp is nothing like C, nor even close to assembly language. You don't
get much more high-level than Lisp. It's a completely different style
of programming than most HLLs, which is why many people find it
difficult to learn. You'd be making a big mistake if you thought all
languages are like C.


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.

yes it is. Are you allready gaining ignorant of the fact that you allready
said this at the beginning of your post? :)

It's called being consistent. Oh, and I completely forgot I wrote that,
which is why I started the sentence with the word "again". :)


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 am uberdrunk, but lets give it a try:

call IsEmailAddress

That's really disingenuous, you know. First of all, I have no
documentation for this library function, so I can't tell if it *EXACTLY*
meets the specification I listed. Second, who says an HLL can't have a
library function that does the same thing?

You completely missed the point. Write the validation in assembly just
using the base language. *YOU'RE* the one who stated writing from
scratch is easier in assembly, yet when it comes time to actually do it,
you don't want to. If it's so much easier, and it makes you so much
more productive, prove it.

Look at the phone number validation in my reply to ¬a\/b and give me the
RosAsm version:

Accept any of:
(202) 555-1212
(202)555-1212
202/555-1212
202.555.1212
2025551212

HLL version:
if (/^(\(\d{3}\)\s?)?\d{3}[\-\.]\d{4}$/.test(str) ||
/^\d{3}([\-\.])\d{3}\1\d{4}$/.test(str) ||
/^\d{3}\/\d{3}[\-\.]?\d{4}$/.test(str) ||
/^\d{3}?\d{7}$/.test(str))
{
// ... valid ...
}
else
{
// ... invalid ...
}

Want something that's not in a library function? Check a potential new
password for at least 2 uppercase characters, at least 2 lowercase
characters, at least 2 numbers, and at least two other symbols.

HLL version:

if (/([A-Z].*){2}/.test(str) &&
/([a-z].*){2}/.test(str) &&
/(\d.*){2}/.test(str) &&
/(([^A-Z0-9].*){2}/i.test(str))
{
// valid
}
else
{
// invalid
}

Oh, and my version allows you to easily change the number of characters
in each set if needed later. Just an added bonus. Now let's see it in
RosAsm.

Each of these took about as long to write as it took to type.


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?

Definitly. Without any doubt. Using RosAsm, of course, and not some of the
other poor exuses for assemblers thats out there.

So prove it above. Consider me an ECMAScript expert, even though I'm
not. (I'm really just an advanced beginner, if there is such a thing. I
wouldn't even characterize myself as intermediate.) If you can code
both examples in under, say, 90 seconds, maybe I'll lend some credence
to what you're saying.


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.

How about using the tool that matters most of all for a change. :P

"Matters most of all"? Is this a religious devotion, or is it really
better suited for the task? You have yet to demonstrate this to me.

David
.

Quantcast