Twisol

If there are two ways to say something, then people will find ways to make their choice of method into speech as well.

To me and my style of coding, there's a difference of intent between the two. A ternary connotes a mere computation, something that should have no side-effects. A conditional connotes a procedure; the arms of the conditional might be expected to have side-effects. (And the case of `if (_) return` or similar are pure control flow guards; they neither compute a value nor perform a procedure as such.)

It's not just about where the symbols go on the screen.

And you do not, under any circumstances, "gotta hand it to them".

(highly relevant @dril quotes, for those out of the loop)

I think the "singularity at the beginning of time" being referenced here is the one postulated before / at the instant of the Big Bang.

I had this thought too. My best guess is that it's down to the length of the urethra. Have you ever lifted liquid out of a glass using a straw, by capping the upper end of the straw with a finger? That liquid wants to fall, but that causes the gas volume above the liquid to expand, so vacuum pressure pulls the water upward, counteracting gravity, and also pulls your finger into the straw slightly. I imagine that, for a longer column of fluid, that vacuum pressure is at least a contributing factor to the unpleasant feeling. (Not to mention that, when urinating, that column of liquid is already moving rapidly!)

Except for the gross factor? The author seems pretty clear that, yes, you can:

> For those of you asking, what are my options for diving in a dry suit? Well… you can just hold it (again, if you have a bladder of steel), nappies/diapers, the p-valve, or just pee in the suit (which is gross and defeats the whole purpose of the dry suit, right?).

The "purpose of the dry suit" is to keep you dry. If you're literally wetting yourself, and with a fluid that is rather more chemically offensive than water, then you're probably going to have a bad time. (I don't know how temperature-controlled dry suits are, but you lose heat a lot more easily through contact with a liquid (that's what sweat is for!), so the urine puddle probably makes heat retention harder, too.)

Just to corroborate as a native English speaker, yes, in my experience the "the" would only be left off in quite informal registers or in haste.

(As an ex-JPLer,) you would be very surprised how many internal tools this decade have been web-stack. Flight systems are one thing, but you need plenty of ground systems to support the effective use of assets in flight, and there's no reason to avoid one of the biggest UI platforms out there.

> There are generators for other critical servers, and in particular the DSN operations have been moved temporarily to another location so they could continue.

That's really good to hear. The DSN is a really, really important asset (not that everything else at JPL isn't, but!), so I'm glad they're not totally coupled to the physical JPL location.

Well, most of the actual sensors are in space ;) but yes, telemetry collected via the DSN gets routed through JPL first.

Also, in addition to the SSD website linked upthread, the NAIF site [0] (where the SPICE library and kernels can be downloaded) also seems to be down. It would not surprise me in any way if some of these facilities are hosted on-prem and are in a power-down state due to the fires.

(Speaking of the DSN, their website [1] is also down.)

[0] https://naif.jpl.nasa.gov/naif/toolkit.html

[1] https://deepspace.jpl.nasa.gov/

The Horizons website at that domain [0] (which was on HN recently) seems to be down for me as well. FWIW, that's not "the" JPL website though, that's just one of many JPL-hosted websites.

[0] https://ssd.jpl.nasa.gov/horizons/

As an ex-JPLer, it would not have surprised me for this to be the case even in the early 2010s.

If I'm not mistaken, that's Ludwig! A friend of mine is a big fan; I was surprised to see him in this game("").

I agree with you on basically all points. But to play devil's advocate, I've often found myself doing something like structured editing when intentionally, carefully refactoring existing code. In those instances, it really matters to me that the programs at the start and at the end are equivalent, or at least equivalent up to certain semantic conditions (for instance: preconditions, things assumed by the domain, or cases not meant to be handled in the subject code). Since making a complex refactor in one step doesn't make me very confident that I got it right, I usually carefully perform a series of small transformations such that, at every step, I have something that manifestly behaves the same as the program before that step.

This seems sufficiently like the structured programming model (small edits forming a path of "valid" programs from start to finish) that I wonder if something similar to structured programming might be genuinely useful in this niche. That said, these refactors aren't simple atomic tree edits; they're more like a small cluster of tree edits that together preserve meaning. So there's a difference in content, even if the "small edits that form a path through programs with X property" mental model is the same.

I love that the primary interface to Horizons is still via Telnet ^_^ I hope they keep that interface forever.

> I suppose you could reduce it further by saying that you want the proof of "A or B". Assuming both true, it suffices to either get a proof for A or for B

