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