Re: [stack] Advantages of cat, joy ..?

>> In practice, I think a lot of the extra surface area (redundancy,
>> delimiters, grammatical rules) that is built into popular programming
>> languages (as well as natural writing systems), is there to serve the human
>> mind.

Yes, of course, and what could be more important ?

William Tanksley wrote:
>That's unlikely. Yes, some of those features were deliberately
>chosen; but most of them were 'chosen' for other reasons than
>"because it's efficient for humans". Ease of parsing drove
>Pascal's design; it's now clear that Pascal's strength is its
>simplicity, not its particular choice of parsers.

Yes, ease of parsing too was more important then. IMO it's irrelevant
today. OTOH I was amazed how long a linux [C] pakage takes to compile.
The bloke who tried Oberon [the Pascal descendant] for the first time,
said he though the compiler was broken, because it just returned --
finished the job < 1sec.

>Lojban is a constructed language that was designed "entirely"
>from scratch in order to be easily learned and unambiguous. One
>of the design choices was to make it easily parsed, and
>the implementor chose to make the language defined by an
>LL grammar. The result has been catastrophic: in spite of a
>reasonably strong community, not one person has EVER achieved
>fluency in lojban (according to the community-acclaimed best
>speaker).

! This amazes and disturbs me ! OTOH, let's not confuse short
term [30 years] populatity with technical excellence.
Look how popular it was for the herd to gamble with their
credit cards.
---------

OK, reading further is this tread, I realise there's been a big
misunderstanding, I agree 'natural languages are the worst disaster
ito [in terms of] complexity. I meant that we should build on
the existing human/sociatal assets, eg.:
* use already existing knowledge - call a 'tail' a "tail" and not
   a "cdr"
* work left to right, top to bottom:
  '7 -> counter' is better than counter := 7
* iteration is more 'natural' than recursion - all things being
   equal ..........

>>As Lojban reminds us, reasoned arguments do little to change people's
>>preferences. As the old saying goes: in matters of taste, there's no
>>argument.

>Not so much. There are a LOT of people totally convinced by
>Lojban at one time or another. My point was that in spite of
>being convinced, they still couldn't learn Lojban up to the
>point of fluency.


'people convinced' or the SCIENTISTS who researched and designed it ?
Finding the reason for its purported failure could make some PhDs ?

BTW-related, I've got this further 'quirk' related to minimalist
menu-driven programming: the same for natural languages - menu
driven canonical form composer, which gives output in any
languages. Firstly think of existing 'aviation talk' with syntax:
1. who I'm calling; 2, who I AM, 3. Where I AM, 4. What I want.

So a valid mesg. would be:--
1. Brakpan ground control,
2. bravo tango lima,
3. approaching your airfiel from the south at 7'500 feet,
4. requesting permission to join the circuit.

You can't write poetry, but you could 'ask when the next bus
arrives from X' in Korean or Zulu ?
BTW. related: did any body ever understand the 'fractal thicket'?

Don Groves wrote:-
>Infix is eminently readable due to our early education but it
>requires a more complicated compiler.

Yes but as stated the compiler cost is irrelevant compared to human
effort cost - these days.  I'd rather pay the compiler to push &
pop, than do it myself.
--------------------
John Nowak wrote:

>Joy's syntax makes algebraic manipulation very easy.

Is the data easily manipulatable or the 'programs
structure transformable to prove its correctness' ?

>Such qualities aren't subjective or matters of taste.

Yes there are objective metrics.
----------------
Stevan Apter gave valuable insight to his subjective view
 of PLs:

>syntax is as important to me as it is to the next guy, but other
>characteristics of PLs matter more, chief among them being how
>many new concepts i'm required to master before i can use the
>language well.

Yes! And menu/prompts help tremendously too ?

>when i'm programming, all my thinking takes place within a very
>simple framework: find a data representation for my problem,
>then find the best set of functions which transform these
>representations to solve my problem. r <- f[a;...;z]. iterate
>until done.

I like that:
  InitialData -->f[a;...;z]--> Solution

Perhaps cat-languages enable easy moving/transforming the
data through the process; like:

IF ( (NextToken(MaxOf(BlueOnes) - NextToken(AveOf(RedOnes) < 5) THEN
   becomes [not in postfix form]:-
BlueOnes > MaxOf > NextToken ; RedOnes > AveOf > NextToken ...etc?
It seems that you MUST think of 'temporarily storeing/stacking'
NextToken(MaxOf(BlueOnes); so you can't escape stack-shuffling.

With procedural languages, you 'leave NextToken(MaxOf(BlueOnes)'
in the source code, and the compiler does the stack-shuffling.

But AFAI-can-see the problem concept/statement is 'nested'
that's why natural languages must handles 'nested concepts',
so the PL must also handle nesting. So stack-push/pop is
inevitable. But I want to off-load as much metal work to
the compiler.

OK, it seems difficult to get away from postfix.

Thanks,

== Chris Glur.