It's great to hear that the author got a diagnosis for their condition (I hope that "condition" is not too unsuitable a word). I'm not very familiar with such things, but I can imagine that could be an important first step to understand and mitigate it.
But it seems to me that they're still some way off from understanding their condition. They characterise it as having "extremely high standards" or not being able to tolerate things that are "wrong or incorrect" as well as others. But, from the rest of the post, it sounds like the real issue is something else: where there are genuine engineering trade offs to be made, they get fixated on a single aspect at the expense of any others. When a decision has two or more dimensions to it (e.g. syntax cleanliness vs backwards compatibility, or language flexibility vs simplicity), then someone fixated on a single dimension is always going to be unsatisfied by the decision of someone who tries to make a careful balance.
One result of this is that their language to describe their situation continues to problematic. If you disagree with someone, then it's fair to say "sorry, I disagree, I guess aspect X is more important to me whereas aspect Y seems more important to you". But it's unhelpful to say "sorry, I guess I just have trouble tolerating how wrong you are".
"sorry, I guess I just have trouble tolerating how wrong you are"
this
I read the piece and it turned me from "I know nothing and have no opinion, other than I do not agree with the very premise of C++, and so walking in the door I'm predisposed to agree with anyone saying they're leaving C++"
to "I have a fairly strong suspicion that you probably earned the disregard you're complaining about, on both interpersonal and technical grounds."
All people with OCPD have attention to details, but the reverse isn't true. But most good programmers do not have the other characteristics or OCPD like being “preoccupied with details, rules, lists, order, organization, or schedules to the extent that the major point of the activity is lost” or “reluctant to delegate tasks or to work with others unless they submit to exactly his or her way of doing things”.
Isn't this exactly like that "god complex vs imposter syndrome rollercoaster" meme? First you think you know nothing, then you feel like the best of knowing something, but then another thing happens that you know nothing of, etc.
I don't think this should be straight up attributed to narcissism. Just "doing your very, very best to get things perfect" is not a trait of a narcissist. Better yet, they usually say they are, but have 0.0 credibility of doing that, and will try to disprove any hint that would, basically, hurt their ego or image.
I met Izzy a few times at cppcon and always came away impressed. I have basically the same thoughts about the c++ community -- it burns people out and it's filled with a ton of negativity and ego and it's very hard to get anything done. While I was at Google I spent some time trying to push for some sort of codes of conduct after a colleague of mine had a reasonable proposal ripped to shreds in email groups with all sorts of inappropriate sexist and personal attacks. I got absolutely nowhere.
Don't get me wrong, there are many good people there pushing for positive change but the amount of inertia in that scene is just staggering.
I'm glad you got out and decided to do something more meaningful with your talent, Izzy
You do not need a code of conduct for complaining about a sexist remark inside a corporation. CoCs ruin projects, create a stifled atmosphere of hate and distrust and it is always the wrong people who obtain power.
Persons who are vocally against CoCs can very well be on your side regarding sexist remarks. Personal attacks are difficult to quantify. Often they are a last resort for shutting up someone who thinks they should dictate everything in a code base, even if it is outside their area of expertise.
Perhaps Google's C++ code base is too mission critical to let it be ruined?
I've seen reports of sexism get ignored and go unhandled (usually because "they're such a good contributor, we can't afford to lose them"), leading to a slow death as people stop contributing. The goal here is to make it so that there's an established set of standards, and a procedure to follow in case they get violated.
If implemented correctly, policies for this should not make matters worse, it should just let these projects be able to draw clearer lines towards acceptable behavior and build trust that these issues can and will be handled.
Call it the “C++ standards community,” then, because that’s where you go to get things like `offsetof` into the actual language, and it definitely doesn’t reflect the whole world any more than the JavaScript standards community does. Both of them are focused on moving the language as a whole forward, while most developers just want to use the thing.
my experience is that c++ community is very helpful, community is a small part of the real world, there are friendly and "bad" people, ask politely and to the point, help while you can, ignore some rants once a while...
> email groups with all sorts of inappropriate sexist and personal attacks.
Do you have a link to the mails / mail archives? I guess I don't typically see that conduct from the C++ community - be interesting to see what I'm not noticing.
If this was internal Google communication as it sounds then you should go to HR about sexist communication, if that doesn't get results then go to the victim and encourage a lawsuit against the company
HR's primary job, overriding all its other jobs, is to spy on you on behalf of corporate. Second is to save the company money on lawsuit payouts.
The only saving grace is that, sometimes, a low-level HR functionary has not got the memo that this is their primary job, and might actually do something helpful.
The primary job of the Director of HR, an the other hand, is always simple corruption, graft, kickbacks, as much of it as they can manage to keep track of. It does no good to try to hire one who won't; they didn't get into HR not to. So, if you think your HR director seems not to, it just means they are playing a deeper game, one probably more harmful to you and the company.
Seriously worth repeating. HR is NOT your friend. I learnt this the hard way.
HR's core function is to protect the company from litigation by employees. The HR management is highly unlikely to side with you against upper management no matter how much you are in the right.
If it is about upper management you might be right. However if it is about anyone lower then their job is to prevent lawsuits and so they are on your side - this time - because it is the best way to do their job.
> So what is out there for me, if not C++ or Rust?
Ada.
I write C++ professionally and used Rust for about a year, but don't use it anymore. In many ways, Ada feels like a much simpler implementation of the C++ feature set. The language lets you focus on intent, while still having a lot of control.
Yes, Ada's still alive and kicking, it has a package manager, documentation generator, parsing/semantic analysis library, and a language server. There's been a *massive* modernization push over the last year of the ecosystem. If you download Alire, you can install the FSF GNAT toolchain and get set up super easily. Some of the older parts of the GNAT tools are showing there age, but they're already there and the ecosystem is significantly better than you'd expect.
Regarding multi-platform support, I routinely swap between Linux and Windows testing things out.
> A lack of default arguments, a lack of basic arity overloading, a lack of variadic generics,
Ada features are opt-in, and you use what you want. It has default arguments, arity overloading, and destructors when needed (with Controlled types). Interfacing with C is super easy, as is bringing in compiler intrinsics. Generics (compile-time templates) are a little weird because you can instantiate an entire package (namespace) with types/functions. They can also take other packages as parameters or you can just write a singular generic function. However, it's missing compile-time ops, variadic generics, and move semantics.
It became clear that the author isn't willing to consider anything that isn't 100% perfect in every way anymore. One tool needs some work - your whole language is out.
Ada is on my list of languages to learn something about (more than the 12 languages in 10 weeks class I took back when I got my degree which is the only time I touched it). It has some interesting features (particularly the SPARK variant)
We should cut people some slack about this, especially considering that the language itself is case insensitive :P
I'm not sure what actually triggers the confusion about this, but it is Ada, not ADA. It's not an acronym, I'm curious about the origin of the incorrect all caps version, but it seems like there's a forgotten historical reason for this.
> It became clear that the author isn't willing to consider anything that isn't 100% perfect in every way anymore.
Not "perfect", "their way". Things like variadic generics or arity overloading are not about perfection (there are excellent reasons not to have them).
And it's fine to want things and not be willing to compromise — which is what OP did, incidentally.
But it has nothing to do with "perfection", and your take is very much unhelpful and inflamatory.
Is there any non-proprietary Ada/SPARK implementation? I've heard some good things about Ada/SPARK, but DDG hasn't been much help in finding out if there's any non-proprietary implementation of SPARK of decent quality.
> Is there any non-proprietary Ada/SPARK implementation?
Yes, it's now available as part of GNAT. The integration in GNAT Studio is good and lets you prove a single line or entire file in the IDE.
I mostly write Ada for my projects and have only dabbled in SPARK. It's super interesting, but also ridiculously hard. I don't have any formal training in this, but to me, I found it at least as on par with C++ template metaprogramming in terms of difficulty.
Alire (https://alire.ada.dev/) can do the toolchain install now. It's pretty much like cargo, and can also be used to select from multiple toolchain versions.
Yes, a lot of GNAT studio behavior is actually written as command line tools that get called specifically so you can use them outside of the editor.
The dialogs for builds/proofs even show the exact command line that's going to be used, and updates as you configure it in the editor dialog. It's a great way to learn how the GNAT tools actually work.
I wrote a toy Ada compiler for my master's thesis. It's a very fun language. I miss using it. I was attracted to Python because of exception handling which I learned from Ada.
No, but you can declare functions inside functions and also use function pointers. When I started using Ada I thought this was a huge issue, but I haven't run into problems with it in practice.
Ok, this is WASM and not native code. Pity. One of my considerations to learn a new language is to look whether the language has native mobile support.
Throwaway.
Having worked in the same company as the author I have to say that I highly respect their work for the c++ language, the continuous effort it takes bringing those abstract concepts into the standard, many not understanding them easily but eventually benefiting from them as an end user.
As a distant colleague it was hard to judge their influence on the codebase though. They do have a reputation in the c++ community but it always felt like I didn't see their footprint in our system (as in meaningful PRs) and that they had very strange working hours, strong opinions and preferred working on unrelated semi-personal projects.
I wonder if there was any language and community they'd feel comfortable in.
Back when there was an in-person conference named "SD West" (usually held in San Jose or Santa Clara, California), I used to attend occasionally. I met Bjarne there on multiple occasions, including one time in a hallway between sessions. We talked like people do. I believe I asked him what he though of Qt as a cross-platform C++ GUI solution (this would have been around 2005). He gave me his honest opinion and we discussed one or two other subjects and then went to our separate sessions. He's just a regular guy who is (or, at least, was ) very approachable in such a context. BTW, I'm not "anybody" in those circles. Just another software engineer among many.
> I discovered that I not only have OCD but OCPD, a personality disorder. If you’ve ever had a conversation with me where I just couldn’t let something go because it was wrong or incorrect and it bothered me, now you know why.
Sounds like about half of the people on internet fora.
The author of the article also sounds like the sort of individual or clique who derail Stack Overflow posts because they feel the premise of the question is wrong (leaving both the original asker and any later reader with their actual problem still unsolved).
It also sounds like it could simply be the perfectionist subpersonality trait getting stuck in, becoming dominant vs. personality which should consist of being able to flow into different subpersonalities as/when they're useful; I wonder how they, if they try to differentiate between determining what it is.
Luckily, now we have an alfabet soup of conditions that can cover any obtuseness, quirkiness and non-conformity of your personality. People are no longer told "your are so and so, try to not be that way any more", people now "have" conditions and, while drug treatments usually exists, it requires a lot of compassion from the rest of us.
Personality disorders are generally not able to be effectively treated with medications. That's not to say that doctors don't ever try, but there's very limited evidence to support it.
Personality disorders have been treated with therapy in many cases. What is the main reason for a label: to get the right treatment. People will never be "normal", but they can live in and deal with society, something they would have failed with even 30 years ago.
Come on now, you can't really believe that someone who "just couldn’t let something go because it was wrong or incorrect and it bothered" them - would have failed to live in and deal with society 30 years ago.
For some definition of failure. Ever read a really old book - something from the 1800s? Ever listen to your old family stories? There are many variations of "Larry, he never leaves the farm". We have no idea what might be wrong with Larry, but it is clear there must have been a lot of people who failed to fit into society. We also know that are variations, in some cases Larry would leave the farm but only for specific and controlled situations because that is all he could handle.
Obvious she is getting out, but it is highly likely with some help she could function a lot better.
Actually, we are living through the peak of social penalization of non-conformity.
In days of old, there was an implicit high tolerance for low intelligence and reduced social ability, since communities ware small, lives were short and violent and strong family support was essential for survival. Nobody cared if Larry can befriend a stranger passing through the village, as long as he could work the fields and provide. Only comparatively rare conditions such as schizophrenia or severe autism would lead to ostracization - the proverbial village idiot.
The Larrys of today are many and can be marginalized for minor issues. A low achievement student can be removed from their class and left back, leading to a vicious cycle of depression and economic exclusion. A functional autist has major problems in the modern workplace and the dating scene, leading to hikikomori individuals.
So while the treatment options improved, the bar for what constitutes a well integrated, functioning adult raised even more, without diminishing the stigma for illness.
I'm sure that's true but I'm also sure that some portions of personality are mutable at will. I wonder sometimes whether diagnoses takes away the will to make changes.
It's kind of like poverty. Some portion is luck and some portion is due to behaviors that can be modified. Trying to solve the problem assuming that it's 100% one or the other doesn't work.
I won't comment on the rest of the blog post, but I can fully relate to this point:
> Despite using golang, working with the absolute impenetrable monster that is kubernetes, taking on a helpdesk like on-call experience for one week at a time tending to configuration files over code, and not touching C++ at all, I feel more rewarded in my work than I ever did writing any amount of C++ in my entire life.
I actually experienced the same in the last couple of years. Doing ops work, and sometimes really tiny code changes which still help to improve a product and get recognized by people can feel really rewarding. Standardization work or any kind programming language / library development sometimes not that much (and that is independent of C++).
I think the reason for this is that in ops/support/etc environment one is working towards a known goal, which is well understood by people (peers, customers). If the goal has been reached everyone is happy, and one will likely get positive feedback. And even on the road towards the goal people will understand why it's important to get something done and help to get to the goal. E.g. code changes might not have to be perfect in order to get merged, and there might not be an extreme amount of bikeshedding.
Working on fundamentals can be different: In a setting like a standard library working group often a variety of people come together which do not share the same goal, and where goals are also not necessarily "customer driven". Instead of that, people more often have their personal goals they want to achieve, and they have their own set of motivations for it. This makes it harder to get buy-in from others. Goals are also not that quantifieable (like "fix a crash" or "improve latency by 10ms"), which makes it additionally harder to argument why something is important or less important.
I used to feel mostly the same about all programming languages out there, all I could see was flaws. Then I started designing my own languages and was forced to admit that flaws are inevitable, and every time you start over again trying to fix them new ones emerge as a consequence of the changes. Better to appreciate the strengths of each language.
The same mindset can be applied to anything including other people; no one is perfect, better to appreciate the aspects you like. That doesn't mean allowing others to treat you badly, just not focusing on imperfections.
And once you do, magic happens, because you will automatically stop focusing on your own imperfections as well which is a much nicer way to live. That doesn't mean stop improving, just not beating yourself up for being what you are.
Consider it an opportunity to branch out to new languages and new ways of thinking. It's good to take a step out to fresh air and take off the reality distortion field helmet that goes with any community of people invested in a particular way of doing things--and I mean that in a broad way, not just technology.
I spent close to a decade doing and thinking about things primarily from a JVM-centric point of view. I wrote C for a number of years, I wrote Java for a number of years, then C++, and worked on JavaScript VMs. Let me tell you, all those communities have their distortion fields. There are zombies of all kinds! (heh) I have my own, custom distortion field.
It's good to escape and see things from multiple different perspectives. You should feel hopeful! Lots of other things are cool and fun!
"This year continued with folks I’ve known for years just dropping out of contact. Calls unanswered, messages unread, numbers disconnected, emails unanswered." This left me sad. A piece of unsolicited advice from someone who maintains friendships well (I hope!)
When you slip up socially, like making an awkward comment - did you do it because you just don't care? Or were you trying to make a well-received comment, and you're just less adept at socializing than you'd like to be?
My guess is that socializing just isn't your strength. But I'm sure you're well intentioned! Very few people try to do things because they want to be stupid. And it hurts when people assume that you're bad at socializing because you somehow want to be bad at it - that isn't true!
But here we have a thing that you're good at (efficient C++) and yet you've made some assumptions about others that feel the same. You "...have to deal with things that are less effecient because someone just didn’t give a damn." Do you think it's really because the people involved don't care? Perhaps they're bad at it. More likely, they have different things they're optimizing for than efficiency. But whatever the reason, the least likely reason is that they don't care about doing things well. Even people who struggle with something typically want to do it well.
I think the OCPD is one thing - but the thing I would work on fixing first is to just assume the best out of others. Friends will drop out of touch with people who consistently assume the worst of them. You need empathy - few people are trying to do the wrong thing. They are doing the right thing given a different set of values; rarely, they're doing the wrong thing because they're incapable. But almost never are they doing the wrong thing out of a preference for not doing the right thing.
> The last 10 years of my life writing C++ in a professional context were a complete waste of time that I will never get back. I have nothing to show for it.
I don't get this part. The language you write something in has little to do with how useful the software is. I've had years writing fulfilling software, and years where I was just spinning my wheels.
Sounds like this person's passion is the language. And that she has failed to bend it to her liking. Reading through her post, and just based on it, I would guess she has the skills and opinions to create her own language and potentially demostrarte why her vision is worthwhile.
It seems to be one of those nowadays numerous people who invest a great part of their time into programming 'communities' to the point it becomes a defining point of their life, instead of just considering the underlying tool... a tool (or one hobby) among others. It often ends this way.
The author contributed to the spec. They have very strong opinions about language design. If you don't, fine, but don't drag down and dismiss those people who are on the front lines creating the tools you use.
Interesting. The only time I've been part of a programming community (really just forums/discord) is when the language was tied to a platform, like gamemaker studio. Everything else I've just... used.
It's just the author acknowledging all the code written belongs to some company or organization, and often, can't even be used as a showcase. It was work for money, plain and simple, but may become a hard sell later.
However, it's not necessarily true. Working with large codebases, working on language design questions, committees, everything grows experience that can be used later. It's just not clear now how, as requirements and work in other companies or in FOSS may be very different than that C++ development.
The author mentions Go as a positive experience. If the ego could be left at the door, Go could be a good language to make a new home in. Either that or Haskell, though with much more investment in all layers.
The language and tooling can have very much to say for overall development and maintenance. Also architecture and design matters, as well as changing requirements. It's all very simple or complicated, depending on unknowable X-factors that often need to be decided up-front.
> It's just the author acknowledging all the code written belongs to some company or organization, and often, can't even be used as a showcase. It was work for money, plain and simple, but may become a hard sell later
Maybe worry less about languages. All through my career I've seen remarkable applications written in languages people heaped derision on, or were less than perfect in some way or the other.
> Why should someone who contributes to the development of the language specs themselves "worry less" about languages?
Why not spend time solving different problems and then go back to languages? Why must one dedicate their life to a single field of expertise? The author was doing devops (with golang and kubernetes - the article is worth a read just for his take on kubernetes) work and said it was more rewarding than his work with C++.
> I simply have to accept that there is nothing out there for me. That I will be miserable as long as I continue to work in tech, and that nothing will ever bring me joy in this space ever again. And I have the C++ committee to thank for this.
That doesn't answer the question. A language committee not implementing changes someone wants cannot be and is not the source of someone else's life-long misery.
I with the author the best in finding a more sustainable and healthy way of constructing meaning
Makes me wonder if I've too strongly tied my career to a specific language. However, right now it's not that I'm specifically a C++ programmer, just that the industry (gamedev) is largely C++. I'm sure in for it if that shifts out from under me before I find stable employment though....
I strongly believe so, too.
Whether you like c++ or not, it can be low or high level and is a swiss army knife of sorts. As a gamedev using c++ I am sure you have learnt a lot about programming and systems and hardware, also about compile-time and runtime.
Those concepts are invaluable and help you out in any language and since c++ is so versatile you'll be able to make yourself comfortable in many languages.
E.g. colleagues of mine who have only used Python have no idea about references, heap and stack, L1/2/3 caches and so on. It's a shame.
I wouldn't worry about it too much. It's the ecosystem and the rest of the frameworks that you'll need to learn, and those will be specific to what you will be trying to do. If you are a proficient c++ programmer you'll have no problem with anything that came after it as those languages usually strive to fix problems in c++.
If you don't know web stuff you should learn web. There was a time I would say every programmer should know C. Today I would say JavaScript.
C knowledge is still way more generally useful than javascript and/or web knowledge. Whatever you think of C there's no denying it's everywhere and understanding it is relevant in pretty much every software system in existence, even when that's not immediately obvious.
> C knowledge is still way more generally useful than javascript and/or web knowledge
"Generally useful" is a vague concept. If you judge by number of job openings, you'll probably find JavaScript is more useful. There are probably metrics by which C is more useful.
"Being everywhere" is not necessarily a good measure of the upside one can get by learning it. For example, electronics are also everywhere (more so than C!) but software engineering is generally a better career (measured by income f.i)
Perhaps the point was, learning C is more of an eye opener than an actual skill.
You're going to have to try hard to actually program something in C in the majority of jobs. On the other hand, you'll have to try hard to avoid any C-Based languages.
Of course, if someone new to programming asked me "shall i learn JS or C?", I would recommend JS.
However, after a few years.. give C a try. Make a throw-away "ls" or something.
If you are open to other things, I wouldn't worry about it. Programming languages are tools, and learning others tools isn't that hard. People can jump from C++ to Rust, Java or C# in a small time. And this especially applies if people are coming from more powerful languages like C++ - so that other language features are often more a subset than a superset.
I'm not sure I'm ready to learn another language to be honest. After a decade+ of C++ it'd feel like driving on the wrong side of the road and I wouldn't blame any employers who didn't want to take a chance on that :)
My advice (after also having spent 'too much' time on C++) is to never focus on a single language, it's better to have a shallow knowledge of several languages than a deep knowledge of a single language (especially when it's a "fractal complexity" language like C++ - the mental capacity to deeply know C++ is enough to be productive with 2..3 less complex languages).
Usually it's not the programming language that's important, but the ecosystem around the language (the standard library, available libraries, interests of the community etc...). Programming languages are mostly interchangeable, but their ecosystems are not. Some are more suited for server backend work, some for writing UI applications, some for scripting and automation, etc...
After a while (and a few languages under your belt) you'll select a language based on a project's requirement, instead of trying to shoehorn every project into your favourite programming language. IME the multi-language approach is much more fun and fullfilling.
> Usually it's not the programming language that's important, but the ecosystem around the language (the standard library, available libraries, interests of the community etc...).
I no longer consider an ecosystem separate from a programming language given its importance in the overall utility of the language.
I came to that conclusion after I realized I wouldn’t like the Rust language so much if it weren’t for cargo and the crates.io package manager.
I know a guy who hold the opinion that Docker is a sufficient package manager for C++. I think this misses the degree to which tight coupling of these technologies can yield a lot of leverage.
This is like telling green energy advocates that oil isn’t going away. Everyone knows already. When engaging people consider not assuming maximum naïveté
Comparing C++ to fossil fuels and Rust to green energy is the most Rust thing ever.
Green energy as a jihad is understandable, if maybe counter-productive at times. Rust as jihad makes no sense to me. It’s nifty: exposing mainstream programmers to the Maybe monad, and limited type classes, and cheap (not free!) bounds/use-after-free/double-delete checking is cool. Web browsers and HTTP servers and sshd servers and maybe even shells should probably be written in Rust.
But a sense of safety coming from rustc is easy to over-indulge in: lots of really scary attacks are perfectly possible against Rust programs. It kills 90’s-style stack smashes dead, no doubt and in that sense it’s an improvement, but people get pwned lots of interesting ways now, and there will be a headline CVE in a rust program, count on it.
I keep waiting for the announcement that some propeller-head has implement the Rust borrow checker as a template metaprogram, with the caveat that nothing larger than "Hello, world." compiles within a month.
C++ has gone down a different path, and reasonable one if I can say so myself.
Bjarne Stroupstrup said:
> I don't like garbage. I don't like littering. My ideal is to eliminate the need for a garbage collector by not producing any garbage. That is now possible.
And indeed, with modern C++ idioms you can avoid leaks at the static analysis level, avoid buffer overflows by simply not passing raw pointers around, etc. So no borrow checker / garbage collector necessary. For a little more elaboration on this point, see:
You'd probably be happy with the people doing constexpr shenanigans. A whole bunch of terrible behaviour in C++ is defined away during constexpr expansion (e.g. since none of this is really happening at runtime you can't very well have "undefined behaviour" when there is no behaviour at all) so if you can find a way to write everything as constexpr you get a much "safer" language. e.g. buffers don't really exist, so therefore buffer overflows don't compile.
There are a LOT of caveats when people take this beyond trivial, not least that the compiler diagnostics are mostly useless because the compiler often isn't sure exactly why what you're doing is nonsense, only that it is nonsense. Hey, it wouldn't even have told you that the code was nonsense if it wasn't constexpr - it would just spit out a program that's also nonsense, so that's a win right?
Java was also largely successful, by now it's the new Cobol of business software and will never go away. The same for C++, of course, it will not go anywhere, at worst it will slide a few points down the TIOBE index (where, surprisingly, Visual Basic is on place 6).
I believe that - without any of them explicitly saying so and perhaps even without them consciously understanding what they were doing - the C++ 20 standards committee actually settled on C++ priorities and set backwards compatibility as inviolable priority #1.
It won't go anywhere. But that's including forwards.
For those who are not familiar with C++, the past ~12 years have seen _massive_ changes to the language, the standard library and the surrounding ecosystem. Yes, old programs still run, but they are simply not what you would write today nor how you would write today.
In fact, the C++20 changes are so significant that it will take years for developers to even transition to utilizing them, like it took years for C++11 to be more-or-less widely adopted.
Of course they're adding things to C++. They've been adding things to C++ for decades. I don't anticipate that slowing down for many years if ever. Watch Herb Sutter talking about the question of whether C++ is "finished" a few months back. Bjarne wants Unified Functional Call Syntax, which is the sort of crazy "automatic foot-shotgun" feature that C++ deserves and will fit right in†. Herb wants a pattern matching syntax which of course also de-structures, has overloadable typecasting and includes dynamic type ID as well because this is C++. There's no shortage of additions to C++
But C++ is too complicated and too unsafe. The only way to actually fix that would be to face the monster and slim down C++ and that would threaten backwards compatibility and thus can't be countenanced any more. In that same talk Herb talks about these big problems, claiming he's going to address them. But what he actually does is a sleight of hand trick. He redefines the problem. C++ isn't too complicated it lacks extra features that would make it more orthogonal. So adding yet more stuff to it will fix that. C++ isn't too unsafe it's just too easy to get things wrong, adding yet more stuff will avoid that.
Nobody should be convinced by this hogwash.
† UFCS says foo(a, b) and a.foo(b) are the same thing. In Rust you get one half of this coin, you can call any function at all as a free function, if you can write a.foo(b) there's a (verbose and usually not idiomatic) way to write foo(a,b) instead with the same effect. But you can't do the reverse because it would break a lot of Rust assumptions. In C++ today in most places you need to know whether to write foo(a, b) or a.foo(b) because only one of them will work.
The point is not the _adding_, it's the effective _replacement_. It's like a toolkit with some lame tools. Even though you keep them in there for old time's sake, you add new tools which you use instead of the old ones. So, yes, your toolkit is heavier, but working with the updated toolkit is not like it was working with the old one.
> C++ is too complicated
Well, it is certainly complicated. Certainly more complicated than anyone would like, including the WG21 bigshots. But its (effective) design principles necessitate complexity:
1. Multi-paradigmaticity (sp?)
2. Backwards compatibility
it could drop one or both of those and be much simpler, like you suggest.
> The only way to actually fix that would be to face the monster and slim down C++
Except then it wouldn't be C++, but another language - which is fine. Another famous quote by Stroustrup is: "Within C++, there is a much smaller and cleaner language struggling to get out"
... but that language would not be Rust, it would be slimmer underpinnings of is idiomatic C++20 today. Or perhaps of what idiomatic C++26 would be :-P
> C++ isn't too unsafe it's just too easy to get things wrong
I disagree; or rather, these days, I disagree: This has, paradoxically, gotten much much better - because of all of those additions you decry. They have made it so that you can steer clear of unsafe and complex territory for a lot more things. You write more intuitive, safer code; and are better protected by the libraries you use and by improved tooling. It's true that the underpinnings of these libraries are now (usually) bigger and more complex, but the end result for the developer is the opposite.
---
PS - I would really love UFCS to get into the language, I think the opposition to it is kind of inane.
UFCS fits perfectly with C++ culturally. In particular UFCS means when Library A provides a function that says it can twiddle a foozle, Library B that provides foozles and explicitly doesn't want you twiddling them can't stop anybody calling foozle.twiddle() and C++ says as a programmer the resulting mess lands in your lap.
> Except then it wouldn't be C++, but another language - which is fine.
Hogwash. It's C++ if they say it's C++.
When I first wrote some C++ I could write:
auto foo = something();
That was a very strange way to say "int foo" because auto meant automatic (ie local) storage and the default type was int. But it was legal C++ when I was a teenager.
But, today if I write:
auto foo = something();
That's a variable whose type will be chosen automatically (C++ auto is not merely inference and will choose something even when it isn't clear what you meant).
That was not another language, it was still C++ it was merely changed in an important way. In C++ 20 and particularly in the decision to not take Epochs, they decided C++ must never again be changed.
> They have made it so that you can steer clear of unsafe and complex territory for a lot more things.
No. Putting a little wooden fence along the crumbling edges of a fast mountain road and saying "Now it's safer" is almost worse than not bothering. It is concerning that this fools people.
Real safety looks quite different, consider my misfortunate::Maxwell type in Rust. The Rust traits this implements are definitively safe. If you try to store a bunch of Maxwells in a Hashset things won't go well for you since Maxwells aren't Equal (even to themselves) and yet they all Hash the same. But whereas in C++ such things get you Undefined Behaviour and all bets are off, in Rust we have safety and so the behaviour may be useless (e.g. infinite loop) but it is never Undefined. Our program is wrong but because it's safe we can successfully reason about why it doesn't work.
> Without the ability to break ABI, the C++ standard library is dead.
I agree that the ABI should be broken. However, the standard library is not dead, for 2 reasons:
1. There could be switch to an std2 namespace for new versions of things, or of the whole library. And then std3 etc.
2. There _will_ be a switch to standard library via _modules_, and with that switch the ABI is changing anyway, so it could be used to make changes to existing ABI
... that being said, a lot of the standard library, while not dead, is kind of brain-dead, like std::map and std::unordered_map; or how you need the mountain of code that is ranges to be able to say `vec2 = transform(vec1, my_func)`, even though that was perfectly doable with C++11 at the latest, etc.
> Why have an ABI then ?
Because that way compiled code can work with other compiled code without them being compiled together? :-(
Yeah, I have an issue with the term ABI - application binary interface. It is misleading because if it were really a binary interface, you could interoperate with code compiled in other languages. But you cannot do this in C++.
C++ doesn't have an ABI. It just pretends to have one.
Java was sold as a ticket off of the Microsoft sharecropping treadmill. It largely succeeded at that, so much so that Microsoft ended up obliged to clone it. (The joke is on users of that: Worst of both worlds!)
Java needed no other selling points, and had none. But there is enough money around it, since, to generate them, howsoever fitfully.
I agree with GP. When I started my career in 2000, people used C or C++ for pretty much everything. People wrote desktop GUI apps with MFC. People built web apps with cgi-bin, ISAPI, and C++ implemented COM objects consumed from asp classic. The only way to build mobile and embedded was C or C++ (PalmOS, Windows CE, later Symbian).
Eventually, some of that stuff was rewritten in languages like Java, C#, PHP, JavaScript, TypeScript. Other stuff was re-implemented for new platforms using Objective-C, or Google’s version of Java, or C# in Windows Phone/Unity/Xamarin.
As someone with health and burnout issues who cares about correctness and fell out of love with C++ some time ago (but hasn't really gotten into Rust or Zig) I feel like I can sympathize a bit with Isabella.
In my case my employer terminated me 2 months ago following an ischemic attack. I had been neglecting my health and working an unsustainable schedule since 2020. Now my family is helping me make lifestyle changes I need.
The experience made me rethink my work priorities. Correctness is important to me but I'm less interested in solving the same correctness problems I've solved for many years in imperative languages like C++, Go or Java when statically-typed functional languages like Haskell offer the promise of preventing many of those problems .
So now I'm teaching myself Haskell. It's not easy but I'm learning a lot and it's helping me understand other languages better as well. I hope my next employer shares similar views about correctness and functional languages.
Rule Number One: The ISO C++ Standard Working Group is not the source of your life dissatisfaction. Neither is your current choice of programming language (unless it's Java).
The WG isn't even one group. It is just a lot of people drawn together to work on what will end up one thing, the next Standard. And then another. Any impression of coherency is illusory.
It must be frustrating to propose a bunch of ideas, cultivate and advocate for them, only to never see them acknowledged or accepted by the standards committee over the course of years.
That being said - let's get real about this. Simply coming up with a bunch of ideas for improvements is not enough. Neither is being vocal about it on Twitter, or giving talks at a convention. Gaining the community's support and acknowledgment is key here.
That you feel something is an "improvement" doesn't mean others see it that way. Same for "faults" and "imperfections". This isn't the community's fault, or Bjarne's.
This is the reality of working in a team. On a language used by millions of engineers around the world, which powers every facet of our modern society.
Especially for committee work, it's quite clear once you go there that what matters is being sponsored to attend regularly and build up relationships so that you can get experienced people on your side.
People on the committee are not sufficiently good to just accept a proposition based on technical merit alone. The whole thing needs to be made accessible and easy to digest, and preferably integrate well in what others want to do.
It's political work, which is tedious and frustrating. Some people are good at this (especially if they can figure out a way to integrate that into their career), but for most people, it's just a waste of time and effort.
> I have ... extremely high standards for everything ... it causes me extreme distress ... to have to deal with things that are less efficient ...
That's somewhat of a curse when it comes to (most) software engineering, but doubly so for languages like C++ which:
1. Have many decades of baggage (40 + C's baggage from before).
2. Have backwards compatibility and non-breakage as one of their goals.
3. Are not designed by a single person or unified entity, but by a committee representing a diverse array (excuse the pun) of interested parties.
4. Have a slow evolution process which favors consensus and partial and gradual adoption of ideas.
Such a language will inadvertently fail to satisfy the author's sensibilities and expectations. He is certain to get frustrated about issues with the language which don't get addressed, proposals which come up and languish for years and years, limited changes which seem half-assed, etc. - and that's even without being active in the circles around the standards committee.
That's as far as the language is concerned.
---
I can't speak to what people in those circles are like personally; I've never been in touch with any of them except barely with one or two (and one was nicer while the other not so much). But I can certainly relate to developing a dislike for a programming language because you've seen "how the sausage is made" and have an aversion to it.
----
> I’ve sadly burnt all of my energy the last 10 years on C++.
I've had this happen in other initiatives in my life. You want to give something your all, really take it forward, you have good ideas, which people even recognize, if pressed, as such - but it's like you're trying to push an elephant in one direction or another (or an Ent, I guess). It just won't budge, and when you try to hard you get chaffed at best and injured at worst. And there's often zero recognition of your effort.
Hmm... ok, but I couldn't tell from the article, and the website's name is "izzy", which I mistook for a male name. I can no longer edit my answer though.
Good lord, the amount of self importance, ego, and whiny idiocy in this post is astounding. People not accommodating what you consider are high standards cause you physical pain? Seriously?? SERIOUSLY? Since you're doing work for cancer research, maybe go see how people with cancer have pain compared to what you apparently feel when someone doesn't comment their code to your standards you nitwit.
You're not special or important, get over yourself.
> 2021 was not too kind to me. I discovered that I not only have OCD but OCPD, a personality disorder.
Then later...
> I simply have to accept that there is nothing out there for me. That I will be miserable as long as I continue to work in tech, and that nothing will ever bring me joy in this space ever again. And I have the C++ committee to thank for this.
It sounds like the author has made a self-diagnosis, and is not currently seeking treatment with a licensed therapist. There is no language around addressing the disorder, and plenty of blaming external forces.
If so, it might be worth exploring the option of therapy.
My experience as a career software engineer is so different from the author's that is genuinely amazes me that the spectrum of experiences is so broad as to encompass both of us. I have built software for over 25 years, in at least 30 languages/frameworks/toolchains. While I certainly believe some are stronger than others, and certainly more fit for specific purposes, I have never really given a shit about the languages or the tools and have always been able to make them work and build the product. Looking back, none of my joy, happiness, or satisfaction has come from the languages or tools themselves, but from the products I built using them and who was helped by those products.
Perhaps in 2022, Isabella should work on caring less about the means and more about the ends of engineering. There are so many important, valuable things engineers can do when we stop fetishizing the tools and start focusing on the outcomes.
I actually like C++, it is not perfect for sure but it's getting better, plus the famous "there are only two kinds of languages: one that nobody uses, one that many complain".
In the end there is really no alternative, in fact there is none. I could not find a language to replace c++ myself in practice, so I will keep using it all the way.
Izzy could abandon all C++ committee work, like the other 4 million C++ programmers, and just use the language to get work done and accomplish goals. Maybe publish a library or two in Boost that might take off, and finally be pushed into the Standard by appreciative users.
Abandoning a productive language because of not getting enough of your proposals accepted looks pretty sour-grapesy, so to speak.
Almost everybody who got anything into a Standard got only one thing in.
It appears that the mean, the language and tooling, has become everything, and the end, the software or the program or the results, has been reduced to nothing.
Since the author is open up front about their OCD issues, this talk immediately came to mind. It's a bit of an elaborate tongue-in-cheek joke, but I found it personally helpful for thinking about why a choose a language. Pervert in this context does not mean sexual deviancy. In the Lacanian sense, a pervert is a person who enjoys being a vessel of the rules.
The Pervert's Guide to Computer Programming Languages - SXSW
The Pervert's Guide to Computer Programming Languages
Psychoanalysis and Software
What are the issues with selecting a programming language?
• Which programming language should we choose?
- Just saying: 'use the right tool for the job' begs the question
• Why are there over 1000 programming languages?
• How do we critique a programming language?
• Why do language designers create new programming languages?
• Rational reasons
• Maximize expression while modeling:
• a specific problem
• a broad range of problems
• Psychoanalysts: "Many decisions are not rational"
• Programming language choice can be rational, non-rational, or a mix
• Use Jacques Lacan and Slavoj Zizek's critical theory
• Critique non-rational decisions
• Discover ulterior motives (ours and others)
• Explain the diversity of language options
Jacques Lacan
• French psychoanalyst and philosopher
• Extremely cryptic
• Preoccupied with desire and enjoyment
• Popularized the mirror image, the Big Other, and the triad of the Imaginary. the Symbolic. and the Real
• Believes all humans fall into the three basic mental structures of psychosis, perversion, and neurosis
Why the 'Pervert's Guide'?
• Based on the Pervert's Guide to Ideology by Slavoj Zizek
• Pervert is a person who enjoys being a vessel of the rules.
• Zizek calls the analyst's method of discourse the pervert's discourse
• The analyst sits in the position of the object of desire for the subject.
• The analysand projects his or her ideals onto the analyst (transference)
• When we analyze programming languages we are operating in the analyst's (i.e. pervert's) discourse.
I re-watched it since I am once again thinking about programming languages
17:15 "Slavoj Zizek likes to say that obsessional activity is doing something in order to do nothing" which to me sounds like pursuing a goal without ever wanting to achieve it, liking the pursuit more.
41:10 C++ is an obsessive language
So by this measure, Izzy Muerte developed a effective strategy for themselves, since they are a self-described obsessive working in an obsessive language and says they wasted 10 years of their life on C++ while accomplishing very little. So, success?
I laughed at this point at 34:55 "Closure is what I call the ultimate perversion language" because Rich Hickey comes across to me as a subversive disciplinarian (no offense intended)
I find it strange that the author treats spending time with a language as a personal sacrifice.
If that's the case, maybe quit programming altogether? No matter what you work on, language or a piece of software, if you think you are sacrificing part of yourself, just stop. It's not worth it.
> I need your help! Especially if you are queer/trans, disabled, a woman, and/or a person of color, and in that case especially if you think you don't know anything about compilers.
So there are niche languages for everyone. I had hoped Tulip would go somewhere, but after so long I lost interest.
“The reasonable man adapts himself to the world: the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man.”
I always hate that quote. Much of the misery and suffering in the world also comes from the unreasonable man. Every tyrant is trying to adapt the world to himself. Every stalker is trying to adapt the world to himself. Every poacher is trying to adapt the world to himself. Every vandal is trying to adapt the world to himself. Many a murderer is trying to adapt the world to himself. Every person demanding Ivermectin to treat Covid is trying to adapt the world to himself. Trump spread the lies about the 2020 election trying to adapt the world to himself.
In addition, the reasonable man is also adapting the world to himself. Every time you turn on the air conditioning or heat, you are adapting the world to yourself.
Every human is trying at some level to adapt the world to himself while also recognizing that some things are easier to change than others.
In addition, many of our greatest advances came from people who knew how the world worked and carefully pushed change along 1 dimension. Every scientist with a ground breaking discovery appreciates the fundamental laws of nature and works within those constraints. The quacks forever making perpetual motion machines are trying to adapt the world to themselves without realizing the constraints.
My point exactly. I qualitatively explain that "a virtual private 'cloud'" is essentially the old datacenter, and all its components. When we say K8s, it is a "puff", and we get to own all the complexity we put on the cloud provider.
Probably there are some ninjas at the FANG companies who are savvy enough to keep their system fully saturated and maximize the cost/performance ratio of the resources.
My little riff-raff team needs to squeeze the most functionality out of the services at hand and work off technical debt ahead of gettin' all fancy with all this new-fangled stuff.
It sounds like the author is spending too much time way up in the hights of abstraction and needs more concrete things to work on. For instance, writing more programs -- I bet there are a lot of programs where you don't even really need variadic generics (or was it generic variadics?).
Don't get me wrong: I appreciate that people spend all this effort to design and evolve languages. But you need to ground yourself in concrete practice for many reasons, including your own sanity.
Disclaimer: I don't know anything about the author aside from what's in the article.
> A lack of default arguments, a lack of basic arity overloading, a lack of variadic generics, all make me not want to write Rust.
I'm not sure how serious this is, TBH? I mean, Rust does have macro syntax that supports all of these things (as seen e.g. in println!() and format!() ), and there are pretty solid engineering reasons to avoid those features within the basic workings of the language. I'm pretty sure most Rustaceans would argue that Rust is quite probably Doing the Right Thing here.
In my experience, Rust's multiple named functions is usually (not always) more clear than multiple function overloads, and practically always better than constructor overloads (you'll never convince me that std::vector's constructors are sane). However (IIRC) I wish it was possible in Rust to abstract over arity, in the case of function forwarding and tuple overloading.
Wouldn't variadic generics make working with tuples of any length easier[1], as const generics did for arrays? If that is the case, then I don't see how Rust not being C++ matters in this case.
Yeah no kidding. I understand not wanting to deal with nonstop support issues on releasing it, but just release it with a big "SOLD AS IS" warranty sticker on it, throw up a forum, and let the community help itself on it while you go back to making your game and ignore people who DM you about it.
I think Jonathan may have a bit of OCD himself and don't want to release something imperfect. This is meant as a tongue in cheek comment. Don't get offended anyone!
Why do people even bother with standards committees for library features?
Just write your own libraries, no one is stopping you.
Also, it looks like this person doesn't even write C++ professionally. Looks like that's the problem. C++ is a practical language for practical people solving practical problems, not for idealists.
FYI: the author is named Isabella and AFAICT uses female pronouns. In light of that, the amount of "he" and "him" in the comments so far seems a bit excessive.
EDIT: it looks like a lot of those comments have been cleaned up or deleted since I first made this comment. Thank you.
which uses she/her. I guess it has changed over time. In either case, male pronouns (or "this guy" in one still-extant comment) are incorrect and seem like the result of stereotyping or opposition to modern gender reality.
Your use of she/her seems like the result of stereotyping trans people.
Everybody loses when we play this game. You can’t expect people to hunt down the preferred pronouns of everyone that writes an article before discussing said article. Your comment is no more substantive than comments correcting spelling or grammar, it’s just noise and doesn’t contribute to the discussion.
> You can’t expect people to hunt down the preferred pronouns of everyone that writes
No, but I think it's perfectly reasonable to expect they'll look at the name at the bottom of the article and use the most likely matching pronouns instead of assuming male because it's tech. If that turns out to be incorrect at least it's an honest mistake, not a stereotype. "You can't expect" is just an excuse for not making any attempt to respect people's wishes in this regard, and IMO counts as transphobia.
I enjoy writing code in objC/Pascal/Go/JS/Lisp/Swift. They all have their beautiful parts IMO. Funny the one I enjoy the least is the most modern: swift. Xcode and platform lock in may have a lot to do with that though.
Izzy, please write your own language! We need more competitors to Rust and C++. (Zig is too low-level). It would be great if you could make it a type-safe LISP!
It seems to me like this person needs help, and I hope they get it. I hope they have friends or family in their life that can convince them to get the help they need.
I got as far into the tutorial as "Ada++ requires variable declarations to be made in a specific area called the declarative part", said "that's stupid" (actually out loud), and abandoned it.
Then wrote this. (You're welcome.)
Even C ditched its separate section for variable declarations.
I understand how it can be frustrating, but it can also be super helpful.
I'm not super familiar with Ada++, but in Ada all declaration areas are the same. You can declare anything (types, functions, variables, tasks i.e. threads, or even full packages) in any declaration area. This is actually somewhat powerful in being able to write everything locally and then refactor it out to where it belongs.
Writing tasks in declarations is interesting because they operate like C++ jthreads, so the related block of statements won't exit until all threads complete. You can get around this by detaching work by using allocators, but that's more advanced.
The advantage of declare blocks would be the structure they provide - both in terms of understanding how much memory usage a subprogram can have in branching scenarios, but also as a way of showing the programmer possible areas where the problem might be better broken up into smaller pieces.
Note that within these declare blocks you may also declare new types and further subprograms - something which cannot be done within the body of a C function. Imagine the possibilities there : )
It is no surprise, after 10 years of Andrei's book, while the language has progressed a lot, it keeps being a programing language for enthusiasts still soul searching for a market.
You are probably aware of the pace of evolution in the C language. Nothing happens, and if it's a horror show. The maximally take the easiest thing from C++, but usually the worst.
On the other hand, the advantage of the glacial pace of change in the C standard is that the language hasn't been ruined yet. One of the most important tasks of the committee should be to say "no", even if that's not a popular thing to do. The right place for experiments in the C ecosystem is outside the standard, in libraries and language extensions.
The C++ committee says "no" overwhelmingly more often than not. That is much of what Izzy was complaining of.
Izzy got more stuff into C++ than 99.99% of others who tried. Ze spread zerself too thin pushing too many things. It is a major achievement to get one thing in.
I write some c++, as well as some amount of code in other languages. I wouldn't consider myself part of the cpp community. c++ is hands down the most frustrating to deal with, and leaves me asking why I'm doing it to myself.
The answer is, of course, that there are some things that're really only possible in c and c++...and however much I'd typically prefer to just do something in c, c++ has a way of luring you in with the promise that it'll be just a bit more ergonomic and safe....And it is, kinda.
But sometimes it feels like the entire cpp community is one giant case of self induced Stockholm syndrome...They wont change the fundamental things that make it difficult.
On the flip side, there seems to be some fetishization of incidental complexity. I have the impression that many in the community pride themselves on how smart they must be to work with such a difficult language, without considering that there could be a language that's significantly easier to use with the same benefits. Or using that difficulty as a gatekeeping mechanism to insulate the community from the less-smart.
I'll posit this: c++ isn't hard, it's just frustrating because you need to parse incomprehensible error messages, or seemingly arbitrary limitations, or have some ridiculous number of overloads...
And then the naming that they decide on in committee...I'm gonna pick on `std::unordered_map`. The name describes it based on what it is not. The reason it's named that is naively, just because `std::map` was already taken by a tree implementation. I don't know why they couldn't have chosen something like `std::hash_map`, or something. The template parameters declare a hash _functor_ is necessary...so the reasoning that you might have an unordered map implementation that doesn't use hashing is up in smoke...
...I'll stop there, because I could probably keep going for quite some time. My point is that c++ isn't hard, cpp is dumb. It's dumb because it makes some of the simplest things contorted into ordeals.
> I don't know why they couldn't have chosen something like `std::hash_map`
According to Herb Sutter the name `hash_map` (or `hashmap`) had already been taken by some C++ standard library implementation that shipped a class with this name in the std namespace: http://www.gotw.ca/publications/mill20.htm
This is sort of a great example of them shooting themselves in the foot...They can't name something right because implementations are already using the name...
if only the language had a way of putting names in some different area where they wont conflict with each other...
they could have done something like create a new namespace: std::maps, and then have std::maps::tree_map, std::maps::hash_map, or something to that effect, and use std::maps::tree_map as the implementation for std::map for backwards compatibility.
instead they chose to name something by what it isn't.
Imagine needing to announce your "departure" from a community.
> Bjarne looked me up and down, put on a face of disgust, and walked away.
Sure you aren't projecting? To the author of this article, you need to get some help not hiding behind "I have OCD." The way you sound is really off-putting.
Sorry if this sounds hard, but you have some form of narcissism that in the end only hurts you more. Drop your pride.
Sounds like the author is getting help already. Starting with the diagnosis. Receiving a diagnosis that you have a personality disorder is not an easy pill to swallow. It also doesn't fix anything, but it helps explain past behavior.
Narcissism may also play a role but as a personality disorder it is incredibly difficult to manage and find support for.
Saying "drop your pride" to someone that you suspect of having NPD doesn't seem any more helpful to me than saying "just stop having obsessive thoughts" to someone with OCD. Besides sounding harsh, this attitude is probably not very useful or effective.
Imagine realizing you wasted a decade of your life in the false hope of making a difference, but couldn’t because of a dysfunctional community dynamic… I can’t because I haven’t done that, and perhaps you can’t either.
It may read this way to you but that’s the nature of blogs. They’re public diaries. Narcissism is often part of the medium itself.
The problem is she had specific ideas of what would make C++ better, and when 500 smart people are in the room there will be people who disagree. I've seen a lot of what I thought were good ideas get shot down when someone else brought out an objection I hadn't though of. Sometimes someone listens to the objection, spends a couple years of rework, and the process repeats a few times until the objections are satisfied, or at least the majority agree they are worth ignoring. This is not easy, but it is a required part of making them useful. Anything else just adds more inconsistencies until C++ is completely unusable.
Many people cannot handle it and think it is the C++ community being obstructionist when in fact it is just that we all have different needs, the only thing in common is we need a language that we can use for our problem so you better not mess that up.
That would be true, except large parts of the current C++ process are broken. The process advocates for papers, biasing towards people with personal quests and a lot of free time. I had many (informal) objections to <random> while it was in the standards process, but since I didn't have time to write a paper, the library got waved through in its broken state.
Completely agreed, but sometimes blog posts by ordinary writers end up on the front page here, and it’d be good to consider that maybe they weren’t expecting tens of thousands of people would read it. In this case I think it pays to cut the author some slack and sympathize a bit.
The author has clearly had a rough time, and there’s no need for an internet pile-on. At the very least it’s not constructive and needlessly personal to label the author a narcissist as in the top level comment I’m responding to.
Maybe the ability to “make a difference” while being disconnected from the community enough to not see the dysfunction is the dysfunction.
I’ve never fully understood the languagism stuff and I have openly mocked “… considered harmful” but maybe languagism should be considered harmful. Seriously, if you like writing software, isn’t the tooling a medium? Bad tools is no fun but you can still make software, you can solve problems, you can see it work, that’s what it’s about, right?
> Imagine needing to announce your "departure" from a community.
If you're active enough in a community that you'd need to explain something multiple times to multiple close contacts then isn't it the most efficient way to do it?
Contributing to the spec, creating a very widely used set of CMake utilities, and being a widely enjoyed speaker not enough for you?
With the condescending airquotes and demeaning comment, one might think you had done some research. Clearly you hadn't. A Google search can tell you all of this.
> "Contributing to the spec, creating a very widely used set of CMake utilities, and being a widely enjoyed speaker not enough for you?"
No, this is clearly not enough to get shit accepted into the C++ standard. As evident by the fact that none of OP's ideas made it into the standard. Why should any of that matter?
I'm sure OP is not alone here, by the way. I submit there must be thousands of amazing ideas proposed by amazing people that don't end up being accepted into the standard for a myriad of reasons. Get over it.
this is just from wikipedia for context:
"Obsessive–compulsive personality disorder (OCPD) is a cluster C personality disorder marked by an excessive need for orderliness, neatness, and perfectionism."
Comports with this in my opinion. Having known some people who were called "Type A personalities" who tend to be great at metrics and goals but not always so great emotional intelligence. Narcissism is common etc. This is the kind of person who will fixate on an uncleaned toilet or rattle in their car for weeks, losing sleep.
Recalling one person I've known with these traits, she sounds a lot like this person. After a couple of decades and seeing her raise a family has convinced me she is indeed Human, if she had gotten therapy things would be a lot different. She's much more pro-social, though she also didnt really maintain her friendships but she definitley never had a career with walls of compiler warnings to ignore. That might have killed her.
Closing her blog, Izzy expresses a deep frustration and lack of any derived meaning from what she had viewed as her purpose (c++ I suppose) as well as a general feeling of isolation. If you are feeling some shadenfreud about this for some reason, its clear she is very unhappy. It doesnt seem particularly rational to view languages this way. My impression is that this person is probably in distress and depressed. If this were my friend I would be making phone calls.
Izzy: Good luck, lady. C++ is hard, but so is life. Keep looking for that purpose. If you happen to read here, I suggest volunteering at an animal shelter. Just working on something less demanding and quite possibly more rewarding is a great therapy break, as you've found from your Ops position. You are well positioned to tackle this.
I read the whole article before posting my comment (which is currently top voted, at least it looks like that to me, so maybe that's what you're objecting to). It's quite possible I've missed something, or a lot of things, but your comment isn't helpful determining that... You just said to read the whole thing again. Ok, but what specifically have I got wrong?
Not OP, but I can tell you why your comment seemed armchair-psychologist-y to me. The issue is saying "it doesn't seem like her problem is actually X, it seems like it's Y." You read a short article written by someone who, based on the tone and explanation up top, was not in the best frame of mind.
The bigger issue with your comment from my perspective though is that you said "But it seems to me that they're still some way off from understanding their condition", which to my ears is just demeaning. Someone posts an article about leaving a community, with a lead in explaining their state of mind as of writing it, and your response comes down to "sounds like you don't understand your condition you were recently diagnosed with".
Personality disorders are hard, they don't go away and they can take years to get a handle on. When the top response to your article where you mention your disorder is someone saying you don't understand it, it becomes that much harder.
Well, nothing in your comment gave me the impression you were referring to anything in particular. But I was honestly trying to understand what your point was. Really, it just comes across as unspecific rant, so I think I was being pretty generous.
What in my comment is "unspecific"? Most of the comments here are speculating about the author's mental state, claiming they must have self-diagnosed this issue (which isn't true), or that they just need to find another language to write apps in (missing the point they were an active contributor to the spec and cared deeply about this language). Very few of them are actually addressing the content of the article itself, instead dismissing the author as either insignificant to the cause or just being whiney, etc.
I have quite a few comments here pointing that out to people. If you didn't get much worth out of my comment, or if it was obvious, perhaps you weren't the intended reader.
I don't personally equate "scrupulous" to "[having] trouble communicating", nor do I really consider it a "problem". They are mutually exclusive.
Also, from a language design point of view, they have very strong opinions about language design and heavily criticize the design of all modern languages. That shouldn't be surprising to anyone. Programming language design is a field of CS. People are allowed to obsess over it. It'd be a shit world of people didn't obsess over specific fields of science. I can't believe I have to explain this.
The people here aren't arguing with the statements about language, but instead for the author even having opinions about languages at all. That's incredibly demeaning and dismissive.
> A lack of default arguments, a lack of basic arity overloading, a lack of variadic generics, all make me not want to write Rust.
I'm sorry but these are such superficial problems. I don't need overloading (arity or otherwise) since Rust kind of has overloading thanks to the traits.
Variadic generics might be necessary since C++ doesn't have a good macro system. But Rust does so you achieve it that way.
I guess this is why macros aren't the be-all end-all solution to problems in language design: It's difficult to construct tooling around them.
It could be argued that "functions" are a form of programming language extension that are friendlier to tools. For programming-language fascinated beginners, this could be a good way of motivating "functions" as a language feature.
"hates implicit behavior" and "lacks arity overloading" both sound refreshingly sane to me.
default arguments? I have to agree that one is hard to justify. It's not merely convenient but also does no harm that I can see, even specifically in the context of rust's special mandates. Then again it's also not a huge problem either, and maybe a good thing for rust's special goal, that you always have to supply default values when calling rather than when declaring.
Not knowing this person beyond this bit of text, I come away thinking I too would probably not want to adopt many of their ideas and would be another one of the many people they are "disappointed" by for that.
I do not buy their parting shot "... and I have the C++ committee to thank for this."
But it seems to me that they're still some way off from understanding their condition. They characterise it as having "extremely high standards" or not being able to tolerate things that are "wrong or incorrect" as well as others. But, from the rest of the post, it sounds like the real issue is something else: where there are genuine engineering trade offs to be made, they get fixated on a single aspect at the expense of any others. When a decision has two or more dimensions to it (e.g. syntax cleanliness vs backwards compatibility, or language flexibility vs simplicity), then someone fixated on a single dimension is always going to be unsatisfied by the decision of someone who tries to make a careful balance.
One result of this is that their language to describe their situation continues to problematic. If you disagree with someone, then it's fair to say "sorry, I disagree, I guess aspect X is more important to me whereas aspect Y seems more important to you". But it's unhelpful to say "sorry, I guess I just have trouble tolerating how wrong you are".