
Carbon: high level programming language that compiles to plain C - flexterra
http://home.kpn.nl/pt.kleinhaneveld/carbon/about.html
======
shadowmint
I wish projects like this wouldn't force you to install their libraries in
order to play with them.

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

~~~
055static
It's is one of life's small pleasures when programs (useful programs) compile
fast and with relative simpicity.

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.

------
jryan49
Reminds me of <https://live.gnome.org/Vala>

------
nnq
When the first thing I read about a language it on it's description page is
"compiles to X" or "runs on Y", this is definitely a sign that the language ha
NOTHING INTERESTING TO OFFER whatsoever. Adding insult to injury, underneath
is a bulletted list of language features that any language worth it's salt has
them! And please... "Named constructors"... WTF?!

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

~~~
jasim
Not every language needs to be one of those that changes the way we think
about programming. It is perfectly fine to experiment on mundane languages by
adding mundane features. Incremental improvement is a good thing and it is too
early to just write off this because it seems to be un-interesting.

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

~~~
njharman
> not every languages needs to change ... way we think about programming. >
> I'm sure this project was extremely interesting to the author

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

~~~
Xcelerate
If it's upvoted, then the HN crowd finds the language interesting. If not,
then it will fade away like every other article that doesn't get votes does.

------
Ogre
The Example link contains, I think, only two things that aren't valid C++.
"self." (could be replaced by this-> or simply nothing in C++) and the
["stdio.h"] int printf... syntax for including just one thing.

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.

------
jedbrown
Without a source-level debugger, I see little advantage relative to COS, which
_is_ C, but has a more advanced object and type system than Carbon.
<http://news.ycombinator.com/item?id=1192791>
<https://github.com/CObjectSystem/COS>

~~~
wbhart
There's less typing for the programmer than in COS as far as I can tell. And
productivity is an important improvement.

------
bcl
This is going to need better documentation than a Yacc description if it is
going to catch on.

~~~
andrewflnr
There's example code here,
<http://home.kpn.nl/pt.kleinhaneveld/carbon/example.html>, for what it's
worth. Pretty pedestrian, from my perspective.

------
michaelfeathers
It's odd to see compilation to C as a main selling point.

~~~
alexchamberlain
Some of us rather like C...

~~~
cbsmith
Yeah, which is why traditionally a LOT of languages, particularly early in
their careers, have compiled down to C. Really aside from JVM targeted
languages, it still tends to be the trend.

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

~~~
rat87
> Yeah, which is why traditionally a LOT of languages, particularly early in
> their careers, have compiled down to C. Really aside from JVM targeted
> languages, it still tends to be the trend.

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

~~~
cbsmith
CLR targeted languages are few and far between, as are JavaScript targeted
languages, so I didn't consider them a big enough factor to impact the
"trend".

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.

------
FraaJad
While not discouraging the original author, Vala from Gnome has taken this
thinking a lot further. Vala is actually quite fun to use even for non-GUI
projects. And it doesn't have to depend on GTK libraries to produce working
programs.

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

------
daenney
This is going to be rather confusing, I actually thought someone accidentally
reinvented Carbon, <https://developer.apple.com/carbon/>.

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

~~~
delinka
Writing Carbon that calls Carbon. Let's call this act Magnesium because ...
fusion.

------
WalterBright
Compiling to C puts some significant constraints on your language. For
example, C doesn't have COMDAT support, thread local storage, exception
handling is limited to setjmp/longjmp, static uplevel function links are a
problem, symbolic debug info is going to all look like C, etc.

~~~
tptacek
I'm not sure I understand how C's lack of high-level exceptions makes a
difference for a high-level language that compiles down to C. The high-level
language can provide exception support, just like large-scale C packages
sometimes do using longjmp.

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

~~~
WalterBright
setjmp/longjmp tends to be pretty primitive, compared to decent eh support.

Standard C does not have thread local storage.

~~~
tptacek
Are you missing the fact that we're talking about using C as a substrate for a
higher-level language?

