From: lithgow@usl.com (Malcolm Lithgow)
Newsgroups: comp.sys.acorn
Subject: Re: Oh no ! More .....
Date: 6 Oct 92 01:03:28 GMT

Sigh -- why is it that the HLL advocates can't come up with any new
arguments?

[In message "Re: Oh no ! More .....", Kreijkamp J writes:]
> - High level structures.
>   Assembler doesn't support proper data-structures, type checking,
>   or (to follow the current flow) objects.

A good macroing package and a set of strict coding guidelines will get
you this quite easily. Not as smooth as an entire compiler, perhaps,
but just as usable by intelligent programmers (rare beasts,
unfortunately ;->).

>   Ever written programs >= 10k lines? (in ansi-C)
>   At least I don't want to write this lengthy progs in assembler...
>   ...and certainly I don't want to debug one!

The same goes for C, see below.

> - Portability.

The only decent argument for HLL's. I concede it, and it is why I'll
use an HLL over assembler for many projects.

> - Standarisation.
>   By using standard (C-)libraries your company can force people to use
>   standard interfaces, possibly shared-libraries, etc.

Just as easy in Assembler -- much of RISC OS is merely an assembly
level shared library with a precisely defined interface.

>   Also it is more easy to reuse code.

You are more likely to reuse code in assembler because the stuff is so
hard to write. As for the technical difficulty of reusing assembler, it
is no greater than for an HLL.

> - Readability.
>   Very often other people should be able to read your code too,
>   for making extensions, and fixing bugs.

Sorry to burst your bubble, but while raw HLL code may be more readable
than raw assembler, neither is sufficiently readable. (Ever tried
reading the UNIX source code?)

If a system like Knuth's WEB is used in combination with either HLL or
assembler, then you may get a readable program. In this case, the HLL
is no more readable than the assembler.

Let's come out of the dark ages here, and start using some tools beyond
20 year old HLL's and assemblers!

> - Tools.
>   For the most modern computer languages are good tools for developping
>   and debuging. I haven't seen many for Assembler.

Sorry? Look at UNIX. Look at Acorn's DDE. Look at Microsoft's
Development Environment. All of these support assembly with both
interactive source-level debuggers and macro assemblers.

> - Etc.
>   Go to your library and look for example by the subject software
>   engineering.

Yeah, and?

>Assembler only wins in
>
> - Speed.
>   but nowadays compilers have very good optimalisation, and processors
>   are faaaaastttt....

Not fast enough though -- just look how slow Adobe Photoshop is! Not to
mention desktop UNIX or Word for Windows (a few examples).

> - Size.
>   Again there are good compilers which optimise very good, and the
>   shared-libraries concept (like CLib on the arch) can reduce code
>   size dramaticaly in a multiprocess environment (RiscOs apps)

See my other posts about why assembler will nearly always reduce size,
regardless of how good the compiler is.

I think I've said all I can now. So it's goodbye to this thread from
me. It's actually been quite helpful for me this time 'round -- taught
me a few new concepts and gave me a few new ideas.

-Malcolm.  lithgow@usl.com  These are merely my opinions.
Newsgroups: comp.sys.acorn