4 ms·

By that logic people should have kept using Fortran instead of Python (which was the new guy a couple decades ago). But Fortran will never be Python, and Python

By that logic people should have kept using Fortran instead of Python (which was the new guy a couple decades ago). But Fortran will never be Python, and Python will never be Fortran, no matter how much maturity/improvements. Because maturity means getting close to it's potential (local maxima), without the ability to drastically move to a hypothetical global maxima (without breaking all it's legacy, like a more drastic Python 2 -> 3, or adding things indefinitely until you get effectively many languages/dialects in one like C++). New languages on the other side don't have as much baggage (and can start with increased knowledge from previous attempts) so they are able to freely potentially target better local maxima that old languages cannot anymore. Plus in this particular case, Python was not really designed to target the scientific domain (nor ML which did not even exist in the way we use nowadays), it was repeatedly retrofitted with possibly a lot more effort than would be necessary to create something better from scratch.

bonoboTP 6y ago
> By that logic people should have kept using Fortran instead of Python There were very real pain points with Fortran, C++, MATLAB etc. compared to Python. Now this is hard for me to argue in a few sentences as it's a distillation of having worked with many languages, but I feel that Python strikes a great balance for productivity. It feels like pouring your thoughts directly onto the screen, with no need to fight the language. The syntax is very clear, concise, "Pythonic" is a word of praise. As I said, this kind of debate is rarely productive and devolves to religious arguments, but that's my stance. The only issue with Python is speed, but if you use Numpy properly, even that isn't a big issue. > and can start with increased knowledge from previous attempts They often don't make use of that out of a sense of pride and not invented here.
- krastanov 6y ago
  > The only issue with Python is speed, but if you use Numpy properly, even that isn't a big issue. Numpy leaves a couple of orders of magnitude of performance on the table, especially if you use small arrays and a lot of intermediary computation. It is terrible in terms of memory allocation overhead. Cython or @tensorflow.function fix much of that, but then you are not really using python anymore. > They often don't make use of that out of a sense of pride and not invented here. This is a lazy and rather hurtful accusation.
  - montalbano 6y ago
    Agree, but to add, there are many transcendental functions (e.g. I needed to use the Mittag-Leffler function many times in my work) which are near-impossible to implement in Numpy in a way that gives anywhere near usable performance. It's not a common enough function to be pre-implemented in Scipy special functions. In my case, I wrote the algorithm in Numpy/python myself which was almost unusably slow. I then outsourced it to a precompiled fortran program. Finally I just switched to Julia. There was already a library, MittagLeffler.jl which did everything I needed and was written in pure Julia. In the end everything was much faster than the Python/Fortran frankenstein code I had. Edit: For more info on Julia and difficult (computationally) mathematical functions see: https://youtu.be/mSgXWpvQEHE?t=1262 https://youtu.be/mSgXWpvQEHE?t=1262
    - krastanov 6y ago
      And, unlike in many other languages, that MittagLeffler julia function can probably already work efficiently on special arrays (distributed arrays, GPU arrays, etc), is fussable into inner loop kernels, and supports automatic differentiation, without extra work from the author of the package.
