Why it’s necessary to shoot yourself in the foot
g-w1.github.io
g-w1.github.io
The “You could have invented monads, and maybe you already did” approach: monads do solve a problem, but if you’re presented with the solution before being exposed to the problem, you’d be like “This is magical, complicated, unnecessary. Why would I ever want the problem that this solves?”
If you don't already have all the problems that Kubernetes solves and the complexity that goes with those problems, adding Kubernetes prematurely gives you problems you didn't have by introducing complexity you weren't (yet) subscribed to.
A: "What the hell is a PersistentVolumeClaim? Why can't I just write to disk?"
B: "But what if you don't have a disk at the edge? How does this scale?"
A: "What edge?! What scale?! I have a disk!"/rant
The ones that have experience with devops tend to appreciate Kubernetes
I manage my personal infrastructure with Terraform.
I still prefer to keep services running with docker-compose when I can.
git pull && docker-compose restart docker pull ghcr.io/NAMESPACE/IMAGE_NAME:latest
docker-compose restart IMAGE_NAME ssh <server>
cd <directory>
git pull
tsc
pm2 restart allNo restart or compile because php don't care.
I think this is also why I didn't see the point of the design patterns book.
This frustrates me a lot when I see our current education system, from the kindergarten to post-grad.
For instance my 6th grader son's book introduces LCM/HCF out of the blue, something like "this is LCM and here's how you calculate it". Not a single motivating example.
Or take design-patterns. I learnt about two dozen of them in college and promptly forgot them within a week. I finally begin to appreciate them after encountering problems at work.
Imagine if carpentry is taught by asking pupils to cram about 150 tools over 3 years. Or they start out by saying "Let's build a chair" and discover the need for one tool at a time and mastering them as they go along. They will also learn that they should look for a tool should they encounter a new kind of task.
Why study long-obsolete tech?
Because it helps you better understand why the current tech is what it is, and it even makes one think about possible alternatives, which in turn foster innovation much more than merely religiously learning current technology.
> When teaching programming, we should let people make these mistakes, and then show them the tools to correct them.
This was one of my pain points when I was in college studying CS. It was killing me to have the teacher just dictate that programming lecture without showing what problems it solves and/or how difficult our lives would be if we don’t get it right. I still recall that interfaces lecture where the teacher keep telling us to declare some sort of class with some methods but without implementation!! Any class could then benefit from this! How/Why?! I wasn’t able to get this interface thing until I graduated and worked on a personal C# project with WPF where I designed it with a basic architecture of plugins/addons that got loaded at runtime, those plugins should all have some common functions that can be called by the host app, only and only then, I fully understood interfaces and how/why/when to use them. At that point, I wished I can go back to college, explain this concept to students and get back!
I believe the reason why college teachers struggle to explain such concepts in a better way is their lack of experience in the field.
It was only when I picked up a couple of online courses like CS50 from Harvard and CS106 from Stanford (quite outtdated now) that things started to make more sense. Sometimes those things take time and looking at them from different perspectives, and even different programming languages/paradigms.
E.g. I started to appreciate the use of interfaces more when I started using Go, going from Java, where they're implemented implicitly, that I realised they're actually really useful and not just a nuisance.
This happens to ... a friend of mine.
"The good thing about making mistakes, is that you get to know which mistakes are worth making."
Now, granted, too many people / organisations / whole fucking countries aren't even learning from their own experiences, but you should really strive to learn from others too.
However, responding here since you did, I think you missed the whole point of that sub-thread. People aren't telling you that Bjarne's terrible I/O streams functionality is great so you should use that. They're praising the much more normal looking std::format and related features which have been adopted from fmt.
As a result assessing Bjarne's I/O streams and discovering that they're terrible is not a meaningful reaction to that praise. We know Bjarne's feature is bad, we're talking about a different, much better, feature.
Well, std::format is what you actually told me I was a fool and a noob for refusing to use under the pretense of being pragmatic. ("you are deliberately choosing to use poor tools and calling this "pragmatism" because it sounds better than admitting you're bad at this and you don't even want to improve")
So I've finally put in the work and made std::format run on MSVC because that's the only compiler where std::format is available for me (gcc-12 and clang-14 don't include it on my Debian VM).
And guess what, simple file with main() and std::format("Hello {}\n", 42) + fwrite() takes 1.4 seconds to compile there (no linking, no optimizations) compared to 0.16s for compiling a cpp file with the equivalent snprintf/fwrite call.
0.16s is still much but MSVC takes 0.12s for compiling "return 0". Subtracting that, it's a somewhat reasonable overhead of 0.04s for including + using stdio.h / snprintf. And 1.28s, so literally 32x that amount, and realistically a nerve wrecking time to wait for a single file to compile, for the std::format version.
I'm not sure how to take you seriously anymore. It's hard to imagine you've actually used this yourself, because paying more than a second to compile a single print statement is not OK. I wish people like you would just be a little less loud and more considerate when judging people that are trying to actually get something done.
The code under test:
#include <format>
#include <string>
#include <stdio.h>
int main()
{
std::string x = std::format("Hello {}\n", 42);
fwrite(x.data(), 1, x.size(), stdout);
return 0;
}
Microsoft (R) C/C++ Optimizing Compiler Version 19.35.32216.1 for x64
I should expect most people have more than one. Have you ever seen a benchmark which tried just calling some library feature once and then pronounced it slow? Like, hey, your new hash table is slow, I called insert on it with one value and that took ages / How about the next time? / What do you mean next time, it's slow, I'm never using it again.
Perhaps this all points to a process issue, that your development process is... let's say unusual and that's driven you to make some perverse trade offs because you aren't able to imagine a way to do what you do with the technology everybody else is using. Maybe they're not the crazy ones ?
https://twitter.com/magdraws/status/1551612747569299458
The good news, though probably in the distant future for you, is that C++ standard library modularisation should dramatically speed up compilation since the compiler won't need to laboriously discover all the facts about foo.h over, and over, and over again as it is mentioned in each place it's used.
But you're right, I don't use any of this stuff in anger, I write Rust. I admire fmt because I think it's a remarkable achievement to have a type checked formatter as a library function.
Oh, I have many seconds, and I'm already spending many of them, to the point that I'm not willing to just give them out for free. In a project with dozens or hundreds of files I'm not willing to introduce a central dependency that slow down each of them by one additional second.
> The good news, though probably in the distant future for you, is that C++ standard library modularisation should dramatically speed up compilation since the compiler won't need to laboriously discover all the facts about foo.h
I'll believe when I see it. Have you tested it? Currently, we can't use modules at work since we're not on the newest compiler.
But I take your point.
-- Douglas Adams, Last Chance to See
:-)
By three methods we may learn wisdom: First, by reflection, which is noblest;
Second, by imitation, which is easiest; and third by experience, which is the
bitterest.I’m also pretty sure that students in civil engineering are making virtual bridges collapse every single day.
It’s also true in other engineering branches : we have barely the same planes design since decades and that’s for good reason.
It’s not really something you can do when rules and best practices are going left and right every couple of months.
And don’t get me wrong I’m convinced that the peak of program engineering is in the past. But the industry keep forcing new things to developers.
Meanwhile in programming you will literally have someone hash their passwords using md5 in 2023.
Maybe the difference is liability and possibly ending up in jail when things break. Software error has become a common excuse these days. If your companies enourmous unethical fuckup is exposed, just blame it on software error. Everybody understands: software errors happen and there is nothing we can do to prevent them from happening.
Only this is not true. We know how to test code. We know about formally verified code. In safety critical domains (aviation, automotive, industrial, banking, ...) we have been doing this forever.
I am not saying that every garden shed should have to follow the same rules as an interstate bridge, but maybe if our webservices fail spectacularly on a regular fashion maybe we should look towards software engineering practises that prevent things from failing that often?
¹ After that most bridge collapses have been due to organisational failures, like a lack of maintenance or a lack of oversight or enforcement of the established rules
It’s the job (and value) of a teacher to help you understand not only how but why we do like this.
Since we are more or less thrown is this beautiful "life-long learning" career without professional teachers, it’s way harder to understand the why without exceptionally great mentors. And that’s my pet theory that this is at the roots of cargo cults.
Before civil engineering became a profession all kinds of people would build bridges and all kind of bridges would collapse. The solution wasn't to accept that bridges collapse, the solution was to not allow just anybody to build a bridge and to create standards that bridges had to adhere to.
Also, as a self thought programmer that is regularily shocked of what he finds in the field, done by supposed professionals: Being self thought has nothing to do with it. Because I can also read on someone's experiences and mind set. Every self thought programmer will read books on programming made by people who program. Even self thought programmers will avoid goto atatements like the pest even if they don't know the original reason for that rule.
The problem in software engineering is one of culture. We program shit and move on. If it breaks it is not our fault. Very few people feel ownership and/or responsibility for the code. Granted: Very few companies are willing to pay the money needed to allow for such a process, except if they are in a field where it is required by law (automotive, aviation, ...)
What we need is a clearer liability structure for software errors. If a companies software is investigated after privacy leaks and they are on the hook for each individuals data that they mistreated if the software is not up to standard companies will think twice to cheap out on software engineering. If software engineers are on the hook if a company gave them everything needed to make a safe product and they didn't, they are on the hook.
I don't say everything needs to follow that level/standard, but as of now a software error is treated like a unavoidable act of gods will that nobody could have foreseen or prevented.
I do agree with you that the profession doesn’t lack its fair share of big egos and self taught arrogant geniuses.
But there is a difficult equilibrium to find between this and the other side of the coin which is the cargo cult of inherited best practices and over engineering.
Most programmers (including sometimes myself) have a hard time choosing the right tool for the right job. But learning to pick the right tool is hard.
Even learning this from others is hard : I’ve happily learned from a lot of specialists how to use a specific tool in depth, but I can count on one hand the number of people who suggested me a better tool for the task.
And honest reflection on failure is punished in hierarchies.
I had many collegues in unversity that had to shoot themselves into the foot. A normal part of learning. But as we were always working together everybody had the chance to see the others doing so.
Now there were some people who saw others shoot themselves in the foot in a particular way, only to go and do the same thing on their own project. Don't be that type of person. Be the person who observes others shoot themselves into their foot and wonder how you could prevent yourself from doing that in the future (and accept that for some things you can't).
Software engineering is very similar. Sure maybe you are the type of person who can't grok a footgun unless they got shot by it. But you can try not to be that type of person. Making mistakes is important. But make them at home or in toy projects, don't make them in a decade long effort by a ten people team with the data of million people. And if you are in such a project it is part of your job to learn from other similar projects and the ways they shot themselves into the foot.
I would add one thought here - it's not just about seeing others make mistakes, or about making the mistakes yourself. It's also about seeing how mistakes can be made across bigger teams or time-frames. Well-intended innocent creative choices at one point in the process can cause serious trouble later. Or two independent choices can create unforeseen problems. That's the sort of experience that's least visible, and that's what experienced mentors can provide.
So, I would argue that it's best to have a healthy mix - you want to see others fail, you want to fail yourself, but then you also want to have mentorship by others who have made these failures themselves. Seeing someone else make a mistake and then making that same mistake yourself can be a very valuable and humbling experience.
However I also think that most people need to experience the pain and frustration of hitting themselves with their own decisions a number of times, until they develop enough humbleness to see the benefits of using other's experience instead.
Learning C before Rust so you better understand Rust isn't "foolish action" nor does it "impede one's own plans".
I grow tired of authors twisting and abusing the meaning of common English idioms so the author can say "well actually some times you want to shoot yourself in the foot"
But i want to attach something on your "some opinion" title's
> You should learn Zig (or C) before you learn Rust
part.
I had learned C before Rust but, vectors are not used in C. It belongs to C++. And although I know C, Rust is still very confusing to me. In my opinion, it would be better learn C++ before Rust.
You mean by default?
std::vector is famously the only C++ standard library container which isn't crap, but, the fun thing is that it's still a bit crap anyway. Like a lot of C++ standard library features it could be better, but that'd be an ABI break, so too bad either use somebody's custom replacement which is better or put up with the good-but-not-great std::vector
What really disqualifies C for anything practical these days is the strings. In that it has zero native support for them, they're not a first-class citizen as they damn well should be, they're a complete illegal alien. String.h is such a trainwreck from a UX perspective that I despise every minute I ever had to work with it. C++ at least has some out of the box support for them, even if it's very barebones and clunky af.
Like aside from getting an educational perspective of how incredibly limited and poorly designed languages used to be, there's no reason we should still be building our cars out of wood with stone wheels which is what using C (and C++ to some degree for that matter) feels like. For learning how processors and computers work at the lowest level, going with something like assembly on a microcontroller makes more sense anyway.
I would like more, indeed a lot more, but in a resolutely bit banging language I will put up with &[u8] and that's what std::string_view gives you in practice. The out-of-box string literal in C++ is unacceptable, as is std::string (an owning, growable string) used for read-only purposes. None of this stuff should have survived into C++ 11, and yet today you will still see it used.
If you want to "join together" strings data and printf/snprintf isn't convenient enough, go ahead and use different tool. But don't act like computers can natively compute the concatenation of two string buffers, and offer you the result into your expecting hands. On a lower level, everything needs to be stored in memory somewhere, and if "just somewhere in a heap allocation" is good enough for your purposes, use a different language but don't expect best performance nor simplicity.
C doesn't have strings is because there wasn't a well accepted library for them at the precambrian time it was being designed. Otherwise it would've, not out of some ideological fit-for-purpose nonsense. It was supposed to be a high level language, as high as they could go with systems being as crap as they were back then.
What I mean is that strings are an abstract concept (roughly, a sequence of characters that can be indexed and possibly mutated) with many possible implementations and runtime characteristics. IMO, for C it wouldn't make much sense to prefer one over the other, other than the obvious statically allocated fixed size array where the compiler can already do all the work.
> If you have native arrays, you can have native strings, end of discussion.
C does have native arrays (of fixed size) and so does have native strings (of fixed size). It even has convenient syntax for instantiating these strings -- string literals. There is even syntax to concatenate them (at compile time) by simple juxtaposition in the source code.
> C doesn't have strings is because there wasn't a well accepted library
Nope, the reason is that "strings" (even if you assume their representation is strictly a tuple of size + pointer to contiguous character buffer) need storage of size that is unknown at compile time.
Storage needs to be managed, and the storage management can be either manually done or be done automatically by the language runtime. C opted to not have any of the latter except for stack variables and global variables (lifetime of process) -- and neither of those support dynamically sized allocations (exclude VLAs here).
If strings were simply an issue of library or syntax support, all the strings you could envision would exist by now. But even the best string libraries (for C) are a bad joke and do almost nothing to make string processing more ergonomic.
Honestly, I don't miss any of that, almost all of my string needs are well covered by printf/snprintf. Once I worked on my own text editor, and for this developped a text rope data structure that kept track of the line endings and the number of unicode code leader bytes etc, and supported efficient string operations at almost arbitrary sizes (easily gigabytes). Most languages probably don't give you this with their built-in "string" type.
What helps though, is to pick your tools according to the job. There is a lot of scripting work or web work that the language is simply not suited for. However for systems programming it's doing fine, giving you a lot of control while automating the most common headaches (register allocation, function calls, computation of data member offsets, etc).
> It was supposed to be a high level language, as high as they could go at the time anyway.
That is patently false. It was supposed to be a language that could allow them to program systems but more conveniently, and it was based on prior art. (There are certain figures on HN that I expect to immediately pop up and add that the art was already quite more advanced and "high level" at the time and C wasn't innovating on any front).
Well alright maybe a string is more like a big int or big decimal than a long, but all of these are commonly used enough that they should be part of just about any language. Just treat it as an vector/arraylist that autoexpands to a the new length when it goes over the max and that's that. Maybe having hidden mallocs introduces unclear pitfalls, but frankly so do raw pointers and everything else C does anyway so it's not like it would be much worse in that regard.
> C does have native arrays (of fixed size) and so does have native strings (of fixed size). It even has convenient syntax for instantiating these strings -- string literals. There is even syntax to concatenate them (at compile time) by simple juxtaposition in the source code.
Yeaaah that's almost like a preprocessor thing though isn't it? Unless there's a separate type I've never seen they're still just a char* that's made at compile time.
> text rope data structure that kept track of the line endings and the number of unicode code leader bytes etc, and supported efficient string operations at almost arbitrary sizes (easily gigabytes). Most languages probably don't give you this with their built-in "string" type.
Well there certainly are esoteric cases where having full control can have major performance benefits, but one could always just revert back to a char array if it's actually needed and still have normal strings for 99.9% of daily use.
And well, Microsoft shipped the blazingly fast VSCode that's somehow made in javascript and runs on the molasses that is electron, while outperforming Sublime Text that's native C++. If done right, the VM/compiler should be smart enough to optimize these repetitive things according to best known practices instead of having to do it by hand over and over and over and over.... and probably messing up half the time.
> If strings were simply an issue of library or syntax support, all the strings you could envision would exist by now. But even the best string libraries (for C) are a bad joke and do almost nothing to make string processing more ergonomic.
"No way to fix this" says only language in existence where this is consistently terrible.
Well aside from assembly, but that one gets a pass since calling integers words is a special kind of madness that's not to be messed with.
There is no way to fit what you describe in C. A string needs storage and lifetime management -- not only do you have to create new strings, you also have to delete strings that become unreferenced. There is no way to wrap a nice syntax around this in C to just make temporary strings that get automatically cleaned up. You would have to introduce a dependency on a global heap allocator, and introduce reference counting or similar machinery, and C is simply not about doing that.
And with a more structured approach, that missing syntax doesn't hurt that much. It can feel good to know what lives where and how the storage is managed. If you don't like it, go look someplace else. But don't critique C for concentrating on more basic and essential abstractions.
> Unless there's a separate type I've never seen they're still just a char* that's made at compile time.
Compile time is what I said right? And it doesn't make a char-pointer but a fixed size char-array.
You can have what you want in C++ thanks to RAII, like std::string. Whether the result is worthwhile is another question.
> If done right, the VM/compiler should be smart enough to optimize these repetitive things according to best known practices
User inputs aren't performance sensitive at all. You have a human in front that's sending maybe a dozen Byte/s of data at peak. Any language can handle that.
For visual output you're sitting on top of a browser rendering engine that's highly optimized in C/C++/Rust etc. Billions of dollars have been put into it. It's still certainly possible to use the API (the DOM and CSS) in the wrong way to make it dog slow.
The efficiency of making modifications to the data model underneath is predicated on the selection of data structures. If those are wrong, it will be slow no matter the selection of language or VM/compiler.
The text buffer is certainly one central datastructure that has to be fast. https://code.visualstudio.com/blogs/2018/03/23/text-buffer-r.... One thing to try is finding the "string" in there. See also the "Why not C++" section.
What's fundamental is the reference type, because that's the type you're going to use much more often, this is correctly a slice type, it refers to some bytes, I said above &[u8] is the least capability that's reasonable, and that's at last what std::string_view gives C++
This is one of the many fundamental choices Rust made that's much cleverer than it looks. The str type (some bytes which are promised to be UTF-8 text) is a language feature, a slight improvement on [u8] that's core to the language, however String is just a library type, albeit a very heavily optimized library type. A $1 micro controller might well have some use for &'static str, the immutable slice reference, e.g. to talk about some text baked into its firmware, but it doesn't have a heap allocator, it's not about to waste precious RAM on a dynamic allocator, and so it doesn't need String.
The str type you mention is a nice feature, and in the future when I will have switched to Rust or whatever, I might use it to write my programs in 5 lines less.
While in C I have to use C's "slice" type: char x[] = "Hello". I know it's not quite as good since if I was to pass this around, I would have to make a pointer + length representation for this. If I needed it, it can be automatized from string literals: struct String(const char *buffer, size_t size); #define STRING(lit) (String){lit "", sizeof lit - 1}. Or char buffer[256]; my_api(buffer, sizeof buffer);
For the few situtations where string manipulation is required, it's just not a real problem.
Example: (Destructive) Move assignment is the correct thing, if you introduce that to begin with, showing Copy as an optimization, I think that makes more sense than the way it's often taught knowing people are familiar with languages that default to (or only have) copy assignment.
Another example: Rust doesn't have boolean coercion, the boolean coercion is so rife that you find it in otherwise seemingly principled languages, but the consequences are quite awful - in Rust you can cheerfully teach the entire language without this concern, because Rust doesn't have this coercion. "false" is neither true nor false, it's a string, 0 is neither false nor true, it's an integer. Many modern languages avoid C's extreme coercions - you can't write "Ten" + 5 or 'a' + 1 in such languages, (in a few of them it's a concatenate operation, which I don't love either, but at least it's not some weird coercion) - but they still insist "false" is true because it seemed easier and C did it. Rust does not.
Unfortunately learning the fundamentals requires a lot of reading and practicing and most literature and content out there isn't great.
The OP would have known why holding a reference to an item in a list sometimes is not a good idea by knowing the fundamentals of memory allocation, which can be found on many books and articles totally unrelated to Rust.
One of my favorite books for learning fundamentals is Effective Java, even when I wrote very little code in Java during my career I found some of the concepts and ideas in that book to be language agnostic.
... which can be learned by shooting yourself in the foot with C.
My opinion is, it's best to have done a little low level programming because it will nag you subsconsciously when you go accidentally quadratic or worse in a high level language.
"Men say that a stitch in time saves nine, and so they take a thousand stitches today to save nine tomorrow." - Henry David Thoreau, Walden.
It's good to not shoot yourself in the foot. Really. But, depending on what you're working on, it may not always be worth the effort to prevent.
For some things, of course it is. If you're working on something either safety-critical or enterprise-critical, you almost certainly want to use whatever tools you can to prevent shooting yourself in the foot.
But sometimes the price of the safety costs more than it's worth. At the extreme other end, if I'm writing an experimental one-off for my own curiosity, I'm not going to worry about satisfying the borrow checker (unless the point of the one-off is to learn Rust). If I'm writing an experimental one-off for work, that's likely to be still true - I'll write it in whatever gets me there fastest, because the point is learning what the results are, not producing production-level code.
Use the level of protection that's appropriate for what you're working on - no less, but also no more.
Note that all this is somewhat orthogonal to the question of whether one needs to shoot oneself in the foot before learning how not to. This is more like, once you've shot yourself in the foot, learn when to leave yourself exposed yourself to the possibility of shooting yourself in the foot again.
It is sad that newcomers are told to learn this tool and that tool while they never get to know the problem those tools are solving.
Another experience that triggered an A-ha moment for me, was reading the OAuth2 RFC (6749). I had previously read multiple docs of libraries implementing the protocol and had integrated with such libraries in the past, but it was only when I read RFC and the problems the different flows try solve that it finally clicked.
That is how my university professor made whole semesters hate programming.
An IDE makes the entry into programming much easier and fun.
then they shouldn't have picked java as an intro language.
It is more than possible, but for anything non-trivial, it just sucks.
It's very gratifying when you're a Unity dev in a room of Unity devs and you're the only person who can diagnose and fix a build problem involving raw OpenGL ES and Objective-C++.
From another angle, these baser systems like C and vanilla JS are _simpler_ and you just have a lot less to learn at once. It's a good waypoint.
Interestingly not my experience.
I usually start something uselessly complex, with more passion than reason, to learn or brag, then halfway I indeed shoot shoot myself in the foot trying to be clever or lazy.
I would not recommend to look for footguns, they are already looking at you :)