Applications and Packages, WRI Strikes Out!
- To: mathgroup at smc.vnet.net
- Subject: [mg131035] Applications and Packages, WRI Strikes Out!
- From: "djmpark" <djmpark at comcast.net>
- Date: Wed, 5 Jun 2013 03:28:41 -0400 (EDT)
- Delivered-to: l-mathgroup@mail-archive0.wolfram.com
- Delivered-to: l-mathgroup@wolfram.com
- Delivered-to: mathgroup-outx@smc.vnet.net
- Delivered-to: mathgroup-newsendx@smc.vnet.net
One usage of Mathematica could be as an integrated research, developmental, educational and communication medium for mathematics and technical subjects. It's great advantages are its active calculation and dynamics and the ability to document (with Workbench) and preserve active usable knowledge. It is an organized method to build up capability. I always thought this was an implied vision and goal for Mathematica but perhaps I am mistaken. The fact is that the Workbench/Application facilities are only just barely adequate and then only with ad hoc methods suggested by WRI people, which either produce error messages (that we are supposed to ignore) or don't work at all, or that require redoing hundreds of pages of documentation! Much of the work has to be done by editing underlying expressions. The whole thing is ill-designed, neglected and shoddily implemented. WRI can add all the doo-dads they want but without the Application capability Mathematica is just a super fancy calculator, dynamic information retriever, and minor programming language for stand-alone results that will be copied out to other media. Here is an example of poor design. In any application it may be convenient to break the routines into a collection of sub-packages. From a computer science point of view the sub-packages should be organized hierarchically so that as each package is read in it only uses public symbols from packages already read in. But this is not always convenient and also because of the historical development of an application a packageA may use a symbol from packageB and vice versa. Or this may involve other intermediate packages. This is supposed to be taken care of by the second form of the BeginPackage statement with the list of "needs" contexts needed for the package. The documentation says: "The interpretation of symbol names depends on context. BeginPackage thus affects the parsing of input expressions." You can say that again. But the entire matter is misleading. What the BeginPackage package needs is the contexts of all the exported symbols used in the `Private` section, else they will go into the `Private` context of the current package being loaded. But what WRI does is actually load the entire packages, along with their own `Private` definitions. This produces a tangled web that is very difficult to analyze. It definitely produces multiple definitions of routines, some with exported symbols put into the `Private` context, and you just have to hope that Mathematica uses the proper definition. In fact, it won't always. Why doesn't WRI have a restricted interpretation of "needs" in the BeginPackage statement that just picks off the exported context names and does not load the definitions? The `Private` definitions should only be loaded in their own package code where the developer has supposedly named all the contexts that are needed for it. Is there some reason that couldn't be done? I hate "computer science" and pay WRI lots of money to do it. Why can't they do it? I fault Stephen Wolfram for his neglect of facilities for Mathematica Application development. It appears that nothing has been done for over two years. There are many problems in the design, implementation and documentation of Application development in Workbench. When it is so unstable we don't even know if the entire paradigm might change. David Park djmpark at comcast.net http://home.comcast.net/~djmpark/index.html