
C (Cbang) - A system oriented programming language - kalenz
http://blog.lse.epita.fr/articles/12-c---system-oriented-programming.html
======
antirez
I didn't checked the details, but I would love to see ten attempts every year,
trying to solve the same problem.

D and Go are not trying to provide us with a better C, because they don't
share the concept of, a language that translates straightforward to assembler,
but still is designed so that you can mount good abstractions with it.

This is what you need for kernel programming, embedded systems, and a good
deal of system programming as well.

At the same point C is one of the top-used languages in the world, with a vast
code base, and yet almost all the attempts in the languages area are about
much higher level or exoteric stuff. Not that I don't want that kind of
research, but it's bizzarre that no one is focusing where a lot of meat is.

I bet this better C will arise in a few years at max, and it is not going to
come from academia. Times are mature apparently, there is even a C conf this
year ;)

~~~
pjmlp
Native Oberon, Spin, Singularity, Home, Inferno are all operating systems
written in GC enabled system programming languages.

D and Go are just following that thread.

Eventually all mainstream OS will have such type of languages and C will be
legacy.

Microsoft is already slowly doing that by dropping support for C later than
C90, and adding COM based API as the default Windows API. Now mainly for
Metro, perhaps for the complete OS in later versions.

Apple as well, by adding reference counting and GC on their systems language,
Objective-C.

C only got spread thanks to UNIX, and brought upon us the wrath of buffer
overruns and dangling pointers security exploits.

We need better languages for doing systems programming.

~~~
Arelius
Interesting that none of those systems are in active usage...

> Eventually all mainstream OS will have such type of languages and C will be
> legacy.

That's just speculation. Personally I have high hopes for languages with
optional-only GC, and much stricter memory management principals. Ala, Rust.

~~~
pjmlp
Windows and Mac OS X are, and they are slowly incorporating such changes, as I
mentioned.

Don't forget that UNIX was once upon a time a research operating system, and
took a few decades to have industry impact.

New ideas take time to mature.

~~~
calloc
Objective-C isn't used in XNU the kernel that Mac OS X uses, Mach is a mixture
of C and C++ (A subset of it actually, known as IOKit).

~~~
pjmlp
System programming is more than just the kernel.

I imagine that the kernel can easily compiled with the Objective-C or
Objective-C++ compiler, if Apple so wishes.

~~~
kelnos
You "imagine" incorrectly. A functioning Obj-C requirement requires a runtime.
Currently that runtime (libobjc) is written in C, and it requires a C library
to function. Yes, you can rewrite those portions to use only functions
available in kernel-land, but it is by no means "easy" as you suggest.

~~~
pjmlp
This just goes to show you don't understand compilers.

All languages require runtimes, even C. The thing is that C as high level
assembler it is, uses the operating system as its runtime.

The C language is also part of Objective-C, in a similar vein as C++ also
supports most of the C89 features with small exceptions.

So it is possible to have the Objective-C runtime compiled using the C subset
of Objective-C. This is known as compiler bootstrapping.

~~~
Arelius
C hardly requires it's runtime. Objective-C without the runtime is just C, if
you write the runtime, GC, and other low-level system components in the C
subset of Objective-C you are just writing the kernel in C.

~~~
pjmlp
Technically you will be using the Objective-C compiler, so it is still
Objective-C even if the syntax looks like C.

The same applies if you would be using the C subset of a C++ compiler.

~~~
Arelius
This is in the original context of how all systems will be written in "GC
enabled system programming languages". If the language is not GC enabled due
to missing a runtime or w/e then the technicality isn't relevant.

~~~
pjmlp
What is relevant, is that universities and some companies seem to have another
opinion.

I am old enough to remember the days when UNIX and C were funny research
projects. Look at them now.

So I leave you with a list of research projects for the boring days, when you
don't have anything to read.

<http://www-spin.cs.washington.edu/>

<http://www.oberon.ethz.ch/archives/systemsarchive/native_new>

<http://www.ocp.inf.ethz.ch/wiki/Documentation/Front>

<http://www.jnode.org/>

<http://www.jnode.org/node/175>

