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

Betov <betov@xxxxxxx> wrote...
David Jones <ncic@xxxxxxxxxx> écrivait
news:MPG.20005bd3b863fd8898969b@xxxxxxxxxxxxxxxxxxxxx:

Betov <betov@xxxxxxx> wrote...
David Jones <ncic@xxxxxxxxxx> écrivait
news:MPG.200049b8f4929257989699@xxxxxxxxxxxxxxxxxxxxx:

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


You are a great clown, David. Congratulation: I was in a
sad mood today, and you succeeded to make me laugh a lot.

Glad I could entertain you. Since you're an expert assembly
programmer,
would you mind having a crack at being more productive and writing an
equivalent function in assembly in less time? :) I would love to be
proven wrong.

I am afraid that nobody around would be interrested in reading
a so trivial loop with a lodsb / stosb pair, hosting a trivial
If/else_If cases verifications, David.

In other words, you can't write one in less time, meaning I was more
productive. :)


So said, if you really fail to understand anything, i have to
point you to the following facts, which have relationship with
the topic:

1) Your scriptic delirium is 100% unreable, and even an expert
of that kind of notation, would probably have 100 times more
difficulties at fixing any minor bug, than in trivial Asm.

It's only unreadable because *YOU* don't know how to read it. An expert
in that language (which uses regular expressions) would have no problems
reading it. Someone who doesn't know assembly wouldn't be able to
maintain the assembly version.

As for fixing bugs, the smaller the code, the easier it is to find and
fix bugs. In this case, the code is denser, but it's doing less (it
doesn't have to read through the characters -- the language does that
for you), so it's still a net win.

Moreover, the overriding point wasn't that this was the clearest code in
the universe -- it's that different languages are better suited for
different tasks, so you should fit the language to the task, not the
task to the language. To go back to the hardware analogy, you can use a
screwdriver on a nail, but a hammer is so much easier.


2) Before writting your above absurdity, you have _LEARNED_ the
given convention for expressions. This is an evident _COST_:
The _lesser_ you need to learn, the better.

And this affects developer performance how? There is an initial
education cost for any language, Betov.


3) The compilations of such expressions will always be way less
optimal than any trivial Routine (written in whatever language).
Not implementing a so trivial Function (Routine), in a program
that is supposed to make use of it, is, definitively, not
understanding one single bit at the programming art.

Now you are talking about runtime performance. This is an area where
assembly is the right tool. Optimal code generally takes longer to
write than sub-optimal code, though, so developing all of your code in
optimal assembly would take longer, lowering productivity.


4) Writting a trivial If/Else_If on Digits and separators, in a
While/End_While Loop will always be way easier and faster to
write than such an awfull and confusing mess like the one you
seem to prefer.

It's only confusing because you've never worked with regular expression
syntax. And the loop's not "trivial" in the sense that you have to
check for matching and/or missing punctuation.

If it's always way easier and faster to write, please do so and prove me
wrong. After all, it's "trivial", so it shouldn't take much to show me
up, eh?


5) And in case you would really not know, selecting the &ES_NUMBER
Style, for an EditControl, would save you from any parsing, at all.

Yeah, that works really great for validating data from a text file or
passed across the network, not to mention that it wouldn't allow the
original input format to be displayed in the application. People like
the formatting displayed in the control, Betov. Which is easier to
read: 2028675309 or (202) 867-5309?

If you can't solve the problem, redefine it, eh? ;)

David "dancing a jig in my clown suit" Jones
.

Relevant Pages

  • Re: The War On HLA
    ... >> But when it comes to C I am in agreement with Betov. ... >> Its simply a stupid language. ... language can be easily understood with not much effort by a programmer from ... The Wannabee ...
    (alt.lang.asm)
  • Re: x86 Assembly Language FAQ
    ... >> if any of the moderators can read the language in question. ... >> Friendly, Betov. ... > Can you please explain to me why dislike HLA and ... > I se angry posts in alt.lang.asm and in this Ng. ...
    (comp.lang.asm.x86)
  • Re: Newbie
    ... Betov wrote: ... >>I'm trying to write some graphics routines and a compiler for new ... A dynamic yet compiled language like Dylan. ...
    (alt.lang.asm)
  • Re: Newbie
    ... Betov wrote: ... >>really fast learner, believe me. ... > In all cases you first need an Assembler. ... I'm trying to write some graphics routines and a compiler for new language ...
    (alt.lang.asm)
  • Re: acceptance of forth (was: Re: continued fractions)
    ... But most every scripting language these days offers one ... this is provided by the language itself. ... is classic regular expressions are "greedy" so matching on shortest- ... string in that language and execute it), here are some of the big ...
    (comp.lang.forth)