It is not typesave and doesn’t really support programming in the large. I think the best bet is something like Swift or Microsoft could come out with a C#/F# compatible thing.
To be fair, while that's true I think what's meant here is that Python is the language of choice for using Tensorflow and PyTorch. Probably no other language is used to interface with deep learning libraries and primitives as much as Python.
Im sorry, but this very much feels like a fluff piece. Yes we _may_ need a new programming language, or we may not.
Half of this article is about hardware, while only a small part of it is about programming languages.
> There are several projects at Google, Facebook, and other places to kind of design such a compiled language that can be efficient for deep learning, but it’s not clear at all that the community will follow, because people just want to use Python
Are the libraries not implemented in native code? The brief mention that python gets does not really detail what is wrong with it, aside from not beeing compiled I guess. But that is no issue if the libraries are native, so I dont see a reason to move away from python, let alone create a new programming language for it
You don't have to check baby's diaper to know they went number 2.
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.
The libraries are native code in a similar sense to python being native code. The kernels are native and typically highly optimised but there is a possibility that better optimised kernels can be generated on the fly once the computational graph is known.
The main problem, imho, is that (for best performance) most libraries require the programmer to create a data flowgraph, and to think in terms of this graph. However, this is the perfect job for a compiler. In mainstrain compilers, dataflow analysis has traditionally been the task of the compiler, so it seems silly to break with this tradition. A new (compiled) language could bring us back on track.
I'd probably argue the opposite. Dataflow is a natural way to think about ML activities. The problem is that no mainstream languages offer dataflow as a first class construct; at best it's a set of libraries. That creates some impedance mismatch between intent and implementation. That compilers already do dataflow under the covers would hopefully mean that implementing a first-class dataflow language wouldn't be too hard.
There's already Nim (https://nim-lang.org/), which is Python like syntax and statically typed, with easy parallelisations etc already. What's lacking is the adoption as it wasn't hyped up. There's rarely a need to create yet another language and wait till it becomes mature and fixed all the issues with the eco system etc. If at all what's required is a way of translating all the Python libs to Nim or some similar effort.
I'd much rather a deep learning system that could handle simplified natural language and file operations, and then grow a network for specific tasks. Surely the point of AI is to liberate humans from having to write everything in code, and especially from needing to learn another language (which he fairly observes few people want to do).
I do everything flow-based these days. It's not the fastest way (and I also have the luxury of not having to please anyone but myself), but it allows me to only think about my domain problem instead of programming language issues.
Maybe not quite what you have in mind, but I have tried saving trained Keras models, loading them with Racket (a modern Scheme language), and implemented the required runtime. My idea was to encapsulate trained networks like ‘functions’ for use in other languages.
> Fortran is going to make a big comeback. I can feel it.
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.
We may need a programming language for DL, but I doubt it'll happen soon, if it even happens. Lindy effect working in favor of Python here, as many data scientists have prior "big data" experience in it, and typical software engineers from the "scripting/tooling" world.
People have been calling for the phaseout of C/C++, but even today's most popular DL frameworks have backends written in C++ in lieu of Rust.
> Deep learning may need a new programming language that’s more flexible and easier to work with than Python
Whoever has imagination more rich than mine, how can a programming language can be easier than Python? What's difficult in it?
The only thing I find inconvenient in Python is you can't simply put every function (including every member functions of a class - that's what I would love to do) in a separate file without having to import every one of them manually.
>The only thing I find inconvenient in Python is you can't simply put every function (including every member functions of a class - that's what I would love to do) into separate file without having to import every one of them manually.
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.
> The only thing I find inconvenient in Python is you can't simply put every function (including every member functions of a class - that's what I would love to do) in a separate file without having to import every one of them manually.
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.
[+] [-] xvilka|7 years ago|reply
[1] https://julialang.org/
[2] https://juliacomputing.com/domains/ml-and-ai.html
[+] [-] supernes|7 years ago|reply
[+] [-] xuejie|7 years ago|reply
[+] [-] unknown|7 years ago|reply
[deleted]
[+] [-] orbifold|7 years ago|reply
[+] [-] ovi256|7 years ago|reply
The state of journalism today ... their Github repo web pages show that there's more C++ than Python in both repos.
[+] [-] throwawaymath|7 years ago|reply
[+] [-] sandGorgon|7 years ago|reply
Facebook will obviously go its our own way. Given their investments in the JS ecosystem, im hoping they end up choosing Typescript for this.
[+] [-] dtech|7 years ago|reply
[+] [-] thecatspaw|7 years ago|reply
Half of this article is about hardware, while only a small part of it is about programming languages.
> There are several projects at Google, Facebook, and other places to kind of design such a compiled language that can be efficient for deep learning, but it’s not clear at all that the community will follow, because people just want to use Python
Are the libraries not implemented in native code? The brief mention that python gets does not really detail what is wrong with it, aside from not beeing compiled I guess. But that is no issue if the libraries are native, so I dont see a reason to move away from python, let alone create a new programming language for it
[+] [-] lugg|7 years ago|reply
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.
[+] [-] dan-robertson|7 years ago|reply
[+] [-] amelius|7 years ago|reply
[+] [-] spinningslate|7 years ago|reply
[+] [-] posnet|7 years ago|reply
As well as that esolang that appeared a few months ago on the front page. https://github.com/mrakgr/The-Spiral-Language
[+] [-] unknown|7 years ago|reply
[deleted]
[+] [-] widforss|7 years ago|reply
[+] [-] Kip9000|7 years ago|reply
[+] [-] dunefox|7 years ago|reply
[+] [-] pts_|7 years ago|reply
[+] [-] pjmlp|7 years ago|reply
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.
[+] [-] risubramanian|7 years ago|reply
[+] [-] dunefox|7 years ago|reply
[+] [-] anigbrowl|7 years ago|reply
I do everything flow-based these days. It's not the fastest way (and I also have the luxury of not having to please anyone but myself), but it allows me to only think about my domain problem instead of programming language issues.
[+] [-] mark_l_watson|7 years ago|reply
[+] [-] codetrotter|7 years ago|reply
[+] [-] melling|7 years ago|reply
https://www.bloomberg.com/news/articles/2019-02-18/facebook-...
https://www.ft.com/content/1c2aab18-3337-11e9-bd3a-8b2a211d9...
[+] [-] henning|7 years ago|reply
[+] [-] pjmlp|7 years ago|reply
One of the major reasons why many researchers never cared for OpenCL.
[+] [-] enriquto|7 years ago|reply
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.
[+] [-] tzhenghao|7 years ago|reply
People have been calling for the phaseout of C/C++, but even today's most popular DL frameworks have backends written in C++ in lieu of Rust.
[+] [-] qwerty456127|7 years ago|reply
Whoever has imagination more rich than mine, how can a programming language can be easier than Python? What's difficult in it?
The only thing I find inconvenient in Python is you can't simply put every function (including every member functions of a class - that's what I would love to do) in a separate file without having to import every one of them manually.
[+] [-] klmr|7 years ago|reply
[+] [-] 4233456|7 years ago|reply
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.
[+] [-] tjpnz|7 years ago|reply
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.
[+] [-] scriptkiddy|7 years ago|reply
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.
[+] [-] slack3r|7 years ago|reply
[+] [-] wenc|7 years ago|reply
[+] [-] thosakwe|7 years ago|reply
[+] [-] pi-victor|7 years ago|reply
but python is really popular and easy to grasp. you'll end up writing a new programming language and people would still use python in the end.
[+] [-] kensai|7 years ago|reply
[+] [-] return0|7 years ago|reply