4 ms·
>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.
by 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.
- eesmith 6y agoSo, "hackers" means people who are "primarily software developers"? In that case, your statement that Python "was designed by and for hackers" is not correct. You can go back to van Rossum's 1993 paper on Python, at https://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.38.2023 https://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.38.... and see: > Python is used or proposed as an application development language and as an extension language for non-expert programmers by several commercial software vendors. It has also been used successfully for several large non-commercial software projects (one a continent away from the author’s institute). It is also in use to teach programming concepts to computer science students "non-expert programmers" and "computer science students" are not hackers by your definition, resulting in an internal inconsistency in your claim. Python indeed wasn't built for doing numerical computing in Python. But it was definitely influenced by the needs of people who 'have first-hand experience of running HPC jobs' - under the "steering" model. Here's a representative abstract from 1996, quoting https://www.osti.gov/biblio/461415 https://www.osti.gov/biblio/461415 : > We have described current approaches and future plans for steering C++ application, running Python on parallel platforms, and combination of Tk interface and Python interpreter in steering computations. In addition, there has been significant enhancement in the Gist module. Tk mega widgets has been implemented for a few physics applications. We have also written Python interface to SIJLO, a data storage package used as an interface to a visualization system named MeshTv. Python is being used to control large-scale simulations (molecular dynamics in particular) running on the CM-5 and T3D at LANL as well. A few other code development projects at LLNL are either using or considering Python as their steering shells. In summary, the merits of Python have been appreciated by more and more people in the scientific computation community. One of the authors of that presentation, Paul Dubois, was lead developer for Numerical Python, which evolved into NumPy. The needs of numeric computing, under the steering model, contributed to Python-the-language. Most recently with "@", but also the multiple slice notation a[1:3, 5:11:2] and the change to remove the three-state compare cmp(). Plus under-the-covers support for a wide range of HPC architectures. In turn, Python's support for steering numeric computing helped it make in-roads in HPC, where it remains to this day. You may call the steering model 'an ad-hoc kludge of Python and C/C++', but as I've pointed out, you have a tendency to use needless antagonisms, and that's another one of them. You're the one who claims I don't do "real" programs, only "bread-and-butter things" simply because I don't do bare-metal numeric computing software. Just how much of a multi-disciplinary effort is Julia if bare-metal numeric computing software is the only discipline it focuses on?