rmunn

It's also a very physical play with a large number of onstage fights. Fight choreography is some of the most dangerous stuff to do onstage: a single mistake and someone can easily be hit by a sword that was supposed to just barely miss them. And although stage-fighting weapons are naturally blunted, they're still big heavy metal rods that can bruise or break bones if you get hit by them. (See my P.S. for a funny story about that, BTW — nobody was injured in that one, but it came close a couple times).

There are some scenes in Macbeth that can be turned into offstage fighting if the director wants to minimize risk to the actors; for example, the battle with Macdonwald (not a typo) in Act 1 Scene 2 is reported to King Duncan, but not seen onstage in most productions. (Though an ambitious director might choose to have a mass battle depicted during the transition from Scene 1 to Scene 2, then have the combatants leave when Duncan walks onstage to hear the report). But there are three scenes that explicitly call for an onstage fight:

Act 3, Scene 3: three hired killers attack Banquo and his son; Banquo is killed but the son manages to escape. This all happens onstage.

Act 5, Scene 7: Macbeth fights young Siward, and kills him.

Act 5, Scene 8: Macbeth fights Macduff, and it's a long fight. They fight once, pause to exchange some words while both are gasping for breath, then they fight again. The stage directions call for them to exit the stage still fighting, then come back onstage still fighting, just in time for the audience to see Macduff kill Macbeth.

With three swordfights that must happen onstage, the potential for accidents is a lot higher than for most of Shakespeare's plays.

On the other hand, Romeo and Juliet has a similar number of fights, as does Hamlet — yet neither of them has acquired the same reputation. So it's also possible that there's an element of self-fulfilling prophecy going on here: actors who are worried about getting hurt might not have their full attention on the fight choreography, making them more prone to make mistakes that do actually result in injury.

P.S. Now for the funny story I mentioned. If you haven't seen The Court Jester starring Danny Kaye as the protagonist and Basil Rathbone as the villain, go watch it; it's hilarious, and it deserves to be more widely-known than it is. In the final swordfight between Kaye's character and Rathbone's, the fight ranges all over the castle, and for plot reasons, Kaye's character is alternating between fighting expertly, and making wild, amateurish swings with no skill at all. Thing is, Rathbone was an expert fencer, and helped teach Kaye (who had no fencing experience) how to fight. Now, usually in a swordfight scene, they would substitute a stuntman to double for the actor when the actor's face isn't visible. But in the scenes where Kaye's face is visible and Rathbone's isn't, it's still Basil Rathbone doing the fighting — because Kaye was so inexperienced that he was likely to make mistakes, and Rathbone didn't want anyone less experienced than himself facing an inexperienced actor in a dangerous fight scene. (In fact, if you have a lot of experience with fight choreography, you can probably spot the times when Kaye came very close to actually hitting Rathbone for real, and if Rathbone had been less experienced he might very well have been injured).

I could not successfully search for green-bar; I was turning up a brand of rebar made from fiberglass and various vegan bars and restaurants in different cities... but nothing related to coding or text editing. Do you have a link handy that would explain what the green-bar you're referring to is? Or, failing that, could I ask you for a brief (one or two sentences) explanation/summary? Would be appreciated. (UPDATE: Figured it out, see P.S. below)

BTW, if you've been reading my responses you'll see that I've landed in the same "get rid of tab characters" camp, because while they're nice in theory, they cause pain in practice.

EDIT to add this P.S.: Figured it out. I eventually came across https://elpa.gnu.org/packages/greenbar.html which mentioned the alternating white and green bands of color on old printer paper. I remember those, but I never heard them called "green-bar" which is why I couldn't place the term.

2^27 is 128 megabytes. How much RAM do you want the decompressor to have to allocate for every file? Especially since you can't tell, by looking only at the file size of a compressed file, how many bytes it will decompress to. You could read the file header, but if it's a malicious "zip bomb" type of file, the header could be lying.

