Deep learning may need a new programming language

Python ML code is a bit of a joke. If you're any kind of semi professional developer who sees deep learning code for the first time and doesn't say "what the fuck would you do it like that for", I simply don't know what to tell you.

Im not saying a new language will fix this problem but some new primitives and idiomatic options protecting people from themselves probably wouldn't hurt the industry.

Likewise, something more ergonomic might actually improve onboarding new developers into the space.

There are two types of ml jobs. One for modeling and another for computation. The former deals with the communication with human. The latter deals with the communication with machines. I would prefer that a statistical logic programing language (maybe extended from prolog) for the modeling part. A strong compiler tool or service that compiles it into any machines, on cloud or edge. Most of the time, what human likes to achieve is small and declarative. But for any small modifications of the program, we have to think about the computational flow, deal with the type errors and tune the low level efficiency of CPU and GPU. It's a waste.

I like the settings of SQL where modelers use SQL to mine data while engineers maintain the performance of the computational engines.

On GPGPU programming certainly not, in fact latest NVidia's hardware is designed explicitly for C++ workloads.

On GUI frameworks, C++ no longer has the spotlight on OS SDKs that it once had.

One of the major reasons why many researchers never cared for OpenCL.

It is indeed one of the few existing languages appropriate for generic experimentation in numeric programming.

For example, computing the product of two matrices in C or Fortran is exactly as fast by writing three nested loops or by calling a library function. In python, julia, octave, etc, the difference is abysmal. This is a very sad state of affairs, that forces a mindset where you are allowed a limited toolset of fast operations and the rest are either slow or cumbersome. If you want to compute a variant of the matrix product using a slightly different formula, in Fortran it is trivial change, you just write the new formula inside the loop. But in python or julia you are stuck with either an unusably slow code or you have to write it in another language entirely.

"Vectorized" operations are cool, elegant, and beautiful. But they should not be the only tool available. As differential geometers often resort to coordinates to express their tensor operations, so should programmers be able to.

I do believe that he/she meant that they need way higher levels of abstraction than Python.

Let's say Python is current C, they want something X that's like Ruby in compare to current C.

That strikes me as an anti-pattern although you could mimic this behaviour by exposing each one at the package level. Performance is likely to be terrible if you're working on anything sufficiently large.

When you create a .py file, the CPython interpreter treats it as a "module". You can basically treat a Python "module" as if it were a class because the global variables are automatically scoped unless you import them explicitly. You could actually write some code that would allow you to instantiate the entire module in the same manner you would instantiate a class. Though, I have no idea where this pattern would be useful.

* features: you have an extensive standard library, macros, high level constructs (like generators, asynchronous programming, ...)

* performance: julia is based on LLVM and as long the code is type-stable and avoids memory allocation in hot loops, the performance is similar to C or Fortran.

* usability: you can also program at a very high level like you would do in matlab or python/numpy.