Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watmath!clyde!mcdchg!usenet
From: usenet@mcdchg.UUCP
Newsgroups: comp.lang.misc
Subject: Re: Software Technology is NOT Primitive
Message-ID: <2265@mcdchg.UUCP>
Date: Wed, 4-Nov-87 12:35:14 EST
Article-I.D.: mcdchg.2265
Posted: Wed Nov  4 12:35:14 1987
Date-Received: Sat, 7-Nov-87 15:58:47 EST
Organization: Motorola Microcomputer, Schaumburg, IL
Lines: 704

Here are about half the articles I've received to date that should
have gone exclusively to comp.lang.misc, but were cross posted to
comp.unix, as well.  I have no idea why I'm getting all of these.
Please stop it.  I will post the second half of the messages in
another article.  Thanks.
-- 
Ron Heiby usenet@mcdchg.UUCP	Moderator: comp.newprod & comp.unix

----------

From: gatech!rutgers!hplabs!sun!mandrill!hal!ncoast!crds (Glenn A. Emelko)
Organization: Cleveland Public Access UN*X, Cleveland, Oh

Lawrence (and all),

I have been involved at an engineering level in both hardware and software
design for about 10 years.  Across these years I have seen advances in both
industries, but I must say that I am more impressed with what I see in the
way of hardware technology.  In some ways, it seems, software has degraded
somewhat because of hardware progress.  This has been, and most likely shall
continue to be one of my pet peeves of the whole industry.

First of all, I can remember (as many of you can too) machines which had 4K
of memory, or 16K, and still had to have a rudimentary OS running which could
perform some tasks and still allow the user to load a program.  In those rough
times, people were very concerned and concious about storage, both on disk, as
well as memory usage.  This forced software engineers to think creatively, to
tighten code, and to produce very powerful LITTLE algorithms that could do
many things and could be called from many other parts of the code.  Code was
many times designed to be recursive, if not reentrant, and it was expected
that the software engineer knew alot about the machine and environment (in
terms of the hardware) that was hosting the program, which allowed for tricks
and little magical wonders to happen (laughing, in other words, the designer
took advantage of what was available).  In contrast, today, many designers
know nothing about the destination machine (it's a UNIX box?), and most are
not very concerned about how much memory, disk space, or anything else that
they use, and really could care less if there are four subroutines in their
code which could be combined into one general purpose all encompasing sub.

Further more, it seems, now that we have 3-MIPS and 5-MIPS and higher-MIPS
machines being sold over the counter at reasonable prices, very little time
is spent by the software engineer to really PUSH that machine to it's gills.
In fact, I have noted many specific cases of generally sloppy, slow, and
out-and-out crude coding techniques passing as "state of the art," simply
because it is running on a machine that is so blindingly fast that it does
make that code seem reasonable.  Case and point:  I can recall designing a
sorting algorithm for a data management system which was very popular in the
early '80s for a specific Z80 based computer, and then one day pulling out
a copy of the "state of the art" data management/spread sheet program of '84,
which ran on a 8088 based system, and benchmarking them against each other
for about 20 different test cases (already sorted, sorted reverse, alpha only,
numeric only, fractional numbers, alpha numerics, and numerous data sets),
and watching the Z80 based computer beat the 8088 based system 10 to 1 at
WORST!  And as an added note, the sort on the Z80 was stable, and the one
on the 8088 was not!!!  Yes, I am talking about the "most popular" spreadsheet
of 1984, and a lowly Z80 machine ripping it to shreads!  Is this the current
state of software technology?  Yes, I believe so.

At the same time that I have shared these "beefs" about software development,
I have mentioned advances in hardware which allows the software guru to get
lazy and still be considered current.  We have processors today which can
out-run the processors of 1978 (10 years ago) by 20 to 1.  We have software
today which can probably be out-run by the software of 1978, even when we use
it on that powerful processor.  Sure, it's USER FRIENDLY, ERGONOMIC, etc., but
does it keep pace with the advances in the industry?  Why don't I see ANY
software advances that are even an order of magnitude above 1978?  This would
give me 200 times the power, considering the advances in hardware!!  I would
like to get my hands on a copy of "current software" which shows me this
capability, please email me info, or respond on the net.

Yes, these opinions are specifically mine, and reflect upon nothing other than
my own personal experiences, pet peeves, and general bullheadedness.  Feel
free to differ with any or all of the above, but at least get a laugh out of
it.  I find it funny myself.

Glenn A. Emelko
...cbosgd!hal!ncoast!crds

Somehow, this borrowed caption seems appropriate:

     "When I want your opinion, I'll give it to you."

----------

From: gatech!rutgers!haddock.ISC.COM!stevel (Steve Ludlum)
Organization: Interactive Systems, Boston

In article <3471@sol.ARPA>, crowl@cs.rochester.edu (Lawrence Crowl) writes:
> It looks to me like software and hardware technology have tracked fairly well.
> The cause for the difference in perception is that hardware has done the same
> task cheaper and faster while software has performed an ever more difficult
> task.  Because hardware has simpler measures, it has more apparent progress.
> The actual progress is roughly equivalent.

Hardware doing the same thing faster? Parallel processors are not just faster
they are different. Symbolic machines use different hardware techniques, i.e.
tags. Laser disk do simply store more information but the difference means
much more than just being able to do more of the same thing. Specialized
hardware designs such as DSPs are opening up new areas such as speech and
vision automation, oh and don't forget those little network controllers
on a chip.

Anyway all of the progress in software has just been taking care of a 
few more special cases :-)

