Hacker News Reader

Comment by ndesaulniers | Hacker News Reader

Good question, but a majority of this post is links to cppcon videos. (I do appreciate the shoutout to LLVM).

I think the C community:

* Should have a C conference.

* Actually be more aggressive in adding features to the language. For example, there are some really great GNU C extensions that are long overdue be added to the standard. Compiler vendors should work with the standards bodies more, rather than shipping language extensions, compiler builtins, and various compiler plugins in isolation outside of standards bodies (because then codebases become tightly coupled to the compiler; ie. the Linux kernel).

View on HN

I strongly disagree. C should is adding langauge features at a pace other languages could stand to emulate. C is stable, trusted, and supported everywhere for this very reason. Codebases should not be using extensions, and Linux is wrong to do so.

> Codebases should not be using extensions, and Linux is wrong to do so.

Poppycock. Codebases should use any and all tools available to them to accomplish their goals, given the tradeoffs. Using non-standard language extensions is a tradeoff, and if it suits the Linux community and their goals, there's nothing wrong with that.

That is one way non-standard extensions become standard.

For example, the [[maybe_unused]] and similar annotations in C++17 grew out of gcc builtins.

Of course, C++ is much more aggressive in stealing popular features from the community, especially Boost.

Boost came about from a few members of the ISO C++ committee as a way to iterate on library features. It would be a shame if none of that work made it's way back into the standard.

Boost was created as a place to beta-test future C++ features. Its whole point is to move stuff from boost:: to std::

> C should is adding langauge features at a pace other languages could stand to emulate.

Remember the Vasa! ;)

> C is stable, trusted, and supported everywhere for this very reason.

See the sibling comment about C not being fully supported everywhere. As long as people continue to make proprietary compilers, there will be implementation deficiencies. That's orthogonal to the language itself.

> Codebases should not be using extensions,

Agree and disagree. Maybe "codebases should only use extensions when it's feasible to provide fallbacks" or something.

> and Linux is wrong to do so.

I'm not sure I agree. There are some worthwhile extensions IMO, which is why I made the point earlier that I think it's time to standardize them.

>> Codebases should not be using extensions, and Linux is wrong to do so.

Why? If you can improve the performance/security/stability of Linux by re-writing functionality without extensions, by all means do so(and send in a patch). Why is Linux "wrong" for this?

The problem with not allowing language extensions to be used is that it promotes the staleness of the language.

Just as human languages evolve as people use and adjust it, programming languages evolve as people start trying to change it to better suit their needs.

The difference with human languages and programming ones is that there's a relatively easy process to get everyone in sync on how it changes for programming languages. :)

I also agree with the grandparent comment that more features should be specified and incorporated into the C standard. The fact they exist and are in wide use says a lot all by itself.

C is used more as an API than a language.

This is the fundamental problem with languages that don’t have a good story for user-written compiler extensions: either they don’t adapt to new use cases or the standard gets horribly bloated or else, like Haskell, one implementation becomes the de facto standard.

The main problem with that is there is no single C community.

Imagine trying to get ANSI C, Win32 C, GNU C and every flavor of embedded C together.

Nonsense, that is the C community. They need to be put in a room together to sort out their differences. The differences exist due to communication breakdown which leads to divergence over time.

What about the various RTOS people or embedded firmware people? Or the mathematicians... or the...

It's like saying, "Let's get everyone who speaks English speakers together to agree on our favorite tea."

Seems more like saying "Let's get a bunch of tea drinkers together, who all drink tea for different reasons, and different types of tea, to discuss tea", which sounds like a great thing for a bunch of people interested in tea.

Maybe the fact that there are many split communities is even evidence that a conference would be beneficial. Get some cross pollination of ideas going on.

Even the functional language communities arrange joined conferences to learn and exchange ideas, so why can't C?

Seriously, check out TI's C++ support for their DSPs. Last time I checked they were so behind the curve they didn't even support templates.

That might because they are targeting Embedded C++, which explicitly eschews these features.

Full C++11 support has been on their roadmap for years. http://e2e.ti.com/support/tools/ccs/f/81/t/542711

And IMO, the final Embedded C++ spec is such a terrible idea that it doesn't absolve them. Having written a C++14 RTOS, if I had to give up multiple inheritance, namespaces, sane casts, and templates, I would have just written the damn thing in C to start off with. The value proposition of institutionalized C with Classes doesn't do it for me.

See https://www.youtube.com/watch?v=TYqbgvHfxjM for what you need to do to have C level perf while using the type system to still get you something.

You may want to take a look at Apple's Embedded C++ implementation for I/O Kit, which is grounded strongly in object-oriented programming and inheritance: https://developer.apple.com/library/archive/documentation/De.... Of course, it does drop the very features you seem to enjoy, namely multiple inheritance, namespaces, and templates, but I think there is more reason to this apart from "these things are complicated to implement/hard to use"–I/O Kit was based on NeXTSTEP's DriverKit, which was written in Objective-C and offered none of these features.

Template metaprogramming is very useful on embedded :) https://github.com/kvasir-io/kvasir

I've only glanced at this, but this caught my eye:

> The header only nature of Kvasir and very sophisticated use of the volatile keyword

This isn't a particularly encouraging sign…

Early 2000s:

The main problem with that is there is no single JavaScript/HTML community.

Imagine trying to get IE, Netscape, Opera and every flavor of embedded HTML viewer together.

2018: "This website only works optimally on Google Chrome"

Why does C++ not have that problem? It too has many communities but they manage to go to the same conferences without any issues.

Mostly due to the less diverse nature of the communities I guess. Because C is older and used a lot more low-level you get a lot more strange C versions and C users.

Most of the C developers/users are going to be interested in their topic, which is often already having a conference of their own. Think Linux Kernel Plumbers conference which is just about the kernel, and since practically all of it is written in C that's where you'd find all the people you'd want to meet on your C-topic.

There would be no point in going to a conference that is about using win32 and C when you are not using win32 as virtually nothing (besides the basics, but those basics aren't why you'd attend a conference) ports to your own environment.

Because C++ has a lot of extras that can be used in a variety of cases that cross platforms and APIs all the same, and because it has a different development and dispersion ecosystem, you'd get more of a C++ oriented conference without the information being non-portable.

Reply on news.ycombinator.com