-1

What are the highest level languages that can be compiled to executables? When I say compiled to an executable I am not referring to bytecode, but native assembly code like in the C, C++ sense.

EDIT: One issue that I'm having is that clients have ssh access to my server in a limit access acount. They need to run some of my scripts but I don't want them to see the source code. A Python script (or any other script) cannot be executed without read permission unlike a natively compiled program which only needs execution privileges.

jairajs89
  • 4,495
  • 3
  • 18
  • 14

4 Answers4

2

Any language can potentially be compiled. .net contains a native code generator (NGEN) that translates bytecode into native code, and could potentially be used to create native binaries. And really, any language that compiles to bytecode could have the same capability.

It starts getting tricky when you get into scripting languages (Python, PHP, Perl, etc). In those, it's usually easier to bundle the script with an interpreter in a single executable. But there's nothing preventing someone from writing a PHP or Perl compiler, except that both languages' "eval" functions would pretty much require the ability to parse and execute text -- meaning you'd end up with an interpreter at least linked to the program anyway.

The bigger question is, "At what level does it stop being worth it to compile?". To that, i'd answer "when you're running code that has to be able to interpret itself". IE: i wouldn't bother trying to compile any language that has an "eval" statement/function, unless i were allowed to remove the statement/function.

cHao
  • 84,970
  • 20
  • 145
  • 172
  • One issue that I'm having is that clients have ssh access to my server in a limit access acount. They need to run some of my scripts but I don't want them to see the source code. A Python script (or any other script) cannot be executed without read permission unlike a natively compiled program which only needs execution privileges. – jairajs89 Jun 22 '10 at 07:08
  • If it's an issue, you could maybe have a "runner" program whose sole purpose is to run your script. It could be setuid, and the script could be restricted so that only the "runner" program's user could read it. The only issue is what would happen if it needed to write output files, as they'd generally be owned by the runner program's owner, not the user that started the program. – cHao Jun 22 '10 at 07:11
  • How many? If there's a single output file per script, it could write to stdout and the user could just say "run_this_script >output.txt". – cHao Jun 22 '10 at 07:17
  • Other than the setuid loader thingie, your best bet would be to find a way to package a script and interpreter together. – cHao Jun 22 '10 at 07:19
  • -1 NGEN cannot make a native executable. It sounds weird, but "native generator" does not generate native executables. So you should know before saying that. – Camilo Martin Jun 22 '10 at 07:21
  • Actions: ngen install [scenarios] [config] [/queue[:[1|2|3]] ---- Generate native images for an assembly and its dependencies and install them in the Native Images Cache – cHao Jun 22 '10 at 07:24
  • Thanks for you help, but I think I'll go with Java using the GCJ compiler. At least I don't need to do everything in C anymore.. – jairajs89 Jun 22 '10 at 07:28
1

My vote would be for Java + GCJ. More information about GCJ can be found at:

http://en.wikipedia.org/wiki/Gcj

It can skip bytecode and compile directly to machine code.

Reinderien
  • 11,755
  • 5
  • 49
  • 77
  • Thanks! I didn't know that there was a Java implementation that completely skipped the JVM floating around. – jairajs89 Jun 22 '10 at 07:12
  • Til you use it. Unless it's massively improved since i last used it, the binaries it generates are unbearably slow for supposedly being machine code. – cHao Jun 22 '10 at 07:31
  • Yeah, the disclaimers in the Wikipedia article are interesting. GCJ is no longer maintained, and purportedly, JIT compilation can sometimes achieve better results regardless. – Reinderien Jun 22 '10 at 09:00
1

Many Lisp dialects have native code compilers, as do Haskell, OCaml, and Standard ML.

ekiru
  • 71
  • 4
0

You are confused. The point of computer programming languages is that they can be automatically executed, and ultimately that always means compiling to machine instructions. Therefore by definition, programs in every language can in principle be turned into executables. Some don't actually take that step and are content with interpreted byte code, but most languages do have translators for native code (even Java, for example, has JIT compilers that produce processor-specific opcodes instead of byte code).

The only difference is that higher languages need a bit more of the compiler infrastructure to be included in the executables; no compiler can get rid of the garbage collection mechanism, or run-time type information, or it wouldn't be the same program anymore. But a computer programming language that couldn't be automatically translated to something runnable would be pretty pointless.

Apart from intentionally dysfunctional languages like Malbolge, or course, where writing "Hello world" was a multi-year effort...

Kilian Foth
  • 13,904
  • 5
  • 39
  • 57
  • 1
    No, traditional interpreters did not compile their language, and it is possible to create languages which cannot be compiled (for example, MSDOS batch files cannot be compiled as you can rewrite the batch file while it is executing). – Pete Kirkham Jun 22 '10 at 08:20
  • @pete So what? The compiler can insert itself into the compiled program and rerun compiles of the batch file after changes. Compilation is never impossible, just sometimes senseless. Most lisps carry a compiler around in a similiar fashion. – Jürgen Strobel Nov 08 '12 at 17:09