🚀 go-pugleaf

>>When I see a language, the corresponding question is
>>whether the designers have provided a way for me to use the hardware instruc-
>>tions, and how easy and convenient it is for me to do that.
>
>In other words:  when you look at a language, you look to see how low a
>level it is and how easy and convenient it is for you to hand optimise
>in it.  This doesn't sound like you want a *high* level language to me.

What is the purpose of language? To specify good code on a PDP-11 or good
code on the machine in use? Postdecrement and postincrement operators are
horrendous on a RISC. The lack of a boolean mode and the requirement that
&& and || shortcircuit are horrendous on a RISC. On the other hand, the
machine I use has a (32 int)*(32 int)=(64 int) instruction which C does not
provide for.

I feel the language should provide access to every instruction the hardware
provides. Programmers can then abstract out machine independent operators
if they wish. A good extensible language would permit infix operators to be
defined as the programmer sees fit.
 
>Don't you mean NON-portable software?  To me, semi-portable software
>means that the machine-dependent parts are isolated and that's all that
>has to be changed when porting to a different machine.  With your
>ideas, the machine-dependent parts would be tightly integrated with the
>rest of the software; this is what makes porting a nightmare.

So what? It's not that job of language designer (except, of course, Wirth, from
whom all blessings flow) to decide what is good and bad programming--just make
good tools. Give programmers direct access to the machine so they can be honest
about writing machine dependent code. Give them good abstraction facilities so
they encapsulate it if they desire.

>>the C gurus came up with the idea of saying, "Nobody uses this, so we will use
>>it for exclusive or."
>
>What would you have chosen for xor, considering a very limited
>keyboard, and that most of the other symbols were taken?  C was created

How about `xor' `|-' `+|' .... ?

>>This is similar to the use of \ for an escape character.
>
>I pose the same question as above.  And remember, the escape character
>should be one character, be printable, and the ESC key did not exist on
>most keyboards at the time.

Other language have other solutions which do not use any escape. In fact,
nearly every other language.

>>This is a major bone of contention and interpretation.  I consider that
>>a binary operator function normally uses an infix symbol.
>
>Who invented the f(x,y) syntax anyway?  It sure wasn't the computer
>gurus.  Prefix notation is extendable (arbitrary number of arguments),
>infix is not (well, not easily).  And quite frequently I find myself
>having to add another parameter to a function when I try to generalize
>it.  This would be very difficult to do with infix notation.

Ever see Smalltalk? Postfix and infix notation, and that's it. No prefixes,
no functional notations. From what I've seen of Smalltalk, it's easier to
understand than C. How about
     calculus integrate:f from:l to:U
instead of
     (*calculus.integrate)(f,l,u)

Have you ever seen calls with dozens of arguments? How do you know what each
argument stands for? Algol60 had a neat feature (inspired Smalltalk?):
      integrate(f) from:(l) to:(u)

>>What do you think the reaction of HLL users
>>would be if you required them to write addint(x,y) for x+y if one wanted
>>to add the integers x and y?
>
>Many already do.  It occurs in a very old language; a language about as
>old as FORTRAN.  It's call LISP.

LISP is the primary language of numerical analysis, after all.

>>in addition to the usual operations.  I maintain that any acceptable language
>>should allow such additions, including the temporary addition of infix
>>functions, if necessary.
>
>Then WRITE a language, and show us that this is indeed better.

And if you don't like the operating system, write a new one. Same with device
drivers. Same with cpu. Same with disc drives. God forbid someone who is a tad
more expert might help out.

>>A simple example is division, with quotient and
>>remainder.  Another example is that one frequently wants both the sine and
>>cosine; it is only about 30% more expensive to produce both of them simul-
>>taneously than to produce one.
>
>A LOT of overhead if you only need one.

Even more overhead if you want both and someone decided for you you need to
make to calls.
 
>And why should a programmer programming in a HLL care whether these can
>be performed simultaneously.  He specifies what he needs in the HLL,

If the HLL permits it to be specified.

>and the compiler is supposed to generate the best possible machine code
>for doing that.  If the compiler isn't doing that you should be
>complaining about the implementation, not the language.  Neither of

Oh, c'mon. If the programmer is forced to write incredibly complicated code
because someone decided an operation is unnecessary, do you really expect
any compiler to decode what is happenning and produce efficient results.

That's like putting up fence on a path, making people walk way around, and
then assuming it will be as if the fence did not exist.
 
>@I just did some find/sed/grep hacking to find out just how prevalent
>@cross-posting is.
>
>@Here are the people who cross-posted to five groups:
>@, Herman Rubin,
>
>Congratulations!

Well, that's certainly addressing the issue. If you can't dispute the
message, sacrafice the messenger.