I agree that the cond example is committing the sin of trying to align with tabs. I wrote it because I had misunderstood something you were saying. But also, I've personally seen situations like this. I was working in a team whose indentation convention was "one tab character per indent level", and I had written some C# code like this:

    var result = someObject.SomeMethod(param1, param2,
                                       param3, param4);

And then to my horror I noticed that the editor (earlier I said it was VS Code, but thinking back I think it was actually Visual Studio) had produced this monstrosity:

    var result = someObject.SomeMethod(param1, param2,
    <tab><tab><tab><tab><tab><tab><tab>param3, param4);

(Actual number of tabs was different, of course, and I believe it was followed at the end by a space or two, whereas my example happened to line up without needing an extra space character).

I know not to do that. The editor did it anyway, and if I hadn't been paying close attention to whitespace I might not have caught it.

The editor could have been smart enough to parse the code into an AST, notice that param3 and param4 were part of a parameter group, and said "I will use tab characters equal to the indentation of `var result`, then spaces thereafter". It didn't. I had to edit the call to look like this:

    var result = someObject.SomeMethod(
        param1, param2, param3, param4
    );

And then I was safe from the editor trying to align things with tab characters.

If my memory is right about which office I was working in when I saw the editor do that to my code, then it was more than a decade ago, probably around 2010 or 2011. It's possible that the modern version of that editor has improved its handling, and would have correctly aligned param3 with spaces. I haven't checked recently. Maybe at some point I will, and report my findings.

The counterexample I've personally seen is multiple people editing the same file with different editors. The first person has his editor configured to indent with tab characters, and he writes Python code like this:

    def example():
    <tab>if True:
    <tab><tab>do_something()

Now a second guy edits the file. His editor is configured to indent with spaces. He adds `do_something_else()`, and doesn't notice that the code block no longer has a consistent prefix:

    def example():
    <tab>if True:
    <tab><tab>do_something()
            do_something_else()

Notice that because I've used five characters to type `<tab>`, it is already visually obvious that this is incorrectly indented. But that wasn't obvious to guy number two, because this is what he saw on his screen:

    def example():
        if True:
            do_something()
            do_something_else()

The compiler itself isn't per se concerning itself with how different editors have chosen to display tab characters. But in practice, it has to decide "is the do_something_else() line part of the `if True` block, or not?" And so it has to have some opinion on tab characters. Here, that opinion will be "Inconsistent mixing of tabs and spaces in same file, impossible to know programmer intent, refusing to guess; raise TabError exception here".

The use of .editorconfig files should, in theory, solve this. But just yesterday I had another file, thankfully one where whitespace was not significant. The .editorconfig file said "Indent with tab characters", so my editor, when I opened a new line, indented it with tab characters. But the file was actually indented with spaces, and nobody had fixed the .editorconfig file to say "indent with tab characters... except for this file which is indented with spaces".

Editor misconfiguration in both cases. Not strictly the couterexamples you were asking about. But the Python example, although made up, is reflective of actual situations I've seen. People with different editors editing a file, not paying attention to whitespace, and ending up with ambiguity where the width of a tab character would actually make a difference to whether a line visually appears lined up with its indentation block or a different one.

Tabs are great for indentation in theory. In practice, I've personally seen more pain than gain from files that used them.

The other problem I've personally seen with "tabs for indentation, spaces for alignment" is when your editor destroys your tab-space mix when it adjusts the indentation. I've personally seen an editor, I believe VS Code but I don't remember for certain (EDIT: on second thought it was probably Visual Studio, as my memory is placing me in an office I worked in around 2010 or 2011, before VS Code was created), turn a `<tab><tab><sp><sp>...<sp><sp>` line into `<tab><tab><tab><tab>...<tab>` when I intended or dedented it as part of a code block. I.e., I added or removed an `if:`, highlighted a section of code, and pressed the Tab or Shift-Tab shortcuts. And boom, that section of code was no longer in correct "tabs for indentation, spaces for alignment" syntax: the editor had converted a certain number of alignment spaces into tabs.