ima!stevel 

----------

From: gatech!rutgers!ORION.BITNET!KEN (Kenneth Ng)
Organization: New Jersey Institute of Technology

>In 1950, a
>processor had a control unit, a few registers and an ALU while a program had a
>simple routine to read cards, a simple routine to drive the printer, and a
>simple core algorithm.  Today, a processor had a control unit, a few registers
>and an ALU (note the less than radical change), while a program has a graphics
>interface, a file manager, a recovery scheme and a performance monitor in
>addition to the core algorithm.  There has been quite a deal of change in the
>tools and _functional_ capabilities of software systems.
>
Shouldn't you be taking the software program as a whole and the hardware
as a whole?  Saying the hardware today is just an ALU, registers and
memory is like saying all of today's software is an assignment, compare
and branch statement.  To compare your description of software today to
hardware today, try adding LRU caching, address lookaside buffers,
I/O processors, massive error detection and correction logic, ethernet
and other communication technology, paging, the entire virtual memory
schemes on a lot of machines, etc., etc, etc.
>  Lawrence Crowl                716-275-9499    University of Rochester
     
Kenneth Ng: ken@orion.bitnet
     
----------

From: gatech!rutgers!l.cc.purdue.edu!cik (Herman Rubin)
Summary: It is both primitive and decadent
Organization: Purdue University Statistics Department

Unfortunately, software technology seems concerned only with attempts to do a
highly restricted set of operations.  This has also recently gotten into 
hardware development.  I think that the ideas of the software and hardware
gurus can be likened to producing automobiles which can be programmed to
get you to an address you type in, but will not let you back the car out of
the garage into the driveway.  I suggest that the software developers first
consider the power of existing hardware, next the natural power of hardware
(what unrealized operations can be easily done in hardware but are not now
there), and finally the "current use."  FORTRAN, when it was produced, was
not intended for system subroutine libraries.  There are instruction present
on most machines which someone knowing the machine instructions will want to
use as a major part of a program, but which the HLL developers seem to ignore.

I suggest that a language intended for library development be approached by
the developers with the attitude that a machine cycle wasted is a personal
affront.  I think we will find that the resulting languages will be easier
to use and less artificial than the current ones.  Implementing an arbitrary
set of types is no more difficult for the user than the 5 or 6 that the
guru thinks of.  Allowing the user to put in his operations and specifying
their syntax is not much more difficult for the compiler than the present
situation.  For example, I consider it unreasonable to have any language
which does not allow fixed point arithmetic.  It may be said that this would
slow down the compiler.  However, every compiler I have had access to
is sufficiently slow and produces sufficiently bad code that it would be
hard to do worse.

I suggest that there be a major effort to produce an incomplete language
which is 
        1.  Not burdened by the obfuscated assembler terminology.

        2.  Easily extended by the user.

        3.  Designed with the idea that anything the user wants to do
should be efficiently representable in the extended language.

        4.  Restrictions on the use of machine resources should be as
non-existent as possible, and should be overridable by the user if at
all possible.  The restrictions on register usage in the C compilers
I have seen I consider a major felony.

        5.  Remember that the user knows what is wanted.  I hereby 
