Specialized software exist mainly for education in Physics or for very specific fields or activities. But in general Physics is about  the principles and frontiers, for which there is no ready-to-use package. Hence, tipically each one has code written in some programing language: eg Fortran or C as most people do purely numeric calculations, while some fields, like General Relativity, have a long tradition in symbolic calculations using CAS.

Eg, I have found very useful Maple + GRTensor for calculations in a given metrics.

where these pages?

where these pages?

is a package, that eventually should replace 'series' , whose development seems quite slow. It has appeared in Maple 9.5 (ie 2004) and since then, including Maple 12, ?MultiSeries  > Description  states exactly the same paragraph:

The MultiSeries package is still under development. It is very likely that the functionality will change in the next release of Maple. Thus code using this package may not be backwards compatible with the next release of Maple.

I have mentioned 'assume' below and previously posted about its shortcomings.

How to search for them?

Here, there is a site claiming 100,000+ Hypergeometric Formulas.

How to search for them?

Here, there is a site claiming 100,000+ Hypergeometric Formulas.

Mario, Joe got that expresion with A and B for a different exponent:

Y := (x/2)^(3/2)

instead of

Y := (x/2)^(2/3)

Mario, Joe got that expresion with A and B for a different exponent:

Y := (x/2)^(3/2)

instead of

Y := (x/2)^(2/3)

implies, I think, increasing costs. Indeed for the user as some features have obsolete implementations  (eg  assumptions), and some other  features  are (apparently) not  even implementable (eg explicit contexts). And probably this is an issue even more accute for the developers.

So, it seems to me that that beyond a point, the costs of breaking backwards compatibility will be lower than those of keeping it. The question is how far is that?

but with unresolved defects that affect usability for serious users.

Consistency: mathematical notation and conventions should be uniform thoough the whole system. Currently it is a mess, as eg the case of spherical coordinates.

Documentation: it should be written by dedicated profesionals. Currently its quality is very uneven and it is largely fragmented, what seems consistent with the picture  that it is mostly written by developers in a hurry as described in this case.

Support. Patches should be available for versions in a reasonable range. At present, when a bug in the library is found, in the best case, patches are promised for future dot upgrades of the current version. Those with any previous version are lost.

Which could be the market requesting GUI toys like dials and gauges?

My fear is that this current push for including widgets to the Standard GUI makes it even more bulkier, slower and buggier. Ie even less usable.

Say that these toys are needed  to make kids use Maple. Doesn't make more sense to put them just in a special version for kids?

and wrong as the previous post. 

The standard reference are the chapters on Electrostatics of the classical textbook by Jackson, from where probably the equation for the Green function was copied, but with errors.  For the case  without  boundaries, see  eg this article.

and wrong as the previous post. 

The standard reference are the chapters on Electrostatics of the classical textbook by Jackson, from where probably the equation for the Green function was copied, but with errors.  For the case  without  boundaries, see  eg this article.

it is probablyl about customers (governments in particular), that do not require high quality standards as for other products.

presumably should work, as well as command line interface.

At the time of Maple V Release 3 I was very happy when I had 16MB RAM  to run it!