If you were curious like me what PDCA is, this is the procedure in the article.
Plan: Recognize an opportunity and plan a change.
Do: Test the change. Carry out a small-scale study.
Check: Review the test, analyze the results, and identify what you’ve learned.
Act: Take action based on what you learned in the study step. If the change did not work, go through the cycle again with a different plan. If you were successful, incorporate what you learned from the test into wider changes. Use what you learned to plan new improvements, beginning the cycle again.
Also known as “PDSA” in some school districts that tried to implement it some years ago. It was one of the fad management techniques school districts make their faculty do, and predictably, wasn’t very effective.
Presumably the original PDCA has some good if applied correctly - I haven’t studied it, but have heard good things.
Yeah, it's only applicable to processes that are repeatable and have some amount of measurability - hence the natural application to manufacturing.
I'm not surprised that managers in non-manufacturing/technical areas picked up on it, since it's easy to understand at a glance. However, it's difficult to implement well.
If you know of any person that doesn't deal with repeatable processes all the day, I would really like to hear an example. Specifically on computing (most people here are software developers, aren't they?) the entire attention is focused on creating repeatable processes, that then we use computers to repeat for us.
PDCA means basically that you test a change before completely committing to it. That concept is the same as our canary releases, for example, but more clearly, it's the same idea as running one or two iterations of your algorithm on paper before you go and write the program.
It's not some niche thing that is rarely useful, it's just that people try to push it into exactly the work that can't use it.
> any person that doesn't deal with repeatable processes all the day
Anyone that deals with people, no matter what all the training/literature/latest pop-industrial-psychology fad espews.
>PDCA:
Plan (see: "analyze data," i.e. read tea leaves (metrics)): impossible to do with people. Some try to get a "quick glance" via quantitative data, but that doesn't provide you anything practical, except ammo for political moves. People aren't processes. And any attempt to analyze them as a system is the peak of arrogance.
Do: i.e. either go with your gut, allowing your intuition to navigate you, or go with policy/procedure/a process to cover your ass, and check off the "I'm adding value" box, so you can spend your mental energy on other schemes.
Check: see: "Do." Either you know how a certain action/policy affected someone or you have to read "data" to figure it out. Average case, you redefine your metrics and massage the data to get the result you wanted, so...
Act: you can use your results as ammo for political moves. Pat yourself on the back, have your assistant make a spreadsheet, and then hold a 30 minute jerk-off session/meeting with your superiors and fellow sycophants.
Now that I'm really looking at it, this is already implemented by those who deal with people.
In these cases you could use Boyd's OODA loop. It can be positioned as more able to deal with less certainty, epecially those that need to understand external context. I see echoes of it in Agile.
I am very surprised how complicated C++ is becoming in every revision.
It began with a simple goal of adding classes to C. The STL, inline functions, "true constants" were all nice stuff. C++11 introduced nice stuff like "auto", constexpr. But now the new features are increasing the complexity so much that it is becoming harder to learn the language. Is so much complexity worth? How can someone new to programming ever hope to learn this monstrosity?
I do agree that C++ is a very big and complicated (and ugly) language, and because they value backwards compatibilty the only way it can go is even more complicated, because the cannot strip out stuff.
But you last question can be answered in a couple of directions:
1. you don't HAVE to use C++, if there's another language easier, or better suited to your goals, use that. I think as long as C++ is the best choice for some domains it will stay relevant.
2. you don't HAVE to know/use all features of C++. If you're working solo just ignore the parts you want. If you're in a big team hopefully the codebase is such that you don't need to know everything about it to be productive.
3. Is adding features worth it? Well if you take 1 & 2 in to account, I think the downsides are capped a bit, and the upside is: more options. But of course whether you prefer many options with a lot of complexity, or a straightforward language is subjective.
It’s actually fairly rare that you get to choose what language and language features are used in the code base that you’re responsible for. Sure, if you’re the tech lead at a startup, or working on a personal project, but for all my day jobs, I’ve not once gotten to choose anything that fundamental about the code base.
So just in general, I do think it’s fair criticism of a language for offering crappy features, even if it is “optional” to use them. (Not arguing either way for coroutines specifically, as I’m not a c++ dev).
> the only way it can go is even more complicated, because the cannot strip out stuff.
The irony is of course that they have stripped stuff out. I spent a fair amount of time going through an old code base in my last job stripping out std::unary_function and std::binary_function. Not saying that the replacement isn't better however.
My least favourite example of bad C++ change is deprecating and removing the overload of `std::random_shuffle` that doesn't require a new random device and a random function [1].
Sure, that version was cryptographically insecure, but 95% of the use cases of shuffling have nothing to do with cryptography and don't need to be secured. This is not a case like PHP's `mysql_query` which has an easy replacement: now you must declare an `std::random_device` and `std::mt19937` and pass them to your functions.
This nearly made me fail a job interview in an embarrassing way.
Becoming harder? Last time I wrote C++ was in 2010 or so. There's so much new stuff I already consider it impossible to learn. It will become even more complex with this update.
I think it's not a coincidence that 99% of the complaints about modern C++ on HN are from people who...don't use C++. You don't get anything remotely like this tone of discussion on r/cpp or whatever.
I've been continuously employed as primarily a C++ developer since around 2001. The language was pretty bad back then, but it's been getting better and better since C++11. The vast majority of the new stuff is absolutely wonderful to use, a huge improvement in productivity and code readability.
Big +1 to this. Most of the changes to C++ have been fixing old problems. Concepts are a complex feature sure, but before having named concepts in code, we had unnamed concepts in code that may or may not be named in the documentation. Being able to name these things in code and get reasonable error messages from the compiler / just actually be able to understand it in my brain is great!
Same with constexpr. People used to do all sorts of stupid math / string concatenation in "template metaprogramming" to get compile time execution. Now they write (mostly) normal functions in standard C++ that I can actually read. The language gets more complex sure, but the code I read and write gets simpler.
C++20 is larger than C++11, sure. But for most users, it's simpler too.
> Most of the changes to C++ have been fixing old problems.
It will not fix all the pre-existing legacy code that people deal with on a daily basis. Languages are like infrastructure. People need to get it right on day one since it's exceedingly expensive to fix later on after people have already started to build on top of it.
I wasn't even complaining though. I'm just demoralized due to the extreme and ever increasing complexity. I don't feel like it's worth it to update my C++ skills.
My real complaint about C++ is the utterly insane ABI situation. Only C++ code dares to touch C++ code, no other language can interface with it without a C interface in between. The new standards forced even C++ compilers to break backwards compatibility with themselves due to requiring certain data structure performance characteristics. There is such a thing as C++ code that won't even work with other C++ code produced by the same compiler.
Could you explain what kind of projects nowadays use C++? I'm not up to date at all anymore. Used a lot of C++ until about 2010 (for simulations and Windows programming).
> Could you explain what kind of projects nowadays use C++? I'm not up to date at all anymore. Used a lot of C++ until about 2010 (for simulations and Windows programming).
All browsers you use are written in C++ (Firefox, Chrome...). Node.js is written in C++.
We live in that bizarre world, where on one side we have C, an antiquated and simplistic language and on the other C++ a monster of complexity that provides also basic modern stuff C will never have.
Rust has complexity of its own but it's more like a "philosophical" complexity rather than syntactic. A lot of C and C++ developers just don't like how Rust works.
High-performance database engines and similar data infrastructure are almost exclusively written in modern C++ these days. They benefit immensely from new C++ features.
Read Stroustrup's blue book written after C++11 was released. Not only is the font nicer than the white 2003 edition, it goes into sufficient detail to understand the new (now old!) features of C++11.
I don't think so. The complaints always seem to come from people who parted ways with C++ a long time ago. Given that C++ remains popular, it feels like some are unsure whether it was the right choice and they need to publicly self-justify it.
Many of the complaints about C++ really don't line up with day to day experiences using C++ IMO. They focus on problems and complexities that just don't come up often if at all unless you're really going into the weeds of implementating your own "STL-like" types.
It'd be like if every time Java is mentioned everyone just bashes how terrible JNI's API is. Yes, it is bad. It's frankly horrifying. But it's also basically 0% of where you spend your time when writing Java on the daily.
That's not to say C++ is rosey in practice, just the problems that actually get encountered on a modern code base almost never get mentioned here while all these esoteric edge cases that never come up in practice are beaten to death.
For example take C++ templates. In this thread they are slammed repeatedly. In practice you know what? They're fine. It's not that bad. Template metaprogramming is brain bending and hard, and I wouldn't suggest it. But basic templated classes or functions? No harder or more complex than the exact same thing in Java or C#. And in practice that's really all you do the overwhelming majority of the time.
This article discusses things that are totally irrelevant to someone who will actually use coroutines, because they will use https://github.com/lewissbaker/cppcoro or wait for C++23 to give them the library support for coroutines, which will make usage simple, like the first code snippet from the article.
It is possible to compose them more easily than described in the article; Lewis Baker's cppcoro library for example provides a recursive_generator<> type[0] that allows this without using any macros. It's up to the library part of coroutines to make things easy, end users are not expected to write low-level coroutine code themselves.
I wonder about the allocation elision. Return value optimization became mandatory, and some compilers can already elide calls to new/delete and malloc()/free() in normal code, so perhaps it will be possible to guarantee allocation elision in the future in the most used cases.
If you don't like the culture and work it is not wrong to leave it soon and join a better place. But you can't know if the new place will not have other type of problems. You can't find out in interviews if new company too will have dysfunctional way of working. Nobody shares such things in interviews. If you have friends in other companies then it is the best way to learn how culture is in those companies.
