The Great Debate
- From: randyhyde@xxxxxxxxxxxxx
- Date: 25 Jul 2005 08:23:39 -0700
"The_Stooge", er, "The_Sage" wrote:
> A little research on the history of computer languages
> demonstrates that every company used to use ASM to
> develop their software,
Not every. Not by any stretch of the imagination.
> but ASM proved to be very cumbersome and unproductive,
Except, of course, it got the job done, which wasn't
possible in HLLs at the time.
> for example, you couldn't
> simply compute X^2 + Y^2, you have to translate that
> equation into hundreds of lines of hard to debug ASM
> code.
fld(x);
fld(st0);
fmul();
fld(y);
fld(st0);
fmul();
fadd();
I won't comment on how easy this code sequence is to
read, debug, or maintain, but it's hardly "hundreds of
lines of code."
Your comment is obviously based on comments made before
the days of floating-point hardware, when people had to
write hundreds of lines of code for floating-point
arithmetic subroutines. Clearly, your comments need a
little updating based on the presence of modern hardware.
> As Brian Hayes of AMERICAN SCIENCE put it, ASM
> was so cumbersome and unwieldly that, "By the 1960s
> large software projects were notorious for being late,
> overbudget and buggy; soon came the appalling news that
> the cost of software was overtaking that of hardware".
BTW, Brian did *not* say "hundreds". He said *dozens*.
Here's the URL to the article if you want to read it for
yourself:
http://www.owlnet.rice.edu/~comp212/03-spring/exams/03/ASCS.htm
Here's the pertinent quote:
"Evaluating a short mathematical expression such as
x^2+y^2 might require dozens of assembly-language
instructions."
It is also interesting to note how you quoted Brian out
of context. He did *not* say assembly language projects
were late, overbudget, and buggy. Here's the exact quote:
"With Fortran and the languages that followed,
programmers finally had the tools they needed to get into
really serious trouble. By the 1960s large software
projects were notorious for being late, overbudget and
buggy; soon came the appalling news that the cost of
software was overtaking that of hardware."
Wait a second, he's talking about FORTRAN here! How
disengineous of you to misquote Brian talking about
FORTRAN and use that quote to bolster the use of FORTRAN
over assembly language. :-). The fact might very well be
that FORTRAN is a *much* better choice than assembly for
certain individuals to use than assembly for a given
application, but your intellectual dishonesty here is
appalling.
Also note: Brian is a *journalist*. Not an assembly
language programmer. See
http://www.americanscientist.org/template/AuthorDetail/authorid/490
No doubt, Brian has written some code in his lifetime.
But a quick perusal of his C.V. at the above URL suggests
that he's probably not the leading authority on which
programming languages are the best to use. Given the
audience of American Scientist, I doubt he had to do much
more research than rehash findings in a typical software
engineering paper somewhere. IOW, calling on Brian Hayes
as your "expert witness" here is hardly a solid move.
> Then along came C and things started to change for the
> better.
C has *never* been considered a good software engineering
language. Indeed, the reason C became popular is because
it is *low-level*. Not as low as assembly, but certainly
much lower level that other languages such as Pascal
(which did become popular in the early to middle 1970s,
as structured programming grew in popularity).
> ASM had its heyday and it blew it -- big time!
????
Blew it?
People delivered usable apps in assembly that wouldn't
have been practical at all in HLLs.
During the late 1980s and 1990s, CPU speeds improved so
rapidly that one could count on CPUs running twice as
fast when the product shipped as when the project was
started. This allowed people to write sloppier code and
justify writing slow code faster rather than writing
fast code slower. Today, however, Moore's law isn't
buying us more (uniprocessor) speed. That means that if
an application requires better performance than today's
CPUs can provide, it's going to be up to the
*programmer*, not the computer architect, to remedy the
situation. Here's an article in EDN Magazine, for
example, on that very subject:
http://www.edn.com/article/CA601846.html
> To go back to pure ASM would be like reverting back to
> the stone age. Why should we repeat history?
Because history, as we know it, is coming to an end. That
is, we're not seeing the vast improvements in CPU
performance each year as we've seen in the past. Whether
we have to revert back to writing code in assembly
language is a good question, but clearly something is
going to have to change.
>
> The numerous vices of ASM also contributed to it's
> demise, such as it's lack of independance from a
> particular computer hardware architecture,
We are talking about writing computer applications here,
right? That means software written for general-purpose
computing platforms (e.g., PCs). With Apple's recent
announcement that they are switching to the x86
architecture, this means that 99% of the world's
general-purpose computing platforms are running the x86.
Exactly how important is CPU independence when every
market for your software is running on an x86 CPU?
Sure, there's embedded systems (forget portability there)
and servers (tiny slice of the market). Whether assembly
is good for them or not (probably true for certain
embedded apps, probably not for server apps) is a good
question, but irrelevant to the question at hand --
writing apps.
> lack of
> standardization of libraries,
HLA Standard Library
MASM32 Library
Where have you been?
> failure to work with
> abstractions,
You must be thinking of RosAsm. Modern assemblers like
MASM, TASM, and HLA provide all kinds of facilities for
working with various abstractions.
> lack of support for reliability or
> safety,
And C provides these things? (hey, *you* mentioned how
the arrival of C solved the software engineering
problems; this is a fair question.)
> failure to keep up with computer technology,
Last time I checked, assembly kept up with new CPU
instructions *far* better than did any HLL.
> most lack appropriate engineering-based support tools
> and environments,
You must be using RosAsm.
> lack of clarity in the source code,
You must be reading RosAsm code.
> lack of complexity management,
You must be refering to RosAsm,
> lack of straightfoward
> and user friendly concurrency support,
And C supports this how?
> lack of
> distributed system support,
And C supports this how?
> poor maintainability,
You must be looking at RosAsm code :-)
Seriously, C isn't a whole lot better.
> lack
> of true object-oriented programming support,
HLA and TASM both support *true* OOP.
> lack of
> portability, etc, etc, etc
Again, how important is portability when every
general-purpose PC platform out there uses an x86
processor? And besides, just because you've written your
code in a HLL doesn't mean that it's portable. Try
recomiling your Win32 app for Mac OSX, for example.
>
>
> Isn't the point of a programming language to make it
> simple to transfer thoughts from an idea to the
> program?
No. That may be one of the many goals of a programming
language, but it isn't *the* point.
> Anyone should be able to write a program,
"Should" and "can" are two different things. Some people
just don't have the ability to solve problems on a
computer. They should *not* be writing computer programs.
> instead of relegating the programming to programmers.
Shouldn't everyone be doing their own physics? Shouldn't
everyone be their own doctors? Shouldn't everyone do
their own airplane design? People specialize for a
reason.
> Programmers (typically) don't major in higher math, so
> how are they going to write a program for a quantum
> physicist?
First, most CS programs I've seen (of any quality)
require students to take two years of math, more than
enough to do the job for a quantum physicist under the
physicist's direction.
Second, having done that kind of work, I can vouch for
the fact that it can be done; no problem.
Heck, the *physics* was harder than the math. Somehow I
managed to get through it all.
> It would be far better if the physicist
> could write his own program without having to have two
> degrees to do so, since the physicist could understand
> his thinking far better than just a programmer could
> do.
Sure, but then the physicist would spend all his time
doing computer programming rather than physics. By your
argument, the CEO of a large company should be writing
all his own software rather than running the company. How
do you think the shareholders would feel about that?
Perhaps that physicist should also build the office and
lab that he's going to occupy. After all, he knows his
requirements better than anyone else concerning how he is
going to use the space. Perhaps that physicist should
also design his own computer system (down to the
semiconductor level); after all, he knows his computing
requirements better than anyone else.
Again, people specialize for a reason. The physicist will
be *far* more efficient doing *physics* than writing
software.
> The point is that physicists have to rely on
> software to do their job and the most inefficient and
> cumbersome way to do that is to have someone who has no
> clue what you are talking about write a program for
> you.
Hire good help :-)
Seriously, though, the main reason physicists wind up
writing a lot of software is because:
1) there is no budget to pay a programmer to do the job
(and bean-counters figure it's cheaper to have a
physicist do the job, no matter how inefficient they are)
2) most programming on physics jobs gets done at
universities where there is slave labor (grad students)
to do the work. (You actually think physics professors
write their own code?)
> The time would be much better spent for the
> physicist to do it themselves,
The time would be much better spent if the physicist did
*physics* rather than wasting his/her time writing code.
> if only there were a
> language that would allow to do that.
There is. It's called "English" (or whatever natural
language the physicist speaks). The physicist uses it to
explain what code he needs written to the person writing
the code, so the physicist can concentrate on more
important matters involving physics.
> That is why you
> will see books on FORTRAN FOR SCIENTISTS or BASIC FOR
> SCIENTISTS or C FOR SCIENTISTS but no ASM FOR
> SCIENTISTS.
Yep, all them grad students have to have something to
read when their advisor makes them do a job they are
ill-prepared for.
BTW, you *will* notice that there are "ASM for
ENGINEERS" books.
> ASM just isn't user friendly.
Good thing programmers are the ones who deal with it
rather than users, eh?
> Personally, I
> like ASM very much, but if I had a choice, I wouldn't
> choose ASM -- and I've had those choices to make
> before.
So why do you even post in an assembly newsgroup?
Why not make the choice to post in other groups where
your opinions might be appreciated? Do you honestly
think you will change one opinion around here? Especially
when you make such glaring technical errors as claiming
"semicolons are optional at the end of C statements?" or
"jump tables have jmp opcodes buried in them?" Yes, you
amaze us with your technical prowess. For sure we're
going to believe what you have to say.
> You have little time, a limited budget, and all
> they want is something that works without crashing
> every other day and they want it now. They don't care
> how big it is or how fast it runs. You can do things in
> VC in a few days that would take weeks to do in ASM.
Yup. And you pay the price for that down the road.
Code that is written quickly, because people don't care
about things like how big it is or how fast it runs
generally winds up having other failures, too.
> The few things that aren't higher level, are written
> in speciality languages, ie -- a DSP compiler specific
> to DSPs or a few inline ASM statements in a couple of
> well choosen locations.
Sorry, the 80/20 (or 90/10) rule is about as
mathmatically valid as Moore's Law. It sounds real good
on paper, but in practice it is unsustainable.
You can't write bloated code (the kind of stuff you
describe above, in VB, for example) and then miraculously
speed it up with a few well-placed in-line assembly
statements. If the code was designed poorly to begin
with, it's going to take a complete rewrite to overcome
the efficiency problems. And to write the code properly
in the first place is going to take a few weeks,
regardless of the language. Sure, you can bang out slow
code fast using VB, and if that works for you, great. But
the other side of the coin is that producing fast code is
slow. Again, independent of the language. The problem is
the programming paradigm that you use. If you want
efficient code, you're going to have to think at a
low-level of abstraction and carefully choose the
statements you use in the program, rather than picking
the first thing that comes to mind.
> And the software industry
> agrees with me
Yes, all of those out of work programmers who are now
pumping gas because their HTML programming skills didn't
cut it in the real world :-)
> -- not because of their opinion or
> because of Randall's make believe conspiracy against
> ASM,
I think you're confusing me with Rene ("Betov") Tournois.
He's the one touting a conspiracy against assembly
language. I'm the one claiming that people should have a
working knowledge of assembly code, even if they write
HLL code only, so they can "Think low-level and write
high-level" (Indeed, I have a book coming out on that
very subject in a couple of months).
You might also want to check out my rantings on why
people should learn assembly:
http://www.onlamp.com/pub/a/onlamp/2004/05/06/writegreatcode.html
Not because they're going to write all these great apps
in assembly, but because it helps them write better code
no matter what language they choose.
> but because of experience. History is a good
> teacher and I would rather learn from other's mistakes,
You certainly don't learn from your own.
> rather than repeat them,
> and ASM is one of those
> historical mistakes.
Meaning it never should have been used in the first
place? Do you actually believe this? Do you actually
believe people shouldn't *learn* assembly language?
> ASM is especially horrible at
> creating GUI-intensive applications for Window$.
> It is far, far easier, simpler, and less conducive to
errors
> to program a GUI intensive application in a visual
> langauge than any ASM code. That is why ASM is never
> used for rapid application developement (RAD).
IOW, because there is no *visual assembler* assembly
language shouldn't be used for writing GUI apps. But what
would happen if there were an assembly language
equivalent of Delphi or VB? Then what?
Cheers,
Randy Hyde
.
- Follow-Ups:
- Re: The Great Debate
- From: JGCASEY
- Re: The Great Debate
- From: Charles A. Crayne
- Re: The Great Debate
- From: Charles A. Crayne
- Re: The Great Debate
- From: Betov
- Re: The Great Debate
- Prev by Date: Re: Which assembler can handle the BIG stuff ?
- Next by Date: Intel Syntax Problems.
- Previous by thread: use stack own by other functions
- Next by thread: Re: The Great Debate
- Index(es):
Relevant Pages
|