execrate any language designer who states "you don`t want to do that"
as either a religious fanatic or sub-human :-).  Those who say that
something should not be allowed because "it might get you into trouble"
I consider even worse.

        6.  Realize that efficient code does not necessarily take longer
to produce than inefficient, and that there are procedures which are not
now being used because the programmer can see that the resources available 
to him will make the program sufficiently slow that there is no point in
doing the programming.

I think that if a reasonable language were produced, we will see that there
will be a new era in algorithm development, and that the hackers will be
competing in producing efficient software.
-- 
Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907
Phone: (317)494-6054
hrubin@l.cc.purdue.edu (ARPA or UUCP) or hrubin@purccvm.bitnet

----------

From: gatech!rutgers!hao!boulder!utah-cs!shebs (Stanley T. Shebs)
Organization: PASS Research Group

In article <594@l.cc.purdue.edu> cik@l.cc.purdue.edu (Herman Rubin) writes:

>I suggest that there be a major effort to produce an incomplete language
>which is 
>        1.  Not burdened by the obfuscated assembler terminology.
>
>        2.  Easily extended by the user.
>
>        3.  Designed with the idea that anything the user wants to do
>should be efficiently representable in the extended language.

Sounds like you want Forth.

>        4.  Restrictions on the use of machine resources should be as
>non-existent as possible, and should be overridable by the user if at
>all possible.  The restrictions on register usage in the C compilers
>I have seen I consider a major felony.

There are reasons for those restrictions, as is clear from studying one
or two compilers.  Some registers are needed for implementing protocols,
particularly in function calling.  Other registers are used for constant
values (0, 1, -1 are popular).  You should try writing a register allocator
before engaging in name-calling.

>        5.  Remember that the user knows what is wanted.  I hereby 
>execrate any language designer who states "you don`t want to do that"
>as either a religious fanatic or sub-human :-).  Those who say that
>something should not be allowed because "it might get you into trouble"
>I consider even worse.

By your rationale, every language should include PEEK and POKE, and the
hardware shouldn't generate any of those silly "segmentation violation"
traps.  Lisp systems should allow the programmer to acquire the address
of an object, even if it will be worthless one millisecond later when the
garbage collector kicks in.  I hardly think a responsible language designer
would include a capability that has proven from experience to be a source
of catastrophic and mysterious bugs, especially if the capability itself
is not particularly important.
 
>        6.  Realize that efficient code does not necessarily take longer
>to produce than inefficient, [...]

Efficient code *will* take longer, if only because you have to spend time 
on profiling and analysis.  Of course, you might be lucky and write efficient
code on the first try, but it doesn't happen very often.

>I think that if a reasonable language were produced, we will see that there
>will be a new era in algorithm development, and that the hackers will be
>competing in producing efficient software.

The whole proposal sounds like something out of the 50s or 60s, when debates
raged over the value of "automatic programming systems" (like Fortran!).

It is interesting to note that the proposal omits what is probably the #1
reason for HLLs: PORTABILITY.  It's all well and good to talk about exploiting
the machine, but my tricky code to exploit pipelined floating point operations
on the Vax will be utterly worthless on a Cray.  The prospect of rewriting
all my programs every couple years, and maintaining versions for each sort
of hardware, would be enough to make me go work in another field!

In fact, the view that software should be independent of hardware is one of
the great achievements of software technology.  The battle of abstraction vs
specialization has been going on for a long time, and abstraction has won.
The victory is rather recent; even ten years ago it was still generally 
assumed that operating systems and language implementations had to be written
in assembly language...

>Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907

							stan shebs
							shebs@cs.utah.edu

----------

From: gatech!rutgers!mumble.cis.ohio-state.edu!karl (Karl Kleinpaste)
Reply-To: gatech!rutgers!tut.cis.ohio-state.edu!karl

crds@ncoast.UUCP writes:
   We have
   processors today which can out-run the processors of 1978 (10 years
   ago) by 20 to 1.  We have software today which can probably be
   out-run by the software of 1978, even when we use it on that
   powerful processor.  Sure, it's USER FRIENDLY, ERGONOMIC, etc., but
   does it keep pace with the advances in the industry?  Why don't I
   see ANY software advances that are even an order of magnitude above
   1978?  This would give me 200 times the power, considering the
   advances in hardware!!

