Because though there might be building trades conferences, there are no hammer conferences. Oh, there will be tool vendors at the building trades conferences, there might be sessions on "Efficient Hammering Techniques Using Machine Learning", but there are no conferences about hammers. Don't forget about the blacksmith conference next week, they'll have hammer vendors, too.
I dunno, a Ruby conference kinda makes sense because one will mostly build web sites with it, so it's really going to be a "Building $FOO with $TOOL" kind of thing. But C is so widely used, it's like having that HammerFest 2019 with everyone from people splitting wood with a sledghammer to jewelers with their teensy little tapping tools. I just don't see the diamond workers drinking with the lumberjacks at the hotel bar after hours. :-) I jest, but it's mostly about networking anyway, otherwise just watch the videos online.
To find the answer, I would ask, Why are there conferences for other technologies? What are they for?
And I think the answer is probably 1) get useful news about recent and upcoming changes and 2) to socialize. I'm going to guess--possibly just projecting--that most C developers are older and not terribly interested in meeting new "C friends" or jumping into some hot, new "C startup".
That leaves #1. Web/AI-ML/cloud/mobile tech conferences feature speakers from the big tech companies that might reveal, in a talk or a hallway chat, info about which of your problems they are about to solve or to cause. Independent speakers serve a sort of journalist role of gathering intel from the big companies, organizing it, and revealing their findings. It's all about "tell me what I need to know so I can decide what to do".
But there isn't much news about C that most C programmers will want to know in order to make decisions. It's almost like news about algebra or, yes, hammers: mature, slow-changing technologies whose changes seldom impact more than a small percentage of users.
So without reasons 1 or 2, the answer to why aren't there C conferences is basic and boring: what important purpose would they serve?
Perhaps they were thinking of the ordinary equation solving that most people know as algebra, rather than the abstract algebra (group theory etc.) covered in university mathematics courses.
C is the tool, so probably a better analogy would have been to pencils, rather than algebra, which is more in line with OP's sentiment regarding hammers.
> I'm going to guess--possibly just projecting--that most C developers are older and not terribly interested in meeting new "C friends" or jumping into some hot, new "C startup".
Unfortunately that doesn't explain why there are not only aren't C conferences today, but there weren't C conferences 15, 20, 30 years ago.
I was a C programmer 30 years ago, but we didn't attend C conferences for two reasons: 1) programming languages weren't newsworthy enough to generate much buzz. Hardware was the focus of attention, and things like programming languages tended to be features of products, not products themselves. And 2) C was already about 20 years old by that point in any case, so monthly magazines were sufficient to keep up with the changes. We didn't tend to go to Fortran or COBOL conferences, either.
We DID go to conferences or expos for things that were buzzy and newsworthy, which meant the exciting new world of microcomputers: Comdex, MacWorld, etc. But the emphasis was on exposition, not conferencing with others, because we got to see exciting, new things with our own eyes, when that was the only way to see them (couldn't "see" things online). We wanted to see them (and they wanted to show them) to inform our decisions. The makers of C tools filled plenty of booths at the "computer expos", though.
Twenty years ago, we had started having big language conferences. JavaOne was like a religious revival or political rally, but C was the old devil being vanquished, not the Hope of the Future. And Visual-J++ and C# conferences were counter-political rallies, where C was going away as both sides agreed, but to be replaced by what? The makers of C tools still filled plenty of booths at the hardware expos, but there wasn't much demand for a C conference where we could hear, in person, about how C wasn't actually dead yet.
And by 15 years ago, all the hotness that inspires a crowd to gather for a conference was based on changes relevant to the WWW. If C had reinvented itself with shiny, new async networking, web service & e-commerce building blocks, concurrency, and whatever in its standard libraries or some such approach, there definitely WOULD have been C conferences. That would have been big news (and probably a bad choice, but that's a different question.) Without something like that, there is still plenty of demand for C, but little demand for a C conference.
Yes but the reason there’s someone making money hosting a conference for X is that there’s a demand for a conference on that topic. Why is there a demand for Ruby conferences but not C ones?
Exactly. C programmers don't define themselves as C programmers mainly. They are firmware developers, game developers or something else. That's where their real interest is.
It's like how they have hamburger restaurants, where you can ask for a hamburger without the pickle, instead of having hamburger without pickle restaurants. C is the burger, bacon, bun, lettuce, tomato, onions and sauces, and ++ is the pickle.
I think you swapped the complexity that each language provides. If C is anything, it's the patty, and C++ literally everything else that makes up the burger.
> C++ literally everything else that makes up the burger.
"Oh, you wanted mayo on your burger? We can do that, but you also have to have mustard. Don't worry, you won't have to pay for it.. but it's going to be in there."
I dunno- I just got back from rubyconf where I both gave and watched talks on metaprogramming with no web focus at all. There was a great illustrated talk featuring lemurs that was just a walkthrough of rebuilding various enumerable methods with reduce. Other ones that I went to:
- a "how ruby's GC works" talk
- A deep dive into how a core dev found + fixed memory usage in ruby
- The unexpected pitfalls of sublassing certain std lib classes
- A new desktop graphics library
- Using ruby to operate an automatic wafflemaker
And these are just the ones I attended. I imagine railsconf is more web focused, but rubyconf doesn't seem like that at all.
A couple members of my team attended and we made a friendly wager before they attended: how many conference attendees would be primarily Rails developers?
We guessed respectively 25%, 50%, 75% (my guess).
Based on some very, very, very fuzzy sampling, they estimated it was somewhere around 50%.
Ruby is used in a lot of places where Rails isn't, by a few large companies. The one that comes to mind is Stripe, which has at least a couple hundred engineers writing Ruby code that has nothing to do with web development (much less Rails).
While Rails certainly did a huge amount to make the language popular, there's lots of things Ruby is good at aside from concatenating snippets of HTML.
Actually, that being said, while maybe 90% of personal Ruby projects don't use Rails, a good half use ActiveRecord in some capacity. I wonder how much that makes it a Rails project, by some reasonable definition.
And many people use Homebrew on OSX, or Linuxbrew (homebrew for Linux -- useful especially for users of beowulf clusters who often don't have rights to install anything except in their home directories), and brew and its formulas are written in Ruby.
I'm surprised it's so low, actually. I'd have guessed 75% as well. And yes, I am a web developer, spending about half my time in rails and the other half split between JS and misc ops stuff.
Thankfully rubyconf explicitly says that it's not the place for rails-focused talks, which results in a lot of great discussion on other aspects + usages of the language. :)
Offtopic: The waffle talk is listed at https://rubyconf.org/program#session-697 and it may have been recorded. These are my favourite kinds of talks at conferences.
Iirc all the talks were recorded by confreaks. They said they'll be up within a month of the conference. That _was_ an excellent talk - the presenter was very engaging. :)
I get your analogy, but I think there are tons of hammer conferences.
There are conferences for most any language with wide adoption. There's also a Slack conference (not "TeamChatConf," but a "Slack Frontiers"). There's a GitHub conf (not "OpenSourceDevCon," but "GitHub Universe"). There is a Datadog conference, and so on and so on.
Maybe C just doesn't have one big company, or an ecosystem of smaller ones, that stand to benefit from gathering a bunch of C devs in one place.
I think the core distinction is business-centric conferences vs developer-centric conferences. You've entirely named the former. Those are geared towards using platforms, and while developers are welcome, they aren't the entirety of the target audience, business professionals (eg MBAs) are just as first-class at those. But Ruby and Python and Swift conferences are going to entirely be geared towards developers.
I think the hammer analogy works better as conferences for building houses (business conferences) vs power tools (developer conferences) vs hand tools (no conferences), the distinction being how quickly can you get to a finished house. A power tool is something that can make houses quickly. A hand tool can be used quickly and efficiently by someone very experienced with them, but power tools can be used by almost anyone.
Haha, I would definitely go there. I went to Donington festival and Wacken while I lived in Europe. Too bad there are no good metal festivals on this side of the world (American continent).
Wow so if you visited that site with no contextual understanding, you would arrive and leave with literally no additional knowledge of what the heck it was! How fantastic!
I agree. I'm mostly a C coder but I've been on the Rust train since pretty early and I remember being pretty confused when they started putting emphasis on the Rust branding with logos, the whole "rustacean" thing, conferences, forums etc... In hindsight I get it but originally there was a bit of a culture shock. I mean I don't wear C T-shirts and as far as I can tell there's not really a standard C logo either.
Maybe we should find a cool demonym like "c-lions" or "c-weeds" or whatever. Then we'll be able to ask the real questions like "is C webscale?".
Now I'm being a bit snarky but I genuinely understand why newer languages need branding nowadays, but in the case of C that ship has sailed long ago, you don't really need to introduce it, it's just C.
In order to avoid becoming a niche language nobody uses due to the network effects of C's ubiquity, and to achieve its goal of completely replacing C as much as is practically feasible, Rust needs buy-in and what economists call pre-committing. That is to say, it needs thought leaders to accept that Rust is the future and commit to building things in Rust, even when it doesn't make sense to do so in the current climate. Hence the heavy emphasis on marketing and RESF psyops.
> "c-lions"
C-lioning - n. Derailing a discussion by "politely" demanding evidence that obviously unsafe programming practices are unsafe and should never be used. E.g., "Can you tell me, exactly, why aliased pointers are bad?"
People often think that book's title is "The C Programming Language" but if you look closely it's really "The Programming Language" and the blue-and-white logo is a linked list diagram. There's a blue circle around the base of the list's "next" pointer, which unfortunately is white on a white background.
By convention, C programmers know it it's unsafe to guess where the arrow points, so this has never been a problem.
I wish people would stop comparing programming languages to Hammers. It's a meaningless meme. Yes, they are tools, but comparing them to Hammers is 100% ridiculous.
A language is not a hammer. It is a tool. You know what else are tools? Chainsaws, databases, lasers, and tunnel boring machines that cost tens of millions of dollars.
Calculus is a tool, but how we write it is just the notation. Similarly, computer programming (or perhaps a subfield like functional programming) is the tool, and a particular language is just the notation for writing it down.
Of the ones you list, only one has a wide focus, IMO. Three of those will essentially be web development conferences, and I don't know what the hell people do with Go these days, but I'll bet it's mostly a handful of things. Python probably has broad enough usage and scope to counter what I said. The exception proves the rule. :-)
> I don't know what the hell people do with Go these days, but I'll bet it's mostly a handful of things
The 2018 Go user survey analysis should be released soon, but I'm guessing you're right that it's only used for a few things; however, those few things are pretty significant in terms of marketshare (distributed systems, backend applications, and general purpose tooling--this hypothesis could probably be checked against the StackOverflow survey). Not much on the front-end or mobile application side nor on the embedded side, but probably making some headway on the AI/ML/data-science side.
In general, I think of Go as Python but with 15 years of hindsight but also 15 years of market catchup. Go does a lot of things better than Python (performance, concurrency, distribution, deployment, etc), but the reverse isn't true. The principle advantage to Python is that it was the lingua franca for the data science niche before the niche became a mainstream competency--this means more people were exposed to Python rapidly, but it also means that people are beginning to build high-quality data science libraries in other languages, including Go, which closes the gap between Python and other languages.
A bunch of us are trying to change that and make Go the lingua franca for data science and machine learning! The libraries du jour are Gonum (https://gonum.org), a numpy/scipy equiv for Go, and Gorgonia (https://gorgonia.org), a PyTorch/Tensorflow equiv. Do help out!
I’m a beginner in Go and not an expert in Python. However Python is a lot easier to develop with than Go: generics, no pointers, standard collections have many convenience functions, package handling, etc.
Saying that Python has "no pointers" is a bit of an oversimplification, somewhere between "technically true, but misleading" and "actually incorrect", depending on how you define your terms and frame the question. Remember that Java has "no pointers" too, it works basically the same way Python does (except for some minor quibbles about primitive types), except if you go to 4.3.1 of the Java SE 11 spec and look for "pointer" you'll find the flat admission that Java has pointers.
The part about pointers that makes programming hard is that you can create multiple references to the same object, and if you don't realize this, you can modify something that you didn't realize you were modifying. In Python this can happen easily enough:
a = []
b = a
a.append(1)
Question: what is the value of b? You might think that this is pretty obvious, but once you can answer this question correctly, you basically understand pointers. In fact, it's not really relevant whether you say that "a" and "b" are pointers or whether you say that they are object references, conceptually, it does not matter what you call them. The fact that Golang has different syntax for pointers and the fact that you can get the address of local variables or member fields is no big deal, since understanding how pointers work is the hard part, and Python already makes you do that.
Package handling in practice I would say is a wash, more or less. Both Python and Golang have multiple different ways of managing packages, depending on your preferences.
It's flat incorrect to say that Python has generics. What Python has is dynamic typing. Golang has interface{}, which is equivalent to what Python has, except it requires casting.
interface{} is completely different, in that it doesn't allow polymorphism. In python, I can add = lambda a, b: a+b, and then call add on ints, floats, strs, or some custom type of my own. In go, I can pass an interface{} and check if its type is the same as some other type I know about. But no polymorphism.
This is factually incorrect, interface{} allows polymorphism. Maybe you are unaware of how interface{} works but if you want to call a method on it you just do this:
This works for any type "a" which has a method "f" with the correct signature, and this is what I meant when I said “except it requires casting”. The fact that you can’t do this with + is merely a consequence of the fact that + is just the __add__ method in Python, and in Golang + is not a method. The fact that Golang matches method signatures whereas Python only matches method names is not really a substantial difference in my eyes.
I don’t think there’s a strong case to be made here that interface{} is substantially different from Any in Python, again, except for the required cast. And I think we all agree that neither Python nor Golang support generics. (Python supports metaprogramming, and you can implement something similar to generics with metaprogramming, but I don’t consider that to mean that Python supports generics. Type checkers retrofitted onto Python also support generics, but I don’t really consider those to be core Python yet.)
You don’t have to check the types, you can say “unpack these variables as into and if they aren’t into, blow up” which is what Python does as well. The major difference is that it’s implicit in Python and explicit in Go.
FWIW, this is one of the biggest selling points of Golang for me - I love the fact that I'm able to be explicit about reference vs. value, and that it prevents me from shooting myself in the foot when I inevitably screw it up.
It's enough of a differentiator for me that I almost can't put languages with and without pointers in the same mental bucket.
C++ is a wildly unstable language compared to C. Every new standard brings a slew of new coding paradigms and features, often changing the way to write C++ code pretty fundamentally. On top of that C++ is a hellish beast of a language of such tremendous complexity that you can probably host hundreds of conference where you'd teach even experienced C++ coders things they don't know. They won't run out of material any time soon.
Meanwhile a C conference would have a hard time coming up with interesting content year after year IMO. You'd end up having to talk about how C is used more than C itself, but then you're no longer really doing C-con, you're doing "embedded-con" or "high performance trading con" etc...
I agree with the parent when they compare C to a hammer, it's a super useful tool and I'm glad that we have it but it's not like I could talk about it for hours (or hear somebody else talk about it for that matter).
This is completely false. C++11 introduced a lot of new paradigms, and that's it. That shift was for the better, and I haven't met a single person who can honestly say that the changes they made turned it into a worse language. Quite the opposite: it's more expressive, readable, and easier to use.
My comment wasn't meant to disparage C++, I'm not saying it's not improving, I'm just pointing out that it's a massively complex language and that it's still evolving in major ways so there's stuff to talk about. C hasn't really introduced significant "new paradigms" in a long while.
I'm a heavy Go and Python user, and you're right that Go isn't particularly interesting--it doesn't change terribly rapidly, but it's also simple enough that you can do interesting and useful deep-dive sessions into the garbage collector or scheduler or other aspects of the runtime or the toolchain. You could also speculate or discuss proposals for Go2. There have also been significant recent changes to the dependency management scheme which affect pretty much everyone.
I don't think there's much of an analog for C. Most of the interesting stuff in C revolves around things you would think you can depend on but actually break in really weird and interesting ways (misc undefined behavior, sizes for integral types on different architectures, idiosyncracies of the preprocessor, the way to trivially exploit that pattern you used to avoid buffer overflow exploits). But most of that is just depressing.
That for different reasons. Go is not a general purpose language (it's creators specifically focus it's uses on networked apps). PHP is on the decline, nothing kills excitement like decline.
I think it's more that C programmers don't really consider themselves part of a C culture in the same way that python, go, ruby, php etc programmers do. C programmers usually have another interest like kernel dev, firmware dev, or 3d game engines that is more interesting to them than the language itself.
People are doing basically everything in Go right now! Front-end web development being the exception (though there is GopherJS...). Projects like Docker, Kubernetes, CockroachDB, Consul (and anything Hashicorp does), Mattermost, and etcd are all being written in Go!
Anecdotally, I've heard people using Go to rewrite some of their Ruby services in which more performance is needed.
That's absolutely false. Firstly, while the advent of Jupyter notebooks have certainly made using Python better for data science, why would you think that would cause people using Python for unrelated purposes to stop using it for those purposes?
Practically, while data science / ML / etc work is a big part of Python, I'd wager a much larger part is still web development work (Django et all). And of course, just using it as a "scripting" language, or using it to create GUIs, etc.
To be fair, it is my impression that even in data science, python is more a less a scripting language, and all the libraries which do the heavy lifting computing-wise are written in something else, because speed. Has this changed?
Sure, but for every line of code in such a library there's a hundred (or hundred thousand) lines of code that use that library. A small bunch of people maintain some CUDA code that's underneath a Python wrapper, but great many people write code that uses it.
The underlying libraries may be in C, but the vast majority of data scientists never need to alter the C so it's fair to say most data science code is written in python. Python/Numpy/pandas has enabled data scientists to avoid writing C entirely.
Python is probably mostly data science if I had to guess.
You think? I'll admit that my view of the Python community is super narrow, but I was thinking Django, me writing a bunch of test scripts, backend stuff. I know data science is a "thing" with Python, but I just didn't imagine that it had become it's main use. I guess TIL there's a whole other world of how people use Python, and it might be most of them. :-)
I run an ML team whose primary language is Python, and I’ve been doing scientific computation in Python (eg finite elements, numerical optimisation) in Python for a long time.
My personal impression is that Python is used in more fields than almost any other language, but that every community is only peripherally aware of other communities.
For example, Python is big in Earth Sciences (or so I am told). Almost nobody outside Earth Sciences knows that.
Until maybe 5 years ago, I had no idea that people used Python for web development. It had just never occurred to me. GvR famously had to google what wsgi was.
So I think your final sentence probably applies to most users of Python.
Yup. Python has some really good GIS libraries. So field that needs to deal with map data will often find itself drawn to python. And since it's a pretty newb friendly language you find that people who wouldn't otherwise program write simple scripts to manipulate the data and maybe output it to a csv so they can import it to excel.
At this point, Python is probably the second most used language for system programming (after C), one of the top 4 in web development (no idea on their ordering), around the top for other network protocols (I'd guess 3rd), the top language for data science, on the top 5 of scientific computing, on the top 5 for embedded computing (what sounds completely crazy, but there are few languages there), on the top 4 for game creation (probably 4th), the top one for electronics CAD and among the top for other kinds of CAD, the top one for GIS...
I can't think of other niches right now, but whatever one you think, it's probably on the top 5 there.
Yeah, I started using python around 2.0 and stopped using it because of 3, but from the beginning of my time using it, there always was numeric or numpy
I don’t know about that, Django is arguable still the most productive web-framework.
I mean, I like JS as much as everyone else and graphql is better with Apollo than it is with graphene, but I can make a full django app and deploy it before I’m even done looking over the changes to my JS packages that have occurred since I used them last.
Hell, even if you want to use vue or react, I still find django more productive than node, Apollo and prisma. And that’s not mentioning flask.
So I’d wager that python powers a fairly large part of the web, and with good reason.
For as much as this is getting downvoted, I've been to PyCon several years running, and it is correct. While the actual usage of Python is very broad, the PyCon convention itself skews very heavily towards data science applications.
I've been to JSConf EU a couple of times and it's certainly not a JavaScript conference "about building web sites".
Aside from the non-technical talks there were talks like
* how concurrency works in modern JS engines
* a talk about the upcoming BigInt type
* how fingerprinting attacks can circumvent privacy measures
* HTTP/2 Push
* a look at upcoming language proposals
* a retrospective on the JS build tool for React Native
* a talk about versioning
* experimental time travel debugging support in Firefox
* a talk about error handling
* a talk about module systems in JS
Etc etc.
Sure, many talks are either about general web technologies or about new APIs of the web platform, but there is usually also significantly overlap with backend or native mobile and IOT.
When I worked with Python I also went to meetups and followed conferences which always had a wide range of talks from web frameworks to automation, data science and system administration.
Likewise at a Ruby conference I'd also expect talks about tools like Chef or Puppet, which are only tangentially related to web development specifically.
So I don't think your portrayal of conferences is fair at all. "Why aren't there ${language} conferences?" seems like a very sound question, even if ${language} is used in a wide range of industries for very different purposes.
I very much like your answer. And I now realize why disliked PyCon that much. There are so much things that can be done in python that I don't necessarily care about. Language is not the most important thing, what I do with it is.
I much more prefer going to a conference about let's say, web dev or machine learning. Once at the conference, I might prefer going to a talk that use python because I know this language better.
C conference: Address is past the end of the street.
C++ conference: Reading the address requires working out an elaborate series of compile-time templates that finally resolves to the actual address. You go there to find that it's past the end of the street.
JS conference: The address is "the last place we held it". You attempt to figure out what that means, but you didn't attend last year. After some research, you find a copy of last year's invitation. Its address reads "the place where we always hold the conference". After more research and a bit of guess work, you finally arrive, but nobody else is there. You have a sinking feeling the conference wasn't in Uzbekistan after all.
TS conference: As JS, but the invitation includes a helpful explanation of how to find where "the last place we held the conference" is. Unfortunately, one of the explanations is wrong, and you arrive in Uzbekistan.
Java conference: To calculate this year's address, you must first go to a JavaConferenceFactory on the outskirts of town. Talk to the JavaConferenceFactoryManagerSingleton, and give him your JavaConferenceConfiguration. He can give you a JavaConference, which you can cast to a JavaConferenceImpl. The JavaConferenceImpl contains a JavaConferenceAddressLocator, which when passed a WorldMappingSystem can give you a JavaConferenceAddress.
Haskell conference: There is no conference. Holding one could cause side effects.
Go conference: The address is given in a simple, predictable format: interface{}.
Python conference: the conference was abruptly cancelled after the social event which went awry when couple of attendees got into a fight over mixed tabs.
Apparently there's not enough interest among those who write C. Back in 2012, Brandon Philips (CoreOS CTO & kernel contributor) tried valiantly to organize a C conference, but there weren't enough speakers and presentations.[1]
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.
C is effectively frozen in time, thanks largely to Microsoft's decision to deprioritize C support in favor of C++.
C99 is almost 20 years old and MSVC still doesn't fully support it. Forget about C11. If you're a C programmer who cares about portability, you stick with C89.
There's not a lot of point to having a conference about something that is stuck on a 30 year old standard.
I think this is a very debatable claim. MSVC is an insignificant compiler in a lot of industries. In something like scientific computing, everything is written with gcc, clang and Intel on mind. Sure, you'll find some companies still using MSVC, but it's not industry standard any more and it's very unclear how an insignificant, outdated compiler can stop the progress of world's most fundamental programming language.
C's strength is being the lingua franca of the bottom of the stack. I can believe that there are some applications that know a priori that they will never need to be portable to MSVC. But for any foundational open-source library, closing the door to MSVC is a high price to pay. Someone, sooner or later, will want to use the code on Windows. If you are zlib, ffmpeg, freetype, Lua, LuaJIT, sqlite, libpng, c-ares, OpenSSL, PostgreSQL, glib, gtk, or anything that aspires to be as widely used as these, you stay C89-compatible to support MSVC.
MSVC is becoming less and less relevant. People are writing C99 and C11 and MSVC's insistence on breaking portability with modern codebases is incrementally marginalizing it as people switch to compilers that understand their standard compliant code.
Observation: Before 2014, iOS conferences were iOS conferences and was mostly about how to use the frameworks. After 2014, iOS conferences renamed to Swift conferences and everyone tries to figure out how to use Swift - like this is the main pain point or what?
In my experience, they're still about frameworks mostly, they just brand themselves as Swift conferences to indicate there isn't going to be any Objective-C oriented content presented, so people don't attend with the wrong expectation.
Swift-oriented content at a conference is also going to be popular, as unlike frameworks, it affects every developer, as compared to frameworks where only a percentage may use each one.
A lot of major apps are still Objective-C codebases (Facebook, Spotify), though I would imagine everyone will migrate eventually, considering the momentum of open source libraries seems to be heading that way. As someone who works fulltime in Swift and previously in Objective-C, I'm slightly nostalgic for the days of long, descriptive method names, and faster compile times, but overall glad to have migrated.
Objective-C, as a language, is still improving slowly. But it’s pretty mature overall; the majority of Objective-C developers I know actually write Objective-C++ and hence tend to follow the development of new C++ features.
Swift is a complex language, and this allows for a lot more people to talk about how their programming paradigm is the best way to write Swift. It’s the same reason we often see articles like “extending Optionals” or “AutoLayout with a DSL” on Hacker News: Swift is so overwhelmingly used for iOS development that people seem to find it useful to specialize it in places where it designed to be general, and they love to tell other people about it.
Probably useful for justifying costs to managers if your company is currently migrating to Swift, which is pretty common in iOS shops at the time (and now?)
It's interesting that many of the comments here (7 of 9 top-level comments currently) answer the question in the title, rather than respond to the blog post (which has some interesting points and a great list of relevant talks from conferences... starting to watch some of them right away).
I believe it's mentioned, but BSD conferences are often a great place to find presentations that typically gravitate towards low level systems C programming.
OpenBSD has an events page with a list of past talks given by developers, along with slides, and if it exists, any video.
I agree with his reasons for the lack of C conferences, and present one more: what I've noticed from the C developers and "community" (if there is even something to be called that) is a relative lack of dogmatic cargo-cult thinking and otherwise trend-chasing compared to other language communities, which I hypothesise is partly responsible for the "we must have a conference" attitude. To repurpose a phrase, "the choir doesn't need to be preached to."
Also, I allude to above, there's not much of a "C community" either. It's all just a bunch of people using the language for very different purposes and with very different styles, and IMHO this diversity is a good thing; it just doesn't make for a population who would like conferences.
Yes, it was in jest. The result of "true --version" is actually quite extent, bringing licensing and authorship information and a short explanation of the GPL.
This is a good example. C made the transition from "hot new platform" to "infrastructural millstone" before conferences on trendy programming topics were a thing.
The original Bourne Shell was written in an odd preprocessed dialect of C called "Bournegol". I'm sure this was analogous to the kind of innovative techniques people present at conferences today.
Maybe someone else can comment authoritatively on how ideas and techniques were disseminated in the early days if Unix and C. My guess is that it happened through listservs and Usenet, thus reaching even isolated Unix installations who wouldn't have been funded to attend a central conference, if that had been thought of. In Ireland I know that in the 70s there were local meetings of DECUS, for users of Digital Equipment Corp hardware and software. I don't know about Unix.
There's has been a mini resurgence in C from (normally high level language) programmers who are getting sick of web development and are interested in data oriented design.
Conference benefits could be:
Pushing the C standard. C11 is barely supported.
Discussing new standards in a forum other than mailing lists. Did you guys know there is already a C17 standard?
Letting old C devs pass on their wisdom to new C devs. C has a lot of pitfalls but also has a lot of neat tricks.
The problem is that nobody new to the scene wants to write C anymore. It's not a secure language, it has no convention and is full of hacks. On top of that it has undefined behaviors and is supported differently by different systems.
Nowadays people want to write in Go, Rust, Swift, etc.
Of course, for now. But I still disagree that it is as easy (or hard) to write C without bugs as in any other languages. Most people should not write C.
In the same vein - if you happen to be stuck in a problem domain where counting/avoiding allocations is important the other languages I listed above (even C++ really) make things very hard. Rust has a decent take on building a safer c++ (with what appears to be C++ levels of complexity). Would like something similar to emerge for C.
C is so much fun though. Having so much direct control over everything, no layers of abstraction clouding your view, is incredibly enjoyable in the right context.
And you'll struggle upstream if you go that route. Pretty much all vendors for embedded platforms only provide C libraries/drivers/examples/subsystems/documentation.
The compiler vendors I listed are vendors for embedded platforms, they also sell boards.
The problem, as expressed multiple times on C++ conferences, is the devs that are religiously against anything that isn't C89 + language extensions + Assembly.
Surely I know that, but there is this image being sold that C is the only option, when those companies that I have listed are in business for at least 20 years now.
I also know there are a large amount of people in the trade that have zero regard for writing secure C code, despite the availability of tooling to help in such regard.
Which is getting worse now that those systems are being plugged into the Internet.
Sure, I've seen embedded work done with anything from assembly to Lisp. But it's all marginal, trying to get into embedded development without learning C would be very career limiting. For example, not sure how many new projects are started in 2018 with Pascal on PIC but suspect not a lot.
Perhaps the most popular non-C development platform these days is Arduino on Atmel 8 bit chips, but it is still really a dumbed down version of C(++).
> Letting old C devs pass on their wisdom to new C devs. C has a lot of pitfalls but also has a lot of neat tricks.
On this topic, does anyone know any good blogs along these lines? I'd love to read some practical day to day stuff from people that have been working in C for decades, usually all I see from places like HN are weird compiler incompatibilities and rare exceptions that I never have to deal with.
Most of my experience comes from toy projects and horrible decades old code I deal with at work. The former is great for trying out ideas but I don't learn how they scale (human wise) on larger longer projects and the later is more a lesson in what not to do.
There absolutely are C conferences. They just aren't conferences of this type:
"We have speakers who made some cool stuff in a hyped up new language called C and are exited about it, and sharing the techniques!"
They are of this type:
"We have speakers who will share some approaches for preventing and discovering stability and security flaws in widely deployed low-level, middleware and embedded components and stacks."
You have to read between the lines that a lot of this is actually about C.
C doesn't need to be mentioned in the title because it's the 900 pound, white elephant in the room.
C conferences are also of this type:
"We have a gathering of experts in the domain area surrounding a very specialized software stack (that happens to be written in C, and carries a C API).
It's not clear which meaning you're trying to convey. C is definitely not useless, so I imagine that the "white elephant" part at least is not intended. Note that an adult elephant weighs several thousand pounds, so a 900-pound elephant is probably a baby elephant.
It is an interesting thought. I went to one of the early OSCON conferences in Portland and it was pretty cool to have the Ruby (Matts), Python (Guido), and Perl (Larry Wall) people all at the same conference. I was a budding Python programmer, but sat through sessions on the other languages to get a feel for what they offered.
That was a great conference - amazing attendees spending the evening hanging out around the conference center hacking code and an amazing diversity of presenters.
I go to OSCON often and that atmosphere has never been repeated as things have splintered off into language/application area specific conferences. Something's been lost - at least for the casual or beginner programmer.
Not sure about conferences, but what bothers me is that there is no single acknowledged discussion group about C, after Google destroyed newsgroups and comp.lang.c with it. There should be a very popular Reddit sub about it, but yet Reddit is not enough standard among developers, unfortunately.
I'm unsure what you mean by Google "destroying" newsgroups. Newsgroups were decentralized to begin with, the fact that Google purchased Deja News and then didn't... I don't know, turn it into a Reddit-equivalent or something doesn't surprise me. You can still use Google Groups as a Usenet gateway and there are still other Usenet gateways around, although the offerings are getting a bit more scarce and it's no longer a standard part of your ISP's package.
Whenever I look at places like comp.lang.c (which still exists) I remember the bad Usenet experiences I had in the 1990s. It's certainly not worse than it was, in my mind. If anything killed newsgroups, it was Slashdot / Reddit / Stack Overflow and the like.
Maybe "killed" is a strong word. My feeling is that when Google exposed that part of the internet to the web, it became interesting for spammers to target USENET much more than in the past, which was a very strong contributing factor for USENET to die. Moreover once no longer an "hidden gem" many felt exposed posting to USENET, now that it was trivially web accessible.
My feeling is that the web was becoming larger and more accessible every year, and that while Google probably did that more than anyone else, you could equally blame AOL for providing NNTP access to the general public in 1993, or Deja News for starting their archive work in 1995, or Google for their indexing work starting in 2001.
That's just assigning a name and face to economic forces, though. It's the underlying economics that killed Usenet—experts hang out there, so it’s valuable, so non-experts start hanging out there, until the experts leave because there are too many non-experts. This happens to every internet forum; Usenet was just older. Travel back in time and any randomly selected person on the internet was likely to be some kind of expert.
Yes, what you say surely makes a lot of sense. Maybe there is to start some form of forum that is very unpleasant to use, like, just having a command line interface to access it... and vim as editor :-D
A tree farm (at least the type that provide pulp for paper) is just a type of forest. Anyway, where I'm from, paper most definitely comes from forests (mostly second-growth) not anything you would call a "tree farm".
If you're implying all program languages are derived from C, that's simply false. Lisp is based on the lambda calculus and predates C, as one easy counter-example.
If you're implying that all languages run on top of C, that's also false. Theoretical Lisp Machines [0] have been envisioned which do not run C anywhere, and many languages (rust, go, etc) can be built into unikernals that run on real hardware with no C anywhere in the mix.
As far as I can tell, your statement is both pointless and wrong in even a generous interpretation of it.
Show me a lisp which is used by enough people to fill a conference in 2018 that isn't implemented in C. Show me a lisp machine which was manufactured any time in the past 10 years.
Steel Bank Common Lisp and Clozure Common Lisp are both implemented mostly in Lisp with some C code thrown in. And the European Lisp Symposium always has a large share of Common Lisp programmers.
CLOC tells me there's 28391 lines of C and 426525 lines of Lisp in there. Also remember that Lisp has, on average, higher code density than C thanks to advanced macro usage.
The runtime is written in C. That's the important bit. Just because the compiler, standard library, etc, isn't - doesn't mean it's not based on C. You cannot use SBCL without a C compiler.
The installation scripts are written in bash. That's the important bit. Just because the compiler, standard library, etc, isn't - doesn't mean it's not based on bash. You cannot use SBCL without a bash shell. /s
Of course you can use SBCL without a C compiler - you simply use a precompiled version. You can't build SBCL without a C compiler.
Shell scripts just slap commands together. You could just be a human interpreter reading the source and get the job done. C is a much more fundamental requirement of SBCL. Much more so than in the way SCBL depends on Python, for example (e.g. it doesn't).
Listen, I get that in the ivory tower of lisp you don't like looking at the little C bricks at the bottom, but the fact is that they exist and C is a hugely important language upon which the entire modern world of computing is built.
Sure, all of us execute stuff on kernels that are written in either C or C++ or C# or Objective-C, utilizing runtimes that are written in the same languages and calling APIs that are defined by the C application binary interface. That family of languages isn't going anywhere and choosing C instead of raw assembly is often chosen out of practical reasons, such as code maintainability.
Still, I find it hard to put an equality sign between "X has a runtime written in C" and "X is written in C".
The runtime for sbcl is just the garbage collector and parts of the OS interface. It's not like the JVM (or e.g. GNU clisp) where the runtime is interpreting code.
The OS interface for any program that is targeted at *nix is likely to be written at least partly in C, because POSIX is very hostile to non-C languages, which leaves us with the garbage collector.
If the GC's implementation language is the most important thing for an implementation then every language implemented mostly in C++, but using bdwgc for garbage collection is actually implemented in C and assembly.
This doesn't really sound sane to me. In this particular case, it would mean that if you throw away SBCL's compiler, SBCL's standard library, SBCL's extensions, and replace them with something completely different, you still get the same Lisp implementation because all of the aforementioned elements aren't a part of what you call the implementation.
The ones based on Java run on the JVM, which is always written in C :) The ones written in Lisp, well, at the bottom it's C again. I haven't seen a popular lisp yet with a meaningful amount of assembly in lieu of C.
I have some of these exotic Lisp Machines from the 80s which run no C code by default and where the C compiler is optional and written in Lisp. ;-) Obviously exotic and outdated. An alternate world.
> I haven't seen a popular lisp yet with a meaningful amount of assembly in lieu of C.
There are plenty to choose from, implement fully in Java like jikes, partially implemented in Java and C++ like OpenJDK, implemented in Java and C like MicroEJ, and lots of other ones to chose from.
Then there is project Metropolis on the OpenJDK, which targets to replace Hotspot with Graal, thus reducing the amount of C++ code on the runtime.
> Theoretical Lisp Machines [0] have been envisioned which do not run C anywhere
I have one at home. It's not theoretically, but factually. About 10000 Lisp Machines had been sold between the late 70s and early 90s. Which probably adds to $500+ million in sales - then.
They actually can run C, but that's usually optional.
Okay, I'll amend my position from "Everything is based on C", to "Everything is based on C except for a handful of LISP machines that nobody cares about but a handful of fundamentalists".
At which point someone who collects antique UNIVACs will tell me I'm wrong, too.
C is not the first programming language out there, you know. And for its first decade it wasn't even the most popular. There are still architectures in production and use that you'd struggle to find a conformant C compiler for.
It's really bizarre how you expect the world to revolve around it.
Point me to a compiler or interpreter, any of them, that isn't either written in C or written in something that was written in C. And of course, whatever you play with, it's running on an operating system written in C.
If programming is turtles all the way down, C is the bottom turtle, standing on the solid ground of Von Neumann architecture.
The point is, C is utterly pervasive. Everything that we think is different from C is made from C.
I'm also pretty sure that some are written in C++, whose implementations are usually also written in C++, and which (while closely related to C) is not C.
> And of course, whatever you play with, it's running on an operating system written in C.
That's obviously not the case if what you are playing with is an OS written in not-C. It's actually not entirely true in plenty of cases, because operating systems that use C range from almost-entirely C (with some assembly) to C-among-other-things (e.g., z/OS and it's mix of PL/X, HLASM, and C/C++.)
> If programming is turtles all the way down, C is the bottom turtle
I’m pretty sure the bottom turtle is native machine code and/or processor microcode.
I think the point that he is making is that most popular modern implementations of assemblers, Java compilers/JVM's, Ruby and Python interpreters are written in C, or in a language which itself was bootstrapped from C, eg. C++.
I guess the point is that the other languages are based on C. From your list CPython, CRuby and the GNU assembler are written in C. Not sure about Java.
Edit: not necessarily agreeing, there must be some languages that do not rely on C.
C++ is not C (it was once implemented as a preprocessor in front of a C compiler, but that's not th same as being C, and it's now more likely to implemented as a self-hosting compiler.)
I think a better question is why are there so many {language/framework} conferences?
Why should a conference be so narrowly focused when the problems faced by software developers largely don't change based on the choice of tooling, and in fact learning about how different tooling choices provide different costs and benefits when solving these problems is particularly interesting and useful knowledge.
C has seeped so deep into the collective unconscious of all programmers that the thought of setting up a conference for it is a bit risible. Branding a conference with your programming language is for languages that need to be promoted -- and C is perhaps the most accepted, most ubiquitous, and most cursed programming language ever, so promotion is the last thing it needs.
I think the conferences that exist are there to make money, and for vendors to pay to promote their wares.
As the platforms such as Java, Python, Javascript, .Net have a focus on tooling the conferences are paid for by the tooling companies and the employers wishing to have their staff associated with the burgeoning tech, ironically with speakers often paid badly just for the exposure, reinforcing the for-profit nature of the conferences.
C/C++ on the other hand would be represented only as an adjunct of a larger industry conference, such as automation , Industry 4.0 or Aerospace and often run by bodies like the IEEEE. There are no large tooling companies for C++, and no-one is making money by creating development tools for a relatively static and stable language, so there's no need to promote it exclusively.
So, the conferences are there, but C++/C exposure is specialised and not profitable to promote.
Because ioccc is either too cheap to rent a ballroom, or they're not too cheap but in following their theme and long practice, they aren't telling you when and where they rented one.
Are there many new projects being started these days in C, or even C++? I would expect most of that to have moved over to Java or Golang, with most C-family coding being on extensions of older projects.
Of course! Many, many algorithmic intensive applications are written in C/CPP. Low-level applications are as well. As just one example, most algorithmic Python libraries are actually implemented in C/CPP.
Not to mention any memory-intensive or real-time software, e.g. embedded systems - most of those are running on C/CPP, and plenty of new embedded systems are created every day.
There are entire product categories (Games / Databases / Operating Systems / Video editors / Animation / Data analysis tools / robotics) where C/C++ continue to be the dominant languages.
Thanks for the info, but I'm not sure databases belongs in that list. I work on a database system (Couchbase), and our codebase is pretty mixed. The oldest part of the system, the Key-Value storage engine, is C++, but the newer parts are a mix of Erlang, Golang, and Java.
Anyone know what some of the newer systems, like Spark and Snowflake are written in?
I think ANSI C is rare for a new project, but C++ is still common, though I don't know which C++ is dominant. Lots of embedded systems compilers will have borked mostly-C++98 support, there's probably some C++ 98 purists holding out, and then there's the latest C++xx standards that probably don't have full compiler support everywhere too -- plus you always get folks who conflate "C/C++" as if they were one, when they're not, though people sure do like to try and program C++ as merely "C with Classes". Java stole a lot of C++ people over the last 20 years, Go seems to be stealing mostly from the speed-challenged dynamic language crowd who didn't do much interactive development anyway.
Tons. Heck, I'm working on one now. Nothing really matches the performance or wealth of libraries as C/C++. Rust comes close but even then for something like a linear algebra library the ability to use CPU intrinsics, etc. makes a huge difference.
The entire embedded systems industry revolves around C and C++. This includes the automotive industry, aeronautics, robotics, medical devices, space, much of IoT, appliances, countless defense projects, infrastructure, etc. And even in a traditional computing environment, many projects requiring high performance and portability are still being written in C or C++, such as games and high-fidelity modeling/simulation.
Firmware! People seem to forget that firmware exists --everywhere--, even at very high-tech firms. For example, think about Tesla, there are probably millions of lines of C in the firmware repository
Yes. They're two of the most popular programming languages, and that didn't happen by supporting only old code. I started a new c++ project last week since I still prefer it to go.
There are none. Standard Rust is great for game development, the infrastructure just isn't there right now, but I think if you were to write a new game engine or operating system from scratch, Rust would be the first candidate language to do so in.
The game engine segment is much like the operating system segment - the size, momentum/inertia of the incumbents (ie. UE4, Unity as an analog to Linux, Windows etc) make it rather difficult for new entrants, especially for ones written in languages that are not as popular as C or C++ (eg. Rust).
It's simply too hard right now to find enough programmers proficient in Rust who could assemble a competing product, IMHO.
I'm excited to see what happens with Embark Studios; EA SEED started using Rust for stuff, and Embark is a new studio founded by some ex-DICE/SEED folks that's doing everything in Rust. There's also Ready at Dawn and Chucklefish...
Chucklefish 2D games or what have you are a far cry (no pun intended) away from a high performance 3D engine like Unreal though. And from what I can find on EA SEED they are mostly using it for server side and pipeline stuff, rather than the primary rendering engines for their 3D games. I'd love to stand corrected if this isn't the case.
Don't get me wrong, I'm optimistic, and I'd like to see it happen. Although I was a C/C++ holdout at first, I'm starting to come around to the Rust way of thinking, even if I don't like a lot of the terminology and the "RIIR" crowd are completely annoying.
> Halcyon itself is still largely C++, but a lot of data pipelines and servers are written with rust, and quite a few rendering experiments, as well. Enough pieces are being developed to build up enough critical mass for 3D, though!
> Nope, but our next revision of Halcyon is built using Rust
but Embark claims that all their stuff is Rust-first. There’s some other rumblings at other places, but they’re just that, rumblings. As I said, excited to see what happens; it hasn’t happened yet!
That's great to see even if it's still early days. Thank you also for being a great proponent for the Rust community, your thoughtful and considered answers here have helped convince me to look into Rust more over the longer term, whereas the foam-at-the-mouth types completely send me in the other direction.
Honest question: for these performance critical things, how good are compilers for Rust, Go etc. compared to modern C/C++ compilers? One reason that Fortran is still so heavily used in HPC is the quality of the compilers.
Not that I am really qualified to comment on these things, since I don't program in Rust, Go or FORTRAN, but AFAIK the one thing that is often claimed to prevent languages reaching C/C++ performance levels is garbage collection, which Rust doesn't have (but Go does).
As we all know benchmarks need to be taken with a handful of salt since the publisher often has a vested interest in pushing one point of view or another for monetary or whatever reasons.
My personal view is that until we see a AAA game engine or mainstream operating system that is able to run a comparable suite of software to Windows/Linux written in Rust or Go, we won't really know if these languages (or implementations thereof) are going to be suitable for these things.
Embedded software, firmware, low-level OS components like drivers and kernels, game engines, key-value stores, databases, and the compilers/interpreters for a lot of other languages.
Lets be honest: conferences exist to waste time. Nothing productive gets done on conferences and best thing you can take our from them is to socialize with like-minded people.
Sure, why would anyone want to waste time lifting their nose briefly from their employer's grindstone to get exposed to new colleagues, new ideas, and new business opportunities?
I tentatively agree with the idea that conferences reduce the amount of work that someone gets done for a few days (you can see this by how much work free software maintainers like myself generally get done during conferences), but I absolutely disagree that it is a net negative for your employer.
In my view, as someone who contributes to free software as my job (though the rest of this is somewhat related to proprietary developers too), conferences are a great opportunity to have IRL discussions over current development topics as well as meet people from other free software communities (who might work for proprietary software companies). And arguably that is getting work done (and I have written patches side-by-side with someone while at conferences quite a few times).
Having connections in your field, as well as being well-known by your field (perhaps by submitting talks to conferences) is very useful for both you and your employer. In most cases, a lack of conference attendance by a company is seen as a "bad smell" in some communities (it indicates that they don't have an interest in the community around something they use -- maybe because they think that interacting with their community through conferences is a waste of time). It also potentially gives you access to more recruits, because people looking for work often attend conferences to expand their connections.
Not to mention that most medium-and-larger companies can spare a few thousand dollars a few times a year to send their employees to a conference to act as both a marketing tool and as a form of training at conferences. I'd bet that medium-sized companies spend more on stationary and tea+coffee supplies yearly.
If you’re looking at conferences from the point of view of “a way to improve programming skills” it really isn’t. It’s the equivalent of workforce training in other fields.
It's because non-monetary benefits are a good way to attract talent in a tight labor market, which is more or less how the software developer market has been for the past twenty years. Developers like going to conferences, so they like working for employers who pay for them to go.
Think about why tech companies provide ping-pong tables and nap-chambers (obviously unproductive) and yet Wal-Mart isn't sending its warehouse workers to warehousing industry conferences (presumably at least somewhat productive).
Sometimes a 30 min conversation with an experienced developer can save you 3 months of work. Conferences can be extremely productive, but it's just like everything else, it depends on how you personally do it. For some developers its "nothing productive gets done after lunch" and for some like you it's "nothing productive gets done on conferences" but that's a very individual thing and definitely not true in general.
1. Decide up front what sessions I am going to attend. All of these things should be stuff that I know very little about or take my knowledge from 200 to 300. Don't go to sessions that you know the answer to. Be super selective on sessions as well: skip vendor shills and affirmative action placements.
2. Look AND SCHEDULE casual between-session coffee meetings with folks I know are attending. This both deepens my relationships with them and you also tend to meet people most effectively this way that happen to be with that person.
3. Go to birds of a feather (if possible). People are much more likely to want to meet other people at these things.
4. Ask everyone you can "How their conference is going?" and "What are you working on in this space?". I make it a goal to ask at least ten people this a day between the coffee station lines, lunch, happy hour. At a great conference people love talking about what they are passionate about.
5. Drop out of late night events and drinking sessions if you are just there for the music or the beer and not getting knowledge or connections out of it. This is business, not party time.
If you can't do these things, yes, it is a waste of time.
But if you can, I find that I can leverage all of the info and contacts out of this relentlessly at my $DAY_JOB to get a lot done the rest of the year.
Lets be honest: lunch exists to waste time. Nothing productive gets done at lunch and best thing you can take out from them is to socialize with like-minded people.
Can you back this up? This doesn't seem to be as true as your "Lets be honest" introduction claims it is. Even more, it seems like a needlessly polarizing cynical opinion to me.
In theory, I can get from watching the recordings most of the value I get from attending. CPPCon's YouTube channel is excellent.
In practice, I just don't seem to get round to watching them. Going to the conference means watching a whole bunch of them with no distractions. Very useful.
They do? I didn't think they'd be holding workshops and answering SDK questions at other conferences. Certainly Apple devs attend conferences like any other engineer.
If you think that making connections with people working on same things you do is waste of time you’ve got another thing coming. But yeah nobody writes code at conferences, I thought that was pretty obvious.
I've absolutely seen people from well-known companies and consulting groups sitting in a conference talk hacking on their work projects. Very frequently. For the past decade, easily. And as recently as last week, at RubyConf.
I was mentally distinguishing between "code that gets written at a conference because it's a conference" and "code that gets written at a conference because the person is bored/on a deadline/unable to persuade their employer that they need to have time to learn".
I think we can safely say that 'conference' means different things to different people and all conferences are very different. Some involve highly specialized academics pontificating on highly esoteric subjects, some are places where people go to do million dollar deals, some are just thinly veiled excuses for people to expense their holiday to their company and some involve half dozen hackers sitting around a table knocking out code. And at some conferences all these things are going on at the same time.
Basically any statement to the effect of "everybody does/nobody does X at conferences" is almost certainly false.
To be clear, I mean both. IMO, the "social" work is the more valuable work that gets done, things like discussing proposals, working on new ideas, coordination between different projects, that kind of thing. Code happens too, of course, and sometimes, the ability to pair in person with someone you're not usually located near can be invaluable.
No. Conferences will have learning and training sessions. Conferences will have reps from customers, partners and vendors you work with or are thinking of working with. And yes, you can use this time to also connect with like-minded people.
For a while we had some quality conferences around topics such as Ruby, Javascript etc. with great technical talks that were open to anybody who had an interest and wanted to attend. These days many, if not most of them are thinly veiled political/social justice action get togethers that actively ban people who do not share in the ideology.
maybe the vast majority of use cases for applications do not require the lower levels of abstractions provided by C. Meaning, whatever overhead associated with higher level languages, they are entirely within the realm of acceptability, for the vast majority of use cases.
I also think, as you go lower in the levels of abstraction, each implementation of a solution with that language becomes less applicable to other use cases, so there is a more robust barrier between each instance in the community.
Because it's a perfect language. And hence there's no need to improve (or whine and moan) about it. Which is what language conferences are normally for.
Why doesn't C have an actual, formal semantic model?
"Furthermore, we argue that the C standard does not allow
Turing complete implementations, and that its evaluation semantics does not preserve typing. Finally, we claim that no strictly
conforming programs exist. That is, there is no C program for
which the standard can guarantee that it will not crash." [1]
Not really. There's tons of conferences/trading shows and obsession for machining tools, woodworking tools, HVAC systems, welders, plumbers, cleaning tools, construction tools, tattooing tools, sewing, etc.
AWS developed this conference featuring the latest advances in manufacturing, fabrication, installation and examination related to thermoplastics welding and joining.
Shipbuilding / Aluminum Conference
Sep 17, 2019 - Sep 19, 2019
Industry experts will deliver the latest research and innovations in both the Shipbuilding and Aluminum industries. Aluminum is one of the most versatile and widely used metals in manufacturing, but its unique chemical and physical properties can also make it one of the most challenging to weld. The critical importance of welding in the shipbuilding industry will also be addressed by providing current information on emerging technologies being developed for shipbuilding applications.
2019 Aerospace Joining Conference
Sep 23, 2019 - Sep 26, 2019
To bring together experts from Research & Development, Manufacturing and Applications in the areas of advanced welding and brazing, adaptive manufacturing, single crystal repair and advanced repair technologies for the aerospace and IGT engine industries.
2019 Welding Industry Summit
Oct 15, 2019
SAVE THE DATE
This year's Summit will be a combination of interactive presentations, panels, and round table discussions intended to give each attendee current information on how more value can be brought to their welding operations, plans, and projects."
Does any of these look like to you as a single tool conference?
I think there are B batteries, they are just obscure compared to C and A.
According to a cursory check of Wikipedia, a lantern battery such as "Energizer 3LR12 4.5 V Max Battery" sold in the UK contains three of what may be known as B cells.
Incidentally, someone once told me he had experience in "C+" programming and I've never been sure if he was joking.
It was actually more the case that the B battery was the "main" battery, and the A and C batteries being there just for the tubes. The A battery was for the cathode heater/filament - it was the one that needed to be big, since its job was to create a lot of heat - and the C, if present, was for grid bias. The main positive rail would be called B+ in a schematic, even for mains-powered equipment, the same way that Vcc is used in transistor circuits.
I dunno, a Ruby conference kinda makes sense because one will mostly build web sites with it, so it's really going to be a "Building $FOO with $TOOL" kind of thing. But C is so widely used, it's like having that HammerFest 2019 with everyone from people splitting wood with a sledghammer to jewelers with their teensy little tapping tools. I just don't see the diamond workers drinking with the lumberjacks at the hotel bar after hours. :-) I jest, but it's mostly about networking anyway, otherwise just watch the videos online.