- jdietrich 6y ago
  >The only issue with Python is speed, but if you use Numpy properly, even that isn't a big issue. This is literally the pain point that Julia set out to solve. Nobody uses Python for real programs, they use an ad-hoc kludge of Python and C/C++. This is basically fine if you're doing bread-and-butter things that are well covered by existing libraries, but it's a serious drag if you're trying to do anything really interesting. Python still suits a lot of people and that's fine, but "mature" is very much a double-edged sword. We're in the middle of a scientific computing renaissance right now and Python really isn't keeping up; it was designed by and for hackers, but Julia is a multi-disciplinary effort.
  - eesmith 6y ago
    > Python really isn't keeping up; it was designed by and for hackers What does "hackers" here even mean? Is it just a throw-away disparaging term? Hacker has at least three distinct meanings: deeply knowledgeable software developers, shallowly knowledgeable programmers, and people who break into computer security systems. I assume you are not using the first of these, else you would likely say the Julia developers are hackers too. And you are definitely not using the third. van Rossum's training, for example, came through the language design and implementation process for ABC. Tim Peters, another early designer, worked on compilers for Kendall Square Research and Cray Research supercomputers. (Eg, https://bugs.python.org/msg303574 https://bugs.python.org/msg303574 describes developing libm for KSR, and http://stackless.com/coroutines.tim.peters.html http://stackless.com/coroutines.tim.peters.html shows his knowledge of features of Icon and Simula 67.) So already there it was a multi-disciplinary effort. What don't you say Python was designed for an era of single-core computing and for tasks where raw performance took second place to usability instead of going hand-in-hand? Seems rather more correct and less needlessly antagonistic. But you seem rather fond of needless antagonisms, as people certainly do write "real" programs all in Python.
    - jdietrich 6y ago
      >What does "hackers" here even mean? Is it just a throw-away disparaging term? No, my point is that the Julia team includes a lot of people who aren't primarily software developers. Many of the top committers to Julia are working scientists who have first-hand experience of running HPC jobs with Julia; their input is a crucial factor in the success of Julia as a numerical computing language. Python is a very good scripting language, but it's not built for numerical computing and it's not built by people who understand the needs of scientific users. It's not a bad tool, it's just the wrong tool for the particular jobs that Julia was built for.
- ddragon 6y ago
  I feel like you considering Python as having few real pain points in data science as either lack of knowledge of other languages or imagination/ambition. I do work on Python for data science/engineering in a production environment and I do find many of those all the time. Python does not feel like pouring my thoughts because I cannot write Python directly without taking hours to handle a few million points of data, so I have to juggle with multiple dialects (pandas, numpy, pytorch, tensorflow), and Python ends up being one of the languages that I need some documentation at all times. And then that documentation is also not obvious what's the input, do I need to give a tuple, or perhaps a dict or even a list because typing is very recent so the ecosystem isn't up to date and sometimes I can't even type my code properly because I legitimately don't know what a library function returns. And even with mypy I keep finding errors that I can only find after deploying (I don't blame Python on this one, and Julia isn't really better, but I can still dream of something that is dynamic when I want but still safe). Also Python for a dynamic language has pretty mediocre interactive story (using ptpython since the default repl is unusable), even simple things like copy pasting to a REPL can end up being a pain because of indenting, and the repl is far away from Lisp, Clojure and even Julia and Elixir. And Elixir also makes me especially disappointed with Python's multithreading story (in Elixir it's so natural that it really is the "pouring your throughts on the screen" for distributed). It ended up being a rant, but I have many pain points with Julia as well, but it's still a new language that has more space to evolve and find ways to solve them, and if the solution is yet another language that solves all of them, I'll quickly jump. I spend a lot of time programming, so any significant improvements on the usage of my time is worth the effort in learning.
  - bonoboTP 6y ago
    > so I have to juggle with multiple dialects (pandas, numpy, pytorch, tensorflow) NumPy should be enough for general computation. If you need autodiff or GPU then add in PyTorch. Pandas is more about various metadata than the actual numerical computing. If you want those types of features, the complexity doesn't disappear if you go to a different language. There's an effect where a new generation of developers see complexity built by the earlier generation, say it's too complicated and mess up, we don't need all that, so start over clean and it all looks so easy. But it's deceptive, because it will get complicated again once you put in all the features but it will look familiar now to this generation of developers as they grow side-by-side with the new language/framework. After a few years the cycle repeats and a new generation says "what's all this mess, why do I need to juggle all this, I just need XY." > Also Python for a dynamic language has pretty mediocre interactive story (using ptpython since the default repl is unusable), even simple things like copy pasting to a REPL can end up being a pain because of indenting, and the repl is far away from Lisp, Clojure and even Julia and Elixir. Use Jupyter Notebooks (or IPython if you don't want to leave the shell). > disappointed with Python's multithreading story Thread pools (executors, futures etc.) and process pools (multiprocessing module) work quite nicely.
- tgv 6y ago
  > The only issue with Python is speed That's a big one. Memory usage and typing are other issues. That it doesn't really run in the browser is another. Or that it has more issues than C++ when trying to write a portable GUI. It's fine for education and prototyping.
- nemothekid 6y ago
  >They often don't make use of that out of a sense of pride and not invented here. You are handwaving away a big reason why there is research into non-Python solutions. Unless you work at FAANG, or some other institution where developer time is much, much greater than compute time; simply using a more performant solution can save either in days of waiting or thousands of dollars a month in compute.
- oivey 6y ago
  There are very real pain points in Python, too. Developers tend to internalize these pain points to the extent that they’re completely blind to them, and that limits innovation. Not all interesting and fast algorithms can be vectorized. The idea behind Julia is that you can write code that should be fast, like loops, and it will be. You don’t have to bend over backwards to jam your algorithm into a C wrapper. It’s fair to question whether the trades with things like JIT compilation were worth it in Julia, but it should also be understood that NumPy is insufficient for supporting all of the interesting things you can do with arrays of numbers on a computer.