In watching this discussion, it seems the only metric which people
want to apply to software is performance.  Raw performance, how many
widgets can you prefrobnicate in minimal picoseconds.  It seems to me
that this is not the right way to view software.

Aside from the fundamental problems of P?=?NP and similar questions, I
tend not to like looking at software from the sole standpoint of how
fast it goes.  Yes, speed is important - anything written by a
programmer should be designed to be fast, as fast as possible.  I
think I do much more than an adequate job of that in the code I write.
But I am not looking for pure speed in what I design; I am also
looking for new functions, new capabilities, a different way of doing
something, a different way of looking at an old problem.

Consider the case of bit-mapped window displays.  The hardware to
implement them is relatively simple.  A largish memory, an ability to
move large bit patterns fast, possibly a dedicated co-processor for
managing the whole beast.  The rest is software.  I think this is an
excellent example of a wonderful marriage between advances in hardware
and software.  Hardware provided the ability to do something in new
software.  The new software provides new capabilities and new power
for the user of the whole package.

Now consider the resulting power of that package.  I'm sitting in
front of a Sun3 using X.  The hardware provided here is exactly what
is needed to support the software concepts required.  But to me, the
resulting power of this box is really embodied in what the software is
doing.  On my screen right now, there are 10 windows.  All of them are
doing useful things.  Granted, some of them are not doing very
interesting things; I have an analog clock in one corner, and two load
meters in another.  But that still leaves 7 other windows doing real,
vital, practical work.  Even those two load meters are vital to my
work, because it's those meters that I will be watching to see if
something causes a performance spike, and that will cue me to go look
at the indicated system to see what's going wrong.  So in practical
terms, I have 9 simultaneous activities going on which are of value to
me.

That's roughly an order of magnitude improvement over the days of
1978, when I sat in front of a dumb CRT, connected to exactly one
system, doing exactly one thing.  The parallelism inherent in my brain
is being put to positive use.  I didn't even need parallel hardware to
do it.  An approximation of parallelism through timesharing is
sufficient for my mind to fill in the remaining gap.

I am not attacking or denigrating the advances in hardware in any way
whatever.  (My graduate work was in software performance increases,
after all, trying to take better advantage of existing recent hardware
improvements.)  But I think that software has come rather a long way
in the last 10 years.  It just hasn't come to us in terms of raw
performance.  It's exactly those areas of user-friendliness,
ergonomics, and expanded user capability that provide the final
improvement in the real power of the machine.
-=-
Karl

----------

From: gatech!rutgers!cs.rochester.edu!crowl (Lawrence Crowl)
Organization: U of Rochester, CS Dept, Rochester, NY

In article <594@l.cc.purdue.edu> cik@l.cc.purdue.edu (Herman Rubin) writes:
>I suggest that the software developers first consider the power of existing
>hardware, next the natural power of hardware (what unrealized operations can
>be easily done in hardware but are not now there), and finally the "current
>use."

No, software developers should first consider the task to be solved.  The 
efficient use of the hardware is moot if the software does not meet the need.

>There are instruction present on most machines which someone knowing the
>machine instructions will want to use as a major part of a program, but which
>the HLL developers seem to ignore.  

The task of language developers is not (or should not be) to directly support
the hardware, but to provide an environment in which a programmer can
effectively express the solution to a problem.  In those cases where efficiency
matters, the language model is generally chosen to be efficiently realized on
conventional machines.  Catering to specific instructions on specific machines
is generally a loss because the resulting programs are useful only on that
machine.  Supporting common instructions directly in the language often means
presenting an inconsistent model.  For instance, the arithmetic right shift
provided by many machines provides division by two except when the number is
negative and odd.  Should languages be designed around this quirk?  I do not
think so.

>I suggest that a language intended for library development be approached by
>the developers with the attitude that a machine cycle wasted is a personal
>affront.  I think we will find that the resulting languages will be easier
>to use and less artificial than the current ones.

I think that just the opposite is true.  Designing a language around
optimizing the use of a specific machine is likely to leave a language so
riddled with special case restrictions as to be hopelessly complex.

>Implementing an arbitrary set of types is no more difficult for the user than
>the 5 or 6 that the guru thinks of.

