3 ms·
> Hopefully the scientific stack will be rewritten in better languages like Go, Lisp, Ocaml, etc. I don't keep my breath on that. Because Python can be used in
by bayindirh 2y ago
> Hopefully the scientific stack will be rewritten in better languages like Go, Lisp, Ocaml, etc.
I don't keep my breath on that. Because Python can be used interactively, relatively mature, hard plumbing work is done by real computer scientists, and all is left to play with the code until the numbers look right for a given research.
It's just a better MATLAB in practice for some disciplines, and none of the languages we have provides this kind of flexibility with that amount of leeway for play. Zip the virtualenv and send over. If it doesn't work just delete the folder and reinstall anaconda...
Nobody is thinking about the performance of their code or the elegance of what they do. They care about the papers, deadlines and research in general. Code quality, general performance, organization can go whereever they like. All underlying high performance code is written in C anyway and only implementers of these code cares about that code. It's akin to docker for (data) scientists mostly.
How do I know? I'm an HPC admin. I see that first hand.
- pjmlp 2y agoCommon Lisp does, but then again, only druids care about its existence and the tales of strange machines, powerful graphics workstations, that used to be fully written in languages full of parenthesis. To the point people don't realize notebooks are how those machines REPLs used to work.
- deleted 2y ago[deleted]
- rbanffy 2y agoElegant tools for a more civilised age.
- cb321 2y agoJulia is a REPL-driven interactive system that was specifically syntactically (to its detriment IMO) targeted at Matlab users while Python for science was on the rise. Julia code does usually run faster than Python stuff without a lot of care & feeding for either, but Julia just didn't catch on quickly enough and will probably always be playing catch-up. Julia/Python/R is even earliest in the name Ju-Py-te-R, although that now supports like 40 PLs and "notebook" is probably a reference to the 1991 Mathematica 2.0 Notebook Front End (and obviously it was mostly just a coining/play on words, not "priorities"). Personally, I think the often trivial-to-modest extra effort to work with static types is worth the effort both for correctness, specificity and performance, but 95+% of REPL-oriented systems (by number not mindshare - more like 99.9+% by mindshare) are lax/dynamic about types by default except maybe the Haskell Hugs interpreter and a few other exceptions. Cython w/cdef | Common Lisp with (declare) do at least allow gradual typing, and arguably the "type stable/not" flavors of Julia battles are roughly in that camp. Like most "defaults", most people just use the default even if other things are available, though. That's why to me it's worth making users be a little more explicit like Nim does. Anyway, I am just discussing alternatives floating about, not trying to be disputatious. Mostly people / scientists use whatever their colleagues do in a network effects way, with ever so occasionally generational shifts. Sometimes research communities are held hostage not just to a specific programming language, but rather to a very specific code base - certain kinds of simulators, reaction kinetics engines, and so forth. (TensorFlow or PyTorch might be a contemporary analogue more HN folk could relate with.)