C++: Engineers Wanted, Programmers not so Much - David Sankel - C++Now 2019

[@jonathanrobert3620]

One of the best engineering presentations I have ever seen. This should be shown at the beginning of every SE program at university.

[@llSoleyll]

The DRY example is totally misleading and not proving anything. The author replaced one fragment of code that needs to be written ONCE per program with another (even longer) fragment of code that needs to be written ONCE per program. So how is that an application of DRY? Replacing a single statement with another single statement is not an application of DRY. Another similar absurd example would be replacing "++i" with "increment(i)"... That is again not the point of DRY, because the number of repetitions is still the same.

[@colinmaharaj50]

7:40 So I like or I should say, I need esthetics, mostly because the code I write, I will be the one to troubleshoot it some years later. Now there are pieces of boiler plate stuff I have written like date conversions, or file io stuff, that I close up and make it have as few lines as possible.

[@GeorgeTsiros]

"int main(int argc, char**argv)" is NOT what "don't repeat yourself" is about. First of all, there is not even any _repetition_ here. This _definition_ exists _exactly once_ in each program (the _declaration_ is implicit in the C standard itself). Bad example! Bad!

[@SS-kg8rj]

I think the speaker misses the fact that doing the Python major version change is equivalent to moving a plant from Portugal (or wherever) to the US to use his own analogy. You've got to keep the old stuff running while you bring in the new stuff. From that perspective, the move was a win, not a disaster. From that lesson, they also learned that they want to release more often which they have done. From an engineering perspective, I would not count the 2->3 migration as a disaster. It is how an engineer should do it.

[@SS-kg8rj]

Additionally, he's forgetting how long it took to get concepts into C++ yet uses it as an example of a language of great engineering. And you still can't have compile time interfaces(!!!) which Python has had since 3.9. As of this writing, Python is now number 2 and C++ is number 4 in the speaker's referenced Tiobe listings.

[@MaddieM4]

I don't think Python 2->3 is purely success or failure. They got there eventually under difficult constraints, but way over any reasonable time or effort budget. In hindsight, there's a lot of ways the migration could have been made smoother, and the Python team learned the hard way how much they underoptimized for the migration experience.

[@jacktaylor1516]

I think code migrations would be a lot easier if maintainers focused more on consistency and correctness and less on feature additions.

[@bawbak8800]

To me, it sounds a naive way to compare software engineer with other engineering fields. Firstly, we just call this phenomenon wrongly as software engineer, because most part of that is not engineering at all, and it's literary science and tons of research. Engineering is the step after knowledge being generated by science. Which about software, we haven't reached that point yet. I'm not talking about making a web service with a bunch of CRUD operations, I'm talking about creating a complex software, which you have to care about its details as much as possible to be able to handle its complexity for maintaining and adding new features to it. We don't care about those details (which you might call them aesthetics) just because we are some picky programmers. We have to really care about them to avoid having future headaches and really understand what we are doing. The main mistake that people make is they think developing software is like creating some physical products that you can do it like other stuff or engineering it like others. In this age, developing software is the most complex thing to do, and that's why we have so many shitty software programs with millions of lines of code which exponentially growing plus their complexity. I hope one day people understand that developing software is still a new phenomenon and we need to do it in its unique way.

[@piotrarturklos]

"code review is a hostile environment that simulates working with the code in the future" (paraphrased) This blew my mind and seems excellent for teaching people about code review. You pretty much have everything in one sentence. I bet there is a book that could be replaced with it.

[@phisyka]

I think the idea of measuring the value of of software by its technical debt in monetary terms is fascinating. One way that could be translated to is 'programmer hours' required to fix, and also delays at the later portions of your business pipelines. Although estimating time it takes to do something is difficult, so collecting data for fixing bugs or having errors could be used to determine the cost.

[@raveheart58]

One of my favourite talks recommended to me by a work colleague. I'm on board with this idea of ideologies vs fitness. And not getting caught up in const correctness.

[@piotrarturklos]

Const correctness is a bad example of a bad ideology because there is a high penalty for using it inconsistently: you will fight the compiler errors. It is an ideology, but a one that you have a choice to buy into at the point of language design, not at the point of writing an individual program. Once it's in the language, it's over. You pretty much either use const-correctness everywhere or nowhere, otherwise you aren't maximally productive. But this is also a false choice because all the libraries you use are const-correct, so you have no choice but to stick to it always. (Note, I'm talking about being maximally productive, not merely about being able to produce anything.)

[@MrAbrazildo]

2:35, I'm sick of low quality wine, with plenty of alcohol! 2:48, a brandy, a drinkable alcohol. 1:10:29, but what about exceptions and interfaces? They are slow high-level features. As long they keep being completely optional, I think they are welcomed to the language. 1:29:00, C++ could only has GC as optional feature, as D does, because otherwise the language would not fit the performance demands from certain fields.

[@andersbodin1551]

Maybe technical debt should be accounted using a risk matrix.

[@abhishek.chakraborty]

Please create a *playlist* for all 2019 videos i.e. C++Now 2019 🙏 like e.g. _C++Now 2018_ : kzbin.info/aero/PL_AKIMJc4roVSbTTfHReQTl1dc9ms0lWH That would be very helpful in making these easily accessible

[@GeorgeTsiros]

meanwhile, a CPU will execute _quadrillions_ of instructions each day and not fail _one_ A CPU will likely go through its entire life not misexecuting even one instruction. A heart has _worse_ availability, considering at a very old age it misses cycles.

[@youkenez]

One of the key ideas here that "aesthetics" should not be the goal reminds me of the views of kzbin.info who's criticizing contemporary physics that they're trying to find some theory with beautiful mathematics instead of working on what's important, to gain novel insight into how the world works.

[@GeorgeTsiros]

99% "service level indicator" is laughable. If a piece of hardware running at a measly 1 MHz would be expected to fail every _tenth of a millisecond_ . It would _literally_ not have enough time to be brought to power before it halts.

[@AidenBull-b4u]

But if your base unit of time is days and not microseconds, working for 99 days and going down for a day is workable.

[@volkangundogdu1008]

intentionally too much polarised, lack of objective approach due to prejudged opinions however in overall he performed good to explain the subject