Who implements the arbitrary set of types?  The user?  The language designer?
If the language provides mechanisms to allow the user to implement types, then
the task of the language implementer is only difficult.  There are many issues
in value instantiation, etc. which must be delt with in a language that allows
definition of arbitrary types.  If the implementer must implement the arbitrary
set of types, then the task is impossible.

>Allowing the user to put in his operations and specifying their syntax is not
>much more difficult for the compiler than the present situation.

User modifiable syntax is a very difficult to define consistently and very
difficult to parse.  The consensus so far appears to be that it is not worth
the cost.

>For example, I consider it unreasonable to have any language which does not
>allow fixed point arithmetic.  It may be said that this would slow down the
>compiler.  However, every compiler I have had access to is sufficiently slow
>and produces sufficiently bad code that it would be hard to do worse.

If the target audience of the language does not need fixed point arithmetic,
the introduction of a fixed point type is counter productive.  How many
compilers have you looked at?  Some produce very good code.  Others are
atrocious.  It is far easier to criticize code generators than to provide a
generator that produces better code.

>I suggest that there be a major effort to produce an incomplete language
>which is 
>        1.  Not burdened by the obfuscated assembler terminology.

We already have this.

>        2.  Easily extended by the user.

What do you mean by "extended".  Different notions have different costs and
benefits.

>        3.  Designed with the idea that anything the user wants to do should
>be efficiently representable in the extended language.

What do you mean?  Is the resulting representation efficient with respect to
execution time?  Is the resulting representation efficient with respect to
run-time storage requirements?  Is the representation of what the user wants
concisely represented in the source?  Choosing one of these options might lead
one to design C, Forth or Prolog, respectively.

>        4.  Restrictions on the use of machine resources should be as
>non-existent as possible, and should be overridable by the user if at all
>possible.  The restrictions on register usage in the C compilers I have seen I
>consider a major felony.

Many such restrictions are present to allow the resulting programs to be
time efficient.  This requirement is in conflict with what I suspect you want
for point 3 above.

>        5.  Remember that the user knows what is wanted.  I hereby execrate
>any language designer who states "you don`t want to do that" as either a
>religious fanatic or sub-human :-).  Those who say that something should not
>be allowed because "it might get you into trouble" I consider even worse.

The user may know what is wanted, but translating that into code is not always
a simple task.  Consider assigning a boolean value to an integer.  Is this
something that "the user knows what he's doing" and the language should accept,
or is it something that "the user doesn't want to do" and may "get him in
trouble"?  Almost always it is not what the user wants.  If it is what the
user wants, the result is usually a non-portable, difficult-to-understand
program.  (The management usually does not want the latter even if the
programmer does.)

>        6.  Realize that efficient code does not necessarily take longer to
>produce than inefficient, ...

True, but the one in a thousand cases where this is true don't help much.
Efficient code almost always takes longer to produce than inefficient code.
You must invenst development time to get efficiency.

>... and that there are procedures which are not now being used because the
>programmer can see that the resources available to him will make the program
>sufficiently slow that there is no point in doing the programming.

If that is the case, the procedure was either not worth much to begin with,
or not within the bounds of feasible computations given today's hardware.

>I think that if a reasonable language were produced, we will see that there
>will be a new era in algorithm development, and that the hackers will be
>competing in producing efficient software.

Algorithm development is independent of any specific language, so a new
language will probably have little affect on algorithms.  Hackers are already
competing in producing efficient software, so a new language will have little
affect here also.

>Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907
-- 
  Lawrence Crowl		716-275-9499	University of Rochester
		      crowl@cs.rochester.edu	Computer Science Department
...!{allegra,decvax,rutgers}!rochester!crowl	Rochester, New York,  14627

----------

From: gatech!rutgers!hao!boulder!utah-cs!shebs (Stanley T. Shebs)
Organization: PASS Research Group

In article <596@l.cc.purdue.edu> cik@l.cc.purdue.edu (Herman Rubin) writes:
>In article <3603@sol.ARPA>, crowl@cs.rochester.edu (Lawrence Crowl) writes:
>> In article <594@l.cc.purdue.edu> cik@l.cc.purdue.edu (Herman Rubin) writes:

