CSV Reader Benchmarks: Julia Reads CSVs 10-20x Faster than Python and R

So, "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.... 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 :

> 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?

Yes it is possible to make those changes and even if it wasn't it does not detract from the impressive and useful innovations Julia has made. That is why I usually refer to them as cosmetic but that is possibly not the correct word either because it does not convey the implications of having that default beyond simply being unattractive. Cultural may be the correct term.

Julia claims that it wants to solve the two language problem. To do that it must win both the scientific compute, HPC, data science, machine learning, etc. group and the CS, software engineering, dev ops group. I've shown Julia to quite a few members of the latter and they always love the idea and technical capabilities of Julia but visibly cringe when they find out it uses one based indexing. They also almost universally find the syntax ugly.

Unfortunately the available packages to change that also does not help because most people will never change the defaults and IMHO it would be bad to do so. When writing Python you follow the PEP-8 style guide, it is just best practice to follow the languages conventions so everyone is on the same page. This is the same problem with C++ trying to add all these new features and a solid package manager like Rust has, it will never fly, people just won't use it everywhere, it isn't going to be in the standard library, It isn't the default and it isn't part of the culture.

One is R&D, and one is operations. Obviously there are situations where it makes sense to combine them, but most successful companies with any real technology to sell will not treat R&D this way.