Prev: Find value of unknown const that causes integral to equal some
Next: Find value of unknown const that causes integral to
From: J and B on 13 Jun 2010 04:11 In writing code which is the preferred method, Work Bench or Mathematica? In ether one, why do you use it vs. the other?
From: Hannes Kessler on 13 Jun 2010 18:52 On 13 Jun., 10:11, "J and B" <noslow...(a)comcast.net> wrote: > In writing code which is the preferred method, Work Bench or Mathematica? > > In ether one, why do you use it vs. the other? I use both. For smaller programs, I prefer Mathematica. For larger packages (stored in $UserBaseDirectory/Applications and loaded with Needs), I am in the transition to the Workbench. One advantage of the Workbench is, that it allows to work on or more new packages without mixing them with the finished packages ready for use in $UserBaseDirectory/Applications. Only when a package under development has reached a functional state, I copy it from its Workbench project directory to $UserBaseDirectory/Applications. Another advantage of the Workbench is that you can add help documents to your packages which can be viewed in the Mathematica documentation center. One can also use the Workbench debugger if the code is developed in .m files (not in .nb files). I did not use this feature until now as I still prefer to maintain my packages via .nb files: Write a package in a notebook .nb file, mark the code cells as initialization cells or convert them to the Code-style - this creates automatically your package .m file on each save of the corresponding notebook .nb file. Workbench has a number of deficiencies and bugs. It may crash or issue a lot of not helpful error messages if you do not follow exactly the standard examples. There are many options which can be changed, but the help documentation does not explain the effects for ordinary users. When you create help pages and compile them, you have to restart the Workbench each time before you can see the changes in the Mathematica documentation center. The links to other help pages created by the DocumentationTools palette are incorrect if you have a non-English Windows (in my case a german Windows), an english Mathematica and compile english help pages. I've got a confirmation regarding the last 2 bugs by the support of Wolfram Research without any workarounds. It seems to me that the Workbench may become a great programming environment for Mathematica programs in the future. At the moment it offers some possibilities but was also a source of big frustration for me. You do not need to know the Workbench in order to write good Mathematica programs efficiently. My recommendation for a beginning Mathematica programmer would be to start writing programs in the standard Mathematica environment. You can use all the formatting features and styles in .nb notebooks in order to comment your programs and their testing procedures. In addition, you can use the very good Mathematica-editor for .m package files. There are real Mathematica experts who do all their work - code writing, debugging and compiling help files - in the standard Mathematica environment. It's just a question of your personal preferences. Best regards, Hannes Kessler
From: Bill Rowe on 13 Jun 2010 18:53 On 6/13/10 at 4:11 AM, noslowski(a)comcast.net (J and B) wrote: >In writing code which is the preferred method, Work Bench or >Mathematica? Everyone will have their own preference based on their personal preferences and work flow. For me, I code in Mathematica rather than Workbench >In ether one, why do you use it vs. the other? Although, I've done some investigation with Workbench, I've yet to see a compelling advantage over coding in Mathematica. And since I've used this means of coding long before Workbench was available, without a compelling advantage of Workbench over Mathematica for coding, I've no motivation for changing.
From: David Reiss on 15 Jun 2010 02:28 I generally use Mathematica -- even for projects of quite considerable size (tens of thousands of lines of Mathematica code). I can organize things within a notebook far more efficiently and document things directly within the notebook to provide detailed reminders to myself of the reasons why I chose the methods that I did. I use http://www.scientificarts.com/worklife (which, indeed itself is one of those very large applications) to be able to move the package from its development directory to the various Mathematica Applications directories, adn to be able to load and reload the package iteratively as I develop it. --David On Jun 13, 4:11 am, "J and B" <noslow...(a)comcast.net> wrote: > In writing code which is the preferred method, Work Bench or Mathematica? > > In ether one, why do you use it vs. the other?
From: David Bailey on 15 Jun 2010 02:29
On 13/06/10 09:11, J and B wrote: > In writing code which is the preferred method, Work Bench or Mathematica? > > In ether one, why do you use it vs. the other? Much of my work uses J/Link and accesses compiled Java code, so I suppose the WB should be useful to me. However, when I tried WB it seemed hard to learn and not very well integrated with Mathematica, so I use Mathematica to edit and test Mathematica code, and various batch processes to compile the Java code and assemble the various files in my packages. I guess some people like Integrated Development Environments (IDE's) that do all sorts of (hopefully helpful) things behind the scenes, others prefer to keep complete control over what is going on, and use batch files or bash scripts. One specific problem with the WB is that it can't display all the Mathematica characters. By contrast, the FrontEnd editor does a splendid job of editing .m files, and displays the full range of characters. I think this editor, which came in at version 6, made the need for the WB less important. The standard way to integrate package documentation is to use the WB, however, David Reiss and I have figured out how to do this from within Mathematica. The beauty of performing a task like this outside an IDE is that you can set it up as a sequence of commands that can be re-executed as required, rather than remembering a string of mouse clicks! David Bailey www.dbaileyconsultancy.co.uk |