🚀 go-pugleaf

In article <BvGz2u.2rv.1@cs.cmu.edu>, spot@CS.CMU.EDU (Scott Draves) writes:
|> >>>>> On 1 Oct 92 12:57:12 GMT, jamesh@castle.ed.ac.uk (James Hammerton) said:
|> 
|> 
|> jamesh> (define fac
|> jamesh>  (lambda (n)
|> jamesh>   ( if (= 0 n)
|> jamesh>     1
|> jamesh>     (* n (fac (- n 1))))))
|> 
|> 
|> 
|> jamesh> fun fac 0 = 1
|> jamesh> |   fac n = n * fac (n-1) ;
|> 
|> 
|> jamesh> Now which is easier to read?!!!
|> 


	Well that depends upon how long you have been programming in lisp/
SML/whatever. 

	In my experience one doesn't really *see* syntax after about 3 weeks
of hard hacking in a language. When I started hacking lisp I was irritated
by all the brackets - after a few weeks the problem went away. SML type
errors were another problem - again after a couple of weeks they didn't bother
me.

	Probably the biggest advantage/disadvantage of ML is that it inforces
a certain "type of thinking" when problem solvoing - one is *forced* to
think in terms of types. When programming in lisp one doesn't have to think
in terms of types before writing a program. Whether this discipline is a good
or bad thing is debatable - I certainly don't believe the wild claims of certain
ML fans who say something like "once the program is type correct your problems
are over ...." - I still solve the *wrong* problems (only this time with
a type correct program :-)) - neither lisp nor ML helps me here :-(

	Rather than worrying about syntax I'd like to see a classification of
the types of problem area for which lisp/ML/C/Prolog/footran etc. are
appropriate.

	Joe Armstrong