MathGroup Archive 1992

[Date Index] [Thread Index] [Author Index]

Search the Archive

Re: combination problem solved with Mathematica

  • To: mathgroup at yoda.physics.unc.edu
  • Subject: Re: combination problem solved with Mathematica
  • From: gaylord at ux1.cso.uiuc.edu
  • Date: Mon, 30 Mar 1992 09:13:38 -0600

> ark at research.att.com said 3/ 30/92

Whether or not it is an advantage to use a language that is
>"not limited by datatype" is something about which reasonable
>people can disagree.
>
>
 Strong typing has two considerable compensating advantages.
>	   First, typechecking often finds my mistakes for me before
>	   I actually run my program.  Second, it often allows for much
>	   more efficient code generation in those cases where the compiler
>	   can use its knowledge of types to figure out much better
>	   machine code to generate for programs.
>
>Finally, I should note that comparing programming languages is a
>tricky business, especially when you include standard library functions.
>The trouble is that a good library can radically alter the character of
>a language, and is it often true that the language and library were
>designed by different (groups of) people entirely.

===============================================

i once  read a quote on the net from a person who said that a professor
teaching ML at cmu told the class "if you submit to the discipline, you'll
learn to like it" (which i suppose makes ML a B&D language). 

strong typing can certainly be useful 

typechecking is a  special type of pattern matching (Cameron Smith called
it  "pattern matching at the top-level only") This is available in the
Mathematica programming language and in addition you can use all sorts of
other pattern matching constraints.
i agree strongly it is good practice to use it not only to provide a safety
net but to enable polymorphic definition/overloading.

the  built-in functions of the Mathematica programming language have been
(as far as i know) designed by the same group and there seems to be good
quality control. these functions have been extremely well-optimised (as
indicated by speed tests on the list manipulation functions).
this is especially true for the functions that are implemented in C. In
general the rule is, the more built-in functions you use the faster the
Mathematica program will run.

built-in functions that are written in the Mathematica programming language
itself (as packages) are of probably not as efficient but of course, are
very useful. 

as the user-defined library of Mathematica grows, there will be the
definite danger that the language could degenerate from the proliferation
of poorly written user-defined expressions.

as someone once said 

"eternal vigilence is the price we must pay for good code"






  • Prev by Date: combination problem solved with Mathematica
  • Next by Date: Fortran form in input
  • Previous by thread: combination problem solved with Mathematica
  • Next by thread: Fortran form in input