><< I suggest that the software developers first consider the power of existing
><< hardware, next the natural power of hardware (what unrealized operations can
><< be easily done in hardware but are not now there), and finally the "current
><< use."
>> 
>> No, software developers should first consider the task to be solved.  The 
>> efficient use of the hardware is moot if the software does not meet the need.
>
>Which of the tasks to be solved should the software developer consider?  On one
>machine there may be hundreds or even tens of thousands of users.  Some of
>these users may have dozens of different types of problems.  

Then the software developer has dozens of tens of thousands of tasks to solve!
There aren't enough software people in the world to solve each problem in an
individual and idiosyncratic fashion, so instead several tasks are decreed to
be "similar", which really means that some compromises have to be made.
This situation is not unique to software.  For example, bridge designers don't
usually get new and unique rivets for each bridge - instead, they have to order
from a catalog.

Everybody wants every one of their programs to be maximally efficient on all
imaginable hardware, while at the same time spitting on programmers because
it doesn't happen at the press of a couple keys.  It's unfortunate that the
popular culture encourages the belief that hackers can conjure up complicated
programs in a few seconds.  I suspect it even influences people who should
know better.  To quote Fred Brooks, "there is no silver bullet".

>And should we use the same algorithm on different machines?
>I, for one, would question the intelligence
>of those who would attempt to enforce such restrictions.

I find it interesting that the people who have been programming the longest -
numerical analysts - are exactly those who use dozens of different algorithms
to solve the same problem, each with slightly different characteristics.
Could mean either that multiplicity of algorithms is coming to the rest of
computing soon, or that numerical analysts haven't yet found the correct forms
for their algorithms...

>> User modifiable syntax is a very difficult to define consistently and very
>> difficult to parse.  The consensus so far appears to be that it is not worth
>> the cost.
>> 
>If the syntax is somewhat limited, it will still be very powerful and not so
>difficult to parse.  The reason that the typical assembler language is so 
>difficult to use is due to the parsing difficulty 35 years ago.  Except for
>not using types, Cray's assembler constructs on the CDC6x00 and on the CRAY's
>go far in the right direction.

I think you would have a hard time proving that the minor syntactic 
improvements of the Cray assembly language (with which I am familiar)
have any effect at all on productivity, reliability, etc.  After all, Lisp
programmers can be immensely productive even though the assignment statement
has a verbose prefix (!) syntax.

>Who is the target audience?  There is no adequate language for the production
>of library subroutines.

Aha!  I wondered if that was the motivation for the original posting...
You have touched upon my thesis topic; but you will not have to die for it :-).
My thesis is most directly concerned with the implementation of Lisp runtime
systems, which have many similarities to Fortran libraries (really).
The basic angle is to supply formal definitions of the desired functionality
and the hardware, then to use an rule-based system to invent and analyze
designs.  Not very intelligent as of yet, but I have hopes...

Of course, this approach involves a couple assumptions:

1. As you say, there is no "adequate" language for the production of library
subroutines.  After poking through the literature, it is pretty clear to me
that no one has *ever* designed a high-level language that also allows direct
access to different kinds of hardware.  There are reasons to believe that such
a beast is logically impossible.  The output of my system is machine-specific
assembly language.

2. I also assume that human coding expertise can be embodied in machines.
What compilers can do today would have amazed assembly language programmers
of 30 years ago.  There is no reason to believe that progress in this area
will encounter some fundamental limitation.  I've seen some recent papers (on
the implementation of abstract data types using rewrite rules) that still seem
like magic to me, so certainly more advances are coming along.  Closer to
reality are some compiler projects that attempt to figure out optimal code
generation using a description of the target machine.  This is extremely
hard, since machine "quirks" are usually more like machine "brain damage".

>The user should be able to introduce type definitions (structures in C), new
>operators (such as the very important &~, which may or may not compile
>correctly), and overload old operators.  This should be very flexible.

Take a look at HAL/S, which is a "high-level assembly language" used in the
space shuttle computers.  Allows very tight control over how the machine
code will come out.  In fact, there are probably a few people reading this
group who could offer a few choice comments on it...

><<         3.  Designed with the idea that anything the user wants to do should
><< be efficiently representable in the extended language.
>> 
>> What do you mean?  Is the resulting representation efficient with respect to
>> execution time?  Is the resulting representation efficient with respect to
>> run-time storage requirements?  Is the representation of what the user wants
>> concisely represented in the source?  Choosing one of these options might lead
>> one to design C, Forth or Prolog, respectively.
>> 
>First execution time, second storage.  I do not advocate obfuscated code to 
>attain this, and I do not believe it is necessary.  None of the languages you
>have cited meet any of my points.