Yes, absolutely :) I thought about this framing too, but figured the one I gave above might be more immediately convincing.

Thanks for taking a stab at it! I think I understand the angle you're attempting to take. May I offer a relatively contrived counterexample to poke at this a little more deeply?

Suppose I have a proposition that says, roughly, "if A and B and C then contradiction". Furthermore, suppose that A and B together are already contradictory, and B and C together are also already contradictory.

Now I can construct two proofs, one in which I use A and B (but not C) to yield the desired result, and another in which I use B and C (but not A).

In what way can we say that these two proofs are essentially the same? It appears that each uses potentially rather distinct information in order to derive the expected contradiction; it isn't clear how to go from a proof that avoids A to a proof that avoids C in a smooth way.

It really is! I got very, very lucky for the area I'm in, believe me. I'm not moving out until I'm out of the area for good.

The path example is extremely fertile ground for this kind of discussion! It is definitely true that both paths encode the information that one's house is connected to the local store. But is that all they encode? Homotopy theory is all about the different paths between two points, and it tells us some quite interesting things! In particular, if you have two paths from point A to point B, you can ask: can you smoothly animate an image of the first path into an image of the second, such that every still frame in-between is also a legitimate path? (If you can't, that tells you that there's some form of hole in between them!)

In the house/store example, a path is also a witness to the fact that, if you perform a road closure anywhere not on the path, then connectivity is preserved. Simply stating that the two points are connected doesn't tell you whether it's safe to close a road! Moreover, taking the two paths together tells you that performing a single road closure that only affects one of the paths will still leave a route you can take.

In both examples, if the paths were logically interchangeable, you wouldn't be able to get more information out of the both of them than you could from just one. But because they aren't equivalent -- because each contains some information that the other does not -- we can deduce more from both together than from either individually.

That's a fair response; thanks for taking the time.

I was primarily reacting to this part of your message...

> I'd argue that two correct proofs are always the same.

...with emphasis on the "always". To my eyes, a proof is any object that witnesses the truth of a proposition. The proof can be more than a witness, but to be called a proof, it must do at least that much.

To say that "two correct proofs are always the same" is, to me, to say that proofs can be no more than witnesses of the proposition; to be the same means to be indistinguishable. My argument is that two correct proofs may be distinct in useful ways.

I suppose this discussion depends on what "same" means ("depends on what the meaning of the word 'is' is", heh). Do you mean something other than what I mean? Your use of "logically equivalent" is probably telling -- so, two proofs should have the same deductive power? We often speak of propositions this way, but I'm not sure how to understand that notion on proofs. Terence Tao gives some possible notions of proof equivalence in a comment on the OP [0]; you might enjoy reading them and considering which is closest to your intuitive idea of equivalence :)

[0]: https://gowers.wordpress.com/2007/10/04/when-are-two-proofs-...

You can do that, yes. My argument is that you don't have to do that -- you can prove asymptotics or stability after the fact, having previously only given an algorithm as a proof of sortability.

Putting these properties in the specification assumes you already know (or suspect) that your algorithm has these properties; then you are simply verifying what you knew. If you develop your algorithm first, then want to analyze it in terms of (say) asymptotics, then not only is it far too late to change the type, you don't even know what the asymptotics are yet. You'd still like to treat the algorithm formally in order to determine those asymptotics, but since you don't know them yet, the algorithm can't inhabit a type that states those asymptotics outright.

> An algorithm is not a proof.

That is an opinion that many do not share. FWIW, I framed my response as an opinion; you gave yours as a blanket statement. It is not wrong to treat algorithms as valid proofs.

In a dependent type theory, propositions are represented as types; the proposition that "all lists can be sorted" could be represented represented as the type "forall (t : Type) -> (le : Ordered t) -> forall (xs : List t) -> exists (ys : List t). (Increasing le ys, PermutationOf xs ys)". A proof of this proposition is exactly a program (algorithm) with that type; the sorted list is the `ys` component of the returned existential product. Yet the inhabitants of this type are not graded by asymptotics or stability; any sorting algorithm will do.

In a setting where inhabitants of the above type are distinguishable, you could then write proofs of asymptotics or stability against individual algorithms. That is, the proofs of the sorting proposition are themselves the subjects of subsequent propositions and proofs thereof.

I disagree with this on two points.

