An issue I think is important wrt. software engineering of scientific programming was highlighted by Tim van Beek when he suggested that Fortran climate models, hopefully not traducing his comment, must have bugs.
I have no experience of producing usable software in Fortran but reading Isaac Held's code, it looks as elegantly functionally decomposed and as professionally documented as any industrial applications programmer could want.
I had a go with some version of Sun's Fortress, which tried to introduce some kind of type safety somewhat in line with formal methods. Oracle who bought Sun then dumped it as the task of refactoring a weakly-typed imperative language was too much work and not the way to go.
As I think most complex future technology will almost certainly be designed and built on terrascale multicore processors then parallel programming will have to be taught to the Rasberry Pi virtuoso 7 year olds asap but not in Python.
One of the best bridges I've come across between category theory, CS and correct by construction practical code construction can be found in the proceedings of the [Mathematically-Structured Functional Programming (MDFP) workshops](http://www.cs.bham.ac.uk/~pbl/msfp2014/) at the International Conference on Functional Programming (ICFP).
I keep posting references to Jerzy Karczmarczyk's's [scientific functional programming papers](https://karczmarczuk.users.greyc.fr/arpap/) on automatic differentiation. Haskell code is available in Ed Kmett's [category-extras](hackage.haskell.org/package/category-extras), [vector-space](hackage.haskell.org/package/vector-space) and [ad](hackage.haskell.org/package/ad) packages among others.
If people want "press the solve button" model interfaces then that something I think Azimuth should definitely support. [[Stephan Liljegren]] commented that he thought making an Azimuth server was an off-track idea as we can use some cloud Sage server without any of the hassle. I agree.