It’s such a short list of value types though. How can they have that much trouble? All of the various ints and floats, bool, char, structs, and enums. Everything else is reference.
Having an asterisk both be the type indicator and the dereference operator is one of the great programming language design blunders of our time, along with allowing nulls for any type in so many languages.
The code in the image is C or C++ or similar. In those languages and languages derived from them, curly braces are optional but the parentheses are required. It should be the other way around to avoid logic errors like this:
<span style="color:#323232;">if (some expression)
</span><span style="color:#323232;"> doSomething()
</span><span style="color:#323232;">else if (some other expression)
</span><span style="color:#323232;"> printf(“some debugging code that’s only here temporarily”);
</span><span style="color:#323232;"> doSomethingElse();
</span>
Based on the indentation you’d think that doSomethingElse was only meant to run if the else if condition was true, but because of the lack of braces and the printf it actually happens regardless of either of the if conditions. This can sometimes lead to logic errors and it doesn’t hold up to a principle of durability under edit — that is, inserting some code into the if statement changes the outcome entirely because it changes the code path entirely, so the code is in a sense fragile to edits. If the curly braces were required instead of optional, this wouldn’t happen.
I have all of my linters set up to flag a lack of curly braces in these languages as an error because of this. It’s a topic that sometimes causes some debate, ‘cause some people will vociferously defend their right to not have the braces there for one liners and more compact code, but I have found that in general having them be required consistently has led to fewer issues than having arguments about their absence, but to each their own. I know many big projects that have the opposite stance or have other guidelines, but I just make ‘em required on my own projects or projects that I’m in charge of and be done with it.
The company had avoided certain destruction, after having fired the previous CEO and putting a new one in it’s place. The new CEO had managed to bring a newfound calm to the company and it’s ranks, and brought an air of meditative discipline to board room meetings.
Some said it was crazy, but making the LectoFan EVO the new CEO was the best decision the company board had ever made.
I find it very hard to believe that AI will ever get to the point of being able to solve novel problems without a fundamental change to the nature of “AI”. LLMs are powerful, but ultimately they (and every other kind of “AI”) are advanced pattern matching systems. Pattern matching is not capable of solving problems that haven’t been solved before.
But C syntax clearly hints to int *p being the expected format.
Otherwise you would only need to do int* p, q to declare two pointers... however doing that only declares p as pointer. You are actually required to type * in front of each variable name intended to hold a pointer in the declaration: int *p, *q;
Rust borrows a lot of it’s design from functional programming languages like Haskell, which has its good and bad. You could also choose to implement this behavior iteratively like typical C programs, but that tends to be ugly in other ways.
Personally, I’ve grown fond of the functional style. You see it in other places too, like the higher order functions in JavaScript. What’s good about them in Rust is you still get amazing performance due to zero-cost abstraction. Trying to implement it yourself would likely be slower, so use them any chance you get.
Which are used to calculate stresses for dams, fluid dynamics for planes and ships, capacity and load simulations for power, and to compile and operate servers.
Software engineers are the pinnacle of engineering.
Check out this book on Amazon (or your library) to see just how clever and useful we really are.
If you need a book to tell you how useful you are, chances are, it's claims might.be a bit overblown. The profession that has most of those.books written about them are managers after all. Just saying.
Software engineering doesn’t treat failure anywhere near important enough for me to consider it proper engineering. Bugs are expected, excused and waived, which for anything critical just isn’t acceptable in my opinion.
Bugs are inevitable. Humans can’t write more than a few dozen lines without making a mistake - it’s inevitable because we’re barely sentient apes, floundering to understand the full scope of the problem space
But through methodology, bugs can be mitigated. You can reduce their number, and fail gracefully. We have countless ways to do it, and we teach how widely
There’s a science to it all, and those of us worth our salt know it… It’s not our fault that management disregards our warnings and pushes ever tighter deadlines.
We know how to do better, our warnings just fall on deaf ears far more often then not
Meh. There’s a saying in my field: “anyone can build a bridge, only an engineer can make one that barely doesn’t fall down”.
Humorously reductive as it is, software is what makes that “barely” thinner than human calculation would normally yield. So… Yeah. Not what I’d call a pinnacle.
programmer_humor
Active
This magazine is from a federated server and may be incomplete. Browse more on the original instance.