First, oftentimes the interest in proving long-standing, difficult mathematical problems is because we hope a proof will demonstrate new tools for tackling similar problems. In that sense, the exact content of a proof is quite important. Not to mention, there is value in having multiple proofs that each demonstrate quite different toolkits. Mere truth is not often the most important thing -- after all, mathematicians can (and do!) take certain propositions as premises of downstream work. If we discover a proof for one of those premises, that just means we can drop the premise from downstream work. Not having a proof doesn't block us from making use of the proposition anyway.

Second, sometimes the content of the proof is relevant formally. A sibling comment gave an example in terms of paths between two points; it is often the case that you care not only that the points are merely connected, but you also have a preference for which path is taken. Or, you can do an analysis of the paths themselves, and determine their length or average furthest distance from the nearest McDonalds. A path is "just" a proof of connectivity, but the individual paths can be quite distinct when studied themselves. Less abstractly, a constructive proof will yield an algorithm that can be performed, and we know quite well that the variety of sorting algorithms (that "merely" prove that "all lists are sortable") actually vary in quite important ways, including asymptotics and stability.

My studio apartment in California is $1500/month. At the same price, I would be in a 3-room Tokyo flat yesterday!

I, uh, cannot in good conscience call Java's annotation processing APIs "clean" or "clear"; the way they interact with the multi-round processing model, and in particular make it extremely hard to build well-behaved processors that can cope with parts of the compile-time code graph not existing until later rounds, has baffled me for a long time.

Despite their definite flaws, though, I have to agree: compile-time code generation via annotation processing is something I think we should do more of (and invest more time into better tools for it).

Thanks for the correction! TIL :)

Different languages handle this in different ways, but the most common seems to be adding access controls to the class itself, rather than just its members.

For instance, Java lets you say "public class" for a class visible outside its package, and just "class" otherwise. And if you're using Java 11 modules (nobody is though :( ), you can choose which packages are exported to consumers of your module.

In a similar vein, Rust has a `pub` access control that can be applied to modules, types, functions, and so on. A `pub` symbol is accessible outside the current crate; non-pub symbols are only accessible within one crate.

Of course, lots of languages don't have anything like this. The biggest offender is probably C++, although once its own version of modules is widely supported, we'll be able to control access somewhat like Java modules and Rust crates, with "partitions" serving the role of a (flattened) internal package hierarchy. Right now, if you do shared libraries, you can tightly control what the linker exports as a global symbol, and therefore control what users of your shared library can depend on -- `-fvisibility=hidden` will be your best friend!

I had the extreme pleasure of seeing Bruce Waggoner of the Voyager team give a keynote at !!Con just last month. The recording landed on YouTube just a couple days ago, so this is great timing: https://www.youtube.com/watch?v=dF_9YcehCZo

I don't really know -- I'm a user, not an analyst. But the two things that drew me in were:

1. There's no global firehose that your posts automatically get dropped into. I'm a generally shy person, and one of my particularities is that I don't want my content (or, well, existence) to be pushed at somebody who didn't specifically ask for it. The number of social media platforms that meet this criterion is vanishingly small, because everybody and their uncle wants an Algorithm (tm). Mastodon instances also have a default instance firehose; I'm told people don't really look at that, but the fact that it's there at all makes me overthink posting, and I end up not posting at all.

Instead of a global firehose, you can add free-form tags to your post that act like much, much more localized streams of posts. You don't have to use tags at all; and you can also use completely nonsense tags that are more like footnotes, in a very Tumblr style that I enjoy.

2. The UI is wider than Twitter, or Facebook, or Mastodon. It feels like it's more inviting to longer-form content, and while there's plenty of short blurbs and memes to be found, there's just a much higher proportion of blog-style content.

Also, the way reposting and commenting interact is just way better IMO. If you repost something, the comments on the original post are visible above the comments on your repost, and that makes the whole chain of interactions feel more cohesive. In contrast, quote-retweeting on Twitter creates entirely separate bubbles of discussion (often at odds with each other). And on Cohost, while you can create a repost chain to make a kind of "thread" equivalent, the UI naturally discourages it in favor of just making a single long-form post.

> I don't really understand why anyone would use an "alternative" microblogging platform

> just go to the cesspool of

Cohost didn't feel like a cesspool to me. That's a pretty darn strong differentiator.

There are other UX differentiators for me, but it's all subjective. Cohost didn't feel as "cramped" as the others. The others really put the focus on the "micro" in "microblogging", even if technically they (now) allow for longer-form posts. The culture just isn't there for it.

Ah, that totally makes sense! No worries :)