cbkeller 6y ago
I mean, A lot of people did! HPC, DiffEq, etc.* And to some degree it's these communities who are now adopting Julia, interestingly enough. *Elaborated in my other comment on GP https://news.ycombinator.com/item?id=24748107 https://news.ycombinator.com/item?id=24748107

bonoboTP 6y ago

> By that logic people should have kept using Fortran instead of Python There were very real pain points with Fortran, C++, MATLAB etc. compared to Python. Now this is hard for me to argue in a few sentences as it's a distillation of having worked with many languages, but I feel that Python strikes a great balance for productivity. It feels like pouring your thoughts directly onto the screen, with no need to fight the language. The syntax is very clear, concise, "Pythonic" is a word of praise. As I said, this kind of debate is rarely productive and devolves to religious arguments, but that's my stance. The only issue with Python is speed, but if you use Numpy properly, even that isn't a big issue. > and can start with increased knowledge from previous attempts They often don't make use of that out of a sense of pride and not invented here.

krastanov 6y ago
> The only issue with Python is speed, but if you use Numpy properly, even that isn't a big issue. Numpy leaves a couple of orders of magnitude of performance on the table, especially if you use small arrays and a lot of intermediary computation. It is terrible in terms of memory allocation overhead. Cython or @tensorflow.function fix much of that, but then you are not really using python anymore. > They often don't make use of that out of a sense of pride and not invented here. This is a lazy and rather hurtful accusation.
- montalbano 6y ago
  Agree, but to add, there are many transcendental functions (e.g. I needed to use the Mittag-Leffler function many times in my work) which are near-impossible to implement in Numpy in a way that gives anywhere near usable performance. It's not a common enough function to be pre-implemented in Scipy special functions. In my case, I wrote the algorithm in Numpy/python myself which was almost unusably slow. I then outsourced it to a precompiled fortran program. Finally I just switched to Julia. There was already a library, MittagLeffler.jl which did everything I needed and was written in pure Julia. In the end everything was much faster than the Python/Fortran frankenstein code I had. Edit: For more info on Julia and difficult (computationally) mathematical functions see: https://youtu.be/mSgXWpvQEHE?t=1262 https://youtu.be/mSgXWpvQEHE?t=1262
  - krastanov 6y ago
    And, unlike in many other languages, that MittagLeffler julia function can probably already work efficiently on special arrays (distributed arrays, GPU arrays, etc), is fussable into inner loop kernels, and supports automatic differentiation, without extra work from the author of the package.