What's wrong with Forth?  It can be extended in any way you like, it can be
adapted to specific machine architectures, the syntax is better than raw
assembly language, and its compilers don't do awful things behind the user's
back.  You'll have to be more specific on how it fails.  I agree with you that
C and Prolog cannot always be adapted to machine peculiarities.

>The VAX has twelve general-purpose registers available.  If I write a program
>which uses eleven registers, I object to the compiler, which does not need any
>registers for other purposes, only giving me six.

How do you know it "does not need any registers for other purposes"?  Are you
familiar with the compiler's code generators and optimizers?  Writers of code
generators/optimizers tend to be much more knowledgeable about machine
characteristics than any user, if for no other reason than that they get the
accurate hardware performance data that the customers never see...

>An obvious example of this is [...] the denial of such
>simple elegant ideas as goto.

"Goto" is neither simple nor elegant on parallel machines.

>The bit-efficient algorithm above starts out
>with a case structure; I immediately observed that, by 99.999% of the time
>keeping the case as a location only and using goto's, the code would be
>considerably speeded up without any loss of clarity.

OK, this is the time to use assembly language.  What's the problem with that?
It's the accepted technique; no one will fault you for it.

>> Efficient code almost always takes longer to produce than inefficient code.
>> You must invenst development time to get efficiency.
>> 
>This is because of the badness of the languages.  I do not mean completely
>efficient code is easy to produce, but I thik that 80% to 90% will not be
>that hard to get.

(I assume 80-90% of optimal is meant)
You had better come up with some hard evidence for that.  Various computer
scientists have been trying to prove for years that the right language, or 
the right method, or the right environment, or the right mathematics will
make efficient programming "easy".  So far no one has succeeded, but the
journals are full of polemic and anecdotes masquerading as scholarly work.
It's really depressing sometimes.

No silver bullet...

><< Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907
>>   Lawrence Crowl		716-275-9499	University of Rochester
>Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907

							stan shebs
							shebs@cs.utah.edu

----------

From: gatech!rutgers!uunet!ateng!chip (Chip Salzenberg)
Subject: Re: software ICs vs. libraries
Organization: A.T. Engineering, Tampa, FL

In article <5606@jade.BERKELEY.EDU> adamj@widow.berkeley.edu (Adam J. Richter) writes:
>In article <1691@culdev1.UUCP> drw@culdev1.UUCP (Dale Worley) writes:
>>Another feature of "software ICs" comes from the fact that they are
>>part of an object-oriented system.  One can actually write, say, a
>>linked list manager that will work on objects of *any* type.
>
>	"Object oriented?"  What you are describing involves
>parameteized typing and polymorphic routines.

Not so.  Objective-C supports _heterogoneous_ collections.  For example, a
single Set can hold another Set, a Dictionary, an Array, and any number of
other types -- _simultaneously_.

-- 
Chip Salzenberg         "chip@ateng.UUCP"  or  "{uunet,usfvax2}!ateng!chip"
A.T. Engineering        My employer's opinions are not mine, but these are.
   "Gentlemen, your work today has been outstanding.  I intend to recommend
   you all for promotion -- in whatever fleet we end up serving."   - JTK

----------

From: gatech!rutgers!ll-xn!culdev1!drw (Dale Worley)
Subject: software ICs vs. libraries
Organization: Cullinet Software, Westwood, MA, USA

chip@ateng.UUCP (Chip Salzenberg) writes:
| Objective-C supports _heterogoneous_ collections.  For example, a
| single Set can hold another Set, a Dictionary, an Array, and any number of
| other types -- _simultaneously_.

The other important feature that object-oriented systems need
(Objective-C has it, I don't know of C++ does) is that one can build
two objects that present the same external interface, but for which
the method-routines are different.  I.e., I can have two different
sorts of "dictionary", implemented differently, and the code that uses
them can't tell the difference between them.  (This is why you need
run-time mapping from method-names to routines.)

Dale
-- 
Dale Worley    Cullinet Software      ARPA: culdev1!drw@eddie.mit.edu
UUCP: ...!seismo!harvard!mit-eddie!culdev1!drw
If you get fed twice a day, how bad can life be?