If you can't tell the difference between computer science and software engineering, then at least one of those worlds contains none of your feet.
107 karma · joined June 19, 2021
Of course, I make no claims about how far in the long one will need to look to see that play out.
So, using those relativistic definitions for energy and momentum, I think you're exactly right, at least up to the part about "since the final object is at rest". However:
- As I understand it, invariant mass, aka "rest mass" (which is equivalent to "rest energy", aka "rest mass energy"), is invariant, and it's the same before and after the collision, so the kinetic energy doesn't get "converted into rest mass energy". Rather, if the final object is at rest, then all of its kinetic energy has been radiated away; kinetic energy (E_K) is is total energy (E) minus rest energy (E_0 = mc^2, where m is invariant mass)
- I have no idea whether gravitational waves are the only way for the kinetic energy to be radiated away. I imagine other forms of energy could also be emitted.
- In order to know that the final object is at rest/has no kinetic energy (in an inertial frame), I worry that we might need to have specified more in the original question. In particular, I don't know how to handle spin. (I know that black holes have some concept of "spin", but I don't know if this is like rotational spin, or more like quantum mechanical spin, or something else, and I don't know how it figures into the black holes' total energy.) If we change the original question to say that the black holes are not spinning, then I think we can ignore this (since the collision is head-on).
[1]: https://en.wikipedia.org/wiki/Mass_in_special_relativity#Rel...
To reiterate, I'm not a physicist. I may be off base here, but that's my understanding.
This isn't just a style thing, either; there are consequences. REPL-driven development loses a lot of its slickness when some expressions can only be eval'd in a special context.
Also, what am I supposed to do if two different parts of my program want to use Clolog? If I'm using Clolog, and one of my dependencies is using it too, will we end up trashing each other's global state? (The case of external dependencies is just an example. Let's say I have an application that sets up the Clolog state and runs a query. Part of the setup involves calls to other parts of my application. At the time the code was written, those other parts didn't use Clolog, but now they do, and there's a bug, because those other parts are trashing the Clolog state that their caller had set up, before it runs its query.) Of course, you could get around this by adding something like a dynamically bound variable that points to the instance of state to use, but at that point you're jumping through hoops to support a subpar (stateful) paradigm that Clojure developers expect to be free of.
I get that "sort of" was an attempt to hedge, but really, this isn't even close. Homoiconicity here would be if all javascript source files were valid JSON documents. A weaker version would be if it were common to use JSON to represent an arbitrary javascript program, but I've never heard of that, either. (For a good explanation of this weaker sense of homoiconicity, this stackoverflow page [1] is pretty good.)
[1]: https://stackoverflow.com/questions/31733766/in-what-sense-a...
To use Clojure as an example of a language that is homoiconic, you can take any Clojure source file, send it to an EDN parser (EDN being Clojure's equivalent of JSON), and not only will parsing succeed, but the result will be a complete representation of the program (you could execute it if you wanted to). In contrast, if you try to send JS to a JSON parser, you'll get an error as soon as it hits a function definition, or a for loop, or an operator, or whatever.
Tabs are oriented along a horizontal axis; as with hsplits, you move through them by moving the focus left and right. Stacks are oriented along a vertical axis; as with vsplits, you move through them by moving the focus up and down. The reason you want the ability to choose between the two options is (to continue parent's quote of GP) "to allow you to flip back and forth between [relevant pairs of] windows with just a couple keys". To reuse (and better explain) the example from GP:
[ _ _ Tabbed Browsers _ _ ]
-------------------------------------
| emacs | Tabbed Terms |
| | |
| | |
| | |
| | |
So, the choice between stacking and tabbed matters. I'm not saying you can't have this choice in a scrolling tiling window manager. (Does Niri have stacking and tabbed containers? I hope so.) I'm also not saying that you or anyone else has to want to make that choice (it's okay to prefer a "simpler model" where you scroll around to get to all of your windows). What I am saying is that the author of TFA thinks that with traditional tiling window managers like sway, you can't have "very many windows open" without "constantly swapping between fullscreen and non-fullscreen views and running out of workspaces", and this is simply not true. (Perhaps worse, in the next sentence, they dismiss the solution out of hand by saying "don't get me started" on nested tabbed/stacking containers, because they're "the least ergonomic Band-Aid™ for the space issue I've ever seen", but it seems to me that declining to give a full treatment to that subject may actually be why the author's never seen it done ergonomically. But now I'm speculating.)
------
BTW, since anyone still reading is probably a completist: at the top, I said that directionality was "one of the" important differences between tabbed and stacking containers. The other one is how much space their title-bar areas take up vs. how many children they have. Stacking containers are O(n) in the number of children; tabbed containers are O(1). Interestingly, combining this with the directionality property yields an interesting result: in sway, there is a sort of asymmetry between the horizontal and vertical dimensions.
> If you don't find yourself constantly swapping between fullscreen and non-fullscreen views and running out of workspaces, you don't have very many windows open. Don't even get me started on tabbed/stacked layouts with nested containers, the least ergonomic Band-Aid™ for the space issue I've ever seen.
On the contrary: I think this author really ought to get started on tabbed/stacking layouts! Constantly swapping between fullscreen and non-fullscreen views, like running out of workspaces, definitely sounds like an antipattern to me. I don't believe that the number of windows is the problem here.
If I'm deep into something, I might have 10 or more windows open, all on one workspace, on a 13" 1080p laptop panel. Of course, not all of the windows are visible at once. A common pattern for me is to have most of my screen taken up by a container split "horizontally" (meaning into a left side and a right side), where each side can be a tabbed container containing several windows. For example, I often have Emacs on the left, and several tabbed terminals (including man pages) on the right. Maybe some of those terminal tabs on the right are split "vertically" into a top and a bottom terminal (e.g. for a shell prompt on top and man page on bottom). Outside of this big left-right split container, which fills almost the whole screen when it's visible, I'll usually have some browser windows open. If it's just one browser window, I'll put it and the big-left-right-split (BLRS) in a stacking container. This way, you can think of the browser as being "above" the BLRS, and you can get there and back by moving the focus up and down again. It's like each stacked item (the browser and the BLRS) gets its own workspace, in that they each take up nearly the full screen when visible, but actually they're both on the same workspace, and the only cost is the loss of one title-bar's height of screen space. Then, if I want more browser windows, I can split the existing one into its own tabbed container. (I use both WM tabs and browser tabs, just like I used to use multiple browser windows on one workspace with Gnome.)
Basically, as my number of windows grows, things become (slightly!) more nested, rather than being ejected into surrounding workspaces. The trick to making this ergonomic is to choose what to stack vs tab so as to allow you to flip back and forth between (at least) any two windows with just a couple keys. (I also have two keybindings to split a container and immediately make it stacking or tabbed, and also two keybindings to focus parent-wards/child-wards. Then, you can easily jump from a window in the middle of a tabbed container on the right of the screen to the window on the left half of the screen---you just focus parent-wards then left (two keys). To get back, just focus right (one key).)
I should also add that I haven't really seen any problems with apps behaving badly when being resized, including Firefox. Maybe that's because my workflow mostly looks and feels like "slots" of a few different sizes (roughly full screen, half screen, quarter screen), and adding new windows to, or moving windows between, these slots is never going to change the size of the slots or the windows displayed in them. In fact, with traditional floating window managers, when has resizing a Firefox window ever caused me to lose my place in the page? Only when I make it super unusably narrow, or short, or both, and then expand it again. This is what would happen if you open a bunch of windows all in horizontal and/or vertical splits, with no stacking or tabbed containers! But why would you do that?
https://github.com/futo-org/Grayjay.Desktop/blob/373cd8448cb...
[1]: https://en.m.wikipedia.org/wiki/Clojure#Extensible_Data_Nota...
In fact, there doesn't seem to be a spec or standard for it, outside of the de facto standard used by Clojure and the programs in its orbit. I guess nobody's bothered to write a standard, because the people who are already using EDN are doing fine without one, and the people who aren't either don't know what it is or don't see its value.
Are you saying DFU is not useful without an MMU/MPU? Why would that be?
Is this attack actually in anybody's threat model?
GP isn't asking about the "endgame" as in "for what purpose did this author do this thing?". It was "endgame" as in "how is the story of LLMs going to end up?".
It could be "just" more cat and mouse, like you both mentioned. But a sibling comment talks about the possibility for architectural changes, and I'm reminded of a comment [1] from the other week by inawarminister ...
[1]: https://news.ycombinator.com/item?id=38123310
I think it would be very interesting to see something that works like an LLM but where instead of consuming and producing natural language, it operates on something like Clojure/EDN.
The rolling hitch [1] is a slight variation that works great as a drop-in replacement. For attaching a rope to a pole, I go as far down this list as is feasible and/or necessary:
- two half hitches [2] (this is actually just a clove-hitch around the standing end)
- round turn and two half hitches [3] (like the above, but a little more secure and it takes the load while you tie it)
- anchor hitch [4] (even more secure, but harder to tie under load)
[1]: https://www.animatedknots.com/rolling-hitch-knot
[2]: https://www.animatedknots.com/two-half-hitches-knot
[3]: https://www.animatedknots.com/round-turn-two-half-hitches-kn...
When I switched from Debian to NixOS a few years ago, I installed it on a separate subvolume, and it ended up taking almost exactly as much space as Debian did (about 12 GiB with gnome and everything else). And really, what would you expect? It's nearly all the same code, just organized differently in the filesystem.
P.S., you can check the store usage of the current system profile with `nix path-info -Sh /run/current-system`.
I'm definitely going to use this, and I think there's a more general statement: "Every time software is used to fix a problem in a lower layer (which may also be software), a gremlin is born."
user> (require '[rum.core :as rum]
'[hiccup.core :as hiccup])
nil
user> (rum/render-static-markup [:p "<script>alert('you have been pwned')</script>"])
"<p><script>alert('you have been pwned')</script></p>"
user> (hiccup/html [:p "<script>alert('you have been pwned')</script>"])
"<p><script>alert('you have been pwned')</script></p>"