For any particular person, you can tell a story that satisfies "Why?". But for a large number of people, you have to answer "Why?" for one sub-group at a time.
In other words, there's not a single answer that will answer this in a satisfying way.
To answer a different question: It appears that the Israeli government and military wanted to bomb Iran again, and the United States executive branch and military decided to help out. This is an incomplete and unsatisfying answer. Sorry.
> In other words, there's not a single answer that will answer this in a satisfying way.
There could be one, but it would be a book-sized answer (and probably a Tolkien one, if not more).
Every conflict is multi-faceted and happened for a variety of reason, some mattering more than other. Any conflict involving the middle east and you have to go back almost 80-years of history to really provide a satisfying answer. Control of world oil supply, trades with China, opportunistic war to appease local voter pool, diversion from problematic affairs, diplomacy with Israel (which as it own thousand fold reasons for this war), Iran being left weak after losing most of their local allied militia, internal uprising due to a economical crisis caused in part to the removal of the agreement on nuclear and the trade ban that followed ... They all probably play a part.
Of course, working in a legacy codebase is also torture.
Software development is a hyper-rational endeavor, so we don't often talk about feelings. This article also does not talk much about feelings.
Reading between the lines, it looks like reverting the code is supposed to affect how you feel about the work. Knowing that failure is an explicit option can help to set an expectation; however, without a mature understanding of failure, that expectation may just be misery.
With a mature understanding of failure, the possibility of a forced rollback should help you "let go" of those changes. It's like starting a day of painting or drawing with one that you force yourself to throw away; or a writing session with a silly page.
----
If someone thinks that they are giving you good advice, but it sounds terrible, then maybe they are expecting you to do some more work to realize the value of that advice.
If you are giving someone advice and they push back, maybe you are implying some extra work or expectations that you have not actually said out loud.
I'm reminded of a talk I enjoyed about "extreme rewriting" [1] — how rewriting the same code many times (in certain contexts) can help uncover powerful underlying abstractions.
It makes intuitive sense to me that this would be true in complex domains (e.g. legacy code) where you really need to find the right solution, even if it takes a bit longer. Our first ideas are rarely our best ideas, and it's easy to get too attached to your first solution and try to tweak it into shape when it would be better just to start fresh.
Maybe it is the framing of the step as a "reversion" or "roll-back" rather than "spike" or "prototype" that is causing that sense. Personally, I would never throw away the code I spent time and effort writing just to stick to a systematized refactoring method like this "Mikado." I don't think the advice is unsound, and I have done exactly this many times in my own career, but instead of throwing it away I would shelve it, put it in a branch, write a document about what has been/needs to be done, and write a corresponding tech debt or feature/fix ticket for it with the new and realistic estimate.
Regarding "Conspiracy Theories" - they make a lot more sense to me if you call them "Low Information, High Satisfaction" Theories.
Regarding the rest of the article: it reminds me of how things like nursery rhymes or fairy tales or Shakespeare's plays used to mean something very different and very specific.
Counter reason in favor is that you can always count on it being there and working the same way. Perl is too out of fashion and python has too many versioning/library complexities.
You have to write the crappy sh script once but then you get simple, easy usage every time. (If you're revising the script frequently enough that sh/bash are the bottleneck, then what you have is a dev project and not a script, use a programming language).
You're not wrong, but there's fairly easy ways to deal with filenames containing spaces - usually just enclosing any variable use within double quotes will be sufficient. It's tricker to deal with filenames that contain things such as line breaks as that usually involves using null terminated filenames (null being the only character that is not allowed in filenames). e.g find . -type f -print0
You're not wrong, but at my place, our main repository does not permit cloning into a directory with spaces in it.
Three factors conspire to make a bug:
1. Someone decides to use a space
2. We use Python
3. macOS
Say you clone into a directory with a space in it. We use Python, so thus our scripts are scripts in the Unix sense. (So, Python here is replacable with any scripting language that uses a shebang, so long as the rest of what comes after holds.) Some of our Python dependencies install executables; those necessarily start with a shebang:
#!/usr/bin/env python3
Note that space.
Since we use Python virtualenvs,
#!/home/bob/src/repo/.venv/bin/python3
But … now what if the dir has a space?
#!/home/bob/src/repo with a space/.venv/bin/python3
Those look like arguments, now, to a shebang. Shebangs have no escaping mechanism.
As I also discovered when I discovered this, the Python tooling checks for this! It will instead emit a polyglot!
#!/bin/bash
# <what follows in a bash/python polyglot>
# the bash will find the right Python interpreter, and then re-exec this
# script using that interpreter. The Python will skip the bash portion,
# b/c of cleverness in the polyglot.
Which is really quite clever, IMO. But, … it hits (2.). It execs bash, and worse, it is macOS's bash, and macOS's bash will corrupt^W remove for your safety! certain environment variables from the environment.
Took me forever to figure out what was going on. So yeah … spaces in paths. Can't recommend them. Stuff breaks, and it breaks in weird and hard to debug ways.
My practical view is to avoid spaces in directories and filenames, but to write scripts that handle them just fine (using BASH - I'm guilty of using it when more sane people would be using a proper language).
My ideological view is that unix/POSIX filenames are allowed to use any character except for NULL, so tools should respect that and handle files/dirs correctly.
I suppose for your usage, it'd be better to put the virtualenv directory into your path and then use #!/usr/bin/env python
For the BSDs and Linux, I believe that shebang are intepreted by the kernel directly and not by the shell. /usr/bin/env and /bin/sh are guaranteed by POSIX to exists so your solution is the correct one. Anything else is fragile.
These are part of the rituals of learning how a system works, in the same way interns get tripped up at first when they discover ^S will hang an xterm, until ^Q frees it. If you're aware of the history of it, it makes perfect sense. Unix has a personality, and in this case the kernel needs to decide what executable to run before any shell is involved, so it deliberately avoids the complexity of quoting rules.
This won't do what you're thinking it does. If I run that, I get:
env: No terminating quote for string: /path/with"/path/with
… because the string you've given env -S on my system is malformed, and lacks a terminating quote. (You can test this w/ just giving an unterminated quoted string to env … I have no idea why the messaging is so funky looking, but that's sort of par for the course here.)
As I alluded to in my post, shebangs don't handle escaping. Now, yes, you're thinking that env will do it, here. The other problem with shebangs is that they're ridiculously unstandardized. On Linux, for example, that shebang will parse out to:
This is because Linux passes everything after the first space as a single arg. macOS splits on spaces, but does no further processing (such as some form of backslash escapes) beyond that.
It works fine with GNU env with -S support, and a GNU-compatible kernel. I'm aware that won't work on some other systems, hence the 9 other examples. I said I would try that first and see how it goes, and low and behold it works fine on the systems I use.
$ cat bbb.ml
#!/usr/bin/env -S "/home/user/.local/bin/o c a m l" -no-version
print_endline "ok";;
$ ls -lh ~/.local/bin/"o c a m l"
lrwxrwxrwx 1 user user 14 Feb 27 07:26 '/home/user/.local/bin/o c a m l' -> /usr/bin/ocaml
$ chmod a+rx bbb.ml
$ ./bbb.ml
ok
$
But if it didn't work, you can get pretty good mileage out of abusing sh to get the job done for many popular languages.
As someone who use LLMs to generate, among others, Bash script I recommend shellcheck too. Shellcheck catches lots of things and shall really make your Bash scripts better. And if for whatever reason there's an idiom you use all the time that shellcheck doesn't like, you can simply configure shellcheck to ignore that one.
this pairs nicely with the finding of the supreme court:
Under our constitutional structure of separated powers, the nature of Presidential power entitles a former President to absolute immunity from criminal prosecution for actions within his conclusive and preclusive constitutional authority. And he is entitled to at least presumptive immunity from prosecution for all his official acts. There is no immunity for unofficial acts.
Look, you can't have a (working, democratic) government where one party can send the other to jail as soon as they get into power. If presidents could go to jail for doing their job, their opposing party would absolutely try to send them there.
This would then ultimately handicap the president: anything they do that the opposition can find a legal justification against could land them in jail, so they won't do anything that comes close to that. We do not want our chief executive making key decisions for the country based on fear of political retribution!
The Supreme Court has failed, miserably and repeatedly lately, and some of their decisions run directly counter to the law (often they even contradict past decisions!) But deciding the president won't face political retribution for trying to do his job was not a mistake.
Hard disagree. The metric ought to be whether they'll make it out of the court case clean or not - just having the ability to check power in a meaningful fashion when it goes off the rails is something you're only afraid of if you're a war criminal or other flavor of Massive Piece Of Shit.
The reason the rules are the way they are is pretty obvious; we haven't had a not war criminal in office possibly ever, definitely not in my lifetime. It's time we faced the facts - we're the baddies.
This is a really silly take. The whole reason for separation of powers is so that the executive can be bound by laws created by the legislative as adjudicated by the judiciary. Saying that the people in the executive are above the law undermines this completely.
This doesn't say the executive is above the law, it says you can't prosecute the president for doing his job, just like you can't prosecute judges for their rulings on the bench or members of congress for their votes on the floor.
The equivalence is that in all three cases those are the official duties of the office.
I would agree that the scope of the president's job description has gotten overly broad over the last century as congress has delegated more and more of its powers to the executive branch, but I don't think a prosecutorial Sword of Damocles is a good solution to that problem. Certainly it's not the constitutionally prescribed one anyway, which is what the court's ruling affirmed.
For any particular person, you can tell a story that satisfies "Why?". But for a large number of people, you have to answer "Why?" for one sub-group at a time.
In other words, there's not a single answer that will answer this in a satisfying way.
To answer a different question: It appears that the Israeli government and military wanted to bomb Iran again, and the United States executive branch and military decided to help out. This is an incomplete and unsatisfying answer. Sorry.
reply