That was one of the moments that made me move away from tab characters in all circumstances. Because the only way to prevent that sort of thing from happening would be either to fix the editor bug (which I don't have time to do), or to turn on visible whitespace and pay close attention to whitespace every time I make an indentation change, knowing that the editor will sometimes do the wrong thing. I don't want to have to pay close attention to whitespace, and the only way I've found not to have to pay close attention is to either never align things at all, or never use tab characters. Tabs for indentation and spaces for alignment works great in theory, but in practice I have found I can't trust major editors to handle it right.

Agreed... but see my Lisp example in https://news.ycombinator.com/item?id=49593406 for a place where tabs end up unavoidably ambiguous. Because in that `cond` example the tabs look like they're used for indentation, but they're actually being used for alignment, something that falls more under typesetting than under indentation. A smart editor that has read the Lisp code (note that I'm using "read" in its Lisp meaning, i.e. "parsed into a syntax tree") can make those tab characters correctly align the forms the way you'd want them to be aligned for maximum understanding... but really, you would want space characters, not tab characters, in that context.

So even though in most cases those three uses for tabs are independent, in some languages they get muddled. F# is another language where you may want to align text on line two with the middle of line one, e.g. if you write

    let person = { FirstName = "Bill"
                   LastName = "Gates" }

Now, that's considered bad style according to https://learn.microsoft.com/en-us/dotnet/fsharp/style-guide/... — and they're entirely write to recommend against that style — but it's legal syntax. And it's probably why https://learn.microsoft.com/en-us/dotnet/fsharp/style-guide/... forbids tab characters entirely in F# code.

(Those two links point to different anchors in the same document, BTW: the HN link shortening is going to make them look identical until you hover over them).

Got it. You're looking at the problem from the other direction. Yes, tabs are unambiguous if they're the only thing used for indentation. It's when some people use tabs and others use spaces that ambiguity arises.

But there are other cases where the variable-width nature of tabs can create ambiguity all by itself. Take this example from R7RS small:

    (cond ((> 3 3) ’greater)
          ((< 3 3) ’less)
          (else ’equal))

If you write it like this, a smart editor (e.g., Emacs) would probably be able to do the right thing and line up the forms that follow the `cond`:

    (cond ((> 3 3) ’greater)
    <tab>((< 3 3) ’less)
    <tab>(else ’equal))

But to everyone else using a different editor, where the convention is "the tab character just advances to the next multiple of T" (where T is usually 4 or 8), then the second and third lines won't be correctly aligned. And then instead of being able to use the indentation as a visual reference and ignore the parentheses, those people will have to revert to counting parentheses in order to figure out what S-expression each form is part of. Granted, in this simple example that's not hard, but imagine that `cond` nested deep inside a larger expression including a `call/cc` and a `let` or two, rather than being at the top level where it's easy to read.

Here, the ambiguity is because the tab character needs to have a width of six characters in order to align with the text `(cond `. If that had been an `(if ` with just two forms (omitting the `(else 'equal)` case) then the tab would have needed to have a width of four characters. A smart editor that reads the Lisp code and can interpret `<tab>` as meaning "indent this form to align with the form on the line above", but any context that isn't syntax-aware, such as a git diff, will not align those tabs correctly.

Which is why I consider tabs to be ambiguous, because I'm looking at it from the perspective of "how many spaces does this correspond to", and spaces to be unambiguous.

I never had formal training in Latin, just what I've picked up. But grammatically, I would think the second line would translate to "No champion hath the lord", not "no lord hath the champion". Am I misunderstanding the grammatical suffixes here?

That seems like a decent way to handle the mixed-spaces-and-tabs scenario, even between lines: one line starts with `<tab><tab>`, the next line `<tab><tab><sp><sp><sp><sp>`, that's an indent. (Probably someone who likes 4-space indents and 8-space tab characters). Follow that up with `<sp>*12` and that looks like the same indent to someone who uses 4-space tabs, but not the same indent to someone who uses 8-space tabs.

So your proposed prefix-matching rule would correctly flag that scenario, forcing people stop and figure it out.

EDIT to add this P.S.: Actually, my "spaces may follow a tab but tabs may not follow a space" rule, while elegant, is incomplete. Your prefix-matching rule is actually necessary in order to deal with the "two tabs on one line, twelve spaces on the next line" situation. That would be legal under the "spaces may follow a tab but tabs may not follow a space" rule, but it's ambiguous whether that's an indent or a dedent. If tabs mean eight spaces then it's going from 16 to 12, a dedent; if tabs mean four spaces then it's going from 8 to 12, an indent.

What "boneheaded things with tabs" are you referring to? The picture I'm piecing together from your comments suggests that you may use tab characters in a different way than most people seem to, so I'd quite like a further explanation of how you use tab characters and how you expect an editor to handle them.

> Did you mix up your code points there? It's space that's ambiguous, not tab.

Space is always the same width, but tab means a variable number of spaces (usually either 4 or 8, but I've seen 3 before) depending on people's editor configuration.

What makes you say that the space character, U+0020, is ambiguous?

I mean, obviously that one should only appear within Mongolian text and not within indentation.

To state explicitly what should be implicitly obvious, there is no valid reason (that I'm aware of, I welcome any non-facetious correction) to use any character except U+0009 and U+0020 within indentation. Horizontal Record Separator? Zero-width joiner? Language-specific whitespace characters like your example? All make sense within human text (well, maybe not HRS), but in programming, they should be eschewed in favor of the characters that can be typed in every single keyboard layout in the world. Even languages that don't put spaces between words, such as Thai, still put spaces between sentences (or comma phrases) and therefore keep the space bar in their keyboard layout.

And since mixing tabs and spaces (even between lines, where some lines are tab-indented and some are space-indented) creates problems for whitespace-sensitive language, there's a reason why every whitespace-sensitive language I'm aware of has tended to either outright forbid, or at least discourage, U+0009 and its ambiguous meaning (since its meaning isn't clear until you know people's editor configurations, which are usually not available to the validation code running in CI or on other people's machines).

Or you just forbid mixing spaces and tabs in the same indentation sequence, the way most whitespace-sensitive languages seem to end up doing. Or you make a slightly more reasonable rule: spaces may follow tabs, but no tabs may follow a space. That's at least unambiguous.

> And they still can’t count the R’s in strawberry!

Really? I do not have the time to survey the modern LLMs to see if your assertion is correct, but if it is then I'm surprised; I would have thought that that one would have shown up so often in their training data that they would be able to answer that question, even if they would then be unable to (for example) count the R's in raspberry, or in some other word where "count the R's in _____" was not widely found in recent online discussion.

You're running into a cultural difference. The book of Ecclesiastes was written in Hebrew, in a poetical style even though large chunks of it are prose. But if you read other parts of the Bible, such as the book of Psalms (which is entirely poetry, specifically songs, though in many cases we do not know the tune that they were set to), you'll see that Hebrew poetry relied on repetition. For example, here's the King James Version's translation of the famous "to every thing there is a season" passage from chapter 3 of Ecclesiastes, which most translations render as poetry:

> To every thing there is a season, and a time to every purpose under the heaven: a time to be born, and a time to die; a time to plant, and a time to pluck up that which is planted; a time to kill, and a time to heal; a time to break down, and a time to build up; a time to weep, and a time to laugh; a time to mourn, and a time to dance; a time to cast away stones, and a time to gather stones together; a time to embrace, and a time to refrain from embracing; a time to get, and a time to lose; a time to keep, and a time to cast away; a time to rend, and a time to sew; a time to keep silence, and a time to speak; a time to love, and a time to hate; a time of war, and a time of peace.

That could have been said in less than a quarter of the words the author expended on it. But something of the style would have been entirely lost. He wasn't trying to be succinct, he was trying to repeat the same concept over and over until it sinks in.

> ... confused about why I would talk to the human that prompted the AI, rather than the AI that did the work.

One reason is because you can't talk to the AI that did the work, not unless the human who prompted it is able to hand you a file with the complete session and/or context data. (And I'm not at all certain whether Anthropic would allow users to obtain that kind of thing, since it would probably be extremely useful to people trying to distill their models. It's possible they might allow user A to say "Hey, allow user B" (or anyone with the link) "to access my session with GUID ba5eba11-1234-5678-abcd-0decafc0ffee", but I doubt they'd ever allow context data to be downloaded and passed around).

Without the context, you're talking to a different instance of the AI that doesn't have the memory of the instance that ported the code, so the answers you get won't be nearly as useful.

The current "lifetime of the author + X years" rules in effect in the United States still carry the same perverse incentive, though the incentive diminishes rapidly as X gets larger; with the very large value of X in effect today the perverse incentive is so small as to be effectively non-existent, but it's still there in theory.

Personally, I'd prefer a fixed term. I know enough independent authors making a living from selling their books that I'm willing to allow the fixed term to be large, like 50 years from date of completion of the work. (With a good definition of "completion" so someone can't cheat by editing a couple lines per year to keep something copyrighted indefinitely). The simpler the rule is, the easier it is to understand, and the harder it is to cheat it. The more complicated you make a rule, the more loopholes get found.

That was my thought too. Nothing in an ecosystem exists in isolation. Change a single variable, especially a dramatic change like going from 8% to 60% on a single variable, and there will be ripple effects throughout the local ecosystem. The Law of Unintended Consequences is one of those unchangeable, eternal laws that when you forget them, the Gods of the Copybook Headings limp up to explain it once more*.

* https://www.kiplingsociety.co.uk/poem/poems_copybook.htm for anyone who doesn't recognize the reference in that last sentence. Most people will, I hope, but there's always the lucky 10,000. (https://xkcd.com/1053/)

And probably playing Timberborn on a second monitor at the same time.

Oh, sure. What's normal for the bank sure isn't normal for most individuals. I see that someone misread my comment to the point of writing a presumably-angry message that got flagged (so I'm only guessing what it contained), so I wanted to clarify: that sure isn't the daily, or weekly, experience for most people. It's just the bank that sees such sums all the time.

And someone else correctly pointed out that there might indeed be extra scrutiny on such transactions, at a level you might not always see, e.g. when Notch suddenly started receiving tons of money from Minecraft sales, PayPal flagged the account for special attention. But then they figured out it was legitimate, and allowed the money to go through. Personally, having been on the receiving end of credit card fraud (which I caught early enough that the bank refunded me the two fraudulent transactions, a total of $300), I'm glad that "this looks funny" gets flagged. It causes me more inconvenience than it has saved me money: every time I try to buy airline tickets back home (I live and work overseas) it's a large enough transaction that it gets flagged, and I have to call the bank and say "Yes, that large purchase on (airline) is legit, please let it through next time when I try again". But it saves me from being on the hook for $2,500 if someone were to get hold of my CC number again.

The tutorial is the wiki. I used to play Dwarf Fortress back in the 2008-2009 era, and I kept going back to the wiki when I needed to learn something. It was, and still is, comprehensive, containing not just a "getting started for beginners" tutorial page, but also a list of every building and workflow (from ore to metal to swords and armor, from seeds to plants to food and drink...). In-game tutorials are not the only way to learn about a game; a well-maintained wiki (that isn't on wikia, oops sorry they're called fandom dot com there days — but that's a whole other rant) is also an excellent resource. And certain types of games seem to lend themselves to having well-maintained wikis: Dwarf Fortress's wiki is perhaps the best I've ever seen, narrowly beating Minecraft's also-excellent wiki.

I'm sure there is special handling for large sums... but six figures isn't it. Businesses routinely write checks for half a million dollars, two million dollars... it's perfectly normal to see such amounts within the banking world. There might be some extra scrutiny on the back end that you don't see, but since it's well within the realm of normal operations that the bank sees happen every day, it's nothing special.

Now, eight or nine figures, that's probably going to pass the threshold for special attention. As in, you might be required to go to the bank in person with photo ID in order to authorize the transaction, that sort of thing. But under 10 million U.S. dollars? Many businesses will handle those amounts monthly, and the bank is used to seeing them.

Have you also looked at Snap! (https://snap.berkeley.edu/), by any chance? It's basically Scratch but with the artificial limitations removed, e.g. you can pass lists to functions, and blocks (functions) are treated as first-class objects so you can store them in data structures, pass them as input to other functions, and basically teach students proper functional-programming thinking (to find the odd numbers in this list, just pass the "is odd?" block as input to the "filter" block and you're done).

"Not available yet", at least to me, carries the implication that it will, not just might, become available at some point. Probably soon enough that it's worth asking the question again later. Whereas "don't know" suggests that it's not worth asking the question again, because you're probably just going to get "don't know" as the answer. (At least, if "don't know" and "not available yet" are both presented as options).

I added labels (just a piece of paper under some clear tape) saying "CROSSOVER" at both ends of the cables, so that if I ever plugged a crossover cable into a place where I needed a straight-through, the label would be right there next to the plug.

Back in my college days, 169.254.x.y addresses were the bane of my existence, because my job was getting students' computers set up with the brand-new Ethernet connection in their dorm room. This usually required a tech to come out to their room and configure Windows 95 properly, with IP and DHCP instead of Novell Netware and IPX (I don't remember why Netware/IPX was the default on so many Windows 95 installs, but that was definitely what I found most often when I went to look at someone's computer that "wasn't connecting to the Internet".)

Occasionally we had someone who knew what they were doing and had their Windows 95 settings set up correctly, and then all we had to do was activate their room's Ethernet port and add their MAC address to the DHCP server's list of authorized MACs. But most often I or one of the other techs had to head down to the person's dorm room and set up their computer's network settings correctly before it would work. Once the 169.254 address was replaced by 192.168, my job was finally done. But there were times when that took some doing.

https://en.wikipedia.org/wiki/Medium-dependent_interface#Aut... is what allowed the switchover to happen automatically, and it got folded into the 1000BASE-T standard. So yes, crossover cables are no longer required because the two Ethernet adapters at either end can negotiate between them to have one of them "flip" the meaning of its Receive (RX) and Transmit (TX) pins.

That used to require a crossover cable; I've done precisely that (with a crossover cable) back before https://en.wikipedia.org/wiki/Medium-dependent_interface#Aut... became widespread. With a straight-through cable, you'd be connecting the Transmit (TX) pin of one adapter to the TX pin of the other one, and the Receive (RX) pin of one to the RX pin of the other — and neither device would "hear" the messages the other one was sending. A crossover cable flipped those wires, so each device's TX pin was connected to the RX pin on the other end, and both devices could "hear" each other.

But with auto MDI-X, each device would notice "hey, I'm sending but not receiving anything," and would try flipping its Transmit and Receive functions around (transmitting on the RX pin and receiving on the TX pin). Since each device waited a random period before doing that, it was very unlikely (nigh-impossible) that they would both flip at the exact same moment. And if they did, the second interval would most likely not be identical either.

I'm simplifying a bit in the explanation above, but that's the broad strokes. And that's how my carefully-labeled crossover cables started gathering dust. (And then I realized "hey wait, I can just use these as normal cables now", and pulled them back out of storage and mixed them with my normal patch cables).

I must admit to occasionally rearranging words or choosing different synonyms to make a column of spaces line up in a monospaced paragraph, so that you could draw a straight line down one column the screen without passing through any letters or punctuation. Or making a diagonal line of spaces, top-left to bottom-right.

I usually only did that when the text already was close to lining up that way, though.