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: firstname.lastname@example.org
- Delivered-to: email@example.com
- Delivered-to: firstname.lastname@example.org
- Delivered-to: email@example.com
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
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.
djmpark at comcast.net
Prev by Date:
Re: Definitions missing
Next by Date:
Announcement: MATLink 1.0 released -- call MATLAB from Mathematica
Previous by thread:
Re: Unexpected expectation behaviour
Next by thread:
Re: Applications and Packages, WRI Strikes Out!