Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watmath!clyde!cbosgd!ihnp4!ho95e!wcs
From: wcs@ho95e.UUCP
Newsgroups: comp.misc
Subject: Re: Assembly language (was: Re: Another 1.3 wish.)
Message-ID: <1667@ho95e.ATT.COM>
Date: Tue, 18-Aug-87 00:58:51 EDT
Article-I.D.: ho95e.1667
Posted: Tue Aug 18 00:58:51 1987
Date-Received: Wed, 19-Aug-87 07:34:28 EDT
References: <8707190424.AA10158@cogsci.berkeley.edu> <434@sugar.UUCP> <3664@well.UUCP> <7197@think.UUCP>
Reply-To: wcs@ho95e.UUCP (46133-Bill.Stewart,2G218,x0705,)
Organization: AT&T Bell Labs 46133, Holmdel, NJ
Lines: 58

In article <7197@think.UUCP> barmar@godot.think.com.UUCP (Barry Margolin) writes:
:In article <3664@well.UUCP> ewhac@well.UUCP (Leo (My glasses have gate arrays) Schwab) writes:
:>	Expressing a new or complicated algorithm in a high-level language
:>is a useful endeavor.  It allows you to clearly formulate and express the
:>problem/procedure in machine-interpretable form.  However, once you have the
:>basic algorithm down, your next step should logically be to translate that
:>algorithm into assembly by hand.  Compilers can do a good job, but never as
:>good as a human.
	It's nice to find an assembler advocate who's rational.  (I may
	flame Doug Pardee later on :-)).  But no, once you've expressed
	the algorithm in a HLL, your next step is to put together the
	entire set of programs or tools to solve your problem, and test
	the heck out of them.  Even with good algorithm design, it's
	not usually obvious how the program will really be *USED* once
	it works.  Programming in a HLL gives you three main things:
		- Problem Formulation in a problem-oriented language
			that a machine can execute.
		- A prototype so you can debug the formulation - SOON.
		- The ability to change the program RAPIDLY.

	You'll always throw the zeroth version away.  You should usually
	throw the next version away (though Marketing may drag it out
	of the trash and sell it as Release 1.)  So it doesn't matter
	that it's three times as big and twice as slow as if you did it
	in assembler, because you'll have a much better product when
	you finally do the production version.  If the performance is
	adequate (it often is!), then market it.  If you work for a
	large company, distribute it widely internally.

	You'll do a lot better by getting the features right than making
	it twice as  fast - witness Microslow Windows.  If you work well
	with  your  customers,  they'll  come back  with  all  kinds  of
	suggestions about  how they use it  and what they want  added or
	improved, and many of them aren't the ones you tuned it for.
	Ignore most of them, put the good ones into your product and
	get Release 2 out fast enough to satisfy people.

	(To give Doug a little slack, if the problem you're trying to
	solve is to make hardware behave, then a machine language may
	be more problem-oriented than C or Fortrash.  But for most
	people, and most problems, that's not true.  Even with the
	Macintosh, much of the "really fine-tuned" was outdone by
	compilers, once good compilers became available.  I agree that
	assembler is useful until you get a decent compiler.)

	But wouldn't it have made more sense to do a mediocre compiler,
	and use it for the ROM?  It *would* have been twice as big and
	not as fast, but it would be *much* more accessible to
	programmers.  More people would have developed good Macintosh
	software, and maybe there'd be more Macs around instead of these
	braindamaged MS-DOS machines.

 -----------
	I suppose all this says I should do most of my programming in a
	high-level language like ZetaLisp instead of C and Shell.
-- 
#				Thanks;
# Bill Stewart, AT&T Bell Labs 2G218, Holmdel NJ 1-201-949-0705 ihnp4!ho95c!wcs