In my opinion, the next step is to figure out a good way to combine something like gnu octave with nice modern GUIs.
Old tools were inaccessible to use because there's nothing to look at with a text-based tool, and inaccessible for engineers to develop because programming was so arcane. Look at Berkeley spice written in C. It's a lot of old-school parsing and implementing matrix methods.
The new stuff that's more accessible to use is more accessible for a software engineer to develop, but it's arguably even less accessible to other engineers and scientists to add their contributions. This creates an issue where the tools remain as good-looking toys that never get any serious technical chops.
Splitting the implementation is the way to go, but neither side would be happy about the interface. There's also the issue of platform because good engineering tools only run locally.
I don't know what the answer is, but it's not Python. We already have python, and yet, there isn't an explosion of collaboration to make great tools for the physical sciences and engineering. It's too much of a compromise for both sides.
> I don't know what the answer is, but it's not Python. We already have python, and yet, there isn't an explosion of collaboration to make great tools for the physical sciences and engineering. It's too much of a compromise for both sides.
I would argue that python is actually ideally suited as a solution for many if not most things, just because there isn't large adoption in a subgenre of engineering, doesn't mean it isn't the right solution.
The primitives are there, its easy to comprehend, and there is a large amount of adoption in the scientific community outside EE.
I see lots of stuff that used to be done in things like matlab or mathmatica being done in python directly these days. At least at one of the places that I worked at, where we were a huge matlab shop for doing model design / algorithm simulation, has migrated most of their stuff to python.
Things like antenna design, RF simulation and a number of other things have a lot of of folks writing python code.
Are any of those examples successful open-source projects with both the computation and the GUI written in Python? I don't know of anything in any field like that.
I think you misunderstood me. The choice of tools for front and backend have to be independent. The only really successful projects implemented in one language are all in C++, and that's difficult for everyone to approach.
I may be confused as to what you mean by GUI in this context. If you are talking about a data exploration GUI... many, many scientists and physical science engineers use Jupyter/JupyterLab as a frontend for data exploration. This largely replaces the need for something like matlab.
If you are talking about practical implementation of those models, I have seen many non open source projects use those backends (things like pandas, sklearn, etc.) with things like django or flask as a frontend.
Old tools were inaccessible to use because there's nothing to look at with a text-based tool, and inaccessible for engineers to develop because programming was so arcane. Look at Berkeley spice written in C. It's a lot of old-school parsing and implementing matrix methods.
The new stuff that's more accessible to use is more accessible for a software engineer to develop, but it's arguably even less accessible to other engineers and scientists to add their contributions. This creates an issue where the tools remain as good-looking toys that never get any serious technical chops.
Splitting the implementation is the way to go, but neither side would be happy about the interface. There's also the issue of platform because good engineering tools only run locally.
I don't know what the answer is, but it's not Python. We already have python, and yet, there isn't an explosion of collaboration to make great tools for the physical sciences and engineering. It's too much of a compromise for both sides.