Probably, I am missing something.

When I purchased the Workbench 2.xx license, I just ran the installer then launched Mathematica and everything worked (not as I expected but it worked). In other words, to run Workbench I did not need anything extra (as for example and additional piece of software not included in Workbench, say, Eclipse). What I am saying is that I understood that Eclipse was, somehow, included in Workbench 2.xx.

To me, this is a bit confusing.

Which is the difference now between Workbench 2.xx and the new Workbench (3.xx) ?

Many thanks.

I have the 64-bit version of Eclipse running with the WB plugin under windows.

And it works with the 64-bit version of Eclipse Neon?

I looked at http://support.wolfram.com/kb/27221, which makes no mention of 64-bit vs, 32-bit Eclipse. But the October 2016 answer at http://mathematica.stackexchange.com/questions/18183/how-to-install-the-wolfram-workbench-plugin-into-eclipse-kepler-or-neon says 32-bit Eclipse.

Yep, that the same plugin!

Yes, 'my' Workbench 2.x has been sleeping the sleep of the just deep within my software relics vault for about three or four years.

Is this a new official replacement for Wolfram Workbench 2 and 3?

Is it available to all Mathematica users?

Just wondering because I thought there might be something of a more official announcement and not just an installation procedure.

Available to everyone, even without Premiere Service! This is excellent news. Making the documentation tools available to every Mathematica user was very much necessary. I hope that this will lead to more people publishing quality packages.

I'd like to reiterate other posters' comments about the criticality of an IDE for WL to make the transition from "small code" to "big code" - at least more regularly outside the WRISphere. My history is that while WW used to be a large part of my workflow, nowadays I would say that 95% of my development work takes place in the front-end. That 5% though, pareto-like, is still worth more than this percentage might indicate: it provides an "orienting home" for my project; it is used to generate documentation, v.occasionally for stubborn bugs and rudimentary refactoring; to push and package deployments (although I would also say that I've never found WW especially natural to use).

The advantages of certain front-end features, in the end, I found too useful and there is one game-changer that I think now makes it feasible to produce large projects in the WL - the advent of Associations (for implementing a version of object-orientation, structs etc). To be sure, to harness this in the front-end, I've probably spent ~2 months in total (spread out over several years) creating a native front-end IDE (git integration, "Front-end staging area", notebook manipulation, stylesheets, modifying Shift-enter, granular organization, code refactoring, multiple screens etc) but to me what this indicates is that something far more powerful could be industrially created (in fact I no longer add to this IDE having got it to a functioning level since I suspect something is already in the works - something that could perhaps be galvanized with sufficient community sentiment?).

Hence (while never saying never) I can't imagine foregoing these advantages or transiting the code-base already canned away from the front-end, but having said this I would still like to have the back-up of a "traditional IDE" for when other languages are required (or the other 5% of the time and/or when certain features are yet to make their way into a "native" IDE) while also noting that others might have a greater need for such language integration.

Therefore, I don't think this is an either/or scenario but that actually, a two-pronged approach/strategy is essential for bringing people on-board in the creation of WL "big code"; Something along the lines of:

1. A state of the art, front-end IDE (focused on those who predominantly develop in Mathematica - documentation, git version control, unit tests, refactoring just to start with)
2. A "traditional IDE" that is used in-house at WRI but which is now also coupled to each Mathematica release (for those who need connections with other languages or prefer this environment)

(I don't know enough about WRI's in-house requirements or IntelliJ IDEA's innards to judge the feasibility of the following proposition but ... given the availability of willing contributors, its newness, the lack of WW-love and releases, maybe a bold route would involve positing IntelliJ IDEA as the "traditional IDE" for the WL?).

I also want to make a final point, perhaps off-topic and obvious but one that I feel sometimes gets overlooked in such discussions. It is not just the technology that is at issue here, nor even the education of how to use it effectively but equally pivotal are the designs on which it operates. My experience is that a soundly designed architecture on a limited IDE will every time beat a poorly designed architecture on a state-of-the-art IDE.

I also think Mathematica/WL needs and deserves more attention and tool support for larger projects. I'm still trying to get my head around how WolframAlpha was built using the IMO rather primitive Workbench Piggybacking on Eclipse...

I don't think it is unfeasible to start an IDE from scratch designed for Mathematica. Starting from the already available notebook (or package file) editor might be doable. As mentioned, there are just a few essential things missing from Mathematica right now that "serious programmers" expect, including:

• no more hangs/crashes of the front end
• easy-to-use debugger
• version manageable plain-text files
• search (the current find and replace dialog feels very out-of-date)
• refactoring
• support for multiple files
• not having to manually re-evaluate definitions when things change

Mathematica is AFAIK in a unique position offering such wast symbolic computation power/knowledge and data access. Being able to instantly visualize some output is something other languages are only starting to get (e.g. Apple's Swift, check out "WWDC14 Apple Swift Demo") which Mathematica has had from the start.

Please keep WL alive and help it spread and be adopted.

I would welcome an updated Workbench as well.

Last time I knew, the workbench supported "profiling" - the execution trace histogram.

I'd like to be able to use this again, is installing and using the workbench was easy.

-- Mark

You can spend 120,- Euro for nothing indeed

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.

Yes, please!

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.

If you are referring to the IDEA plugin: it is cross platforms and works on every platform where IDEA itself does (Windows, OS X, Linux)

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.

For developing large packages, Workbench is a big help, since you can seamlessly modify the package and test it with a notebook.

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.

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 am interested in this. I am currently using the beta Workbench 3, which apparently can be had on request, but a new release would be welcome.