Slashdot Mirror


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

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.

263 comments

  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 Anonymous Coward · · Score: 0

      *fewer

    2. Re:What we need is... by Anonymous Coward · · Score: 0

      *more gooder

    3. Re: What we need is... by Anonymous Coward · · Score: 0

      That the goodest.

    4. Re:What we need is... by c++horde · · Score: 1

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

      Agreed.

    5. Re: What we need is... by Zero__Kelvin · · Score: 1

      I can't even imagine how different things would be without Google, and neither can you, you faux neo-luddite you.

      --
      Guns don't kill people; Physics kills people! - John Lithgow as Dick Solomon on Third Rock From The Sun
    6. Re:What we need is... by dwarf-bitch · · Score: 1

      Agreed........said the guy who works for Microsoft or HP.

    7. Re:What we need is... by Anonymous Coward · · Score: 0

      *zero

    8. Re: What we need is... by Anonymous Coward · · Score: 0

      Wut? Duckduckgo. Not like only alternative is Lycos and Yahoo anymore..

    9. Re:What we need is... by walllaby · · Score: 1

      No one is being forced to use them.

    10. Re: What we need is... by Anonymous Coward · · Score: 1

      Google, android, AI, autonomous car, digital books, youtube, chrome, maps, street View.

    11. 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.
    12. Re: What we need is... by Anonymous Coward · · Score: 0

      I remember what life was before Google. It wasn't that bad, you just had to specify your search query a bit stricter.

    13. Re: What we need is... by Anonymous Coward · · Score: 0

      That whining piece of crap. You're not going to find an easier language. Also not one with the full community around it. He's probably just pimping some corporation.

    14. Re: What we need is... by Anonymous Coward · · Score: 0

      Duckduckgo gives me shit results. Maybe if they tracked me they could personalize search results.

    15. Re: What we need is... by Anonymous Coward · · Score: 0

      Then delete your Facebook, stop Google searching and don't order from Amazon. My bet is that you use at least one of those things while criticizing them simultaneously. There's no magic involved in why these companies are successful. Look in the mirror

    16. Re: What we need is... by bjwest · · Score: 1

      Without Google, Yahoo or some other search provider would've filled the void, and things today probably wouldn't be much different. Yahoo was the dominant search provider back in the early days.

      --

      --- Keep the choice with the user..
    17. Re:What we need is... by Anonymous Coward · · Score: 0

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

      And certainly also not a programming language designed by and spawned from Facebook. What would they call it, Faeces? OOP(s) was for "Object Oriented Programming", this would be POO for "Programming Objections Obviously."

    18. Re: What we need is... by Anonymous Coward · · Score: 0

      I have never used Facebook or Amazon, and I switched from Google search to DuckDuckGo long ago. All three of those giants are still pervasive, though. Lots of people I know claim they can't live without them.

  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 jellomizer · · Score: 1

      After 2 years of R&D we finally string concatenation and parsing that isn't locking up the computer!
      What were we doing again? Oh Deep Learning algorithm. I guess we now need to figure out how to hook the code up to a data source, and maybe we can find a way to interact the the GPU Cuda cores.

      Yes, I am exaggerating. But C++ Doesn't solve that Python has with the Deep Learning Systems. Sometimes we need a non-general use programming language, that is optimized for the type of coding involved. These programming languages rarely make it on the top programming list, however when used correctly we see a real advantage with them.

      --
      If something is so important that you feel the need to post it on the internet... It probably isn't that important.
    3. Re:Easy by BringsApples · · Score: 1

      We're almost forced to ask, "What language is the humans' cerebral cortex written in?"

      --
      Politics; n. : A religion whereby man is god.
    4. Re:Easy by Anonymous Coward · · Score: 1

      Lisp

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

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

    6. 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.

    7. Re:Easy by ChatHuant · · Score: 1

      "What language is the humans' cerebral cortex written in?"

      Brainfuck, duh!

    8. Re:Easy by Anonymous Coward · · Score: 0

      The summary did say more flexible just like the article, but the quotes from LeCun didn't .. Maybe the target is actually a less flexible, domain specific language like TensorFlow.

    9. Re:Easy by balbeir · · Score: 1

      Gibberish

    10. 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});
    11. Re:Easy by Anonymous Coward · · Score: 1

      Assembly is pretty flexible.

    12. 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.
    13. Re:Easy by Anonymous Coward · · Score: 0

      Pfft! Mine is written in LOLcode.

    14. Re:Easy by Anonymous Coward · · Score: 0

      Any good examples of how c++ outshines python at machine learning/ai ? Or are you just a c++ zealot?

      I'm all about both languages and how they can be the tool to solve different problems, but do neither stack up and perhaps we need to re-approach the idea of AI in a new language?

      Great if c++ is the solution to encapsulate some of the extremely primitive ideas of AI. bad if it's just another "IF" machine based on bad decisions that can't be easily reproduced.

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

    16. Re:Easy by Anonymous Coward · · Score: 0

      Reality proves much of this wrong.

    17. 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."
    18. Re:Easy by UnknownSoldier · · Score: 0

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

      From d3wasm

      I did a couple of changes to the idTech 4 engine in order to be able to start the game before all the data have been loaded. So, along with the initial 5MB executable download, there is a first 15MB download to fetch only what is necessary to load the game engine and enter the main menu. Then, the remaining ~380MB are fetched asynchronously.

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

      I prefer C/C++ myself but you don't know what the fuck you are talking about W.R.T games and scripting:

      1. You DO realize that there is a WIDE variety of games from "idle games" and simple puzzle games to full blown First Person Shooters right?

      Are you telling me the JavaScript implementation of 2048, xkcd Sand Castle Builder, or Cookie Clicker is slow??

      2. You DO realize you can "transpile" C/C++ code into JavaScript right, such as Doom 3, using Emscripten right?

      Or how about RollerCoaster Tycoon? Here OpenRCT2 was ported to run inside a browser.

      > yet GPU's APIs have standardized more or less on just four API's, OpenGL, Direct3D, Vulkan, and WebGL.

      FTFY.

      WebGL exists to offload rendering to the GPU inside the browser. There are TONS of playable WebGL Games

      3. Lastly, Unity can target WebGL

    19. 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.
    20. Re:Easy by Dunbal · · Score: 1

      Humans aren't too good at multithreading either. Especially the ones that say they're good at it. Fortunately the human brain isn't just one CPU but a collection of processors, many of which run vital processes autonomously, otherwise we'd be fucked.

      --
      Seven puppies were harmed during the making of this post.
    21. Re: Easy by Zero__Kelvin · · Score: 1, Troll

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

      --
      Guns don't kill people; Physics kills people! - John Lithgow as Dick Solomon on Third Rock From The Sun
    22. Re: Easy by Zero__Kelvin · · Score: 0

      Ah ... I see your confusion. You don't know how C works and you think M$ specific .dlls must be "the norm." You seem to be confusing Microsoft specific names for various libraries with an actual runtime. Again, C has no "runtime" concept.

      --
      Guns don't kill people; Physics kills people! - John Lithgow as Dick Solomon on Third Rock From The Sun
    23. 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.

    24. Re: Easy by Anonymous Coward · · Score: 1

      Wut? Golang supports lightweight threading, fast gc and approaching C++ speeds. Unless you need functional, works bestest as system language.

    25. Re: Easy by Zero__Kelvin · · Score: 0

      Even if your assertion were true it would have literally nothing to do with DK. Since you have established yourself as having no clue what a runtime environment is, let me at least offer a clue. JAVA has a VM/runtime environment. A runtime environment abstracts the hardware layer. C *never* does that. Off you go now...

      --
      Guns don't kill people; Physics kills people! - John Lithgow as Dick Solomon on Third Rock From The Sun
    26. Re: Easy by K.+S.+Kyosuke · · Score: 1

      The common meaning of the word "environment" implies that "runtime" includes "runtime envuronment", as in the *environment* (set of objects or bindings) available at program's *run time*. If the environment is null, then there's no runtime enviroment, but that is mostly not the case even with C programs.

      --
      Ezekiel 23:20
    27. 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
    28. Re:Easy by Anonymous Coward · · Score: 0

      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.

      You must be terrible at writing filters.

    29. 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.

    30. Re: Easy by K.+S.+Kyosuke · · Score: 1

      So the rest of the program is expected to bring its own runtime and OS interface?

      --
      Ezekiel 23:20
    31. Re: Easy by Aighearach · · Score: 1

      C is my primary language, and I gotta say, you seem pretty confused. Somebody pointed at the C runtime, and you start crying and claiming they don't understand C. That's just daft.

      Run time, compile time. In C this is not complicated.

      If you didn't have a runtime, how would you assign constants at compile time and have them exist in RAM at runtime? Simple, you wouldn't.

    32. Re:Easy by Aighearach · · Score: 1

      All mammals have boobs.

    33. Re: Easy by Aighearach · · Score: 1

      Threading in C is pretty straighforwards.

      The problem is, it is up to the programmers, all of them, to be very careful. Threading in C is unsafe. You have to take every step carefully, or some part of the code will smash the toes of some other part.

      That's fine for me, it sounds like it is fine for you. But it gets really hard to do something like deep learning that way without risking deadlocks.

      That's why something like Go-lang is better for that sort of application; it is easier to avoid deadlocks while only using idiomatic code. And the syntax is C-like.

    34. Re:Easy by Aighearach · · Score: 1

      Strictly speaking, if you're writing spaghetti code there is no reason to rely on a language. or other arbitrary rules.

    35. Re:Easy by Aighearach · · Score: 1

      Show me somebody who can multitask, and I'll show you somebody who can always sound like they did something.

    36. Re:Easy by Pseudonym · · Score: 1

      It's worth comparing this with the C runtime for a 32-bit CPU or a microcontroller. It wasn't so long ago that 64 bit division was a function call.

      One more thing that I didn't cover is the C++ runtime, which is a little larger due to exception handling.

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

      Why are we calling startup code, calling conventions, and standard libraries a runtime when in this context, runtime obviously implied interpreter.

    38. 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});
    39. Re: Easy by Anonymous Coward · · Score: 0

      You're just pointing out all the fancy things people have built in layers below JavaScript to work around the limitations of the specification itself. JavaScript is single-threaded with multitasking reminiscent of very basic cooperative schedulers.

    40. Re: Easy by bigpat · · Score: 1

      The constraints on deep learning AI aren't going to be solved with squeezing 10% better performance out of the software.

      And you don't program AI. You educate an AI.

    41. Re: Easy by Anonymous Coward · · Score: 0

      NAME
                stpcpy, stpncpy, strcpy, strncpy -- copy strings

      LIBRARY
                Standard C Library (libc, -lc)

    42. Re:Easy by Anonymous Coward · · Score: 0

      This is just a big fat troll. Don't bother with it.

    43. 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.

    44. 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.
    45. Re:Easy by Anonymous Coward · · Score: 0

      The latest Java JIT compiler (GraalVM) is written in Java, and it produces better, more optimized, code than the C++ one that it replaces.

    46. Re: Easy by Anonymous Coward · · Score: 0

      Yes, well known Windows library glibc. What do you think the 'c' in that stands for, precisely? What do you think libstdc++ is for C++?

    47. Re: Easy by Anonymous Coward · · Score: 0

      If the main concern is parallelization then they should probably not even use a procedural programming language.
      Maybe something data driven...

    48. Re: Easy by orlanz · · Score: 1

      Darn you!!! You beat me to it. So much posting space wasted by the others going offtopic... I thinking "Its a 15 line answer!!!" (So it was less than 15, but whatever).

      Is this no longer covered in second or third tier CS classes?

    49. Re: Easy by orlanz · · Score: 0

      Bullshit! Where to start?!?

      1) Few care about multithreading anymore. Haven't really since Intel stopped doing their GHz race and over hyping their hyperthreading. Most people actually want multiprocessing. This is especially true in the subject arena of the /. post.

      2) Having programmed in C, C++, Java, and Perl; it is ridiculously easy, in comparison, to do multiprocessing programming in Python!! I just can't state this enough!

      The best language I found to do multiprocessing is Erlang. There are "supposedly" easier ones but I found this to click for me. Combining Erlang's design concept into a Python program using Process and Queues creates a highly flexible program that due to duck-typing can be lego pieced to a simple (but almost useless) multithreaded one; to a decentralized global network of socialistic workers.

      3) As C is sometimes joked as being a wrapper around Assembly, Python is basically a wrapper around C (same for Perl).

      4) The SME of the posting says Python isn't the correct language because of the hardware requirements; not anything specific to Python in its current HW environment. He envisions a future where the hardware is specialized for the specific requirements of AI learning and data gathering and interaction. Things where entire sections of the IC will power down if unnecessary. Similar to how GPUs are better for Bitcoin than CPUs. And with specialized HW, you need a specialized software and programming environment for it. Like C is for x86/AMD; he wants X for AI-HW.

      The problem is that there is so much momentum behind Python that the AI community won't let it happen.

      But I think the HW community has much more momentum to prevent this than the software part. Specialized HW is expensive in every way. Heck, "specialized HW" is actually redefined as "taking standard chips, and configuring them for the program steps". No one wants to venture outside the standard lego building blocks. THAT is the problem.

    50. Re:Easy by Cryacin · · Score: 1

      So male = C runtime
      Female = Flash Runtime
      ?

      --
      Science advances one funeral at a time- Max Planck
    51. Re:Easy by Anonymous Coward · · Score: 0

      Python is not written in Python.

      Actually, some runtimes are.

      The interesting parts of Python from a deep learning / AI perspective are not. Take a look at the source code for numpy, scipy, pytorch. Pytorch: https://github.com/pytorch/pytorch . The colored bar will show you what langages are used:

              C++ 49.5% Python 32.3% Cuda 10.0% C 4.6% CMake 2.0% Objective-C++ 0.9% Other 0.7%

      Here's numpy:

              C 52.9% Python 45.8% C++ 1.1% JavaScript 0.1% Fortran 0.1% Shell 0.0%

    52. Re:Easy by Anonymous Coward · · Score: 0

      Well, that may be the minimum of setting up a C run time, but in modern computers there's a fair bit more that the OS does for user space programs. You know, stuff like setting up your virtual memory, inserting you in to the scheduler, setting the execute permissions on the pages where the executable code lives, loading libraries in to memory and resolving the link addresses, stuff like that. There's a hell of a lot more than just setting up your stack.

    53. Re:Easy by thereddaikon · · Score: 1

      Cute. That isn't the same thing as an interpreter runtime which is a hardware abstraction layer. If you know enough to recognize assembly then I know you know the difference between the java virtual machine and crt0. Stop being obstinate.

    54. Re:Easy by pezezin · · Score: 1

      Are you purposely forgeting about libc? malloc/free IS a runtime, for example.

      I have coded in C without a runtime, writing bare-metal code for microcontrollers, but the code you run on your PC has a runtime.

    55. Re: Easy by thereddaikon · · Score: 1

      everything in C is unsafe. That's part of the reason it is so fast. Using C makes you a better programmer.

    56. Re:Easy by thereddaikon · · Score: 1

      It's less about fighting over hardware resources and more about race conditions and data dependencies. Some operations simply can't be parallelized by their nature. And others can but the results for the different parts must come out in a certain order. This is a fact of math. We have the order of operations and you cant get around that. If you try to then your results are wrong. Simply put the universe itself is single threaded. The was you get around this safely and cleanly is redefine just how "big" your threads are. What exactly are you dedicating a thread too? Get large enough and you can find structures that aren't dependent on data from one another to survive and that is where you delineate the threads.

    57. Re:Easy by Bengie · · Score: 1

      Nothing is easy to multithread in because multithreading anything more than the most basic of processes is inherently complex

      I'll agree that multithreading makes a problem more complex, but I disagree that multithreading makes a problem too complex. Many problems are naturally asynchronous and/or concurrent, and I am not talking about embarrassingly parallel problems.

      I self-discovered many common multithreading building block patterns at the age of 11 without any books or teachers. I read about multi-CPU 486 computers and spent several days obsessing about the problem, thinking about how one would allow two independent CPUs to work together. I find multithreading quite intuitive. I would argue that it is no more difficult to design a multithreaded application than it is to design a distributed web application that is so common these days in AWS.

    58. Re:Easy by Anonymous Coward · · Score: 0

      malloc/free are *library* calls (or syscalls, depending on your bent.) They are not a runtime.

      If you're running on x86, your "runtime" - if you even want to call it that - is the microcode that breaks down all of those CISC instructions and maps them onto an internal RISC pipeline *in the CPU itself.*

    59. Re: Easy by Anonymous Coward · · Score: 0

      Have you even *looked* at how a compiled C program is stored and loaded?

      a) Compiler/linker writes those constants to object files(*) and assembles them into the final executable. (*) where necessary - sometimes the compiler inlines the constants and drops them directly into registers.
      b) The exec() syscall essentially mmap()s the target executable and transfers control to it.

      No magic, no runtime.

    60. Re:Easy by Anonymous Coward · · Score: 0

      I don't know, I'm pretty good at multitasking. I'm beating my heart, while breathing, while digesting my breakfast, while typing. Now, my conscious effort is painfully single threaded, probably worse than most, but I can still run a lot of maintenance tasks in the background while completing my main objective.

    61. Re: Easy by Anonymous Coward · · Score: 0

      so floating point was often compiled into calls into the FP library. 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 library routines.

      There, FTFY. Runtime is something entirely different.

    62. Re: Easy by K.+S.+Kyosuke · · Score: 1

      Runtime is the thing that your programs need to perform the most basic operations that most or all programs written in the language in question always need to do. By necessity, that involves things that form a part of the standard library.

      --
      Ezekiel 23:20
    63. Re: Easy by Anonymous Coward · · Score: 0

      You can't even run e.g. TensorFlow test cases without installing undocumented packages from third parties. Never mind how difficult it is for laypersons to get the GPU package installed and working. What does Python itself do to solve these problems?

    64. Re:Easy by thereddaikon · · Score: 1

      I committed the sin of over generalizing. There are some tasks that are trivial to multithread and its easy to see which those are. Anything that can take advantage of gpu hardware acceleration can be easily multithreaded. I was talking about everything else, assuming that the gpu tasks were a given.

    65. Re:Easy by LaminatorX · · Score: 1

      Replacing bottleneck-points in Python with C (and lately Rust or even Go) extensions has been well understood to be the Goldilocks approach for many years.

      You optimize for power only in parts of the project where the trade off in simplicity and ease of maintenance is justified, and enjoy the benefits of Python the rest of the time.

    66. Re:Easy by aod7br7932 · · Score: 1

      Pypy is python written in Python. Plus Python do handle threads well, see Jython, Pypy and and any other variations that compile to a JIT. Python is way past this both issues.

    67. Re:Easy by phantomfive · · Score: 1

      Oh interesting, I didn't know you can call Go from Python now.

      --
      "First they came for the slanderers and i said nothing."
    68. Re:Easy by luis_a_espinal · · Score: 1

      And this is insightful?

    69. Re:Easy by luis_a_espinal · · Score: 1

      Replacing bottleneck-points in Python with C (and lately Rust or even Go) extensions has been well understood to be the Goldilocks approach for many years.

      You optimize for power only in parts of the project where the trade off in simplicity and ease of maintenance is justified, and enjoy the benefits of Python the rest of the time.

      This. This all the way.

    70. Re:Easy by UnknownSoldier · · Score: 1

      Which is why JavaScript ALSO supports WebWorkers -- run scripts in background threads

      The point is the OP is clueless about modern JavaScript.

    71. Re:Easy by Ambitwistor · · Score: 1

      Or you could just use a more modern language that is expressive like Python, but doesn't require you to use a different language to optimize bottlenecks. Like Julia, or Swift.

    72. Re:Easy by Anonymous Coward · · Score: 0

      You are f***ing confused interpreter/virtual machine with runtime, dude, miserable!

    73. Re: Easy by reanjr · · Score: 1

      Or immutable types works good too.

    74. Re:Easy by Anonymous Coward · · Score: 0

      This entire headline and article are old news. Even going back to the 1980's, people have been trying to develope languages better for AI or robotics or automation or the like.

    75. Re: Easy by Pseudonym · · Score: 1

      If the compiler generates a call where there there is no call in the source program, that's runtime.

      --
      sub f{($f)=@_;print"$f(q{$f});";}f(q{sub f{($f)=@_;print"$f(q{$f});";}f});
    76. Re:Easy by pezezin · · Score: 1

      You don't have much of a clue about how modern computers work, do you? Go program a MCU and then you will realize how much magic there is between your C code and the CPU.

    77. Re:Easy by Aighearach · · Score: 1

      This is slashdot, but the flashers and the biggest boobs are men.

    78. Re: Easy by Anonymous Coward · · Score: 0

      Serious confusion in this thread.

      The modern C runtime has permuted from the programmers' view of the x86 CPU to the progrmmers' view of the AMD64. ARM can mimic those well enough not to be hampered too much.

      The fact that so many people seem to have become unable to see the C runtime anymore shows something. Maybe it has more to do with Intel's salescrew than with tech.

      Abstract CPUs don't compute. Ergo, runtime exists, even if you are now blind to it.

      (Maybe the artifact stack frame will get your attention.)

    79. Re:Easy by Bengie · · Score: 1

      When I say "self-discovered many common multithreading building block", I mean like compare-and-swap, atomic reads, atomic writes, channels, ordering, etc. I did not make any implementations of any of these, but around the age of 11, I realized these issue MUST exist as they are a physical requirement of our universe, and regardless of how these common operations are implemented, I could continue thinking about concurrency problems.

      To me, torn reads, torn writes, and ordering are fundamental issues that something must be responsible for. And it was my conclusion that to keep two independent CPUs in perfect sync would require a great performance cost to transistor count, clock rate and-or latency. I did not have read any of this anywhere or test it or see existing code. All of these issues I was able to reasonably assume must exist because of my basic understanding of physics.

      This wasn't some long term issue that I spent forever on. All of these issues were almost immediately obvious, It was a kind of problem you look at, have an gut reaction to notice that the devil is in the details, sleep on it, and realized the issues in the morning. All of this I was able to infer just from seeing a marketing ad for a dual socket 486.

      The biggest issue I face with multithreading is finding pre-existing code that implements my ideas. My assumption about my ideas is someone has already thought about this problem and solved it in an elegant way. I really hate rolling my own concurrent data structures and algorithms, but I've done it many times with great success. Still doesn't mean I am proud of rolling my own. Though, I have been bitten by more concurrency issues in mature frameworks and libraries than my own code. It comes down to risk management. I can't go my whole life being worried that other highly publicly scrutinized code may have some stupid bug that I would have never missed. There is a certain value in conformity.

  3. Oh very much by Anonymous Coward · · Score: 0

    ...necessary. All the best thinkers and programmers avoid python. It is imprecise, ineffective, slow as molasses, and is missing many important features. I have seen brave souls try to use it and end up completely abandoning projects for a different language or even give up entirely.

    1. Re: Oh very much by Anonymous Coward · · Score: 0

      Quite the contrary actually. Your statement is telling more about than about us.

    2. Re:Oh very much by Anonymous Coward · · Score: 0

      and is missing many important features

      like semicolons

  4. Yes, you could call it Smalltalk, or perhaps lisp by williamyf · · Score: 2

    or perhaps prolog...

    --
    *** Suerte a todos y Feliz dia!
  5. "Deep learning" ... by Anonymous Coward · · Score: 0

    could no doubt already write better dialogue than any Marvel franchise. Suck it Kendall.

    1. Re: "Deep learning" ... by Anonymous Coward · · Score: 0

      What did they do to the earlier versions of python? Holy crap. I tried to compile a simple program and it blew up

  6. Easier by Anonymous Coward · · Score: 0

    Just use Lisp

  7. What python isnt good for doing real tasks by Anonymous Coward · · Score: 0

    Who would have thought such a thing. Haha guess all the CS kids are going to actually have to learn to use languages useful useful in the real world noq

    1. Re: What python isnt good for doing real tasks by Anonymous Coward · · Score: 0

      If you don't take more than 5min to write a 'hello world!', it's not a real world language. With python is just too easy.

  8. Please describe the characteristics of such a lang by Anonymous Coward · · Score: 0

    Original post is as informative as a "bad syntax" error message. How is Python inadequate? Is a whole new language really needed or could Python be extended?

    Running "against very entrenched desires from against very entrenched desires from researchers and engineers" is not likely to end well for at least a generation*, unless it offers truly spectacular benefits.

    *untill said "researchers and engineers" are replaced by history

    $CAPTCHA=='lambda" ; lisp rules!

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

    I have one character for you ")"

    Unfortunately Procedural and Object Oriented languages, have gotten a foot hold, and training someone to code functionally is quite difficult, and for parallel processing it may be even trickier.

    --
    If something is so important that you feel the need to post it on the internet... It probably isn't that important.
  10. Re:Yes, you could call it Smalltalk, or perhaps li by steveb3210 · · Score: 1

    or ruby..

  11. Heard it before by Anonymous Coward · · Score: 0, Informative

    "Whenever somebody's conclusion is that we need a new programming language, I know we are dealing with an idiot or more of a philosopher than a programmer."

    1. Re:Heard it before by Anonymous Coward · · Score: 0

      ^^ this here -- Winning

    2. Re:Heard it before by Anonymous Coward · · Score: 0

      a bit harsh, but right 95% of the time.

    3. Re:Heard it before by serviscope_minor · · Score: 1, Insightful

      "Whenever somebody's conclusion is that we need a new programming language, I know we are dealing with an idiot or more of a philosopher than a programmer."

      And yet the idiots/philosophers gave us every languge we use to today. There's a reason we're not writing in machine code.

      --
      SJW n. One who posts facts.
    4. Re:Heard it before by Anonymous Coward · · Score: 1

      Machine code is too fast.

      A hundred years ago it took five floors (200 per floor) of accountants labouring 10 hours a day more than 6 months (with no days off) to make the same fuck-up as your Python code did in just 2 seconds. Of course, your machine code could have done that same fuck up in less than a millisecond, which is far too fast. That is why we do not use it.

    5. Re:Heard it before by Dunbal · · Score: 1

      Insert a bunch of NOPs in the loop to give the port time to catch up...

      --
      Seven puppies were harmed during the making of this post.
  12. hardware by sdinfoserv · · Score: 1

    If indeed f "deep learning" has hit the wall with current languages.... perhaps the hardware itself in it's current configuration isn't up to the task.
    Since all languages simply compile to machine code, which runs on an OS making hardware calls, a top level restriction implies a deep level constraint.
    To develop the next -real- AI, requires a different hardware approach running some as of yet unconvinced OS - followed by a language.

  13. You know you want to, Yann LeCun by Anonymous Coward · · Score: 0

    Go back to Lua! You should never have abandoned it!

  14. Re:Yes, you could call it Smalltalk, or perhaps li by Anonymous Coward · · Score: 0

    ADA think you may be on to something!

  15. 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/

    1. Re:There are only two options here... by Anonymous Coward · · Score: 0

      For God wrote in Lisp code
      When he filled the leaves with green.
      The fractal flowers and recursive roots:
      The most lovely hack I've seen.
      And when I ponder snowflakes, never finding two the same,
      I know God likes a language with it's own four-letter name.

      Parody by Bob Kanefsky of "God Lives on Terra" by Julia Ecklar

      http://www.prometheus-music.com/audio/eternalflame.mp3 (sung by Julia Ecklar)

    2. Re:There are only two options here... by HelpTheNewOverlord · · Score: 1

      Yeah, and junk DNA is just all the parenthesis needed to run the code

    3. Re:There are only two options here... by K.+S.+Kyosuke · · Score: 1

      Junk DNA is features like YES-OR-NO-P or the ~R/~:R/~@R/~:@R formatting directives.

      --
      Ezekiel 23:20
    4. Re:There are only two options here... by Megane · · Score: 1

      God wrote in Lisp code

      I guess that means we know who writes in Perl.

      --
      #naabhaprzrag, #sverubfr-000, #agi-fcbafberq, negvpyr[pynff*=' negvpyr-ary-'] { qvfcynl: abar !vzcbegnag; }
  16. Works for Facebook by vanOorschot · · Score: 1

    Nuf said.

  17. Re:Yes, you could call it Smalltalk, or perhaps li by Anonymous Coward · · Score: 0

    No it's not, you just tell them it's like putting a function call to a dll with a return going into an array to into an array location that you check the status of later. Non zero status in the array means the result has occurred. Easy Peasy - loop until your array has the data you need.

  18. 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 Anonymous Coward · · Score: 0

      If I have to choose, I'll deal with giant mountains of garbage Python over even a small hill of garbage C++, every day of the week. :-)

    2. Re:Dumping Python Is Both And Easy And Lucrative by Anonymous Coward · · Score: 1

      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.

      That's how the python ecosystem is supposed to work.

      Python development is fast and easy. If something sticks around or needs more speed, rewrite in C++.

      Think about it in powertools. Don't know if you will need that standing belt sander for more than a project or two? Buy from Harbor Freight.

      Did it work well enough that you want more quality next time or did you use it enough to wear it out? Buy a decent brand replacement.

    3. 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".

    4. Re:Dumping Python Is Both And Easy And Lucrative by Anonymous Coward · · Score: 0

      I've seen 200k+ lines Project that cost close to billion USD that was so badly written in C++ that I believe it would be better written in Python.

      Firstly it would be 20k+ of code..

      And regarding things you mentioned - Python already has or will have the them. Not by default but probably you will havd tools to enforce them.

       

    5. Re:Dumping Python Is Both And Easy And Lucrative by phantomfive · · Score: 1

      but probably you will have tools to enforce them.

      That is a very probably firm endorsement.

      --
      "First they came for the slanderers and i said nothing."
    6. Re:Dumping Python Is Both And Easy And Lucrative by Anonymous Coward · · Score: 1

      Except, ceteris paribus, this is 200,000 lines of code written by "twenty something year old hipsters or older researcher type people". You could spend the rest of your life debugging this mess with every space-age tool you have and not even make a dent. Been there.

      If you're starting with a clean codebase and have a team of disciplined and excellent programmers (or preferably just a team of one such), the C++ will probably be fine. But in that case, so will the Python. Probably even more so.

      There are reasons to prefer C++ for some projects. But clarity, quality, and debuggability are not among them.

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

    8. Re:Dumping Python Is Both And Easy And Lucrative by tomhath · · Score: 1

      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.

      All the selling points for Java. But most big Java projects I saw were nightmares anyway.

    9. Re:Dumping Python Is Both And Easy And Lucrative by Dunbal · · Score: 1

      Bad coding is bad coding in any language. It's usually not a language problem it's a programmer problem.

      --
      Seven puppies were harmed during the making of this post.
    10. Re:Dumping Python Is Both And Easy And Lucrative by Dunbal · · Score: 1

      The fun thing about garbage C++ code is you know it's garbage because it doesn't work.

      --
      Seven puppies were harmed during the making of this post.
    11. 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.

    12. Re:Dumping Python Is Both And Easy And Lucrative by Kryptonut · · Score: 1

      Amen in the case of a rewrite....it could be garbage Python code, but at least it tends to be readable garbage you have to convert.

    13. Re:Dumping Python Is Both And Easy And Lucrative by melted · · Score: 1

      There's still type checking. Just not _compile time_ type checking. You get such a wonderful feature as things blowing up in your face at runtime just because someone changed something somewhere and did not update all call sites.

    14. Re:Dumping Python Is Both And Easy And Lucrative by K.+S.+Kyosuke · · Score: 1

      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.

      C++ definitely lacks "rigid type checking" and "compile time error checking" in any practical sense, otherwise people would not be hunting (or exploiting) memory errors in C++ code all the time, since these features (actually present in languages like Ada or Modula or Oberon) would strictly prevent them. Whether Python lacks "complex data structures" is debatable; if you're referring to standard library deficiencies, you may be right, but nothing prevents you from implementing anything you want.

      --
      Ezekiel 23:20
    15. Re:Dumping Python Is Both And Easy And Lucrative by K.+S.+Kyosuke · · Score: 1

      C++ doesn't have them by default either. Not much difference here.

      --
      Ezekiel 23:20
    16. Re:Dumping Python Is Both And Easy And Lucrative by Anonymous Coward · · Score: 0

      "Everyone is a bad coder except me."

    17. Re:Dumping Python Is Both And Easy And Lucrative by Anonymous Coward · · Score: 1

      Or maybe you can also use Object-Pascal.

    18. Re:Dumping Python Is Both And Easy And Lucrative by Aighearach · · Score: 1

      If they were smart, they'd do it in ANSI C and just hire consultants.

      It isn't that hard, but who wants to learn all of C++, or risk writing something in the "wrong" subset? Total PITA. Lots of people love C++, but they all love and hate different parts. It is the plague.

      And why would career-oriented people want to get stuck doing it? It is a job for legacy code wranglers, not engineers.

      But in most cases, they should be using Golang or Ruby or something. Python is the howto language, the BASIC of the modern age. The language itself is fine, but the extant volume of garbage code and bad practices makes it dubious for serious projects.

    19. 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.
    20. Re:Dumping Python Is Both And Easy And Lucrative by phantomfive · · Score: 1

      What exactly is "them?'

      --
      "First they came for the slanderers and i said nothing."
    21. Re:Dumping Python Is Both And Easy And Lucrative by pr100 · · Score: 1

      ... and yet the most widely used web framework is an 800k line python program.

    22. Re:Dumping Python Is Both And Easy And Lucrative by Anonymous Coward · · Score: 0

      It's not just about Python, it's also the fact that these days, code performance is very directly priced (slower code costs AWS dollars---you instantly observe the cost impact of optimization). A few low-level developers can cut AWS costs in half in a few months (especially if going from Python to C/C++).

      e.g. Phase 1 of a company: get it out asap. Phase 2 is when they start comparing revenues to costs, and realize that if they pushed the costs down they'd be profitable...

    23. Re:Dumping Python Is Both And Easy And Lucrative by Anonymous Coward · · Score: 0

      Firstly it would be 20k+ of code..

      You meant with 10k lines of code with 'import'? :p

    24. Re:Dumping Python Is Both And Easy And Lucrative by Anonymous Coward · · Score: 0

      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.

      Maybe Python should be considered requirements gathering and specification language. Now you'll have the blueprint for actual production system, with a ready-made test harness even.

    25. Re:Dumping Python Is Both And Easy And Lucrative by Anonymous Coward · · Score: 0

      Or that fixing one bug, creates 3 others. >:)

    26. Re:Dumping Python Is Both And Easy And Lucrative by PurplePhase · · Score: 1

      > "flexible and easy to work with" ... is in the eye of the beholder. You're thinking wrt programmers: I'm betting Yann is thinking wrt researchers and/or reporters.

      Stricter type checking, etc. in the language means they avoid all the errors which would require them to spend more time being programmers and less time doing their higher-level jobs.

  19. Julia anyone? by jgfenix · · Score: 5, Insightful

    I think it fits the requirements quite well.

    1. Re: Julia anyone? by Anonymous Coward · · Score: 0

      Its a great language but not user friendly

    2. 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.

    3. 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++?

    4. 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.

    5. 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.

    6. 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:Julia anyone? by majid_aldo · · Score: 1

      pandas. you can JIT python too.

      --
      --- widget evolution: enhanced, plus, super, ultra, extreme, exxxtreme, ultra-extreme, ..etc.
    8. Re:Julia anyone? by Anonymous Coward · · Score: 0

      Given that Julia lacks the OO that is in Fortran, as well as other features, it's a pretty feature incomplete version of Fortran.

    9. Re: Julia anyone? by K.+S.+Kyosuke · · Score: 1

      Julia has generic functions, which are pretty much the CLOS superset of the single dispatch model at heart of Smalltalk-inspired OO languages. Is that why you're confused?

      --
      Ezekiel 23:20
    10. Re:Julia anyone? by Anonymous Coward · · Score: 0

      I think you are fundamentally incorrect to suggest Python and C are easier to learn than MATLAB. Your primary example is MATLAB's use of a semi-colon to suppress command line output and its use in a parameter list? The syntax of MATLAB is literally as logical as it gets lol. It's as close to "literally coding in math" as any language as gotten. Just look at this comparison of matlab/python statements. https://www.mathworks.com/products/matlab/matlab-vs-python.html MATLAB operates at a much higher level of abstraction than python or C by design. It's a quantitative analysis programming language. Your comment: "It's loaded with arcane semantics like the differences between a normal array and a cell array." How is this a bad thing? It's an abstraction. It makes stuff easy. I'd like to know what about the UI is illogical? A scripting window, a command line to test code on the fly, and a window for seeing what variables are defined called the workspace. It's pretty darn plug and play if you ask me. I think it sounds like you haven't spent that much time in the MATLAB environment, compared to your native languages. And I think learning a new language is frustrating no matter what. Personally, I have moved away from MATLAB because I don't want to purchase any more toolboxes. So I forced myself to learn python. That's my one issue with MATLAB is that it isn't open source. But at the same time the fact that it is a product, means it is constantly being held to a high standard. You are obviously very intelligent, I think if you stuck with matlab for a while it would click and you wouldn't have to keep relearning it. I know what you mean though. Best of luck to you.

    11. Re:Julia anyone? by Ambitwistor · · Score: 1

      I have no idea what you're talking about. Julia doesn't isn't any harder learn than Python. The statement that "you can't just pick it up and go" is just bizarre; the syntax is different from Python, but if you're learning Julia from scratch it's not worse than learning Python from scratch. It's true that their threading model is still in flux, but that's not really anything having to do with the language design.

      Your complaint seems to boil down to "Python is the 'standard' approach, and therefore anything else is designed wrong and hard to learn".

    12. Re:Julia anyone? by Ambitwistor · · Score: 1

      JITing Python is not really a substitute for Julia. Essentially, due to Python's language design, you can't JIT arbitrary code, only a subset, and it won't do dependent compilation (JITting through all your package dependencies to give you a custom-compiled version of user code and all the libraries it depends on).

    13. Re:Julia anyone? by TimothyHollins · · Score: 1

      Yes, almost like that. I'm saying that Python is very similar to other languages, such that Python is very quick and easy to learn if you know any other language. If you know Java, C/C++, Perl, Scheme, SAS, R, bash, MATLAB, or anything similar to those, then Python is easy to read and understand almost from the start. I'd say that even Haskell and Scheme qualify. But if you want to learn Julia, those languages won't be much help.

      If you were to pick up Julia with no prior experience whatsoever, then it doesn't matter of course, unless you wanted to use your Julia expertise to pick up a second language.

      That all matters because the target audience (or a large part of the target audience) are the people that know a bit of these languages. They aren't programmers, they don't know anything about memory management, pointers, instruction sets or achitectures. They just want something that works and is easy to grasp from previous experience. And while that's a shame, that's how the world works. Julia suffers because it cannot attract the "low-skill" crowd in the way that R or Python has.

      For experts, as someone mentioned above, Julia might be an excellent framework. But for wider adoption, Julia has several issues to deal with.

    14. Re:Julia anyone? by Anonymous Coward · · Score: 0

      "Please, tell me what high performance Python numerical libraries are written in Python, without C or C++?"

      Ask an irrelevant question, get an irrelevant answer. Who cares what language the libraries are written in?? In fact you should expect those libraries to be written in a lower-level, higher performing language like C or C++. This is how good systems design is done; it's literally a Best Practice!

      Non performance critical portions of the code can be written in a higher level language that makes the programmer more productive but makes the computer less efficient. The performance critical code sections get special attention and often (usually) that means a lower level language that is less programmer productive but more computer efficient.

      I can't help but think that Python is like BASIC back in the day. Endless technical criticism of the language, but it endured, later becoming QuickBasic, then Visual Basic. I too hated BASIC, but mainly in the early incarnations. Except, it was easy, there was deep demand for it, and many (often too many) systems written in it.

      It sure seems like the hate on Python has the same... general vibe about it.

  20. 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});
  21. how about make? by Anonymous Coward · · Score: 0

    Like everyone that doesn't truly understand make, they end up creating a retarded subset replacement (xcodebuild, cmake, configure, autoconf, etc.). Besides the GIL problem (which isn't a language but an implementation issue), Python is more than capable of being extended to exceed at any task. It's Touring complete, and already has thousands of useful libraries and a huge user base. Torch, Tensorflow, Caffe, Caffe2, and a dozen other ML libraries aren't enough? AutoML and Karas meta-ML libraries already exist.

  22. We already have one . . . . by Patrick+May · · Score: 2

    it's called Common Lisp.

    1. Re:We already have one . . . . by 93+Escort+Wagon · · Score: 1

      it's called Common Lisp.

      Coming soon from Facebook - HHCL.

      --
      #DeleteChrome
    2. Re:We already have one . . . . by K.+S.+Kyosuke · · Score: 1

      Aternatively, the first working version of Racket-on-Chez-Scheme just came out. Now if only they removed that Chez's pesky all-flonums-are-boxed limitation... There's really no need for that.

      --
      Ezekiel 23:20
  23. 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.

  24. slashdot may need actual editors by Anonymous Coward · · Score: 0

    That, you know, actually edit.

  25. google/jax by Anonymous Coward · · Score: 0

    google/jax - this project looks pretty promising

    1. Re: google/jax by Anonymous Coward · · Score: 0

      Haven't you heard? Already cancelled

  26. Fast forward a few weeks/month by Anonymous Coward · · Score: 0

    Facecrud Announcement:
    New ML language...

  27. Re: Thank you for a reasonable reply, however by Anonymous Coward · · Score: 0

    ...even if specific Solutions are unknown, examples of the problem(s) would be enlightening. I admit that I had not read the linked article when I made my comment. In the context of your polite reply, I did look it over.... and, again I request specific examples of the problem. I do not doubt that problems exist, but would like more information.

  28. Assembly is pretty flexible by Anonymous Coward · · Score: 0

    Just sayin'.

  29. So for something that needs the utmost speed. by Fly+Swatter · · Score: 1

    Everyone is apparently using an interpreted language? Sounds to me like they need to apply the second word of A.I. , since they keep insisting on calling it that.

    1. Re:So for something that needs the utmost speed. by ceoyoyo · · Score: 1

      There isn't really any such thing as an interpreted language anymore. There are Python compilers. There are even Python compilers that can be told to compile single functions or methods.

      Deep learning code is absolutely compiled, but for the major libraries the models are specified in python.

    2. 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});
    3. Re:So for something that needs the utmost speed. by Kryptonut · · Score: 1

      The heavy lifting is done by compiled code in the libraries / modules. Python's just the glue language that gives an easy entry point.

    4. Re:So for something that needs the utmost speed. by K.+S.+Kyosuke · · Score: 1

      "Intelligence" may very well involve just using environments that can figure out themselves what to compile, and when. (And don't need to be spoon-fed like C compilers.)

      --
      Ezekiel 23:20
    5. Re:So for something that needs the utmost speed. by 0100010001010011 · · Score: 1

      LLVM has helped to blur the line.

    6. Re: So for something that needs the utmost speed. by K.+S.+Kyosuke · · Score: 1

      Self 91/93 did that long before LLVM, though.

      --
      Ezekiel 23:20
  30. Isn't this what Julia was designed for? by Anonymous Coward · · Score: 0

    Its designed to be faster than Python, inherently parallel and aimed at scientists and mathematicians.
    See https://www.infoworld.com/article/3241107/python/julia-vs-python-julia-language-rises-for-data-science.html

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

    LISP, then?

    --
    I've abandoned my search for truth; now I'm just looking for some useful delusions.
    1. Re:So.... by Anonymous Coward · · Score: 0

      Already tensorflow is moving to Swift. So why not Swift?

  32. use node by Anonymous Coward · · Score: 0

    require 'left-pad' console.log('lol')

  33. Careful what you wish for by Anonymous Coward · · Score: 0

    Or else you'll summon the hoard of JavaScript devs to make your shit pile even steamier and nuttier than before.

  34. I will stick with Python... by Anonymous Coward · · Score: 0

    I've seen dozens of language and I think Python is the best middle ground.

    It would be very, very hard to design something substantially better and easy to learn and versatile.

  35. Re:Yes, you could call it Smalltalk, or perhaps li by Anonymous Coward · · Score: 0

    and for parallel processing it may be even trickier.

    WTF are you on about? Functional is the easiest code for parallel processing. Why do you think it has been making such a come back?

  36. No - easier by Anonymous Coward · · Score: 1

    Don't use languages designed by language lawyers with esoteric constructs designed to lower productivity of average developers.

    A new language is not needed, it's a call to
    - fund a large project to design a language
    - get lots of hype, sell lots of newsprint, magazine space and web blog advertisements,
    - give lots of experts speaking fees
    - sell lots of training courses online and in person
    - sell books
    - sell tool sets
    - let people attend experts conferences
    - help increase the GDP
    - provide jobs for PhD holders to research it
    - ....

    A language is written for the reader and not the elegance i wet my diaper cool shiny needs of the original developer.

    Programming 101 from the 1960s:
            "How hard is it extract the business intent of a program by a developer unfamiliar with the system, business processes and computer architecture?"

    Programming is not creative writing elegance is not the top goal in computer code, program structure or language.

    Another to file in the it's lisp, lisp is good, lisp is the best VS we need to read the program and not be an uber-expert in it.

  37. Person with impressive title says obvious thing by Anonymous Coward · · Score: 0

    Story at 11.

  38. Re:Yes, you could call it Smalltalk, or perhaps li by phantomfive · · Score: 1

    Functional is the easiest code for parallel processing.

    Nah, C# with they yield style of automatically doing multi-threading is the easiest.

    Why do you think it has been making such a come back?

    It hasn't. Some of the nice functionality has been imported into Java, but hardly anyone is talking about immutability.

    --
    "First they came for the slanderers and i said nothing."
  39. Uh-huh by Anonymous Coward · · Score: 0

    It isn't the programming language, it's the farce that is 'AI'. Good grief, these people are stupid. How Facebook remains profitable is an absolute mystery.

  40. Chief AI Scientist and Python in the same sentence by Anonymous Coward · · Score: 0

    That shit just makes me laugh.

  41. Yepp, absolutely by Qbertino · · Score: 1

    That's definitely what we need. A new programming language.

    --
    We suffer more in our imagination than in reality. - Seneca
    1. Re:Yepp, absolutely by Anonymous Coward · · Score: 0

      I personally like the absurdity of the idea. The idea that AI will just be an application that you launch on your desktop computer. I wonder if that is really what Google / Facebook / Uber envision, an App that runs the AI.

      Never mind all of the obviously important things that go into the human model of intelligence - an organic body that seeks out energy to support higher level activity, sensory organs that can perceive the environment, many feedback loops that coordinate sensory data, and allow us to "remember" things that just happened. It takes at least 3 years for this system to really get started, and then it needs a lot of information in order to understand the basic principles of the environment. Oh, but we could probably build an AI program that runs on a desktop and you can just boot it up when you need to ask it a question.

    2. Re:Yepp, absolutely by Pseudonym · · Score: 1

      If the only other alternative is Python, then that is precisely what we need.

      --
      sub f{($f)=@_;print"$f(q{$f});";}f(q{sub f{($f)=@_;print"$f(q{$f});";}f});
    3. Re:Yepp, absolutely by bahwi · · Score: 1

      I know they say AI, but they definitely mean machine learning, which is really just advanced guessing (and can work well, but still)....

  42. Re:Yes, you could call it Smalltalk, or perhaps li by Anonymous Coward · · Score: 0

    And WTF are you on about? Your comment makes it seem like you have never done any serious work in a functional language or any serious parallelism.

  43. Re: Thank you for a reasonable reply, however by Pseudonym · · Score: 1, Funny

    I don't know, because I'm the exact opposite of Yann LeCun: he's an AI guy unsatisfied with programming languages, and I'm a programming language guy unsatisfied with AI.

    I haven't worked in deep learning, so I don't know if he has well-formed complaints or he's just generally unsatisfied.

    --
    sub f{($f)=@_;print"$f(q{$f});";}f(q{sub f{($f)=@_;print"$f(q{$f});";}f});
  44. 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).

    1. Re:What's wrong with python? by Anonymous Coward · · Score: 0

      i did pip3 install tf-nightly-gpu and it all works without needing a shoehorn or anything.. i think it works pretty good!

    2. Re:What's wrong with python? by Deaddy · · Score: 1

      It's okay, you can just containerize each step of the pipeline.

  45. Re:Yes, you could call it Smalltalk, or perhaps li by phantomfive · · Score: 1

    you have never done any serious work in a functional language or any serious parallelism.

    I've done both.

    --
    "First they came for the slanderers and i said nothing."
  46. 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.
    2. Re:Blah blah blah by majid_aldo · · Score: 1

      The objection was on flexible high-performance computation, not "AI" theory.

      --
      --- widget evolution: enhanced, plus, super, ultra, extreme, exxxtreme, ultra-extreme, ..etc.
  47. Build it and they will come by Zero__Kelvin · · Score: 1

    If someone develops a language that offers true leverage over Python then the transition *will* happen and all that will be left unanswered is "how long will it take for the transition to happen?"

    --
    Guns don't kill people; Physics kills people! - John Lithgow as Dick Solomon on Third Rock From The Sun
  48. we have no data, and hence don't know anything by doom · · Score: 1, Troll

    I say this every other day in one form or another, but let me try again: we all keep jumping up and down and shouting about whether we need a more flexible language or a fussier language with super-strong type-checking and encapsulation and what not, and some are deeply convinced that Pythons's fascist attitude toward formatting is excellent, and some are not -- one of the reaons the Go project was started, from what I understand, was to get away from syntactic whitespace--

    None of us really know who's right about any of this, because to really find out someone would need to do experiments, and designing these experiments would require knowledge of social science techniques, and "Computer Scientists" refuse to consider doing that kind of science, because most of them are really mathematicians in disguise.

    So we're stuck with a religious fervour for concepts like "elegance" without any real reason to believe any of it is right.

  49. Re:Chief AI Scientist and Python in the same sente by K.+S.+Kyosuke · · Score: 1

    Norvig doesn't laugh.

    --
    Ezekiel 23:20
  50. Programming Motherfucker by Anonymous Coward · · Score: 0

    Do you speak it?

    http://programming-motherfucker.com/

  51. Node did this by Anonymous Coward · · Score: 0

    Because of Node and it's webfag fanbois proggies became scared of theads because, ya kno...single thread non-blocking my rectum. Now the problems that threads solved never actually went away. Oh noes!!! We need a new language. Perhaps you could use a new gender while you're at it. Fuck Node. Fuck Ruby. Fuck it all. Fuck-ity fuck fuck.

  52. Re:Yes, you could call it Smalltalk, or perhaps li by K.+S.+Kyosuke · · Score: 1

    I have one character for you ")"

    That's not a character, that's a SIMPLE-STRING of length 1. ;)

    --
    Ezekiel 23:20
  53. 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
  54. Python isn't the problem by NickHydroxide · · Score: 1

    I agree with Yann that our current crop of languages aren't well suited to deep learning, but I'm not sure it's a Python specific problem. I don't think whitespace, threading, syntax etc are the barrier.

    It's much more that Python is fundamentally an imperative language, and deep learning doesn't fit into either the imperative or functional category, I really think DL deserves its own category, designed from the ground up for manipulating tensor data structures of unknown shapes.

    I haven't come across any language that encapsulate strong typing for tensor shapes, so you end up tracking shapes with pen and paper while debugging your code (and not everything is caught at compile time). Named tensors would be a good start (more information here http://nlp.seas.harvard.edu/Na...) but that wouldn't solve everything. People can't agree on computation graph vs a forward/back functional approach - PyTorch prefers the latter, TensorFlow originally preferred the former (but now seems to be migrating to the latter).

    Julia does seem to be the most promising, but that may just be "the grass is always greener" speaking. I haven't played with it myself.

  55. ML Tools All for Python is a very Limiting Factor by Slicker · · Score: 0

    Python has great appeal to academics but it's a very poor choice for any hardcore engineering. It's just inherently slow and, although very readable in small snippets and as glue-code, it's not the best for more complex solutions.

    I am not advocating for a whole new language but really think the best bang for the buck would be in simply to better develop the various ML related tools for JavaScript. JavaScript is today clearly what C was back in the 1980's, as Python is what Pascal was. Or like Verilog (industry) verses VHDL (academia). JavaScript (such as V8-based Node.js) compiles to very fast and memory efficient code. Conventional Object-Orientation is inherently slow and memory consuming as it requires an instance factory added to every program and massive memory allocations for each instantiation (using more memory and lots of CPU usage for the OS kernel's memory defragmentation).. JavaScript corrects these errors with its model for Object-Orientation and now also provides a syntax largely identical to that of conventional Object-orientation.

    We need to clean up Tensorflow.js and build out data science tools for JavaScript, such as paging data editor to work on ultra-large files piece by piece without having to load them completely into memory.

    JavaScript is very well suited for Machine Learning. And it may not hide the underlying machine as do languages like Pascal, Java, and Python (they academics seem to prefer) but there is so much benefit in being true to computation, as it really is.. That is a long discussion on its own.

    I do, however, strongly advocate one very important enhancement to JavaScript to greatly simplify asynchrony and to make possible a method of "bug free" programming. Enable the setting of hooks on variable values such that, when modified, will execution a logical condition expression and, if true, execute a code block with a given variable scope... One little bit hook will not slow down execution. For example: // Establishes that, any time x, y, or z values are changed, the expression is evaluation and, // if true, the provided function is executed and the data object "scope" is passed to it.
    var scope = { ... };
    var condition = when( x { doSomething() } );
    condition = undefined; // kills the "when" hook

    This could GREATLY reduce the complexity of things like business logic based on multiple async data queries. It could also make possible, "bug free" programming when using purely for stateful programming between "when" conditions. That is, only syntax errors, system errors, and errors in requirements could go wrong, if all your programming is conditions on states changing states. Overall, software would be vastly more robust than the tendencies today.

    Matthew

  56. If only ... by hvidstue · · Score: 2

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

  57. Re:Yes, you could call it Smalltalk, or perhaps li by phantomfive · · Score: 1

    I'm not convinced that there is a meaningful difference between concurrency and parallelism.

    --
    "First they came for the slanderers and i said nothing."
  58. they could use LISP! by Anonymous Coward · · Score: 0

    Lisp is used for AI because it supports the implementation of software that computes with symbols very well

  59. Wot? by Anonymous Coward · · Score: 0

    More flexible than python? Have these people not seen snakes before? Nothing could be better at tying itself in knots, getting caught in loops, or accidentally eating its own tail ;D

  60. Why not R? by Anonymous Coward · · Score: 0

    as per subject line

    1. Re:Why not R? by majid_aldo · · Score: 1

      Fundamentally the same problem as with Python but worse due to weak software engineering.

      --
      --- widget evolution: enhanced, plus, super, ultra, extreme, exxxtreme, ultra-extreme, ..etc.
  61. 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.

    1. Re:Yes by K.+S.+Kyosuke · · Score: 1

      Only for standalone programs, though

      Maybe freestanding programs, but what about hosted programs? There is definitely an expectation of some basic facilities available to your code.

      There is a very useful kernel module which does nothing but allocate some memory. That's all it does. :)

      Yes, and in the case of kernel modules, there's a part of the kernel that acts as a substitute for a runtime you'd expect available for user-space programs. Surely the allocation, for example, is not performed by means of some magical CPU instruction that knows all the right things to do so that other modules know about the allocation.

      --
      Ezekiel 23:20
  62. LISP by Sparrowhawk7 · · Score: 1

    To quote Albert van der Horst (Feb 17 '14 at 13:23) "I would rephrase the question as "what features of a language are necessary for hard AI?" This is a valid and useful question, and the outcome will be that only Lisp, Forth & assembler have what it takes to do hard AI. – "

  63. Re:Yes, you could call it Smalltalk, or perhaps li by Anonymous Coward · · Score: 0

    Which functional languages?

  64. Re: Yes, you could call it Smalltalk, or perhaps l by K.+S.+Kyosuke · · Score: 1

    ...seriously?

    --
    Ezekiel 23:20
  65. NIH? by sad_ · · Score: 1

    Not Invented Here syndrome at work?
    People want to keep using Python, it must be doing something right.

    --
    On a long enough timeline, the survival rate for everyone drops to zero.
  66. Re:Easy as Parasailing by Anonymous Coward · · Score: 0

    Use ParaSail: https://adacore.github.io/ParaSail/

  67. Re:Yes, you could call it Smalltalk, or perhaps li by Anonymous Coward · · Score: 0

    I seriously question that claim if you think there's no "meaningful difference between concurrency and paralleism," since that statement pretty much implies you have no idea what either of those words mean in the context of program development.

  68. Everyone is hoping we will stumble upon it by lamer01 · · Score: 1

    You never know, right?

  69. What do you have in mind? by raymorris · · Score: 1

    > There is definitely an expectation of some basic facilities available to your code.

    What do you have in mind when you say "some basic facilities"?

  70. Re:Yes, you could call it Smalltalk, or perhaps li by Anonymous Coward · · Score: 0

    Yield in C# is thread safe thus you could use multi-threading/ to iterate through your data set and consume in parallel.

  71. Re: Yes, you could call it Smalltalk, or perhaps l by phantomfive · · Score: 1

    Yeah. Different people have different definitions and from the point of view of the programmer it doesn't really matter if they are happening at the same time or not.

    --
    "First they came for the slanderers and i said nothing."
  72. Re:Yes, you could call it Smalltalk, or perhaps li by phantomfive · · Score: 1

    Lisp, Erlang, Haskell. Most with Erlang, least with Haskell. Some people call Python a functional programming language, but it's not really.

    --
    "First they came for the slanderers and i said nothing."
  73. Correction by Anonymous Coward · · Score: 0

    LeCun on this story:
    For the record, I didn't say "more flexible than Python", I said "More efficient".

    https://twitter.com/ylecun

  74. Most of the comments are from people who don't wri by Anonymous Coward · · Score: 0

    C++ as the replacement for python? The language does not matter. Gathering insights and making them available to customers is the ML business model. Who cares what language you use as long as you know how to implement the actual concepts.

  75. Re:Yes, you could call it Smalltalk, or perhaps li by Anonymous Coward · · Score: 0

    Most with Erlang? The same Erlang that has explicit concurrency and parallelism? The same Erlang that you have to understand the difference between concurrency and parallelism to use on anything bigger than Hello World? That Erlang?

  76. Cython by Anonymous Coward · · Score: 0

    Some of the guys I work with use cython for compiled stuff. It's not the best solution but it does help with some of the issues brought up. Y the python haters

  77. Re: Yes, you could call it Smalltalk, or perhaps l by K.+S.+Kyosuke · · Score: 1

    Different people have different definitions

    Buuuulshit. Words mean what they mean. *Especially* technical words.

    --
    Ezekiel 23:20
  78. A New Programming Lang More Flexible Than Python by Anonymous Coward · · Score: 0

    Well, what you need is C (or C++). And if you want some sort of sane layer beyond that, then there's PHP and PHP extensions. PHP 8's roadmap is being defined *right now* and there's talk of a JIT for CLI and solid multithreading support. So there you go.

    (How does Faceplant's "chief AI scientist" not know about the changes being made in PHP core when they run HVVM on their entire infrastructure?!)

  79. Re: Yes, you could call it Smalltalk, or perhaps by phantomfive · · Score: 1

    You're full of bullshit. If you knew the difference you would have said it, instead you're wasting words. Wasted words is the definition of bullshit.

    --
    "First they came for the slanderers and i said nothing."
  80. easy ... by Micah+NC · · Score: 1

    ... just set up some deep learning tools in that new language that are:

    (1) feature rich
    (2) have good mechanisms for separating and visualizing data and
    (3) have been well vetted by industry.

    I'll hold your beer.

  81. This. by brunes69 · · Score: 1

    This.

    Garbage code is garbage code, and has very very little, if anything, to do with the language it is written in.

    It is just as easy to write garbage C++ as it is garbage python - perhaps even easier.

  82. Re: Yes, you could call it Smalltalk, or perhaps l by phantomfive · · Score: 1

    Stop saying stupid things and say what the difference is between parallelism and concurrency. Concurrency is really nice in Erlang but I was more attracted by its stability.

    --
    "First they came for the slanderers and i said nothing."
  83. Re: Yes, you could call it Smalltalk, or perhaps l by Anonymous Coward · · Score: 0

    Stop saying stupid things.

    Right back atcha.

    what the difference is between parallelism and concurrency.

    Maybe you should read the Getting Started in Erlang guide. Sections 3.1 to 3.3 deal with concurrency; 3.4 deals with one off the many forms of parallelism. But, of course, you already knew that, right? Your claim to Erlang wasn't just BS, right?

    I was more attracted by its stability.

    Sure you were, sweetheart. Robustness is the chapter after Concurrency in the Getting Started guide. You know why? Because concurrency and parallelism is how Erlang achieves robustness.

  84. Re: Yes, you could call it Smalltalk, or perhaps by phantomfive · · Score: 1

    The link you gave doesn't define the difference between concurrency and parallelism. I'm not sure you read it.

    --
    "First they came for the slanderers and i said nothing."
  85. Re: Yes, you could call it Smalltalk, or perhaps by phantomfive · · Score: 1

    Btw if your point was that you think Erlang has better concurrency than C#, you should have just said that. You might be right.

    --
    "First they came for the slanderers and i said nothing."
  86. Re: Yes, you could call it Smalltalk, or perhaps by Anonymous Coward · · Score: 0

    If you need it spelled out, concurrency happens inside a task, e.g. mullti-threading. Whereas parallelism is multiple tasks, possibly on multiple machines. Erlang is better than C# at both because it was designed specifically to do them well.

  87. Re: Yes, you could call it Smalltalk, or perhaps by Anonymous Coward · · Score: 0

    Some elementary Googling turned up a link for your elementary computer education.

    Even you will understand the difference after you have read it.

    https://howtodoinjava.com/java/multi-threading/concurrency-vs-parallelism/

  88. Re: Yes, you could call it Smalltalk, or perhaps by phantomfive · · Score: 1

    Btw if your point was that you think Erlang has better concurrency than C#, you should have just said that. You migh

    --
    "First they came for the slanderers and i said nothing."
  89. Re: Yes, you could call it Smalltalk, or perhaps by K.+S.+Kyosuke · · Score: 1

    You're supposed to have already seen this a looong time ago. The fact that you haven't is not my problem.

    --
    Ezekiel 23:20