|
|
|
|
|
|
by hollandays
1176 days ago
|
|
|
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 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.