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

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


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?

it drives home a point that is imo very important. In 99% of cases, I
would call to my allready written routine for this service. Only the first
time would I scratchwrite. So I actually posted what is the average job
for such a thing.

Yet, in an HLL, we would *never* use an already written routine! That's
why this is disingenuous -- you're comparing apples and oranges and
drawing conclusions from them.

If you take your position to its logical extreme, that would make
assembly the *least* productive since there's less already written for
you -- the library set of an HLL contains more pre-written code that has
been tested and refined and proven over time.


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 ...
}

:)

I will do it when you tell me how this will prove anything that we did not
know from before.

No, I know you won't do it, and neither will Betov. That's ok, I always
knew you wouldn't because you can't. :)

It would help prove that writing from scratch in assembly is or is not
_always_ more productive (i.e., faster with development time to produce
an equivalent product) than an HLL. If you can develop a solution
faster, then it rejects my counter-example.

Calling a previously written routine in any language costs the same
amount of development time -- just set up the parameters and call it --
which is why it's not a fair comparison. (In my example code, I only
used built-in language primitives.)


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.

Can you post code that does a count of the number of colors in any bitmap,
in this EMCAscript thing? It must be able to count complex bitmaps with
100000s of colors in roughly 10-100ms. (Or what will be perceived as
instant on an AMD64).

Ah, again you have failed to grasp my point. EMCAScript is the *wrong*
tool, so why should I use it to do bitmap calculations? Use the right
tool for the job - that's my whole point.

You, however, are claiming that assembly is *always* the right tool,
which I read to logically conclude that it must be the right tool to
perform input validation.

And you keep harping on runtime performance again, while maintaining
you're talking about development time -- mentioning it makes you look
like you're confusing the two. We're talking *SOLELY* about development
time here. In this case, performance isn't crucial.

I don't want to keep beating a dead horse, so this will be my last post
on the matter, unless you do happen to actually write input validation
in assembly in a faster time with a fewer or equal number of bugs, which
you won't do. Ignorance is bliss, eh? ;->


even if I think the whole thing
is absurd. As it has nothing todo with _dev_ times for a real world
project. There are many more factors to count in than to time the building
of one simple spesific parsing routine. I hope you are able to see this?
Or do you seriously think that the realtive timings of two such routines
can be generalized into the relative diffrences between two full projects?

This is true: this routine is not the entire application. Lets say the
actual application is importing data into a database from a text file,
and data verification is run on each field in the record before it is
allowed to be inserted. This runs nightly in the background, so runtime
performance isn't crucial. Satisfied? (And, yes, this is a real-world
example.)

Now input validation dominates the code of the application, so you can't
just ignore it as inconsequential. (Like Betov, if you can't solve the
problem, you redefine it so that it looks like assembly is a better
choice.) If you prefer, assume that there are hundreds of possible
field types, making the input validation code the vast majority of the
application's code.

Is it contrived? Hell, yes. But, as I stated earlier, to disprove that
all primes are odd, you don't need to look at the average case for prime
numbers: you only need a single counter-example (ie: 2) to prove the
assertion wrong. To disprove that assembly is always the best tool, you
only need a single counter-example that shows something else is better
than assembly.

Moreover, other languages (such as Perl) contain regular expressions, in
which you can do much more than ECMAScript can. You're not just limited
to ECMAScript for the example to remain valid. In fact, Perl is a much
better example, but I don't know the Perl regexp syntax, although it's
very similar. (It's analogous to the difference between Intel and AT&T
syntax.)

Here's the really important point: If you use a linker, you can actually
*combine* modules written in *different* languages into a single
application. (A good example is the code behind Orbitz, which is
written in Lisp, C++, and Java, and also has terrific performance.)
This allows you to divide your project into pieces where each uses the
best language for the task, so parts that need fast execution can be
done in assembly, input validation can be done in a language with
regular expressions, etc.

Or you could do it all in assembly and throw away that advantage. Your
competitors won't mind at all.


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.

The tool that matters the most is sitting beteen your ears.

Ah, I misunderstood. On that aspect we agree: if you don't think, your
solution will be terrible.

In that regard, I leave you with a political quip that I think also
serves as an analogy to your unwavering devotion to assembly-only: "Vote
Republican - it's easier than thinking."


Friendly greetings and the wishes for a even more healthy new year.

And you as well.

David
.

Quantcast