Slashdot Mirror

← Back to Stories (view on slashdot.org)

Deep Learning May Need a New Programming Language That's More Flexible Than Python, Facebook's Chief AI Scientist Says (venturebeat.com)

Posted by msmash on from the in-pursuit-of-a-better-language dept.

Deep learning may need a new programming language that's more flexible and easier to work with than Python, Facebook AI Research director Yann LeCun said today. From an interview: It's not yet clear if such a language is necessary, but the possibility runs against very entrenched desires from researchers and engineers, he said. LeCun has worked with neural networks since the 1980s. "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," LeCun said in a phone call with VentureBeat. "The question now is, is that a valid approach?" Further reading: Facebook joins Amazon and Google in AI chip race.

41 of 263 comments (clear)

  1. What we need is... by Anonymous Coward · · Score: 3, Insightful

    What we need is less Facebook, less Google, less Amazon.

    1. Re: What we need is... by king+neckbeard · · Score: 2

      In all fairness, a lot of that was bought by Google instead of created by them, and so, someone else likely would have filled the same niche.

      --
      This is my signature. There are many like it, but this one is mine.
  2. Easy by mobby_6kl · · Score: 4, Funny

    Just use C++

    1. Re:Easy by Anonymous Coward · · Score: 4, Insightful

      True, but even C/C++ and Assembly doesn't provide an "easy" way to do threading, which is the issue.

      Scripting languages, basically do not do threading, of any kind, at all. They're too slow to synchronize across threads, which makes invoking threads inside them fruitless.

      While C is ultimately the right language to do everything in (not C++) , the real issue is that cpu's are expanding in cores, just like GPU's have, yet GPU's have standardized more or less on just three API's, OpenGL, Direct3D and Vulkan. So if you can write a program against Vulkan, you have as close to bare hardware as you are going to get. But for CPU's, there is still a 57 flavors of rubbish programming languages and no standard runtime that works for all of them, at best most of these programming languages are still developed in C or C++ and thus require a complete C AND C++ runtime to function.
      Python is not written in Python. Java is not written in Java. If a language can not compile itself, it's not flexible enough to be used for any of the three main corner stones of software development: Operating Systems, Applications, and Games. While you certainly can write an application or game with a scripting language, it will be slow, it will be limited by the operating system's own libraries (eg 32-bit libraries on a 64-bit OS as just one example) and generally require more maintenance than simply writing it in C to begin with.

      Memory overflow errors are caused by people learning programming languages like Java first instead of C, because if you learn C first, you then learn how to initialize memory, and how big memory chunks actually are.

    2. Re: Easy by Anonymous Coward · · Score: 4, Funny

      Ostensibly, yes. Honestly, most of it was hacked together with Perl.

    3. Re:Easy by thereddaikon · · Score: 5, Insightful

      True, but even C/C++ and Assembly doesn't provide an "easy" way to do threading, which is the issue.

      Nothing is easy to multithread in because multithreading anything more than the most basic of processes is inherently complex. This doesn't apply to SIMD structures which is the main reason why GPU's can be so parallel. One pixel doesn't care what color the other one is.

      While C is ultimately the right language to do everything in (not C++) , the real issue is that cpu's are expanding in cores, just like GPU's have, yet GPU's have standardized more or less on just three API's, OpenGL, Direct3D and Vulkan. So if you can write a program against Vulkan, you have as close to bare hardware as you are going to get. But for CPU's, there is still a 57 flavors of rubbish programming languages and no standard runtime that works for all of them, at best most of these programming languages are still developed in C or C++ and thus require a complete C AND C++ runtime to function.

      A lot to disect here. So for starters APIs and languages aren't the same thing and the main graphics APIs can be interfaced with multiple languages, I've seen programs written in everything from Javascript, Python, C, and Java interface with the OpenGL api. Second, there is no such thing as a C/C++ runtime. Runtimes only exist in interpreted languages like JS with its DOM or in ones that compile to byte code for a nonexistent VM like Java. C/C++ compile to binary for a given architecture. That's the fundamental difference between compiled and interpreted languages.

      Python is not written in Python.

      Actually, some runtimes are.

      If a language can not compile itself, it's not flexible enough to be used for any of the three main corner stones of software development: Operating Systems, Applications, and Games.

      I don't know about flexibility, one of the biggest strengths of these dinky languages is their flexibility. Their biggest weakness however is a lack of efficiency and performance. If you had said they are unsuitable due to performance issues or an inability to run direct on the metal then I would agree with you. It's impossible to write an OS kernel that runs on a real machine by itself in javascipt or python. It cant be done because they both require JITs to work.

      While you certainly can write an application or game with a scripting language, it will be slow,

      Not a guarantee, but likely depending on complexity. There have been many successful games written in Java, minecraft for example.

      it will be limited by the operating system's own libraries (eg 32-bit libraries on a 64-bit OS as just one example) and generally require more maintenance than simply writing it in C to begin with.

      Eh, any program referencing external libraries has this problem. See issues with old C++ programs referencing deprecated Win32 APIs trying to run in Windows 10. However it is possible with some careful coding and luck to write a complex application that can work for decades unmodified in C. The same cannot be said for JS. If you write something complex in JS and dont touch it, three years later it wont work. This is especially true if you use some idiotic technology like NPM. Because storing your dependencies in the cloud is a great idea.

      Memory overflow errors are caused by people learning programming languages like Java first instead of C, because if you learn C first, you then learn how to initialize memory, and how big memory chunks actually are.

      While I do appreciate C, I think you give it too much credit. For one any serious Java programmer has to learn memory management eventually because the built in garbage collection is trash and once you get to a certain complexity level its no longer good enough. On top of that C's memory model is not an accurate representation of how a computer's memory model works anyways. I think this is one of C and C++'s biggest weaknesses and contributes to many of the mistakes programmers make in regards to memory management when using them.

    4. Re:Easy by Pseudonym · · Score: 4, Informative

      Second, there is no such thing as a C/C++ runtime.

      Yes, that thing called crt0 that you've seen all your life is an illusion.

      On a modern CPU, the C runtime doesn't have to do much. It has to set up the stack, argc/argv/envp, atexit handlers, and a few more random things. But it very much exists.

      Also consider that C compilers are allowed to generate calls to memcpy if you assign a large struct or something, and many of them do.

      --
      sub f{($f)=@_;print"$f(q{$f});";}f(q{sub f{($f)=@_;print"$f(q{$f});";}f});
    5. Re:Easy by serviscope_minor · · Score: 4, Interesting

      Just use C++

      Indeed, and the library you want in particular is called DLib.

      http://dlib.net/

      Specifically:

      http://blog.dlib.net/2016/06/a...

      the networks are represented as templates. It's pretty cool and very high performance. Particularly impressive given the relative resources invested relative to Tensorflow and PyTorch/Caffe.

      --
      SJW n. One who posts facts.
    6. Re: Easy by reanjr · · Score: 4, Insightful

      Threading in ANSI C is pretty straightforward. There are inherent complexities in multithreaded code, but those can't be ignored by any language. In the context of what C code looks like, I think the threading interface is about as simple as you can get. Do you have any examples of a simpler model?

    7. Re:Easy by phantomfive · · Score: 2

      Everyone is already using C++ when they need efficiency, even Google. Tensorflow is C++ then they use python for the times when efficiency doesn't matter.

      --
      "First they came for the slanderers and i said nothing."
    8. Re:Easy by Dunbal · · Score: 4, Informative

      There is no easy way to do threading, by its very nature. It's not a language thing, it's a computer thing. If more than one thread is trying to access the same resource at the same time the headaches begin: who goes first, how do you get the threads to accept its place in the queue and "know" when the other is done, etc, etc, etc. Languages that support memory locking of course make things easier but you still have to think the program through very clearly and often you end up with rather unusual and not reproducible bugs.

      However I posit that many people who use higher level languages have no actual idea of how a computer works or what they are actually doing, unlike us old timers who grew up with assembler.

      --
      Seven puppies were harmed during the making of this post.
    9. Re: Easy by Anonymous Coward · · Score: 3, Insightful

      To recap: The first comment mentioned the C/C++ runtime, i.e. the distributable implementation of the standard, providing things like malloc. The second comment misinterpreted this to mean a runtime environment, e.g. the java executable, or the .NET common language runtime (CLR). The third comment noted that the second comment was mistaken, and once again referred to the runtime. Then your comment again mistakes that for runtime environment

      Conclusion: Words are hard.

      Captcha: obvious.

    10. Re:Easy by K.+S.+Kyosuke · · Score: 2, Informative

      Scripting languages, basically do not do threading, of any kind, at all. They're too slow to synchronize across threads, which makes invoking threads inside them fruitless

      Bullshit. You CAN do asynchronously loading of assets with JavaScript.

      Asynchronous and multithreaded programming are two different things. Concurrency is NOT the same thing as parallelism.

      --
      Ezekiel 23:20
    11. Re:Easy by raymorris · · Score: 2, Informative

      The following is the C runtime, crt0. It is 9 lines of assembler: .text .globl _start

      _start: # _start is the entry point known to the linker
              mov %rsp, %rbp # setup a new stack frame
              mov 0(%rbp), %rdi # get argc from the stack
              lea 8(%rbp), %rsi # get argv from the stack
              call main # %rdi, %rsi are the first two args to main

              mov %rax, %rdi # mov the return of main to the first argument
              call exit # terminate the program

      Compare the millions of lines in a the Java runtime.
      C has a runtime like Wiz Khalifa has boobs.

    12. Re: Easy by Pseudonym · · Score: 3, Informative

      To a compiler writer (which is where I got my start) a compiler's runtime is any code that is needed to run a program but isn't generated by the compiler when an end user compiles their program.

      C runtimes used to be a lot bigger than they are now. In the days of MS-DOS, you couldn't assume the presence of a FPU, so floating point was often compiled into calls into the FP runtime. Even today, microcontrollers often don't have instructions which directly implement basic C operations (e.g. 64 bit integer division) so these operations are typically compiled as calls to runtime routines.

      As CPUs get more powerful, C runtimes get smaller. But to say there's no such thing is flatly untrue.

      --
      sub f{($f)=@_;print"$f(q{$f});";}f(q{sub f{($f)=@_;print"$f(q{$f});";}f});
    13. Re:Easy by Anonymous Coward · · Score: 2, Insightful

      You are approaching the problem in the wrong way.

      You capture the problem with this line "If more than one thread is trying to access the same resource at the same time the headaches begin".

      By far the best solution is to avoid this issue in the first place. I.e. write in a functional style, prefer immutability over mutability, and don't share mutable state in concurrent code. Then you will find that reasoning about concurrent code is much much easier.

      Of course, C doesn't really support this paradigm, which is why having written in C for 20+ years I think that it is a poor language.

      Every time I see another bug due to code written in C or C++ due to a buffer overrun, I let out depressed sigh, because I know that someone who is either arrogant or inexperienced is going to stay that the problem is with the programmer rather than the language.

    14. Re: Easy by goose-incarnated · · Score: 2

      You clearly don't understand C, or what constititues a runtime environment.

      Read the standard; there is a C runtime in any hosted implementation. The standard literally refers to a runtime, calling it the hosted implementation. The same is true for C++.

      For freestanding implementations a smaller runtime is compiled in.

      --
      I'm a minority race. Save your vitriol for white people.
  3. Yes, you could call it Smalltalk, or perhaps lisp by williamyf · · Score: 2

    or perhaps prolog...

    --
    *** Suerte a todos y Feliz dia!
  4. There are only two options here... by Etcetera · · Score: 4, Funny

    ... for building Skynet, and it'll be Lisp or perl.

    And we all know which one the Lord used: https://xkcd.com/224/

    --
    Hire a Linux system administrator, systems engineer,
  5. Dumping Python Is Both And Easy And Lucrative by L_R_Shaw · · Score: 5, Insightful

    Over the past few months I have spoken to a few recruiters I know who were asking me to give them all the senior C++ engineers I know or if I personally was interested.

    In what?

    Doing complete rewrites of giant mountains of garbage Python code written by twenty something year old hipsters or older researcher type people.

    It is boring as fuck work but companies and organizations are desperate and willing to pay huge amounts of money to rid themselves of the clusterfuck that is Python.

    1. Re:Dumping Python Is Both And Easy And Lucrative by ShanghaiBill · · Score: 5, Insightful

      If I have to choose, I'll deal with giant mountains of garbage Python over even a small hill of garbage C++

      That is backwards.

      Python is great. I use it all the time. For scripts. Small programs that are fast to write, easy to read, and avoid all the complexity of type checking and memory management. Python is also easy to learn. It is taught in elementary schools.

      But for a 200,000+ line project written by a team, with coders coming and going during the project, Python is a very poor choice. "Quick and easy" doesn't scale. For big projects you need rigid type checking, complex data structures, fine tuned encapsulation, compile time error checking, static and dynamic analysis, verifiable memory allocation and release, etc. C++ has all of that, Python does not.

      So you want to use C++ for the "giant mountains" of code. Python is for the "small hills".

    2. Re:Dumping Python Is Both And Easy And Lucrative by tomhath · · Score: 5, Insightful

      Those companies should be thankful they aren't rewriting giant mountains of garbage C++ code written by twenty something year old hipsters or older researcher type people.

    3. Re:Dumping Python Is Both And Easy And Lucrative by doom · · Score: 2

      For big projects you need rigid type checking, complex data structures, fine tuned encapsulation, compile time error checking, static and dynamic analysis, verifiable memory allocation and release, etc.

      So you're arguing for a less flexible language. Yann LeCun suggests we might need a more "flexible and easy to work with" than Python.

      Why he thinks that's the case is not touched on at all in this article, which makes it an unusually inane story even for slashdot.

    4. Re:Dumping Python Is Both And Easy And Lucrative by Dunbal · · Score: 2

      Kind of like driving, really :)

      --
      Seven puppies were harmed during the making of this post.
  6. Julia anyone? by jgfenix · · Score: 5, Insightful

    I think it fits the requirements quite well.

    1. Re:Julia anyone? by TimothyHollins · · Score: 5, Interesting

      Julia has a tremendous problem. It's not designed for users, it's designed for Julia designers. If they had said "let's create an environment for deep learning that is great for threading" everything would be fine. But instead they went with "Hey, let's do all those awesome and cool things that we always wanted to see in a programming language and also it should be great with deep learning and implicit threading". The result is a (possibly great) environment that takes far too long to learn, has way to many individual quirks and ways of doing things that differ from the standard approach, and just is a bitch to intuitively understand.

      The environment may or may not be great, but the designers made sure that you couldn't just pick it up and go, you have to go "ahaaaa so that's how you do that" for every single thing. And when the option is using Python/R that you already understand or use Julia that you have to learn from scratch, the choice is easy, especially for the people that are scientists and not programmers at heart - which is the exact audience that Julia is targetting.

    2. Re:Julia anyone? by thejam · · Score: 4, Informative

      You can absolutely use Julia productively without getting into all the extra stuff. You can write code similar to Matlab or Numpy. Later, when you want more performance, you can delve into types more. Admittedly, the documentation emphasizes the multiple dispatch sophistication, and maybe Julia has a longer on-ramp than Python. In the past Julia was evolving very quickly, but now that 1.0 has been released, you can stick with that. But there is no other new language that has as strong a community dedicated to readable, powerful high-performance numerics. And the appeal of Julia is not that it does what currently Python or R can, but it's a better place for libraries to written by experts in the language itself. I can't think of a better language for doing research in numerical optimization, when you're really exploring new ideas and not just plugging into someone else's canned, but confining, "solutions". Most Python numerical libraries must, for performance, ultimately rely on C or C++ underneath, so becoming expert at Python does not help you in contributing to new high performance libraries. By contrast, high performance libraries for Julia can be written in Julia itself, so therefore Julia can be a very good long term investment. Please, tell me what high performance Python numerical libraries are written in Python, without C or C++?

    3. Re:Julia anyone? by qdaku · · Score: 3, Interesting

      Futhark looks cool: https://futhark-lang.org/ and promising in this realm.

      "Futhark is a small programming language designed to be compiled to efficient parallel code. It is a statically typed, data-parallel, and purely functional array language in the ML family, and comes with a heavily optimising ahead-of-time compiler that presently generates GPU code via CUDA and OpenCL"

      the ML family of languages being things like Standard-ML, Haskell, OcaML.

    4. Re:Julia anyone? by Anonymous Coward · · Score: 5, Interesting

      You can write code similar to Matlab

      MATLAB is a terrible example of an "easy to learn" language. It's full of shitty hacks like "putting a semicolon after an expression suppresses output; deleting the semicolon causes the expression to dump its output to console." It's loaded with arcane semantics like the differences between a normal array and a cell array. For fuck's sake, it permits semicolons in the middle of a parameter list, like this.

      MATLAB has the quintessential property of an overdesigned language, which is: if I leave it alone for a few months and come back to it, I have to re-learn the whole damn thing. The syntax, the library, and the UI are all unintuitive and illogical. I rely heavily on my cheatfile that I've built up from this iterative exercise to get back up to speed faster. I don't have to do that with Python or C.

      or Numpy

      Numpy is a terrible example of an "easy to learn" API. Numpy arrays use semantics that are logically similar to Python arrays - but of course they're nothing like each other, none of the libraries work the same way, etc. And And some core features are so poorly documented that you have to dig through sample code until you find something that vaguely resembles what you wanna do, and then shoehorn it into the shape you want. And if you want to stare into the abyss of insanity, try looking into using the Numpy array-sharing options to circumvent the cross-thread limitations of the Python global interpreter lock.

      Don't get me wrong: both are powerful and fun when you're acclimated to them. My first Numpy experience was porting a super-simple image processing technique, and my amateur, first-attempt Numpy code finished 10,000 times faster, and that's not an exaggeration. But they're both crappy languages from a model-of-clarity-and-consistency perspective.

    5. Re:Julia anyone? by Pseudonym · · Score: 4, Informative

      Julia has a tremendous problem. It's not designed for users, it's designed for Julia designers.

      I have to disagree with that. Julia is designed for users, but it knows that its use case is not Python's use case.

      Julia was designed as an upgrade for Fortran programmers. Like all good upgrade languages, it learned from all of the languages which tried (and failed) to replace Fortran previously, like SISAL and Fortress.

      There is a cohort of programmers for whom "the standard approach" means Python's highly idiosyncratic approach. In my (admittedly limited) experience, anyone who predates the rise of Python tends to have no problem picking up Julia.

      --
      sub f{($f)=@_;print"$f(q{$f});";}f(q{sub f{($f)=@_;print"$f(q{$f});";}f});
  7. Re:Please describe the characteristics of such a l by Pseudonym · · Score: 2

    That's because he isn't sure yet.

    Just because you are unhappy with their current tools and know through decades of experience that "more of the same" is not going to improve things, that doesn't mean you know what the future should look like.

    --
    sub f{($f)=@_;print"$f(q{$f});";}f(q{sub f{($f)=@_;print"$f(q{$f});";}f});
  8. We already have one . . . . by Patrick+May · · Score: 2

    it's called Common Lisp.

  9. Re:Yes, you could call it Smalltalk, or perhaps li by jythie · · Score: 2

    I am picturing the current crop of 'the past was stupid, never learn from it!' programmers diving into LISP, Smalltalk, or Prolog.

    But as always, designing new languages is more fun than learning old ones, and learning from past mistakes makes you uncool.

  10. So.... by Locke2005 · · Score: 2

    LISP, then?

    --
    I've abandoned my search for truth; now I'm just looking for some useful delusions.
  11. Re:So for something that needs the utmost speed. by Pseudonym · · Score: 2

    People are using scripting languages to piece together subsystems written in low-level code.

    This is the way that tasks like this have pretty much always been done. Your web browser isn't written in JavaScript, even though its performance may make it seem that way.

    --
    sub f{($f)=@_;print"$f(q{$f});";}f(q{sub f{($f)=@_;print"$f(q{$f});";}f});
  12. What's wrong with python? by bahwi · · Score: 3, Interesting

    I mean, sure, a single data processing pipeline might have to use 6 different conda environments, each with different dependencies and python versions due to tool and libraries are often deprecated with even minor point changes to python versions...... oh yeah, all that and then you have to shoe-horn in tensorflow (or something else).

  13. Blah blah blah by c++horde · · Score: 3, Insightful

    We heard these exact same people complain about other languages in the 1980s. They complained about Lisp, then Scheme, then Haskell. No one is forcing them to use them, and no one is forcing them to use Python. A General Purpose AI is a pipe dream that will not ever come to fruition, no matter what language you are using. Deep Learning is stuck again because there is no fundamental theory of learning. We have no idea how we learn. Neuroscience will probably discover that learning is a very biological trait, not one that can be copied or simulated in discrete mechanical systems.

    1. Re:Blah blah blah by Gravis+Zero · · Score: 2

      Deep Learning is stuck again because there is no fundamental theory of learning. We have no idea how we learn.

      Actually, we know how learning works just fine. They are called neural networks and our implementations of them work as expected.

      In truth, what we don't understand is how to build neural networks that give rise to a general intelligence. My theory is that predefined (via evolution) generic brain structures that segment every animal brain is the key to general intelligence while hardwired instincts drive the advancement of general intelligence.

      Neuroscience will probably discover that learning is a very biological trait, not one that can be copied or simulated in discrete mechanical systems.

      That's a very silly argument because absolutely anything can be simulated.

      --
      Anons need not reply. Questions end with a question mark.
  14. Re:Yes, you could call it Smalltalk, or perhaps li by K.+S.+Kyosuke · · Score: 2

    Nah, C# with they yield style of automatically doing multi-threading

    I know next to nothing about C#, but I was under the impression that this was a concurrency mechanism - basically a control flow construct - not a parallelism feature. Did something change?

    --
    Ezekiel 23:20
  15. If only ... by hvidstue · · Score: 2

    ... there was a programming language designed specifically for that

  16. Yes by raymorris · · Score: 2

    Yep. The runtime starts main(), and returns the return value of main to the OS(). So basically it does START and END.

    Everything in between is the responsibility of main(). It needs not interact with the OS at all, other than being started by the OS and telling the OS when it's done. Only for standalone programs, though - kernel modules don't need to do those two things.

    There is a very useful kernel module which does nothing but allocate some memory. That's all it does. :)
    It's used when you have a a few bytes of dodgy memory. You have that module allocate those memory addresses for it's use - and then do nothing else.