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

On Feb 20, 2009, at 10:00 AM, Joe Bowbeer wrote:

> Backing up a bit, to this question:
>
>> So would you rather see the typical Pascal if-then-else statement  
>> or "fun1
> fun2 arg if-else" ?
>
> Even when faced with reasoned arguments about the simplicity and  
> utility of
> the post-fix syntax on the right, almost everyone (outside of this  
> list)
> would rather see Pascal.  For many people, in fact, the syntax on  
> the right
> is a non-starter.
>
> 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.

So true. Let's think about the syntax question a bit. Most people seem
to prefer infix to either prefix or postfix when it comes to writing  
down
an algorithm. We are trained from a very early age to write a + b + c
instead of either (+ a b c) or a b + c +, or its equivalent a b c + +.

However, we don't *think* or *speak* that way. We say "Here's a list
of numbers, add them up (postfix) or "Add a to b" (prefix).

Each method has its advantages and disadvantages. For example,
prefix can add more than two numbers in one command, but it also
needs parens to delimit the list.

Infix is eminently readable due to our early education but it requires
a more complicated compiler.

Postfix gets rid of the parens and simplifies its compiler) but loses
readability due to our infix mindset.

What I notice in this is that the main disadvantage of postfix is only
in our minds while the other disadvantages are real and measurable.

When Forth was first made public in the early '70s, I had the same
sort of negative reaction to its postfix syntax. But other things about
it were so intriguing, such as being able to put an entire multitasking
OS in 8K of memory, that I stuck with it long enough to overcome my
initial aversion to the syntax. What I got in return was a marvelous
tool for solving certain kinds of problems.

And, I haven't been corrupted, I can still work in infix whenever
necessary ;-)
--
don


> However, if you change the conditions, by saying, for example, that  
> this
> language is to be used for on-device programming of an iPhone, where  
> the
> screen is small and typing is relatively awkward, then you might get a
> different answer.  (How many remember programming those old HP  
> calculators?)
>
> By the way, I think my analogies with natural language are flawed.
> Shorthand is too harsh, I think, and Textese (SMS chatspeak) is not  
> harsh
> enough.
>
> Joe
>
>
> On Fri, Feb 20, 2009 at 8:36 AM, William Tanksley wrote:
>
>> Joe Bowbeer wrote:
>>> Don Groves wrote:
>>>> Once used to this way of actually forgetting about all the
>>>> syntax crap, it becomes just as readable, and far more
>>>> succinct than any Pascal-like language.
>>> Can the same be said of shorthand w.r.t. natural language?  (
>>> http://en.wikipedia.org/wiki/Shorthand)
>>
>> I'm not sure.
>>
>>> 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.
>>
>> 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.
>>
>> 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).
>>
>> Actual human languages are parseable by a structure known as a
>> "unification grammar" (to one extent or another), but defining a
>> unification grammar takes a LOT of work, and is immensely slow to  
>> parse
>> (currently). In addition, the linguistic features of unification
>> grammars lend themselves poorly to directing machines -- for example,
>> ambiguity and multiple meanings are inherent.
>>
>>> Joe
>>
>> -Wm
>
>
> [Non-text portions of this message have been removed]
>
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>