<http://programatica.cs.pdx.edu/House/>

<http://hasp.cs.pdx.edu/>

<http://research.microsoft.com/en-us/projects/singularity/>

<http://cosmos.codeplex.com/>

<http://www4.cs.fau.de/Projects/JX/>

<http://wiki.xomb.org/index.php?title=Main_Page>

~~~
Arelius
The problem, is that at the end of the day, some code somewhere is going to
have to deal with resource allocation. Generally speaking with all the other
fluff aside, an operating system, fundamentally manages and multiplexes
resources. It's naive to think that resource management would be best done in
a language with automatic GC. Somebody

I don't doubt that C is not the systems programming language of the future.
But it's not going to be done in a system that's based around automatic GC
either.

~~~
pjmlp
Read the papers of _proven_ work, instead of stating your beliefs.

~~~
Arelius
You use the word proven as if it means something. The work you list is no more
proven in terms of building production systems than any other research work.

Additionally, I find it interesting to note, that if you had in fact been very
familiar with all the work you mention. You should actually have noted that
many of these systems go through significant effort to sidestep the GC.

~~~
pjmlp
It is proven, because groups of people went through the effort of spending
time and effort implementing those systems and used them for daily work as
well.

It not just talk about some guys showing up papers at OS geek conferences.

The Oberon Native for example, was for long time the main operating system at
the operating system research department at ETHZ. Most researchers used it as
their daily OS for all tasks you can think of.

<http://www.ethoberon.ethz.ch/WirthPubl/ProjectOberon.pdf>

The GC was done at kernel level. Besides Oberon code, there is just a little
bit of assembly for the device drivers and boot loader.

------
kibwen
I think that languages that are a just thin shell on top of C (as opposed to
languages that merely target C, e.g. Chicken Scheme) might have some
potential. I'll call this _coffeescriptification_ \--still eagerly awaiting
the first transpiled language that does nothing but remove C's braces and
semicolons. If someone doesn't do it by next April Fools, I certainly will (I
already have the name in mind: _Glee_ (the italics are part of the name, and
mandatory)).

~~~
0xABADC0DA
One thing often overlooked in language design is the filename. It's 2012, why
are languages still stuck with IBM-era filename extentions when they could use
unicode?! For instance:

Rust: filename.ℛ

Java: filename.☕

Glee: filename.☺

Isn't that just so much clearer and nicer-looking than ".rs" or ".java" or
".g"? It's really the fine aesthetic points like this that can make or break a
language.

~~~
kibwen
Brilliant. I'll be sure to mention your <s>name</s> memory address in the
foreword of the obligatory O'Reilly book (taking suggestions for the cover
animal; I'm partial to the thylacine, myself).

One suggested improvement: Rust's extension should preferably be .® to jive
with the language's official logo.[1] And with the advent of emoji, we can
give Perl a file extension of .🐪 (Unicode Character 'DROMEDARY CAMEL'
(U+1F42A)). Perl 6 can get the bactrian camel instead.

