Originally posted by Randall Hyde
Though I agree with the sentiment of your statement, the modern view is that the *standard* library is a part of the language.
The standard library is part of the language... okay.
Though I agree with the sentiment of your statement, the modern view is that the *standard* library is a part of the language.
So then pattern matching and other such things are a part of 80x86 assembly language itself? Or is HLA not an assembler, but rather a separate language? It seems that no matter what context I choose, be it HLA != assembler or HLA == assembler, contradictions seem to spring up. Is HLA a completely different language or just an extension to ASM? Because you seem to want to group it right along with ASM.
Originally posted by Randall Hyde
The "UCR Standard Library for 80x86 Assembly Programmers" was around long enough (and pushed by the 16-bit edition of AoA) that you could consider it a "standard assembly library." It was used by thousands of assembly programmers over the years. No, not an official standard, but the closest thing to a defacto standard that you're going to find.
More confusion. Maybe you can clear things up for me a bit.
The "UCR Standard Library for 80x86 Assembly Programmers" was around long enough (and pushed by the 16-bit edition of AoA) that you could consider it a "standard assembly library." It was used by thousands of assembly programmers over the years. No, not an official standard, but the closest thing to a defacto standard that you're going to find.
This University of California Riverside Standard Library for 80x86 Assembly Programmers. This defines a set of standardized routines for all 80x86 assemblers, or just HLA? The title would suggest it does for all of 80x86 programming everywhere. Does Intel know about this? Why don't they have any say in what goes in the ASM standard library? Or do they?
Originally posted by Randall Hyde
And as the creator of the HLA language, I have every right to define what belongs in the HLA Standard Library. Just like Microsoft could define what belongs in a MASM standard library or Borland could have defined what was in a TASM standard library.
There's a fuzzy area here. Are we talking about language-wide standard libraries or compiler specific standard libraries? Because I was under the assumption (see top quote) that we were talking about language libraries here. And keep in mind the original argument and your refutation which started all of this because I will eventually revisit it.
And as the creator of the HLA language, I have every right to define what belongs in the HLA Standard Library. Just like Microsoft could define what belongs in a MASM standard library or Borland could have defined what was in a TASM standard library.
Originally posted by Randall Hyde
Now that HLA's Standard Library is available for MASM and FASM (probably with NASM coming along before too much longer), you're going to see a few more people using it. The fact that AoA/32-bits pushes the HLA Standard Library means that, in time, it's going to be just as accepted and used as the UCR stdlib package.
What level of acceptance are we talking about here? This is the first time I've heard of the UCR stdlib believe it or not, and a search here on this ASM forum for "UCR" results in only a few links, most of which are in the HLA forum. What guarantee do I and other users have that these libraries are in our best interests? What level of thought and planning was put into them?
Now that HLA's Standard Library is available for MASM and FASM (probably with NASM coming along before too much longer), you're going to see a few more people using it. The fact that AoA/32-bits pushes the HLA Standard Library means that, in time, it's going to be just as accepted and used as the UCR stdlib package.
This point is irrelevant and opinionated but I feel I should make it anyway: I think that a "standard library" goes against the very nature of ASM programmers, who enjoy ASM for the freedom which it gives. Not being bound to any standard. The freedom to reinvent the wheel if we so choose, and also the freedom to let somebody else worry about the details if that too is what we want. In my own ASM programming endeavors I've found myself making regular use of the C standard libraries via DLL. And of course the library bundled with Hutch--'s MASM32 package comes in handy too. But many times I like to forego these things and fiddle on my own. If somebody came to me and said, "Here, use this standard ASM library", I probably would not be able to hold back my amusement.
Originally posted by Randall Hyde
It is fair to include standard library modules defined for a language as you can reasonably expect those routines to be available wherever there is an implementation of that language. The same is not true for 3rd party libraries.
More contradiction. Here, clearly you're not talking about compiler-specific libraries, rather, language-specific libraries. But since when is the HLA library a "standard" for assembly language? Is it? isn't it? Is it trying to be?
It is fair to include standard library modules defined for a language as you can reasonably expect those routines to be available wherever there is an implementation of that language. The same is not true for 3rd party libraries.
Remember your original argument -- that it's fair to compare the C (language-specific) stdlib to HLA's (compiler-specific) stdlib. This argument falls apart here unless HLA is an entirely different language, in which case it would be no more of an assembler than MSVC is, with it's __asm keyword and whatnot. It seems to me that the underlying classification of HLA which moves your arguments changes to suit your presented point. I hope that you will establish some definitive answers to these questions for future arguments.
Originally posted by Randall Hyde
But that's the "I could write that library module..." attitude. If it doesn't already exist and you have to write it, you have to consider the cost of writing that module as part of the project's development effort.
Yes, I could write that, and once I did, I could share it with others. And do so easily. Welcome to the internet.
But that's the "I could write that library module..." attitude. If it doesn't already exist and you have to write it, you have to consider the cost of writing that module as part of the project's development effort.
And other than a few minutes, what's the cost of surfing the internet looking for a free ready-made 3rd party library that does what you need?
Originally posted by Randall Hyde
Rather than bother searching for a decent library routine to do this stuff (then figure out if it satisfies their needs)
And what guarantees does the HLA stdlib have that it will satisfy one's needs? Is this an argument or an infomercial?
Rather than bother searching for a decent library routine to do this stuff (then figure out if it satisfies their needs)
Originally posted by Randall Hyde
, they just use Perl, Awk, or some similar string based language :-)
, they just use Perl, Awk, or some similar string based language :-)
Or include a string class library, of which there are many out there and freely available.
Originally posted by Randall Hyde
Who was making general comparisons? I was simply pointing out that in this one special case (pattern matching), it takes fewer lines of code to implement the solution in HLA than in C.
You just answered your own question. "it takes fewer lines of code to implement the solution in HLA than in C"
Who was making general comparisons? I was simply pointing out that in this one special case (pattern matching), it takes fewer lines of code to implement the solution in HLA than in C.
That right there, you just made one - a general comparison. The correct way of stating that would be "This HLA example takes fewer lines of code than is used in the C example." Your way states something about both languages in a general manner, when the real objects to compare here are not the languages, but the examples -- the efficiency of the code itself, which is the responsibility of the coder, and the level of abstraction that each had to work with. Any veteran C/C++ coder will tell you that that example up there is not exactly the best written one, and could be done a lot more compact, cleaner and easier, even if that means using a different pattern matching and string manipulation library.
Originally posted by Randall Hyde
Here are some additional areas where HLA does a better job than C/C++:
Here are some additional areas where HLA does a better job than C/C++:
Originally posted by Randall Hyde
iterators: HLA has true iterators and a foreach loop. Those things that C++ programmers like to call iterators aren't even close.
http://dictionary.reference.com/search?q=iterator
iterators: HLA has true iterators and a foreach loop. Those things that C++ programmers like to call iterators aren't even close.
An object or routine for accessing items from a list, array or stream one at a time.
Are we redefining iterator here? Last time I checked, C++ iterators did just that.
Originally posted by Randall Hyde
delayed paraeter evaluation: not even possible in C/C++. HLA fully supports call by name and call by evaluation parameters. It also supports thunks. Very important for many AI types of projects.
value/reference parameters: HLA fully supports value and reference parameters of *all* types. C/C++ does not.
macro processing: hey, the C/C++ preprocessor is the most pitiful example of a macro processor that could be written and still be called a macro processor. It is no wonder that C programmers tend to shy away from using macros when they begin learning assembly language - they've been heavily prejudiced by the problems with the C preprocessor (it *can* be done right in a HLL, check out Dylan sometime).
And that's wonderful. I'm happy for you. The right tool for the right job I always say. I'm not a C zealot.
delayed paraeter evaluation: not even possible in C/C++. HLA fully supports call by name and call by evaluation parameters. It also supports thunks. Very important for many AI types of projects.
value/reference parameters: HLA fully supports value and reference parameters of *all* types. C/C++ does not.
macro processing: hey, the C/C++ preprocessor is the most pitiful example of a macro processor that could be written and still be called a macro processor. It is no wonder that C programmers tend to shy away from using macros when they begin learning assembly language - they've been heavily prejudiced by the problems with the C preprocessor (it *can* be done right in a HLL, check out Dylan sometime).
Originally posted by Randall Hyde
such as complete control over the order of evaluation of arithmetic expressions.
Last time I checked, parantheses were used for this.
such as complete control over the order of evaluation of arithmetic expressions.
Originally posted by Randall Hyde
In order to support backtracking, the individual routines leave lots of stuff on the stack and this would mess up the C compiler considerably.
Leaving data on the stack seems a little hackish and dangerous to me. I hope that in the HLA Stdlib Manual there is a warning to the users about that somewhere. How does this pattern matching library handle itself when the user overwrites the data it left on the stack?In order to support backtracking, the individual routines leave lots of stuff on the stack and this would mess up the C compiler considerably.
The standard library is part of the language... okay.
So then pattern matching and other such things are a part of 80x86 assembly language itself? Or is HLA not an assembler, but rather a separate language? It seems that no matter what context I choose, be it HLA != assembler or HLA == assembler, contradictions seem to spring up. Is HLA a completely different language or just an extension to ASM? Because you seem to want to group it right along with ASM.
Just like IF, WHILE, RECORD, and CLASS are part of 80x86 assembly language :-)
Yes, I consider these library routines to be part of the HLA assembly language. HLA is a superset of 80x86 assembly language, just like MASM is a superset of 80x86 assembly language.
More confusion. Maybe you can clear things up for me a bit.
This University of California Riverside Standard Library for 80x86 Assembly Programmers. This defines a set of standardized routines for all 80x86 assemblers, or just HLA?
UCR stdlib is for MASM users writing 16-bit code for DOS. It's been around since approximately 1988. It is not at all compatible with HLA as HLA is a 32-bit flat model assembler. I mentioned the UCR stdlib to simply point out that "standardized" assembly languages have predated HLA by many years.
The title would suggest it does for all of 80x86 programming everywhere. Does Intel know about this? Why don't they have any say in what goes in the ASM standard library? Or do they?
They don't even care about what goes into an assembler, apparently. According to what I've heard, Intel no longer supports the notion of an "Intel Syntax" for 80x86 assembly. They're happy as long as the assembler processes all the machine instructions they create.
There's a fuzzy area here. Are we talking about language-wide standard libraries or compiler specific standard libraries? Because I was under the assumption (see top quote) that we were talking about language libraries here. And keep in mind the original argument and your refutation which started all of this because I will eventually revisit it.
In the case of HLA, we're talking about language-wide standard library. Of course, as there is only one implementation of HLA, we could also say that it's a compiler specific library, too. Then again, the library routines are callable from most other assemblers (with header files already existing for MASM and FASM), so who's to say it's even language specific. You do realize, of course, that MASM implements a different language than NASM, which implements a different language than FASM, which implements a different language than HLA, etc., right?
Nevertheless, though you can call HLA Standard Library routines from MASM, they're still "HLA Standard Library routines". Just like you can call MASM32 lib routines from HLA. Those are still the MASM32 lib routines.
What level of acceptance are we talking about here? This is the first time I've heard of the UCR stdlib believe it or not, and a search here on this ASM forum for "UCR" results in only a few links, most of which are in the HLA forum. What guarantee do I and other users have that these libraries are in our best interests? What level of thought and planning was put into them?
If you write DOS code, go check 'em out.
FWIW, my scan for "UCR Standard Library for 80x86 Assembly Language Programmers" in Google turned up Webster (where you can find the library), several articles (including one that appeared in Dr. Dobb's Journal back in 1992, references to the library in the 16-bit edition of The Art of Assembly Language, lots of links from other web pages, and so on. If you really care, you might try the search over again with Google and check it out. Then again, the UCR stdlib is for 16-bit DOS programs and is a bit obsolete these days. That's why I created the HLA Standard Library -- to provide a 32-bit successor to the UCR stdlib.
This point is irrelevant and opinionated but I feel I should make it anyway: I think that a "standard library" goes against the very nature of ASM programmers, who enjoy ASM for the freedom which it gives. Not being bound to any standard. The freedom to reinvent the wheel if we so choose, and also the freedom to let somebody else worry about the details if that too is what we want. In my own ASM programming endeavors I've found myself making regular use of the C standard libraries via DLL. And of course the library bundled with Hutch--'s MASM32 package comes in handy too. But many times I like to forego these things and fiddle on my own. If somebody came to me and said, "Here, use this standard ASM library", I probably would not be able to hold back my amusement.
Sure. Lots of asm programmers insist on reinventing the wheel every chance they get. How incredibly stupid! How many times do people have to write an "integer to string" conversion routine? But the presence of a "standard assembly library" in no way prevents someone from rewriting the functions to their heart's content (God knows that I've rewritten enough C standard library routines over the years). No one is taking away your freedom with a standardized library. What they're doing is saving you the grunt work of writing code that has been written thousands of times already and shouldn't be rewritten so you can concentrate on the real work at hand.
Ever wonder why there are any "real" applications written in assembly? It's largely because most assembly programmers spend so much time reinventing library routines that they are bored with their project by the time they get around to the real application-specific work.
More contradiction. Here, clearly you're not talking about compiler-specific libraries, rather, language-specific libraries. But since when is the HLA library a "standard" for assembly language? Is it? isn't it? Is it trying to be?
Not at all. The HLA Standard Library is a set of library routines intended for use by HLA programmers. Porting it to other assemblers serves two purposes: (1) many of the routines are nice and they can save other assembly users some time, (2) the availability of the HLA stdlib for other assemblers means that someone can learn HLA and then switch to another assembler at some point in the future without having to give up the investment they've made in learning the HLA stdlib.
Do I really expect MASM/FASM users to jump on the HLA stdlib bandwagon? Do I really care? What I do care about is ensuring that students learning assembly language programming don't have to write all these crazy routines themselves (which prevents them from learning a lot of assembly over the quarter) and I do want to assure them that if they learn the HLA stdlib routines can be called by code written with other assemblers should they need to switch at some point or another. If you really think that I care one way or another whether *you* adopt the HLA stdlib, you're mistaken. I stopped trying to tell "expert" assembly programmers how they should write their code *many* years ago.
Remember your original argument -- that it's fair to compare the C (language-specific) stdlib to HLA's (compiler-specific) stdlib. This argument falls apart here unless HLA is an entirely different language, in which case it would be no more of an assembler than MSVC is, with it's __asm keyword and whatnot. It seems to me that the underlying classification of HLA which moves your arguments changes to suit your presented point. I hope that you will establish some definitive answers to these questions for future arguments.
__asm is not a "C" keyword. If you doubt what I'm say, make your argument over in comp.lang.c sometime. Your whole point about language-specific vs. compiler-specific is a complete red herring. The HLA Standard Library *is* a language specific library. It is specific to the HLA language. Period.
Is HLA an entirely different language? Of course it is (anyone who knows the least amount of formal language theory realizes this is trivially true). This is a true statement for the language accepted by just about every assembler available for the x86 (i.e., when was the last time you saw MASM assembling NASM source code?). Calling HLA Standard Library routines from MASM is about like calling C Standard Library routines from MASM. Doing so doesn't make the C standard library a "MASM Standard Library", nor does it make the "HLA Standard Library" a "MASM Standard Library" when you call HLA stdlib routines from MASM. The HLA stdlib is specific to the HLA language.
And what guarantees does the HLA stdlib have that it will satisfy one's needs? Is this an argument or an infomercial?
And what reason do you have to believe that it doesn't satisfy one's needs. What makes you think that the code you've written is any better than what's in the HLA stdlib. What makes you think the code you can find on the internet is any better than what's in the HLA stdlib? Boy, do you like to argue for the sake of arguing, or what?
You just answered your own question. "it takes fewer lines of code to implement the solution in HLA than in C"
That right there, you just made one - a general comparison. The correct way of stating that would be "This HLA example takes fewer lines of code than is used in the C example." Your way states something about both languages in a general manner, when the real objects to compare here are not the languages, but the examples -- the efficiency of the code itself, which is the responsibility of the coder, and the level of abstraction that each had to work with. Any veteran C/C++ coder will tell you that that example up there is not exactly the best written one, and could be done a lot more compact, cleaner and easier, even if that means using a different pattern matching and string manipulation library.
Okay, put your money where you're mouth is.
Write a pattern matching library for me in C that is as powerful as the HLA Pattern Matching library module. You're the one claiming you've done this in the past and can do it in a few minutes. You've got *my* source code to look at. So now write a pattern matching package in C that is as easy to use, as efficient, and is as powerful as the HLA library module. Then you'll have made your point. Until then, you're arguments are a bit weak.
http://dictionary.reference.com/search?q=iterator
An object or routine for accessing items from a list, array or stream one at a time.
Are we redefining iterator here? Last time I checked, C++ iterators did just that.
Try looking up iterators, as defined by the CLU language back in the late 60's/early 70's. Any decent programming language design textbook will probably discuss this. If not, I'm sure the internet will provide lots of information if you look hard enough. BTW, some languages (e.g., Icon) use the term "generators" here, too (a generator is a combination of an iterator and a coroutine).
The things C++ programmers call "iterators" are more properly called "cursors." C++ does not have the ability to implement true iterators. C# is getting close with its FOREACH loop, but it still has a ways to go.
And that's wonderful. I'm happy for you. The right tool for the right job I always say. I'm not a C zealot.
Last time I checked, parantheses were used for this.
You didn't check very closely. While searching for information about iterators, you might also look into sequence points and evaluation order. You'll discover that C and C++ don't guarantee evaluation order in expressions. E.g., "F( a+b, c+d );" The compiler can choose to evaluate "c+d" or "a+b" first, their choice. In the presence of side effects, this can make a big difference in the calculation. Sequence points define where C will assure you that all side effects have taken place, but they don't guarantee order of evaluation. Assembly is one of the *few* languages where you have absolute control over the order of evaluation. For some expressions (particularly those involving floating point), this can make a difference in the calculation. The really scary thing is that a lot of programmers out there seem to think that they can solve such problems using parentheses; they are, unfortunately, incorrect.
Leaving data on the stack seems a little hackish and dangerous to me. I hope that in the HLA Stdlib Manual there is a warning to the users about that somewhere. How does this pattern matching library handle itself when the user overwrites the data it left on the stack?
Exceptions leave stuff on the stack. Heck, procedure activation records put stuff on the stack. What happens when the user overwrites that data on the stack? Welcome to assembly language.
Oh, yes, the HLA Stdlib manual *does* tell the reader about this.
Cheers,
Randy Hyde
Originally posted by randall.hyde
Ever wonder why there are any "real" applications written in assembly?
Ever wonder why there are any "real" applications written in assembly?
Hmmm, and what attributes must an application have before it can meet all of your criteria for a "real" application?
Originally posted by randall.hyde
It's largely because most assembly programmers spend so much time reinventing library routines that they are bored with their project by the time they get around to the real application-specific work.
It's largely because most assembly programmers spend so much time reinventing library routines that they are bored with their project by the time they get around to the real application-specific work.
I disagree. I think the reason you don't see many assembly-only programs is because it is not cost or time effective to write one, nor is it an industry standard except in very specific areas where it's necessary such as driver design and whatnot.
I would never write an entire application in ASM, except for giggles. If I am reinventing a library routine such as the integer conversion to string, which you seem to behold as so laughably trivial, then I am doing it because I am unhappy with its speed or implementation, and I need it optimized because it's one of the many bottlenecks in a time critical application. You can try to devalue this all you want but the fact is that there is always room for improvement and it is irresponsible to ignore it if you don't have to.
And sure, there are those stubborn crazy people that take pride in writing programs from scratch without relying on anybody else's code. A lot of ASM programmers are like this, and while I or you might not think it's the best way to do things, who are we to condemn it or call it "incredibly stupid"? Seems to me that's rather taking the Art out of Assembly Language.
Originally posted by randall.hyde
If you really think that I care one way or another whether *you* adopt the HLA stdlib, you're mistaken. I stopped trying to tell "expert" assembly programmers how they should write their code *many* years ago.
If you really think that I care one way or another whether *you* adopt the HLA stdlib, you're mistaken. I stopped trying to tell "expert" assembly programmers how they should write their code *many* years ago.
I'm sorry, I seem to have forgotten where or when I proclaimed myself to be an expert assembly programmer, or even so much as implied it. Please help me locate this instance and I will promptly edit it.
Originally posted by randall.hyde
__asm is not a "C" keyword.
__asm is not a "C" keyword.
Didn't say it was.
Originally posted by randall.hyde
And what reason do you have to believe that it doesn't satisfy one's needs. What makes you think that the code you've written is any better than what's in the HLA stdlib. What makes you think the code you can find on the internet is any better than what's in the HLA stdlib?
And what reason do you have to believe that it doesn't satisfy one's needs. What makes you think that the code you've written is any better than what's in the HLA stdlib. What makes you think the code you can find on the internet is any better than what's in the HLA stdlib?
My comment was made under the assumption that you were trying to impose HLA's standard library as the worldwide standard 80x86 assembler library. Apologies for the misunderstanding.
Originally posted by randall.hyde
Try looking up iterators, as defined by the CLU language back in the late 60's/early 70's. Any decent programming language design textbook will probably discuss this. If not, I'm sure the internet will provide lots of information if you look hard enough.
Try looking up iterators, as defined by the CLU language back in the late 60's/early 70's. Any decent programming language design textbook will probably discuss this. If not, I'm sure the internet will provide lots of information if you look hard enough.
You will have to excuse me for having no formal training in computer language creation and design, as that was not my life's path. But the C++ STL implementation of iterators does what I need it to do and it has yet to fail me. It might not be language native iterators, but it's still performs its function, which is all that matters.
Originally posted by randall.hyde
Okay, put your money where you're mouth is.
Write a pattern matching library for me in C that is as powerful as the HLA Pattern Matching library module.
You're the one claiming you've done this in the past and can do it in a few minutes.
Okay, put your money where you're mouth is.
Write a pattern matching library for me in C that is as powerful as the HLA Pattern Matching library module.
You're the one claiming you've done this in the past and can do it in a few minutes.
Let's not cloud the issue with testosterone.
Please help me to locate where I said that I've written an entire pattern matching library. I'm not able to find it.
What I did do is write a string class that included pattern matching functionality by wrapping PCRE, abstracting it to make string operations easier. It very closely resembles Javascript's String object. It also has additional mechanisms for matching nested patterns which is important for such things as XML parsing which is becoming increasingly more useful lately. With it one could write something like "myString.loadfile("foo.txt").match("g/bar/i").dump(stdout);" and be done with it. I realize that it can never quite compare with your life accomplishment so I won't bore you with further details.
Originally posted by randall.hyde
You've got *my* source code to look at. So now write a pattern matching package in C that is as easy to use, as efficient, and is as powerful as the HLA library module. Then you'll have made your point. Until then, you're arguments are a bit weak.
You've got *my* source code to look at. So now write a pattern matching package in C that is as easy to use, as efficient, and is as powerful as the HLA library module. Then you'll have made your point. Until then, you're arguments are a bit weak.
You can zip up your pants and put the measuring tape away. I think at this point you've quite made up your mind about how useless C is, and how the world of programming *should* be, and as I am not a programmer by trade there is clearly nothing I could do to persuade you otherwise.
You simply made a generalization about C that was incorrect, and if you cannot see the fallacy in the statement then there's really no reason to continue arguing in circles. But I will if you want.
Come on guys,
Chill. HLA is something really extraordinary, and the use of a standard library can considerably cut down development time, as Randy puts it. Although, it doesn't stop you from developing your own replacements, it does help YOU. You can call HLA whatever you want: an assembler, a compiler, a preprocessor, a whole new language, or whatever. But it is for assembly language programmers and it surely has made its point -- learning asm easily. Period.
It's evolution, so let it be.
Regards,
Art
Chill. HLA is something really extraordinary, and the use of a standard library can considerably cut down development time, as Randy puts it. Although, it doesn't stop you from developing your own replacements, it does help YOU. You can call HLA whatever you want: an assembler, a compiler, a preprocessor, a whole new language, or whatever. But it is for assembly language programmers and it surely has made its point -- learning asm easily. Period.
It's evolution, so let it be.
Regards,
Art
You simply made a generalization about C that was incorrect, and if you cannot see the fallacy in the statement then there's really no reason to continue arguing in circles. But I will if you want.
You know, I went back and reread my original post. I cannot for the life of me see where I made any generalization at all. Here's what I said:
The cool thing here is that the assembly version is actually *shorter* (in terms of lines of code) than the C version.
Later on, I did make the following generalization:
The bottom line is that C generally requires less effort than assembly (HLA or otherwise). But sometimes, assembly wins.
You came back with:
You just answered your own question. "it takes fewer lines of code to implement the solution in HLA than in C"
That right there, you just made one - a general comparison.
Which, quite frankly, is reading too much into the statement. IOW, you're nit-picking just to be argumentative.
You also accuse me of having made up my mind that C is no good and assembly is a better language. Yet nowhere in this thread have I ever made such a *general* claim. I've claimed that for this particular regular expression problem, the HLA solution is shorter. I've also pointed out a few areas where HLA is better suited for the application domain than C. I have *not* made any inferences from which you could draw a conclusion like
I think at this point you've quite made up your mind about how useless C is, and how the world of programming *should* be
As a matter of fact, I work in C and C++ every day. The fact that they are not the perfect language for every application (with or without in-line assembly) doesn't mean they're useless. Then again, it's important to realize that they are *not* perfect for every application and sometimes assembly *is* the better solution, even for "real" (i.e., large, non-demo) applications.
But you're right. Once the level of the debate falls to the point where someone is making comments like
Let's not cloud the issue with testosterone.
...
You can zip up your pants and put the measuring tape away.
the debate is over.
Cheers,
Randy Hyde