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!
> 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.
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 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.
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?
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:
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.
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 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 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.
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.
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.
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.
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.
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).
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++.
“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.
> 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
> 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.
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.
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.
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.
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
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.
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.
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 : )
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.
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.
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.
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.
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.
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?
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.
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 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?
> 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.
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.
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.
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".
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.
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”.
"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."
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.
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.
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.
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 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.
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 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
> 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.
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.
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.
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...
250 comments
[ 2.9 ms ] story [ 277 ms ] threadOh, if that's the case:
https://github.com/tulip-lang/tulip
> 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.
In short, the type system in C++ just can't quite fully express the requirements.
What I didn't see Google do in that article was trot out any template metaprogramming artillery:
https://www.boost.org/doc/libs/1_78_0/?view=category_metapro...
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?
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:
https://stackoverflow.com/a/48046118/1593077
Is it 100% bullet-proof? No, but then, Rust needs some unsafe parts too.
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.
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:
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:
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.
either way, use zig as the backend
"The Day The Standard Library Died" https://cor3ntin.github.io/posts/abi/
C++ ABI is also a joke. You can neither take advantage of it nor avoid it. Why have an ABI then ?
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? :-(
C++ doesn't have an ABI. It just pretends to have one.
Java needed no other selling points, and had none. But there is enough money around it, since, to generate them, howsoever fitfully.
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.
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.
Well, you/they practised at least C++98, C++11, C++17... That's many different languages already ;-)
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.
I consider myself a green energy advocate and would be glad to see c++ go away but I find naïveté a huge obstacle on the path to both of those goals.
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.
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.
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.
"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)
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.
Sounds like about half of the people on internet fora.
Obvious she is getting out, but it is highly likely with some help she could function a lot better.
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.
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.
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++.
Great things come from those unwilling to settle.
But the Kubernetes riff was telling: when using a cloud provider, so much of the system management is provided. When we insist on DIY, we get to DIY.
So maybe settling a bit here and there isn't catastrophic.
― George Bernard Shaw, Man and Superman
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.
Way too much for most usecases out there. And if you don't understand it, you can't fix it when it breaks.
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.
How did the C++ committee cause this?
I with the author the best in finding a more sustainable and healthy way of constructing meaning
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.
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.
That's not at all the point being made...
The author was mostly referring to his efforts to improve the language, not to write some app or library in C++.
http://www.adapplang.com/
Then wrote this. (You're welcome.)
Even C ditched its separate section for variable declarations.
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 : )
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.
> 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.
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.
[] - https://en.wikipedia.org/wiki/Obsessive%E2%80%93compulsive_p...
The exact same thing jumped out at me. Does anyone know if the author is a particularly well known or influential member of the C++ community?
The community is lessened by their departure
[0] https://www.youtube.com/watch?v=7THzO-D0ta4
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.
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.
Yet another person on here who didn't read the article.
> Multi-argument indexing made it into the C++23 standard, and so did std::byteswap. That’s my legacy I guess.
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 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.
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?
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's not an apology, that's an excuse, and there aren't many of those to justify treating people badly.
Nothing weird about this.
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.
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?
https://hn.algolia.com/?sort=byDate&type=comment&dateRange=a...
Perhaps you don't feel you owe article authors better, but you owe this community better if you're participating in it.
https://news.ycombinator.com/newsguidelines.html
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.
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.
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".
I think the more serious problem with that person is the lack of awareness of their own narcissism.
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.
No, they don't. Attention to detail isn't OCPD.
You're just being deliberately antagonistic. I guess you were triggered?
Correction, it is for OCPD, which is what you suggested upthread; OCD and OCPD are completely different disorders.
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."
I encourage you to try and consider the author's points instead of simply attacking her character.
I'll be there if you need help with that.
When I left C++, I felt like, I finally decided to quit rubbing one off with diamond sand paper.
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.
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
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.
A programming language isn't going to bring you real joy, that can only come from within.
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.
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.
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.
EDIT: it looks like a lot of those comments have been cleaned up or deleted since I first made this comment. Thank you.
https://cppcast.com/guest/imuerte/
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.
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.
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.
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
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.
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.
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?
Is it? Or are your priors being set by outliers sensational enough to be picked up by hn/twitter/whatever
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.