Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Deep learning to translate between programming languages

ai.facebook.com

Post reply on HN
Print view View original

31–40 of 81 posts

Re: Deep learning to translate between programming languages

#31

Post by PunchTornado »

disgruntledphd2 wrote: post #17
peacefulhat wrote: post #9

I can't imagine this working out for producing idiomatic code, especially between very divergent languages like Haskell and C++. Their example is almost straight syntactic replacement, not very impressive. And their real-world use-case is for migrating COBOL projects to python??

Facebook as a company do not believe in ever rewriting large code bases. You can view lots of their open source/technical achievements as out growths of this belief: - 2004, write PHP as it's fastest for now - 2008: PHP is too slow, compile it to C++ - 2011: C++ is too slow, write a VM and compile to assesmbly - 2012: PHP's type system sucks, write a better typer in OCaml (Hack) - They have done much the same for Jav…

I think they chose the right strategy, compared to twitter which loves rewritting to another language.

Re: Deep learning to translate between programming languages

#32

Post by danfritz »

Cool magic trick but I fail to see anything useful coming out of it. I would not blindly rewrite code, rather see how it can be improved and maybe dig a bit in the existing functionality, clean it out, use the new language in my advantage...

Also as a programmer your mental modal is completely out of sync, how do you work on such application suddenly now that its all in Python (coming from C++)? Or is this shipped to a new team which received 100 000 lines of C++ but no clue how it all works?

How would FB use this at all?

Re: Deep learning to translate between programming languages

#33

Post by malux85 »

_y5hn wrote: post #16

This sounds more impressive than it is. I kept an auto-translation going for quite a while from C# to Go just by creating some bash scripts. These languages are so similar, that while not idiomatic, you can be up and running with quite few rules and some simplifications to the original code. While I believe this is a good arena for algorithms to provide solution, I'm sceptical that ML in its current incarnations is t…

Yeah I was thinking it might be better to use something like LLVM IR as the “data structure” and then train deep nets to go $(LANG) => IR and then IR => $(LANG), trained with a lot of idiomatic well written code for each Lang, then the nets might be able to glean the intent more than implementation details.

Not sure though, I’m not an expert in LLVM IR, so I’m not sure how feasible that is...

Re: Deep learning to translate between programming languages

#34

Post by qayxc »

bdavis__ wrote: post #30
qayxc wrote: post #26

Earlier quoted context omitted.

That'd be truly remarkable as in actual magic. Take this rather simple example: PointList interpolate(PointList sample_points, OrderedRealNumberList points_to_interpolate); This function can be auto-documented from its name and the names and types of its arguments alone. No ML required - simple pattern matching and LUTs will do. But then again, do you really need a detailed documentation in such case? Where a documen…

Guessing !! N,X, and F are probably related to NE,XE, and FE "E" means "error"? Maybe. IERR is an error flag. Idiomatic fortran there. Each of those variables will be defined later on, in the code. at least with a type (not required, but it is not 1960 anymore). In that declaration is where some comments would be. REAL*8 N ! Radius of the body in radians Point being that fortran is not hopelessly opaque. A subroutine…

> In that declaration is where some comments would be.

Here's the declaration of the parameters:

  INTEGER  N, INCFD, NE, IERR
  REAL  X(*), F(INCFD,*), D(INCFD,*), XE(*), FE(*)
  LOGICAL  SKIP
Sorry, but no comments to be found :)

> NE,XE, and FE "E" means "error"? Maybe.

Wrong guess - "E" means "Evaluation" as in "to be evaluated" in this case. It's also not clear which are inputs and outputs and primitive data types give no indication at all about constraints and use-case.

> IERR is an error flag. Idiomatic fortran there.

Now that's true, but idiomatic cases that are well documented and don't benefit from AI documentation. Simple pattern matching will do.

The point I was trying to make wasn't really about any specific programming language either. The point is rather that documentation requires translating implementation to intent and purpose.

If you have a system that's capable of translating a program into purpose, constraints, and usage example(s) expressed in plain natural language; you have created a system to end all programming languages, because the inverse transform would be possible as well...

Re: Deep learning to translate between programming languages

#35

Post by acd »

I see the potential to speed up code a lot. Say that you could translate Python to C++ or Nim that would speed up the program a lot. You could profile and translate select hot often used code paths. This has the potential too save a lot of energy by using more efficient programs.

Re: Deep learning to translate between programming languages

#36

Post by bdavis__ »

qayxc wrote: post #34
bdavis__ wrote: post #30

Earlier quoted context omitted.

Guessing !! N,X, and F are probably related to NE,XE, and FE "E" means "error"? Maybe. IERR is an error flag. Idiomatic fortran there. Each of those variables will be defined later on, in the code. at least with a type (not required, but it is not 1960 anymore). In that declaration is where some comments would be. REAL*8 N ! Radius of the body in radians Point being that fortran is not hopelessly opaque. A subroutine…

> In that declaration is where some comments would be. Here's the declaration of the parameters: INTEGER N, INCFD, NE, IERR REAL X(*), F(INCFD,*), D(INCFD,*), XE(*), FE(*) LOGICAL SKIP Sorry, but no comments to be found :) > NE,XE, and FE "E" means "error"? Maybe. Wrong guess - "E" means "Evaluation" as in "to be evaluated" in this case. It's also not clear which are inputs and outputs and primitive data types give n…

i agree with you!

nice to see someone else using fortran 77. or at least reading it.

Re: Deep learning to translate between programming languages

#37

Post by dunefox »

acd wrote: post #35

I see the potential to speed up code a lot. Say that you could translate Python to C++ or Nim that would speed up the program a lot. You could profile and translate select hot often used code paths. This has the potential too save a lot of energy by using more efficient programs.

That seems like a lot of effort when Julia is both high-level and efficient already.

Re: Deep learning to translate between programming languages

#38

Post by RMPR »

dunefox wrote: post #37
acd wrote: post #35

I see the potential to speed up code a lot. Say that you could translate Python to C++ or Nim that would speed up the program a lot. You could profile and translate select hot often used code paths. This has the potential too save a lot of energy by using more efficient programs.

That seems like a lot of effort when Julia is both high-level and efficient already.

Let's rewrite everything in Julia.

Re: Deep learning to translate between programming languages

#39

Post by klyrs »

acd wrote: post #35

I see the potential to speed up code a lot. Say that you could translate Python to C++ or Nim that would speed up the program a lot. You could profile and translate select hot often used code paths. This has the potential too save a lot of energy by using more efficient programs.

Cython already translates Python to C. And if the translation introduces a bug, the Cython developers can find a solution.

This ML crap is inexplicable, and nearly guaranteed to introduce subtle bugs and performance regressions.

Re: Deep learning to translate between programming languages

#40

Post by mochomocha »

WalterBright wrote: post #7
synchronizing wrote: post #3

To imagine future compilers may just one day be AI powered is mind boggling to me.

I've heard that LLVM uses neural networks to drive the register allocator. I don't know how well it works, but it's a pretty cool idea.

In the PGO category, there's also this recent proposal: http://lists.llvm.org/pipermail/llvm-dev/2020-April/140763.h...

At compile-time only, people have also been using trained models to derive cost functions for sequences of instructions (as opposed to analytical models which become very difficult to derive these days given the complexity of modern CPU architectures)

Post reply on HN