jdietrich 6y ago
>The only issue with Python is speed, but if you use Numpy properly, even that isn't a big issue. This is literally the pain point that Julia set out to solve. Nobody uses Python for real programs, they use an ad-hoc kludge of Python and C/C++. This is basically fine if you're doing bread-and-butter things that are well covered by existing libraries, but it's a serious drag if you're trying to do anything really interesting. Python still suits a lot of people and that's fine, but "mature" is very much a double-edged sword. We're in the middle of a scientific computing renaissance right now and Python really isn't keeping up; it was designed by and for hackers, but Julia is a multi-disciplinary effort.
- eesmith 6y ago
  > Python really isn't keeping up; it was designed by and for hackers What does "hackers" here even mean? Is it just a throw-away disparaging term? Hacker has at least three distinct meanings: deeply knowledgeable software developers, shallowly knowledgeable programmers, and people who break into computer security systems. I assume you are not using the first of these, else you would likely say the Julia developers are hackers too. And you are definitely not using the third. van Rossum's training, for example, came through the language design and implementation process for ABC. Tim Peters, another early designer, worked on compilers for Kendall Square Research and Cray Research supercomputers. (Eg, https://bugs.python.org/msg303574 https://bugs.python.org/msg303574 describes developing libm for KSR, and http://stackless.com/coroutines.tim.peters.html http://stackless.com/coroutines.tim.peters.html shows his knowledge of features of Icon and Simula 67.) So already there it was a multi-disciplinary effort. What don't you say Python was designed for an era of single-core computing and for tasks where raw performance took second place to usability instead of going hand-in-hand? Seems rather more correct and less needlessly antagonistic. But you seem rather fond of needless antagonisms, as people certainly do write "real" programs all in Python.
  - jdietrich 6y ago
    >What does "hackers" here even mean? Is it just a throw-away disparaging term? No, my point is that the Julia team includes a lot of people who aren't primarily software developers. Many of the top committers to Julia are working scientists who have first-hand experience of running HPC jobs with Julia; their input is a crucial factor in the success of Julia as a numerical computing language. Python is a very good scripting language, but it's not built for numerical computing and it's not built by people who understand the needs of scientific users. It's not a bad tool, it's just the wrong tool for the particular jobs that Julia was built for.
ddragon 6y ago
I feel like you considering Python as having few real pain points in data science as either lack of knowledge of other languages or imagination/ambition. I do work on Python for data science/engineering in a production environment and I do find many of those all the time. Python does not feel like pouring my thoughts because I cannot write Python directly without taking hours to handle a few million points of data, so I have to juggle with multiple dialects (pandas, numpy, pytorch, tensorflow), and Python ends up being one of the languages that I need some documentation at all times. And then that documentation is also not obvious what's the input, do I need to give a tuple, or perhaps a dict or even a list because typing is very recent so the ecosystem isn't up to date and sometimes I can't even type my code properly because I legitimately don't know what a library function returns. And even with mypy I keep finding errors that I can only find after deploying (I don't blame Python on this one, and Julia isn't really better, but I can still dream of something that is dynamic when I want but still safe). Also Python for a dynamic language has pretty mediocre interactive story (using ptpython since the default repl is unusable), even simple things like copy pasting to a REPL can end up being a pain because of indenting, and the repl is far away from Lisp, Clojure and even Julia and Elixir. And Elixir also makes me especially disappointed with Python's multithreading story (in Elixir it's so natural that it really is the "pouring your throughts on the screen" for distributed). It ended up being a rant, but I have many pain points with Julia as well, but it's still a new language that has more space to evolve and find ways to solve them, and if the solution is yet another language that solves all of them, I'll quickly jump. I spend a lot of time programming, so any significant improvements on the usage of my time is worth the effort in learning.
- bonoboTP 6y ago
  > so I have to juggle with multiple dialects (pandas, numpy, pytorch, tensorflow) NumPy should be enough for general computation. If you need autodiff or GPU then add in PyTorch. Pandas is more about various metadata than the actual numerical computing. If you want those types of features, the complexity doesn't disappear if you go to a different language. There's an effect where a new generation of developers see complexity built by the earlier generation, say it's too complicated and mess up, we don't need all that, so start over clean and it all looks so easy. But it's deceptive, because it will get complicated again once you put in all the features but it will look familiar now to this generation of developers as they grow side-by-side with the new language/framework. After a few years the cycle repeats and a new generation says "what's all this mess, why do I need to juggle all this, I just need XY." > Also Python for a dynamic language has pretty mediocre interactive story (using ptpython since the default repl is unusable), even simple things like copy pasting to a REPL can end up being a pain because of indenting, and the repl is far away from Lisp, Clojure and even Julia and Elixir. Use Jupyter Notebooks (or IPython if you don't want to leave the shell). > disappointed with Python's multithreading story Thread pools (executors, futures etc.) and process pools (multiprocessing module) work quite nicely.
tgv 6y ago
> The only issue with Python is speed That's a big one. Memory usage and typing are other issues. That it doesn't really run in the browser is another. Or that it has more issues than C++ when trying to write a portable GUI. It's fine for education and prototyping.
nemothekid 6y ago
>They often don't make use of that out of a sense of pride and not invented here. You are handwaving away a big reason why there is research into non-Python solutions. Unless you work at FAANG, or some other institution where developer time is much, much greater than compute time; simply using a more performant solution can save either in days of waiting or thousands of dollars a month in compute.
oivey 6y ago
There are very real pain points in Python, too. Developers tend to internalize these pain points to the extent that they’re completely blind to them, and that limits innovation. Not all interesting and fast algorithms can be vectorized. The idea behind Julia is that you can write code that should be fast, like loops, and it will be. You don’t have to bend over backwards to jam your algorithm into a C wrapper. It’s fair to question whether the trades with things like JIT compilation were worth it in Julia, but it should also be understood that NumPy is insufficient for supporting all of the interesting things you can do with arrays of numbers on a computer.

cbkeller 6y ago

I mean, A lot of people did! HPC, DiffEq, etc.* And to some degree it's these communities who are now adopting Julia, interestingly enough. *Elaborated in my other comment on GP https://news.ycombinator.com/item?id=24748107 https://news.ycombinator.com/item?id=24748107