Re: Mathematica and Lisp

*To*: mathgroup at smc.vnet.net*Subject*: [mg130005] Re: Mathematica and Lisp*From*: John Doty <noqsiaerospace at gmail.com>*Date*: Sun, 3 Mar 2013 22:59:56 -0500 (EST)*Delivered-to*: l-mathgroup@mail-archive0.wolfram.com*Delivered-to*: l-mathgroup@wolfram.com*Delivered-to*: mathgroup-newout@smc.vnet.net*Delivered-to*: mathgroup-newsend@smc.vnet.net*References*: <kgse4s$jam$1@smc.vnet.net> <kgutlr$nsc$1@smc.vnet.net>

On Sunday, March 3, 2013 12:21:31 AM UTC-7, Richard Fateman wrote: > C is not my favorite programming language .. see > > www.cs.berkeley.edu/~fateman/papers/software.pdf But in many cases it *is* the favorite language of people with real problems to solve. To me, the primary purpose of a programming language is to put the power of the computer into the hands of the people who understand the problems. For scientific and engineering problems, C is remarkably good at this. I disagree with your contention that Lisp has some sort of linguistic superiority that makes it immune to bugs. In the gEDA project, we use Lisp (Scheme dialect, Guile implementation) for scripting electronic design projects. We see our share of bugs in this code. There are *plenty* of ways to implement subtle bugs in Lisp. Dynamic typing produces various run-time surprises, often missed in testing. Test cases may also miss faulty tail recursion, but then a really big project will overflow the heap. Even engineers out of MIT EECS, steeped in the SICP ideology, are often not very good at coding Lisp. Lisp code is very difficult to review, because in the real world the set of people who understand the problem domain generally has a very small intersection with the set of people who can read Lisp code. > Nevertheless one can almost argue that if you know about > > how computers work on the assembly language level you have > > a modest chance of mapping C constructs to assembler-like > > code "in your head". I've taught this as part of an > > undergraduate course in "Machine Structures". Most C programmers I know cannot code in assembly language, but that really isn't very important. The key to expertise in C is understanding binary data representation. > For EF, the number of unfamiliar operators and the > > number of distinct precedences is substantial. > > > > There is a table in the virtual book documentation "operation precedence" > > in the section Operator Input Forms. > > > > There are roughly > > 69 different precedence categories listed. > > > > In some precedence classes there are many forms. > > For example in the category 4th from the bottom there are these > > operators which, being in the same class, would be parsed from > > left to right (or is it right to left?) anyway, here they are. > > > > =, :=, ^=, ^:=, =. ->, > > and also the matchfix > > /: = > > /: := > > > > While some of the operators have no built-in meaning, and some are > > pretty obscure, they are all part of the syntax. There are also quite > > a few multi-character operators, some of which are new to me.. @@@ ? These are not significant problems for those of us who use the language rather than fighting it.