technicalities: interactive scientific computing #1 of 2, pythonic parts

[graydon]

This is the first half of a two-part blog post that is motivated-by and mostly "about" two software ecosystems I've been poking around at recently. The first (and subject of this post) is I'll roughly call "interactive scientific Python", which includes primarily SciPy/SymPy/NumPy, IPython, and Sage; the second (subject of next post) is a new

Comments

[mmcirvin]

Really there are often more than two languages in the stack: the dichotomy applies incrementally in a relative sense at all levels of the system. In Android (and a couple of its conceptual predecessors like SavaJe OS and DangerOS), Java serves as a "managed" layer intermediate between any scripting that might exist and a fast systems language (though some of the advantage of that was just because the extant systems languages didn't have Rust-esque things like garbage collection and easy threading). Systems languages like C are themselves user-friendly compromises relative to hand-constructed machine code.

And there are other artificial distinctions, such as glue layers you have to construct simply because you're using a library written in some other, maybe more popular language. Sage mostly consists of that, as you mentioned, but there are other examples. These days, if you try to actually use Rust or Go as a systems language, you'll likely end up having to do that, because the existing packages are all in C/C++.

[mmcirvin]

...by the way, my own whole career seems to end up gravitating toward these glue layers, wherever they may be.