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

<//\\\\o//\\\\annabee <"WINOS IS ***.">> wrote...
På Fri, 29 Dec 2006 17:58:02 +0100, skrev Herbert Kleebauer
<klee@xxxxxxxxx>:

But you claim that assembler is the proper
tool for anything, which I claim is wrong.

But this is by definition unlogical. In asm you can build up the higher
functionality you need, targetting the spesific (or general) problems you
want to solve. At no point is this a slower process than doing the same
thing with a HLL. First you do not have to learn the HLL libs, and you do
not have to search them, and perform testcases to find out that they arent
designed to solve the spesfic problem, that you encounter. You be lucky if
you run into theese problems sooner, rather then when you allready wrote
most of your code.

This argument is a fallacy. What happens if you already know the HLL
libraries inside and out? What happens if you never learned assembly
language before?

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.


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.

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


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.


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?)

Writing "from scratch" as you put it can be done in any language, not
just assembly. 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.)


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. You're really just proving Herbert's argument for him: use
the correct tool instead of force-fitting one tool for all uses.

David
.

Quantcast