cliffc@libya.rice.edu (Cliff Click) (09/19/90)
For all those folks involved in the Lisp syntax is good/bad wars... I've done some Scheme programming, darn little ML programming and scads of C/Fortran/Pascal/etc programming. I find ML syntax to be incredibly unreadable, while Scheme & C syntax isn't that bad. Is this a function of: 1) Not enough experience with ML, 2) the difficultly of having a type system in a function language, 3) lousy design of ML syntax or 4) none of the above? Gratefully awaiting your enlightened responses, Cliff Click -- Cliff Click cliffc@owlnet.rice.edu
tmb@ai.mit.edu (Thomas M. Breuel) (09/19/90)
In article <1990Sep18.174851.4175@rice.edu>, cliffc@libya.rice.edu (Cliff Click) writes: |> I've done some Scheme programming, darn little ML programming and scads |> of C/Fortran/Pascal/etc programming. I find ML syntax to be incredibly |> unreadable, while Scheme & C syntax isn't that bad. ML syntax is a little tricky, and quite different from C or Algol syntax. However, it is very convenient for functional programming, in particular if you use lots of currying.
sfk@otter.hpl.hp.com (Steve Knight) (09/25/90)
Cliff wonders: > I find ML syntax to be incredibly > unreadable, while Scheme & C syntax isn't that bad. [...] > 1) Not enough experience with ML, Nope -- the more you use it, the more you hate it. > 2) the difficultly of having a type system in a function language, Nope -- the type system is a pain, but that's got nothing to do with the syntax. It's easy to write a ML-style type-checker for S-expression syntax languages. > 3) lousy design of ML syntax or Alas, it is true. ML's syntax is riddled with problems - the lack of a closing keyword for IF means that you are left guessing how it binds with respect to (for example) a HANDLE statement. The overloading of END means that you are frequently left guessing, or measuring indentation with a ruler, to work out what closes with what. The fact that datatype constructors are tupled rather than curried (as in Miranda) means that pattern matching involves many superfluous brackets. The incorrect precedence for FN almost always forces the insertion of disambiguating brackets. The failure to properly distinguish variable namespaces from constructor namespaces (as is done correctly in Prolog) means that it is trivial to write incorrect programs ..... and so on. As an example of this last point, I will leave you with a rather uncomfortable observation about ML. Taking this definition in isolation out of a program, you cannot determine what it means because the context is too important. fun f x = x; (Get it? "x" might be a constructor or a variable. You don't know.) > Gratefully awaiting your enlightened responses, Sorryfully, I have to say that ML is one of the few languages that makes me wish I was using S-expression syntax. Now stop that sniggering at the back... Steve