C2 Lang design (2014) [pdf]
c2lang.org
C2 Lang design (2014) [pdf]
1–10 of 23 posts
Re: C2 Lang design (2014) [pdf]
#2Looks extremely interesting. I'm skeptical of some of its claims (faster compilation when incremental compilation is removed sounds unlikely, for example), but nothing that worrisome.
Anybody have any experience? Is it still basically a toy language?
Re: C2 Lang design (2014) [pdf]
#3Looks extremely interesting. I'm skeptical of some of its claims (faster compilation when incremental compilation is removed sounds unlikely, for example), but nothing that worrisome. Anybody have any experience? Is it still basically a toy language?
The main site makes it look like the language is about a year old.
I have no doubt that they can make the parsing stage faster, as they won't be parsing the same headers over and over again. This is often a bottleneck in C++, but much less often in C. (I've seen 10+MB C++ files after preprocessing).
Re: C2 Lang design (2014) [pdf]
#4Is there an advantage to this over say a more modern and safe language like Rust? It seems to be just reducing the complexity of the language, but doesn't look like it will reduce memory related bugs.
Re: C2 Lang design (2014) [pdf]
#5Looks extremely interesting. I'm skeptical of some of its claims (faster compilation when incremental compilation is removed sounds unlikely, for example), but nothing that worrisome. Anybody have any experience? Is it still basically a toy language?
The main site makes it look like the language is about a year old. I have no doubt that they can make the parsing stage faster, as they won't be parsing the same headers over and over again. This is often a bottleneck in C++, but much less often in C. (I've seen 10+MB C++ files after preprocessing).
If people used precompiled headers (which have been available for about 20 years) that problem wouldn't be there...
However I'm not sure that the parsing is such a bottleneck these days; I think all the complex constructs are a lot more of a time sink (templates etc). That and linking! Takes an hour to link the webkit library with the regular linker :-)
Re: C2 Lang design (2014) [pdf]
#6Is there an advantage to this over say a more modern and safe language like Rust? It seems to be just reducing the complexity of the language, but doesn't look like it will reduce memory related bugs.
Since you have to rewrite everything, you might as well switch to another language (we switched to OCaml). If there was an incremental path or a safe subset of C or something like that, that would be more interesting.
Re: C2 Lang design (2014) [pdf]
#7Is there an advantage to this over say a more modern and safe language like Rust? It seems to be just reducing the complexity of the language, but doesn't look like it will reduce memory related bugs.
Since you have to rewrite everything, you might as well switch to another language (we switched to OCaml). If there was an incremental path or a safe subset of C or something like that, that would be more interesting.
You can use D, which shares a lot of syntax with C, although you cannot directly reuse C code because there is no preprocessor in D. Some people use D as a "C development compiler".
The incremental path is the official C standards. C will probably gain modules for example.
Re: C2 Lang design (2014) [pdf]
#8This is cool. I've often toyed with a similar idea of creating a language that improves/fixes the thing C messed up. If you aren't worried about safety (memory bugs can largely be avoided by changing how you do memory allocation, i.e. switch from individual mallocing to region based memory management) then C is actually a pretty nice language since it is simple enough to hold the entire language in your head. Plus it's nice to know how things are actually laid out in memory. The problems C2 solves are really the main things that frustrate me about C: header files, lack of a build systems, no modules, spiraling type signatures.
Re: C2 Lang design (2014) [pdf]
#9Thoughts as I read:
1. "uninitialized var usage is error": unfortunately impossible without at least one of the following compromises: Automatically initialize variables (wastes CPU); False alarms (see Java); Built-in formal proof system; or, Require compilers to solve the halting problem.
2. Removed keyword "static": kills one of my favorite tricks, "self-init'ing functions".
3. New keyword "as": A good invention in Pythonland. Good call to bring this in.
4. New keyword "nil": Redundant with NULL?
5. Example - Base Types: Uses uint8 in place of char. This obscures intent and makes code less readable. Compare: int library_fnc(char asterisk errmsg) versus int library_fnc(uint8 asterisk errmsg). (HN wants to turn my asterisks into italics...) In the former it's clear errmsg is a string, in the latter it's not clear (it could be a pointer to a flag).
6. Example - function types. Doesn't one usually typedef the function pointer, rather than the function itself? So making that require two lines is annoying. Aside that, the author is right that C has confusing function pointer typedef syntax.
7. Multi-part array initialization: Encourages unmaintainable code. Depending on what's in those "..."'s, might require compiler to solve halting problem?
8. Multi-pass parsing: Trades maintainability for instant gratification.
9. Symbol accessibility: The author makes "public" (and implicit "private") modify entire structs rather than individual fields...
10. Multi-file module: May lead to unmaintainable code
11. I'm worried about the language arbitrarily defining things like "the results of building are stored in the 'output' directory". OTOH the recipe.txt idea could help standardize what amounts to a lot of ad hoc Makefile programming.
12. Build process difference: Theoretically could speed up compilation. I'm worried for social reasons. In module-based languages, we tend to fall into module hell: one symptom being the infamous 20-page stacktrace (see: Java, Clojure, etc.) The nature of C's #include incentivizes shallow dependency trees (a very good thing).
13. "Language scope": trades portability for convenience
14. Tooling: This shouldn't be part of the language, it should be separate.
Re: C2 Lang design (2014) [pdf]
#10Is there an advantage to this over say a more modern and safe language like Rust? It seems to be just reducing the complexity of the language, but doesn't look like it will reduce memory related bugs.
Since you have to rewrite everything, you might as well switch to another language (we switched to OCaml). If there was an incremental path or a safe subset of C or something like that, that would be more interesting.
My thoughts exactly. If nothing bad happens, I think Rust will be a worthy successor of C in low-level land. If I need a higher abstraction level, I use either Lisp if I want dynamic typing, or OCaml if I want static typing. Together, those three cover a vast spectrum.
addendum: That doesn't mean C2 is not a worthwhile experiment. I might even try it out when a compiler is available.