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"