[1]
[http://en.wikipedia.org/wiki/File:Rust_programming_language_...](http://en.wikipedia.org/wiki/File:Rust_programming_language_black_logo.svg)

------
alexchamberlain
I have a couple of problems with their analysis of C.

 _There's no typed macros_

There are inlined functions...

 _While the type system of C is basically size based, a lot of types have an
ambiguous size (int for example)_

Use stdint.h definitions.

Having said that, I would like namespaces in C!

~~~
cmdkeen
But they've identified this as for systems based programming where you don't
have any guarantee of stdint.h holding true (POSIX compliance). Their
implementation is much more flexible. Albeit slightly reinventing the wheel.

~~~
alexchamberlain
I can see what you mean, but stdint.h is just a bunch of typedefs
stardardising the naming scheme. It doesn't take much work to sort it out.

~~~
simias
Indeed, linux uses u32 and friends for instance. It's really not much of a
problem in practice (kernels are by definition very hardware dependent
anyway...)

------
dmpk2k
How about a few more default data structures, like resizable arrays or hashes?
I find the biggest bump in my productivity in most other languages is that
those two things are there already.

~~~
simias
The problem is dynamic memory allocation. It's actually one of the gripes I
have with the "rust" language [1]. As a C coder I find it hard to take
seriously a language that don't let me customize memory allocation easily.

It's not impossible to do right though, C++ has "allocators" parameter
templates to do exactly that (there's a default implementation that you can
"override" with a custom class).

[1] <https://news.ycombinator.com/item?id=3027777>

~~~
marijn
Rust isn't finished yet. It's about to get 'regions', which come with custom
allocators.

~~~
simias
Hey, thanks for pointing that out (and thanks to kibwen for the link).

I've been trying to use (or rather, bend) rust for kernel development lately,
and memory allocation was my biggest limitation so far (including stack
allocation). Definitely looking forward to future improvement on the language,
it looks very promising.

~~~
kibwen
At least one of the developers wants to make Rust's runtime optional, to allow
the runtime to itself be written in Rust. That would probably also serve your
goals as well, so perhaps you'd be interested in helping out? :)

Quote:

 _"I'd like to see a 'runtime-less Rust' myself, because it'd be great if we
could implement the Rust runtime in Rust. This might be useful for other
things too, such as drivers or libraries to be embedded into other software.
(The latter is obviously of interest to us at Mozilla.) Rust programs compiled
in this mode would disable the task system, would be vulnerable to stack
overflow (although we might be able to mitigate that with guard pages), and
would require extra work to avoid leaks, but would be able to run without a
runtime.

If anyone is interested in this project, I'd be happy to talk more about it --
we have a ton of stuff on our plate at the moment, so we aren't working on it
right now, but I'd be thrilled if anyone was interested and could help."_

<http://news.ycombinator.com/item?id=3724577>

~~~
simias
Thanks for the pointers, I'll look into that when I have more time :)

------
nitrogen
Regarding the use of integers as bit arrays, it would be nice if the syntax
supported referring to a subset of the bits, similarly to bitfields in
_struct_ s.

Example based on the syntax from the article:

    
    
      x: int<+32>;
      x[0:6] = 42; // Set six bits starting with lsb 0 to 42

~~~
slashvar
Yes, this is in the TODO list ;)

In fact, it doesn't reach top priority since we can do without for now (we
have bitfields.) The issue with slicing is more a question of design: does
slicing need to be constant expression or should we authorize more expression
power (and then how could we implement that and how could we check it … )

Anyway, I'm looking for a clever way to define values accessed in a none
uniform ways.

Integer as bit array was the simplest idea to test (and seems useful to me.)
Now the compiler has almost everything I need to implement easily that kind of
syntactic sugars.

------
ThomasBHickey
I'm surprised of no mention of Bliss. Nice low-level DEC-10 language, later
generalized a bit.

~~~
draven
I remember reading about it in an article by Olin Shivers (the history of T,
at <http://www.paulgraham.com/thist.html> ).

After reading the wikipedia page about it, it doesn't seem to be available for
any common platform.

How would it perform as a system programming language today (compared to C) ?

~~~
ThomasBHickey
It would work fine. It had bit-level operators, easy assembler integration,
simple macros. Decent looping constucts after the first version. Everything
was an expression which makes lots of things easier and a good optimizing
compiler (rember Wulf?). It did have a major quirk: you had to be explicit on
addresses vs. values. To get a value you put a '.' in front of an address.
Used to drive some people crazy, but I never had any problem (much) with it.

------
protomyth
If we are going to play at the low level, taking a look at Machine Forth might
not hurt.

------
eduadecastro
I guess its time I made my own language... everybody's doing it!

~~~
evincarofautumn
An uncommonly high number of people on HN (or mentioned in stories posted to
HN) are programming language enthusiasts, so it certainly seems like it.

------
paulsutter
What could be more tedious than another low-level language based on subtle
complaints about C?

~~~
chris_wot
Complaining that someone has invented a new low-level language?

~~~
stcredzero
_What could be more tedious than another low-level language based on subtle
complaints about C?_

YALLBOSCAC? How about a language named YALL and boscc as the name of the
compiler?

