Fri, 6 Feb 2015 00:05:39 +0000 (UTC)

Related articles |
---|

Choosing a parser for Mathematica input drkirkby@gmail.com (David Kirkby) (2010-11-07) |

Re: Choosing a parser for Mathematica input fateman@gmail.com (2015-02-05) |

parsability (was: Choosing a parser for Mathematica input) gah@ugcs.caltech.edu (glen herrmannsfeldt) (2015-02-06) |

Re: parsability and human factors derek@_NOSPAM_knosof.co.uk (Derek M. Jones) (2015-02-07) |

Re: parsability and human factors gah@ugcs.caltech.edu (glen herrmannsfeldt) (2015-02-08) |

Re: parsability robin51@dodo.com.au (Robin Vowels) (2015-02-09) |

Re: parsability DrDiettrich1@netscape.net (Hans-Peter Diettrich) (2015-02-08) |

Re: parsability news@iecc.com (2015-02-09) |

Re: parsability and human factors derek@_NOSPAM_knosof.co.uk (Derek M. Jones) (2015-02-10) |

From: | glen herrmannsfeldt <gah@ugcs.caltech.edu> |

Newsgroups: | comp.compilers |

Date: | Fri, 6 Feb 2015 00:05:39 +0000 (UTC) |

Organization: | Aioe.org NNTP Server |

References: | 10-11-017 15-02-009 |

Keywords: | parse, design |

Posted-Date: | 06 Feb 2015 22:15:43 EST |

fateman@gmail.com wrote:

*> Hi, comp.compiler guys.*

*> I came across this thread while googling for something I wrote;*

*> found this thread with stuff written about me.. It's a bit stale but*

*> if David Kirby wants a Mathematica clone, he should look at Mathics.*

*> Regarding the difficult of parsing the Mathematica language, he misses*

*> the point, I think. By the way, after conducting a worldwide search*

*> for a better name for the language-minus-the-math-library, Stephen*

*> Wolfram chose, tada, "The Wolfram Language".*

It seems that most computer languages are designed to be easy to parse

by programs, but not for ease of use by people.

When computers were smaller and slower, that might have made sense,

but for the computers we have today, making it easier for people

should come first.

I went to a talk, not so long ago, by someone actually studying people

using computer languages. It seems that many people who write papers

about how easy or hard they are to use don't actually do any tests

with real people.

*> Anyway the difficulty isn't parsing x //f to get f(x). It is in the*

*> separation of lexical and syntactic uses of characters like "." which have*

*> multiple uses.*

*> a.3 is Dot[a,3]. a .3 is Times[0.3, a]. And the difficulty with using*

*> "space"*

*> or merely adjacency for multiplication is not resolved by asserting that*

*> mathematicians use it all the time.*

Interesting that when we learn multiplication in 3rd grade, we learn

the x operator for it, but then when we learn algebra we expect

adjacent terms to be multiplied without any operator. Mathematicians

have been doing that for centuries.

Though there is the compilication of multiple character symbolic

names, which mathematicians seem still not to have adopted.

*> I have written papers and email in which I am critical of Mathematica.*

*> I have also written programs that are partial implementations of that program*

*> but with illustrative changes showing (in my view) better design decisions.*

*> Some of these decisions are mathematical rather than language issues.*

But did you do any tests comparing your design to others? That is,

using actual people, both experienced and not so experienced?

The person I mentioned above, though I didn't find the reference,

compared currently popular languages taught in introductory classes

against ones with random ASCII characters in place of the keywords,

and the random one did better!

-- glen

[I can believe it, but I believe there is also some evidence that once

you get beyond examples of trivial size, languages that are hard for

computers to parse are also hard for people to use. For example, with

implicit multiplication, what does this mean:

a b c + d e f + g

Rules like APL's everything associates to the left, or languages where

you have to parenthesize everything may seem "unnatural" but also are

a lot easier to get things written correctly. -John]

Post a followup to this message

Return to the
comp.compilers page.

Search the
comp.compilers archives again.