Last week I attended the Wolfram Tour (which was great). I asked whenever we could expect a new version of Workbench, as the current (public) version 2 is very out dated. They responded that they use a more up to date version internally at Wolfram (with some sort of automatic update system) but this version has not been made public as it would require some effort to create a distributional version of it. The reason that they did not invest in this is probably that Workbench has not got many users, and therefor the effort to create a public version is too great in comparison to the number of users.
They advised us to create a public topic on this and ask for support of the community to make this a higher priority at Wolfram. Please let me (and wolfram) know that you are also interested in a new version of the Wolfram Workbench.
To Summarize the Comments
What do we miss
Creating native Mathematica Documentation
Profiler function
Unit Testing (although this is already included in Mathematica 10+, it feels a bit awkward to me to run a nb for unit testing)
IDE to develop large WL programs/packages: (Proper meaning: debugging, refactoring, code hinting, search multiple-files etc.)
Suggested Solutions
Release (the already internally available) Workbench [preferred solution]
Seperate the functionality (Profiler, Documentation tools) from WB and support (for example) the IDEA plugin
Edit 2 november 2016:
I’ve been working with the new Eclipse Plugin (in combination with Mathematica 11 for 2 weeks now and find that it works really well, have not been able to find mayor errors
I want to thank everyone for taking the time to support this post
Add my name to the ‘list’. I have been after WRI to release a new ‘shrink-wrapped’ Workbench since the old one broke. If it is a matter of priorities, maybe they will be shifted. I think I remember that someone said that WR used to have three or four people working on Workbench, and it is now down to less than one FTE.
I certainly would welcome and encourage WRI to produce a new public version of Workbench.
However, there are two applications of Workbench: 1) Documentation; 2) Everything else such as debugging, integrating C code, multi-person projects etc. It is only the documentation that interests me. Even though I work on moderate size applications and sometimes with a few other people, I don’t find a need for these extra features. I find it easy enough to debug just by inserting temporary Print statements in routines. I don’t find any need for an auxiliary IDE. Mathematica is a fairly sophisticated IDE itself. I’m sure this aspect of Workbench is important for internal Wolfram work what with all the C code, and there may be a few enterprise level customers who would make good use of it. Most users, doing math and science, don’t really need this aspect of Workbench.
Documentation is a different matter. It is a part of preserving your work and making it accessible to others. Documentation is an optional but usual part of an application. An application is the best way to communicate your work to others. Papers in the form of Wolfram notebooks can be supported by applications and may be included within an application. They are orders of magnitude better than current publication practice. It is rather a shame that all the publications of papers on arXiv.org aren’t accompanied by Mathematica paper/applications. - instead of none of them.
I don’t know if user documentation has to be tied to Workbench. Perhaps a separate documentation facility could be provided. It really should be available to ALL Mathematica users. An earlier form of documentation was available to all in Version 5. Somehow this vision of Mathematica as a development AND communication medium got lost. Everything is there except Documentation. Otherwise writing applications is really easy.
As for communicating with people who don’t have Mathematica? Tell them to get Mathematica; it works and it’s worth it.
Frank, does this mean you put your packages, stylesheets and palettes in Workbench? Is this actually seamless or convenient? It must mean that you do all of your development within Workbench and use straight Mathematica only with the deployed result.
What happens if while using the application in regular Mathematica you find you want to update a routine, or stylesheet or palette? This means that you either have to go up to Workbench to make the change, and rebuild all the documentation even if you haven’t changed it, or you can make the changes in regular Mathematica but you must remember to copy the changed files up to Workbench. You have two copies of all these items and must take care to keep them in sync.
I DO NOT put any packages, stylesheets or palettes in Workbench. I leave them all in the deployed application. (I do put the init.m file in Workbench 3, but that’s only because it doesn’t work if one doesn’t deploy some non-documentation file - a definite bug as far as I’m concerned.) Workbench will access all of these deployed files. There is only one copy of them. They can be edited in regular Mathematica and all of the development can be done in regular Mathematica. I only go to Workbench when I want to change or add documentation, which is not that often.
Personally I would probably not use Workbench for package development. The IDEA plugin is great, and I use it regularly.
However, the Workbench did have two special features which I think are important: the documentation tools (!!) and the profiler. There is not reason I see why these have to be tied to the Workbench. It would be great if they were included with Mathematica instead. Especially the documentation tools are essential for proper package development and really should be made available.
If WRI believes that the Workbench doesn’t warrant the effort, they could support the IDEA plugin in some way instead, such as:
Making essential parts of the Workbench (MUnit, documentation tools, profiler) separate and make them easy to integrate in other editors
Endorse the IDEA plugin
Contribute to the IDEA plugin project. It is open source. Anyone can contribute. WRI could do this without having to support the project as an official product.
Not sure I would want to add yet another IDE. I went to the website and I am not sure which platforms are supported.
Like David Park, I’d be happy if the documentation functionality were available in Mathematica. Then I could use one tool for complete Wolfram Language development.
I agree, the IDEA plugin for Mathematica is indeed great and indeed if the Documentation tools are sepperated from Workbench (I think MUnit has been integrated with mathematica 10+) then there is no need for an update on the workbench any more.
In the spirit of short term thinking: I still would like a new version of Workbench as, according to Wolfram, it is only a matter of creating a proper install wizard for public use.
During the past few years I’ve seen a small number of package applications that had “custom” documentation. I suspect that this was usually due to the authors not having access to Wolfram documentation facilities, or maybe not finding them easy to use. This shows that authors are trying to document but not given adequate support by WRI.
It is good practice to document an application such that it follows the same paradigm and merges smoothly with the Wolfram paclet documentation. It’s perfectly possible to do this. The Wolfram documentation method is plenty good. It’s not fair to ask a user or reader to learn a new, usually poorly designed, Help paradigm that perhaps clashes with paclet documentation.
Mathematica documents as part of documented applications or supported by applications are by far the best method of development and communication of technical subject matter. The ability to easily document is the weak point to promoting this usage. Wolfram Research would be providing a benefit to everybody, especially the scientific community, by providing documentation facilities to every user.
Yes, please continue to support Workbench! Maybe I am not making use of the Front End features enough, but I often catch myself starting out “quick and dirty” in a notebook, only to discover that things are getting quite messy and cluttered, then wishing I had started out using Workbench earlier on.
I may not be programmer enough to judge Eclipse against alternatives, but working with .m files makes integrating version control probably much easier than working with .nb files afaik? I also like the ease of refactoring names accross a project with different files all at once.
Working with bigger projects and splitting them up into parts works nice and smooth in Workbench. Maybe I have to see this all be done in the Front End in a convincing way, but as long as I have not seen this I would strongly ask to continue work on Workbench.
Frank, does this mean you put your packages, stylesheets and palettes in Workbench?
I do not understand? I create/maintain my packages in Workbench, which is basically a different front-end of WL (please correct me if I am wrong). Stylesheets and palettes are only relevant in the Mathematica front-end as you can style cells (and elements within them) which are absent in Workbench.
It must mean that you do all of your development within Workbench and use straight Mathematica only with the deployed result.
No, from workbench you can ‘run’ your code, which pushes the code directly to the Mathematica kernel, pretty much the same as using Shift+Enter in Mathematica.
What happens if while using the application in regular Mathematica you find you want to update a routine, or stylesheet or palette?
Stylesheets and palettes are only used in the notebook enviroment from Mathematica. If I want to update a routine, i simply switch to Workbench, update the routine, hit the run button and test the function in mathematica (Or with an unit test directly in Workbench).
This means that you either have to go up to Workbench to make the change, and rebuild all the documentation […] take care to keep them in sync.
This is thus not necessary, as you can run your code directly from workbench without building it first. I think you have overlooked some of the features of Workbench. I definitely recommend looking into these if you develop packages.
I would argue that either Wolfram Research releases a (free, or even better boundled with Mathematica,just like Java) version of Workbench (and the Eclipse plugin) very soon, or professional programmers will still not take the Wolfram Language serious for larger program development. I do use the Eclipse-plugin-beta-version of Workbench nearly every day, sometimes simultaneously with the IntelliJ plugin (both have their strong and weak points). But I am hesitant to teach my clients to use Workbench at all, since it is so very much unsupported and undocumented from Wolfram Research.
So, if Wolfram wants outside developers to use Wolfram Language for more than trivial programs, there is just no other way than to support Workbench (and the Eclipse plugin of course).
Pure programming in the FrontEnd is far inferior to a true IDE, since the FrontEnd is very slow in searching and handling of larger projects (actually you cannot search through more than one .wl or .nb file at once, which is trivial and fast in an IDE), not to speak of frequent hangs and spinning wheels and so on, which still occur (sometimes inevitably).
And of course integration of a code versioning system like git is a must in any non-academic program development setup.
