5 ms·

That is fair enough, but using Python as glue with existing C libraries is the acknowledged use case for Python. I think it is even admitted in this thread. Bu

by klabdn 2y ago

That is fair enough, but using Python as glue with existing C libraries is the acknowledged use case for Python. I think it is even admitted in this thread. But for that use case the claimed performance improvements in pure Python (which I can rarely replicate) are not relevant. They could leave the interpreter as it was for +20 years. For web applications, migrating to Go or PHP should not require much thought apart from overcoming one's inertia. Hopefully the scientific stack will be rewritten in better languages like Go, Lisp, Ocaml, etc.

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 ago
  Common 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 ago
    Elegant tools for a more civilised age.
- cb321 2y ago
  Julia 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.)
tliltocatl 2y ago
> Hopefully the scientific stack will be rewritten in better languages like Go, Lisp, Ocaml, etc. You are talking about people who still use Fortran… Scientists ain't got any time to migrate to another framework every week.
- bayindirh 2y ago
  FORTRAN is actually still developed and wicked fast for the things its users do with it. It's neither left behind nor obsolete.
  - tliltocatl 2y ago
    Exactly, but it's undeniable that even updated it does have some ergonomics issues. It just that its users care less about developer ergonomics. Afaik, there were plenty of attempts to build a replacement (i. e. Fortress), didn't catch on.
    - pantsforbirds 2y ago
      Fortran is in a weird spot. It's incredible for writing the hardest parts of the programs it's used for, but it honestly sucks for doing the "boring" parts. Doing heavy vectorized workloads in Fortran is nice, but doing I/O, organizing code, using any data structure that isn't essentially an array of some sort, etc. all suck.
      - pklausler 2y ago
        It’s a great language for calculating things, not so great for doing things.
    - igouy 2y ago
      > plenty of attempts to build a replacement Chapel vs Fortran https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/chapel-ifx.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/... Julia vs Fortran https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/julia-ifx.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
quotemstr 2y ago
What about Julia? Fie numeric code, not sure why I'd reach for Go first
- igouy 2y ago
  https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/chapel-julia.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
- physicsguy 2y ago
  I had bad experiences trying to productionise Julia code in the past. I realise the pre-compilation JIT-ing story is now quite different but it left a bad taste in my mouth with the community basically saying that it wasn't a problem when it quite clearly was.

by klabdn 2y ago

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 ago
Common 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 ago
  Elegant tools for a more civilised age.
cb321 2y ago
Julia 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.)

tliltocatl 2y ago

> Hopefully the scientific stack will be rewritten in better languages like Go, Lisp, Ocaml, etc. You are talking about people who still use Fortran… Scientists ain't got any time to migrate to another framework every week.

bayindirh 2y ago
FORTRAN is actually still developed and wicked fast for the things its users do with it. It's neither left behind nor obsolete.
- tliltocatl 2y ago
  Exactly, but it's undeniable that even updated it does have some ergonomics issues. It just that its users care less about developer ergonomics. Afaik, there were plenty of attempts to build a replacement (i. e. Fortress), didn't catch on.
  - pantsforbirds 2y ago
    Fortran is in a weird spot. It's incredible for writing the hardest parts of the programs it's used for, but it honestly sucks for doing the "boring" parts. Doing heavy vectorized workloads in Fortran is nice, but doing I/O, organizing code, using any data structure that isn't essentially an array of some sort, etc. all suck.
    - pklausler 2y ago
      It’s a great language for calculating things, not so great for doing things.
  - igouy 2y ago
    > plenty of attempts to build a replacement Chapel vs Fortran https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/chapel-ifx.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/... Julia vs Fortran https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/julia-ifx.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

quotemstr 2y ago

What about Julia? Fie numeric code, not sure why I'd reach for Go first

igouy 2y ago
https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/chapel-julia.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
physicsguy 2y ago
I had bad experiences trying to productionise Julia code in the past. I realise the pre-compilation JIT-ing story is now quite different but it left a bad taste in my mouth with the community basically saying that it wasn't a problem when it quite clearly was.