just to correct a basic fact, the size of the instruction set doesn't
define RISC instruction set (http://en.wikipedia.org/wiki/RISC
"instruction set size").
Heh. I did refer to exactly that article and consequently inserted "adding
to the complexity of each primitive" as well as the modifier "strictly."
can you cite any references that claim that the size of intel's
instruction set has contributed to its success?
Try the Wikipedia article on CISC which really isn't a source, I admit. The
general impression is that not only the total number, and diversity, of the
instruction set but how much is done using a single instruction from the
viewpoint of a programmer/compiler have a role there. How a CISC
instruction set is implemented is besides this point. Some translation may
take place in the process but it doesn't matter as long as it is
transparent to the programmer/compiler.
could it be that since transistors are very cheep, adding instructions is
simply the cheapest go-faster trick?
Could be exactly that and further confirm my stance that added complexity,
when it is carefully hidden and is exposed to the middle user only as a
variety of orthogonal options, does not result in a bad system. In can
actually result in a better system. I'm, of course, not claiming that the
x86 instruction set represents an epitome of orthogonality or good design.
what is a middle user? and why would such a person be
discouraged by having to learn fewer things? does the myriad
of different ways to write an if statement in perl make it more
useable? readable?
A middle user is someone who uses your product to create another product
for an end user who very often doesn't create product on their own,
although that may not be the case. A programmer who uses the language and
compiler you designed, or the OS you created, or the API you developed.
Having to learn fewer things is not discouraging, lack of expressiveness
due to lack of options can be. In case of Perl its popularity establishes
its merit for the area in which it is popular. Besides, we aren't talking
about if redundancy makes a system more expressive (it could but we aren't
talking about that), we are rather talking about addition of options that
are orthogonal to existing ones: options that have no equivalent.
A callback infrastructure can be created in user land using threading but
that would have two disadvantages: the very point of lowering initial cost
using callback strategy is made moot, and people will tend to disagree on
how that extra infrastructure should look like so a variety of
incompatible, highly redundant implementations will pop up.
i don't see how progress == complicated. could you explain
how they are one and the same?
as a counter example, unix uses untyped files. not only does
lack of typing make the system simplier, it makes it more expressive
as well.
I don't see how complex == complicated. You could have a very sophisticated
system at hand that is rather easy to program. Increasing adaptivity
through increased complexity is one well-known evolutionary path. The other
well-known path is increasing resilience through decreased complexity.
There is a point where resilience and adaptivity are just at the balance
you desire for your audience. Making clear who your audience is should
clear this problem as well.
Regarding your example I believe you are mixing redundancy with choice.
While I could even argue for some redundancy I'm not trying to do so. File
typing, as seen on Apple systems, is not orthogonal to other features
already present in those systems; it is redundant. Windows does not have
any file typing similar to Apple's. UNIX-like systems do make some
distinctions between files which have become rather blurry with time. I
brought up the the subject in my awkward manner some time ago when caching
9P was being discussed on the list. It seemed to me that a form of typing
that expressed at a reasonable level of detail the amenability of files to
various caching strategies could have improved the situation of 9P caching.
i don't see how a wage-earning programmer can't be a researcher as well.
and being a wage-earning programmer, i appreciate simplicity and use
it to advantage on a daily basis.
The vast majority of them aren't. That's a fact of life. You appreciate
simplicity because you happen to work on a specific application for which
your target system's API is exceptionally well-rounded. Try designing a
complex UI for some CAD software and tell me how amenable your simple
system is to that purpose. The platforms targeted for, say, creating the
frontend to a CAD system are not chosen by luck really. They have been made
suitable by designers to that and other purposes. Adding of orthogonal
options, when done wisely, should not take away or negatively affect the
core primitives you use and are content with.
several times, i've needed to get a particular bit of h/w working.
given a choice, i go with the one with the thinner manual.
I bet a 8051's manual is thinner that a 80x86's. Does that mean the 8051
will be your platform of choice when it absolutely does not cut the task? I
think it's somebody's motto: simple enough, but no(t) simpler.
--On Thursday, June 11, 2009 19:41 -0400 erik quanstrom
<quans...@quanstro.net> wrote:
> i think you're trying to argue that — a priori — choice is good?
I believe it is. How many of us are using strictly RISC machines on our
desks today? Extending the set of available primitives and adding to the
complexity of each primitive both are natural steps in the development
of computer systems as they see more use.
just to correct a basic fact, the size of the instruction set doesn't
define RISC instruction set (http://en.wikipedia.org/wiki/RISC
"instruction set size").
can you cite any references that claim that the size of intel's
instruction set has contributed to its success?
could it be that since transistors are very cheep, adding instructions is
simply the cheapest go-faster trick?
Limiting options doesn't seem to me
to be an effective way of encouraging good programming practice. It can,
however, successfully discourage potential middle users.
what is a middle user? and why would such a person be
discouraged by having to learn fewer things? does the myriad
of different ways to write an if statement in perl make it more
useable? readable?
> that's not the position i subscribe to. and since plan 9
> is simple and easy to change, it makes an ideal system
> for someone who wants to try new things.
And after the new things are tried out and, one may hope, proven
advantageous? I think the next step would be incorporating them into the
system. A process that in due time will make the system less simple and
easy to change but more immediately useful.
i don't see how progress == complicated. could you explain
how they are one and the same?
as a counter example, unix uses untyped files. not only does
lack of typing make the system simplier, it makes it more expressive
as well.
I see this more as a difference of intended audience than a difference
of taste or philosophy. The real question is whom (sic) you imagine as
your system's middle user: a wage-earning programmer or a researcher.
Were I a programmer who worked for pay I'd very much appreciate being
given every possible option that would let me do my job easier, faster,
and, of course, more properly.
i don't see how a wage-earning programmer can't be a researcher as well.
and being a wage-earning programmer, i appreciate simplicity and use
it to advantage on a daily basis.
several times, i've needed to get a particular bit of h/w working.
given a choice, i go with the one with the thinner manual.
- erik
