4 ms·

Given the success of the Python numerical computing stack (numpy, scipy, etc) it would probably be a good idea to do just that. Of course you’d profile the libr

Given the success of the Python numerical computing stack (numpy, scipy, etc) it would probably be a good idea to do just that. Of course you’d profile the library and move some of the performance-critical bits to C / C++ / Rust. Thankfully Python has some well-trodden paths to that solution.

FpUser 7y ago
IMO a good an practical idea would be to write it in C/C++, expose as flat C API and then offer wrappers in whatever popular consumer languages there are (python included). The world of software does not end with Python
- pbourke 7y ago
  Yes, definitely a good approach as well. One point in favour of the Python-first way is that you can prototype and test much quicker in Python than in languages that are closer to the metal. On my team, we've been successful with this rough approach: 1. write a prototype in Python to explore the idea/ensure correctness 2. extract the core library and re-implement it in Rust 3. consume the core from Javascript via WASM and Python via pyo3 (Python/Rust bindings)
  - FpUser 7y ago
    One point in favour of the Python-first way is that you can prototype and test much quicker in Python than in languages that are closer to the metal. Interestingly I've found something quite opposite for computational algorithms. The problem was that execution of Python under debugger was unbearably slow for me (I used VS Code for this case). So waiting until the code gets to the point I need was not fun. With C however it would get there almost instantly. Compile time for isolated computational function was nearly instant as well. Maybe debugging under VS code was the culprit but I did not feel that for this particular task Python was any more interactive than plain C.
    - pbourke 7y ago
      Yes, I can see that being tiresome. Our projects are closer to simulations, so rather than focusing on a tight core at first, we have a number of factors that can be in play during each time step. Rather than worry about figuring out structures for our simulation objects like we might need to do in a lower-level language, Python lets us just throw together some numpy arrays and dicts as needed, and really iterate quickly on the solution. If I was working on something with a tight computational core I would probably take the low-level first approach like you have. Horses for courses, and all that.

FpUser 7y ago

IMO a good an practical idea would be to write it in C/C++, expose as flat C API and then offer wrappers in whatever popular consumer languages there are (python included). The world of software does not end with Python

pbourke 7y ago
Yes, definitely a good approach as well. One point in favour of the Python-first way is that you can prototype and test much quicker in Python than in languages that are closer to the metal. On my team, we've been successful with this rough approach: 1. write a prototype in Python to explore the idea/ensure correctness 2. extract the core library and re-implement it in Rust 3. consume the core from Javascript via WASM and Python via pyo3 (Python/Rust bindings)
- FpUser 7y ago
  One point in favour of the Python-first way is that you can prototype and test much quicker in Python than in languages that are closer to the metal. Interestingly I've found something quite opposite for computational algorithms. The problem was that execution of Python under debugger was unbearably slow for me (I used VS Code for this case). So waiting until the code gets to the point I need was not fun. With C however it would get there almost instantly. Compile time for isolated computational function was nearly instant as well. Maybe debugging under VS code was the culprit but I did not feel that for this particular task Python was any more interactive than plain C.
  - pbourke 7y ago
    Yes, I can see that being tiresome. Our projects are closer to simulations, so rather than focusing on a tight core at first, we have a number of factors that can be in play during each time step. Rather than worry about figuring out structures for our simulation objects like we might need to do in a lower-level language, Python lets us just throw together some numpy arrays and dicts as needed, and really iterate quickly on the solution. If I was working on something with a tight computational core I would probably take the low-level first approach like you have. Horses for courses, and all that.