I'm always slightly confused when languages target C instead of compiling themselves. Nim, for example. Is it really that much easier to deal with all the idiosyncrasies of C for a backend, and have to hope that the compiler will cleanup the mass of basic code blocks you emit, than emit LLVM bytecode or assembly? Not even having to use the LLVM C bindings, you can just emit the bytecode directives to a file and call the toolchain itself.

Is the idea that you can compile you base code once, and then work on the emitted C to extend the project?

As camgunz said, emitting C code makes your compiler far more portable, as you can find C compilers for virtually every target (e.g., AFAIK, the current version of LLVM does not support SPARC architectures).

Another theoretical advantage of generating C code is that it should be easy to try adding bits of code written in these new languages to existing C/C++ projects. In this way you can test the new language on real life projects without the need of rewriting everything from scratch. (I have never followed this approach, although I have heard of people having done this [1].)

[1] http://roscidus.com/blog/blog/2014/06/06/python-to-ocaml-ret... The languages here were quite different, though (Python/OCaml): but the author followed the idea of slowly converting a project to a new language by first rewriting parts of it. Had the OCaml compiler emitted Python code, I bet the task would have been easier.

I've heard portability arguments; C is far more portable than LLVM. But I'm guessing more people know C than LLVM IR or 4 assembly languages, so C is an easier target.

EDIT: oh, also wildly easy interoperability with existing C/C++ code (so long as the C++ code provides a C interface).

Compiling down to C also makes wrapping C++ libraries much easier. Because when you compile down to C, it's not that much of a stretch to also allow compilation to C++. You can then make wrapping C++ code much easier in the language.

Nim is one language that I know of which takes advantage of that. Here is one example of a pretty large wrapper around a C++ library https://github.com/3dicc/Urhonimo, and here is the documentation for this feature http://nim-lang.org/docs/manual.html#implementation-specific...

Depending on the C standard you're emitting, portability and backward compatibility gains can potentially be huge.

I've even occasionally managed to get code from compiled-to-C languages working on platforms like RiscOS and Amiga.

You can often use any language for esoteric microcontrollers, as long as it's C.

Languages that can be compiled to C could be interesting for implementing embedded system firmware.

In this particular case, ooc is a syntax sugar for C, like CoffeeScript is a syntax sugar for JavaScript. It wouldn't make any sense not to compile to C.

I think the biggest benefit of compiling to C is that you can output comments about which C sections correspond to which lines in the higher level code, and then you can use step-through debuggers to see why your emitted code isn't working right.

You don't have to deal with all the idiosyncrasies of C, because you can restrict yourself to a small subset of C that is straightforward and easily understood.

LLVM bitcode is version dependent. Some of it is architecture dependent. Emitting C is way way easier.

Odd to see it not mentioned as another benefit, but by targeting C instead of say direct assembly you benefit from the decades of optimization research that has gone into modern C compilers.

This is a really interesting idea. I'm surprised this is the first language I've heard of that targets C. C's major strength is portability, but that means change is slow. When browsers stagnated, coffeescript filled the void, which in turn influenced new versions of javascript.

A certain subset of C++ seems to solve a lot of peoples' problems with C, but it also seems there's no consensus on what that subset is. So people stick with C because at least the rules are defined. Compile-to-C languages like this could have all the benefit of switching to C++ without the downsides

I'm feeling a lot more interested in OOC now than the last time I looked, not because the language changed but because I did.

I've tried everything else that's popular in the domain at this point and overwhelmingly, the problem is that new systems languages are too big, too incompatible with the existing ecosystem, or too immature in their tooling. They are usable, and many of their cares and concerns are justifiable, but they're overwhelming in a lot of ways. The compilers do so much, and they break, they have weird error messages, or do surprising things with their advanced features. They're mainly built by people who want to make great compiler technology - and they have that, but that doesn't necessarily lead to a smooth development experience on my end.

Most of those issues are sidestepped with a smaller language that just encodes a bunch of common idioms, which OOC does. There are other viable "compile to C" languages out there, of course, but I'm getting more interested in this one.

Edit: And yeah, this is the Go argument. But Go doesn't want to be C-like, really.

Not a new idea at all, many compilers for different languages output C as one option anyway[0].

Among languages I've enjoyed using and achieving high productivity is CHICKEN Scheme[1]. The compiler defaults to emitting C, though usually the C code is immediately compiled into binary object or executable form. CHICKEN also integrates very well with C as embedded in a C application, using C libraries or writing C directly in "foreign-lambda*" expressions.

[0] http://stackoverflow.com/questions/6498850/programming-langu... [1] http://call-cc.org

Since you mention CHICKEN, the "Lisp in small pieces" book although describe such a procedure.

It is indeed an interesting idea. However, it is hardly the first to do this. The first C++ compiler (cfront) did so [1], and there are other languages that follow this idea still today [2][3].

[1] https://en.wikipedia.org/wiki/Cfront [2] http://chapel.cray.com/ [3] http://nim-lang.org/

Vala is another example of such a language. It generates C and uses GObject under the hood.

https://wiki.gnome.org/Projects/Vala

Nim is one relatively popular language that compiles down to C [1]. Jonathan Blow's upcoming language Jai is another one.

[1]: http://nim-lang.org

Has anyone noticed this awesome tutorial on the site? Just plain awesome!

Thanks for pointing it out. When I reached the homepage late last night, honestly I wasn't going to give it much thought.

The code snippet seemed uninteresting and to lack anything original, the pitch wasn't really selling much, and to top it off there were some text blurbs that seemed unfinished.

Then I saw your comment and read the tutorial. This was actually a pretty interesting read, even without actually following along in a console.

I find it assumes a bit too much so I don't think a total beginner would like it, but for someone used to toying around with new languages it's very well presented I think.

How good does the produced C code look though? I mean if you were on a project which required C code and you used Ooc would your co-workers immediately barf if they saw the C code you committed to the repository?

I think these sort of tools are interesting because many companies are stuck with some ancient language hurting productivity, but being able to use tools like this one can circumvent some of the problems, if only for new code as existing code will have to be maintained in C.

> if you were on a project which required C code and you used Ooc would your co-workers immediately barf if they saw the C code you committed to the repository?

Commiting generated code, are you crazy? I don't care how pretty it looks, if it's not source code, it doesn't belong to source control.

If you still want to put generated C dode in the repository, you can, but the second you type `push` command is the second your C code becomes source code. Treat it as such.

Or, just put Ooc code into the repository. That is the source code after all.

Web developers appear to disagree with you, there is Grunt-generated JS and minified JS committed to repositories all over github.

Seriously what's the point? Hopefully their repositories also have the genuine source code? I'm not interested in reverse engineering.

I haven't tried to find out why people do that and find it baffling, but I guess they don't trust Grunt or their minifiers and want to compare the output of different versions. The repos I have seen also have the genuine source code.

Previously: https://news.ycombinator.com/item?id=882864 https://news.ycombinator.com/item?id=1508943