Wrapping Up 2021. Leaving C++
izzys.casa
izzys.casa
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".
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 think the more serious problem with that person is the lack of awareness of their own narcissism.
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.
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 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.
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
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?
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.
Is it? Or are your priors being set by outliers sensational enough to be picked up by hn/twitter/whatever
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.
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.
- https://pyjarrett.github.io/programming-with-ada/comparison....
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)
Adding ADA to this language feature comparison is interesting to me.
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.
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.
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.
I'd recommend asking in https://gitter.im/ada-lang/Lobby
I've never had any trouble with the installer, at least.
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.
> Does Ada support lambdas ?
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.
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.
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'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.
> 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.
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.
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!
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.
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.
The author was mostly referring to his efforts to improve the language, not to write some app or library in C++.
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...
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++.
How did the C++ committee cause this?
I with the author the best in finding a more sustainable and healthy way of constructing meaning
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.
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.
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.
Well, you/they practised at least C++98, C++11, C++17... That's many different languages already ;-)
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 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.
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.
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?
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...
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:
auto foo = something();
But, today if I write:
auto foo = something();
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.
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.
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.
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.
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.
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.
You're not special or important, get over yourself.
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.
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.
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.
The Pervert's Guide to Computer Programming Languages - SXSW
https://www.youtube.com/watch?v=mZyvIHYn2zk
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.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)
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.
Oh, 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.
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.
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.
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.
But even when I most want that, I certainly don't want it enough to use C++
I do appreciate her high-level comments on non-C++ languages as amusing and accurate complaints.
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.
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.
Then wrote this. (You're welcome.)
Even C ditched its separate section for variable declarations.
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.
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 : )
Surely Izzy is a very informed person on language design and can have at least some opinion about it.
The community is quite nice though.
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.
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.
They should have adopted u8 instead if wchar.
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.
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.
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.
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.
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.
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?
That's not an apology, that's an excuse, and there aren't many of those to justify treating people badly.
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?
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
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.
Nothing weird about this.
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.
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."