Sure, it's just /usr/local, but @#$#@$@# it's annoying when you have to make install on the dependent library before the core application will install.

Use scons. or a makefile. or cmake. Or build a static binary. I don't care; but look at the go source archive for an example of how to do this right.

This isn't a good first touch of a project:

./configure: line 12296: syntax error near unexpected token `CO2,' ./configure: line 12296: `PKG_CHECK_MODULES(CO2, libco2-1.0 >= 0.1.2,,as_fn_error $? "required module missing" "$LINENO" 5)'

hint: you'll notice autoconf isn't in the list above. :P

If you want to experience this, try www.sigala.it/sandro/ and cutils. There's a links to it on the OP's page. Programs as UNIX filters, written with flex and bison. Beautiful.

I like this OP because he includes a grammar file. If every programmer that tries making his own language did this, the world would be a better place. Did he also include the .l file in the src? I'm too lazy to look. I think they should include those too. It makes the whole thing easier to understand (and modify).

I too get annoyed with having to install the author's own libs. Sometimes these libs are better than the standard ones (e.g. everyone knows C's stdio sucks). If the special libs are fixing something that needs fixing, I'm OK with using them. But nine times out of ten, that's not the case.

For this sort of thing, i.e. C code generation, I still like the LISP's that generate C.

(If someone wants to be mean, he could simply compare this feature-wise with one of the Scheme dialects that compile to C...)

I'm sure this project was extremely interesting to the author - maybe from a different perspective than yours.

> (If someone wants to be mean, he could simply compare this feature-wise with one of the Scheme dialects that compile to C...)

I'm not being mean here, but if someone really wanted to be..

No, but neither does(should) every new language be posted and upvoted to HN.

Two and a half things I guess: the methods of MyObject are accessed by main but not declared public (C++ is private by default)

I don't know if that's good or bad, but it's not very compelling to me.

So it is pretty weird for that to be highlighted as the big distinctive feature.

What about .net/mono targeted languages, javasvcript targeted languages? And custom interpreters jit(frequently but not always written in c)

People focused on entirely new languages tend not to target JITs first for the same reason they tend to not target direct machine code first: it just adds complexity to getting a proof of concept out the door. LLVM, the JVM, and yes, the CLR are starting to change this, but aside from the JVM, there are still only a handful of languages going that route.

That said, there are some good reasons for compiling to C. Not every architecture has a backend for LLVM yet, after all.

I was not disputing the conclusion that it can make sense to compile to C. I was just saying that "people like C" doesn't support that conclusion.

It's my language of choice for personal projects. A neat and compact language that is very trivial to pick up, feels light, and yet sufficiently subtle to intellectually engage your mind.

Very productive, good performance, and very portable.

http://www.youtube.com/watch?v=HxaD_trXwRE

caveat: /imho/ the runtime is not yet fully cooked. ETA is Go1.1 (end of year I believe) for beefed up internals.

I doubt that. It may be (mostly) true for languages that match the capabilities of C well, but if a language does not match C well, it certainly isn't 'automatically' because the optimizer in your C compiler will not help much in making the implementations of such features efficient.

For example, compiling JavaScript to C, it would be non-trivial to make the result as fast as the current JavaScript engines because the C code would likely have to do the same zillions 'is this a string?' checks that interpreters do (probably even more of them because it is harder to see the wood for the trees in your translated-to-C code)

For example, it would require lots of work to support, for example, Lisp's number system, Dylan's union types, any variant of 'eval', or, to take an extreme example, to map Intercal code sequences to efficient C operations such as '+'.

https://live.gnome.org/Vala/Documentation

I realise Apple's Carbon doesn't compile to C but my brain's transderivational search just ignored that fact.

Similarly, are you really suggesting that C programs can't have thread-local storage?

Standard C does not have thread local storage.