Hacker Newsnew | past | comments | ask | show | jobs | submit | salsa_catsup's commentslogin

The TNG episode "The Inner Light" is profound. I didn't expect it in Star Trek.

A really beautiful episode and apparently one of his favourites. That moment at the end where he realises what's happening - "Oh, it's me! I'm the one it finds!" - so touching and such a wonderful performance.

I think, with this many decades of hindsight, it is not unfair to claim The Inner Light is TNG's City on the Edge of Forever.

It's every performer in the episode hitting on all cylinders on a script that is doing what science fiction is for.

ETA: Having poked at it a bit, I have just learned that Morgan Gendel and Peter Allen Fields shared a Hugo Award for Best Dramatic Presentation for that script... The first time a Star Trek script won a Hugo since the previous award to Harlan Ellison for the script for City on the Edge of Forever. Nice to know there's a semi-objective metric by which the episodes are already rated as equivalently impactful.


I learned today that the son in that episode is Patrick Stewart's son.

It's a wonderful episode, always in the Top 10.

I thought it was a lovely version of an ancient idea: https://en.wikipedia.org/wiki/Zhuangzi_(book)#%22The_Butterf...


Yes it's my favourite too. For some reason I had set the VCR when it first aired and I'm really happy I did.

That and Frame of Mind (S06 E21) are my go-to episodes. On the surface, they have similar premises, but the resulting emotions are completely different. Both explore disorientation as fear, but one does it over half a lifetime, while the other is a few days.

Richard Riehle, the friend in that episode passed on quite recently as well. Was also in Office Space and a fantastic satire about scope creep in projects for the military, of all things.

It's amazing with all these GPUs they still can't apparently simulate biochemistry enough to search for drugs via simulation. I wonder if that is theoretically possible or if it's one of these things were we'd need more chips than there are electrons in the universe...


Even with the most advanced GPU-accelerated simulation packages, if you want to get to molecular-level detail and nanosecond-level dynamics (both of which are required for drug interaction), the compute time required for an accurate simulation of even a microscopic volume (say a cubic micron) is on the order of the heat death of the Sun. We’re so far from this it’s laughable. The best simulator is still the real atoms of the real world - we just need more reliable ways to control and measure them.


I don't understand the superdeterminism idea. Wasn’t that already the classical/Newtonian view - that everything was predetermined, a universe of billiard balls following their destiny exactly?


Newtonian is just plain determinism. One thing causes another, but does not imply things are fixed in any particular way.

Superdeterminism implies that things are fixed in advance in such a way that the things we "choose" to measure always looks as if there are no local hidden variables (e.g. Bell's inequality) even though there are.


You can imagine the general idea by imagining the state space of a bunch of billiard balls: their position and velocity in a 6D space.

This is a metaphor and not the state or experiment that superdeterminism seeks to answer. I am also speaking well outside the areas of physics I was trained in. So huge grain of salt.

In classical determinism, the trajectories of all billard balls can be derived precisely from their initial conditions. Due to sensitivity to initial conditions and our ability to know them precisely, we can see chaotic mixing behavior where the trajectory of even two billiard balls that start at nearly the same place become more and more uncorrelated as time goes on as they bounce around and into each other. One expects that many accessible observables and functions loose detectable correlations as this billiard ball universe goes on and the billiard balls go on to roughly fill the full 6D state space up to conservation of momentum.

Now imagine the weirder scenario, that there exists some function and statistical comparison you can make between state variables from sets of billiard balls. Although these state variables themselves seem uncorrelated after enough time has passed, there are these properties that always hold with perfect correlation even after infinite chaotic time bouncing around. The points in state space that the balls cover is restricted to some manifold where these statistical properties are true when checked. The system cannot evolve in a way where those correlations of bulk quantities would disappear.

In this toy metaphor it’s not so horrifically odd. Superdetermism gets more flak because: (i) the state space and property in question is so much weirder and more complicated than the kinematic example, the correlations are between objects that measure and the objects being measured! (ii) if these properties are always true under any check we can make there is no way to falsify. Then it doesn’t matter if the behavior is from some unimaginable underlying universal state space geometry or local quantum effects. This same argument could also be applied more generally and inappropriately to reduce any experiment to “that’s just the way the structure of the universe is”.


No, they are completely different. Determinism is the idea that if you have a perfect snapshot of the universe at one time, you could run that snapshot forwards or backwards using the laws of physics and have a complete history of the entire universe. It's a valid scientist idea, but Bell's Inequality experiments pretty much prove it false by showing that either realism or locality is false, and you kind of need both to have determinism.

Meanwhile, superdeterminism is the idea that you can still have realism and locality by claiming that Bell's Inequality experiments are invalid because the universe could somehow "know" you are performing a Bell's Inequality experiment and rig it to get the "wrong" answer. Superdeterminism is equivalent to saying that we can't prove smoking causes lung cancer, because the universe might rig any science experiments to make it look like smoking causes cancer. Anytime you ask why the universe would do that or how you can prove anything in such a universe, they shrug their shoulders. It's a completely BS idea that got traction because specific people pushed it and others don't understand quantum physics enough to know how unserious of an idea it is.


It's quite deeply weird. It's basically looking at the seemingly impossible correlations that occur in quantum mechanics and saying that they happen because the decision about what to measure is correlated with the state of the system somehow (Bell's inequality assumes that these are independent). This is very strange in a universe where we apparently could base that decision on many different seemingly unrelated processes. (including processes that have been causally seperated for near the lifetime of the universe, e.g. by choosing the measurements based on noise in the CMB).


If this is possible, my career as a programmer is now trash. F--- AI.


Just switch from a programmer to a software developer. Don’t compete with AI, use it.


Yes, all I have to do is show them all my intellectual property and let them upload it to their servers, and they will "help" me, and then mysteriously be able to tell others how to duplicate two years of my work in 45 minutes.


Does this mean I can write shaders in Rust for use with WGPU or Vulkan?


WGPU/Vulkan don't work with PTX shaders by default, additional translation would be needed.

On a side note, Vulkan has extension to launch CUDA kernels: https://docs.vulkan.org/refpages/latest/refpages/source/VK_N...


You have been able to for a while with rust-gpu https://github.com/Rust-GPU/rust-gpu.


For compute shaders, you can already do this with CubeCL: https://github.com/tracel-ai/cubecl

You write kernels in a Rust DSL using #[cube], it supports WebGPU through WGSL and Vulkan through SPIR-V, along with CUDA, AMD via ROCm, and Metal. (disclosure: I am a contributor)


The way I understood it, rust would become an option next to Vulkan, WGPU (and opengl etc?).

But only for compute tasks. So, practically an alternative language to write compute shaders in.


Is this so central, that it justifies the use of a single ascii char? Instead of, say, `Never`?


It's not really like there's a budget for it, and "!" is already a type people have seen in the return position of extremely common macros (panic!, todo!, etc.), functions (std::process::exit, etc.), and expressions (return, break, continue).

The question is more whether it's unambiguous (it is), and whether there's something else you would rather use it for (there isn't).


It results in different behavior in the compiler. You don't have to check the return type of a function in which you call a function return never. Using a different symbol gives you a hint why the code works, if you used `Never` you'd have to KNOW it works differently.


It has been in the language for fourteen years. What would be the purpose of changing it? And what else would ! in the type position signify?


I can see that you’ve never designed a language. The design and implementation of Rust took many years. Over that time people’s ideas and priorities changed. Even the people changed. In the early days of the language design sigils were very heavily used throughout the language. Even the language keywords were deliberately shortened as much as possible (consider ”fn“ and ”ret“, for example). Most of the sigils were eventually replaced with traits, but not all of them. ”!“ is one that survived.


Energy density of liquid fuel, with efficiency of electric motor => fuel cells. ? I guess they've given up on those for some reason.


I should have done this with my 2020 Intel Macbook Pro. Now it's basically unusable and spins rainbow wheels constantly, because the OS is apparently garbage for an Intel system.


I had the same experience as you. I bought a super-fast 10-core iMac 27” with 72 GB of RAM in 2020. It ran beautifully until the moment I “upgraded” to Tahoe, when it instantly became unusably slow.

This cost me half a day wiping the disk, restoring the original OS, and then carefully upgrading back to Sequoia. Now it works well again, but I am counting the days to when Linux is the only way to continue using this great piece of hardware.

Another anecdote: a few years ago I was offered a shiny new never-before-used iPad for free by a client (a telco). There was only one catch, I was told: it was a few generations old. It had sat in its box on a shelf unopened for several years. I thought it might be useful at least as an e-reader, but I soon realized why it was now useless: I could not find a single app in the App Store that would install on it because every app required a “newer OS” (which wasn’t available). Most websites also refused to talk to its old (non-upgradable) web browser. Well played, Apple.


Is Racket the Lisp where I wanted to write keywords like `foo:` or `:foo`, but they went with something like `'#:foo`, which ruined keyword syntax for me?


Fear not, you can make `#%top` and `#:app` rewrite `foo:` to `#:foo`.

FWIW choosing `#:foo` over, say, `foo:` was due to backwards compatibility. In Scheme and Racket `foo:` is a legal identifier, so there might have been programs that stopped working, if `foo:` suddenly was a keyword.


I don't know about Racket, but I do know Guile does that and I kind of prefer it as a way to reduce syntax (because the number sign is syntax already for most Lisps as the marker for a vector, and it's also used to bring functions into the symbol namespace in a Lisp-2) by freeing the colon.


Do they do something neat with the colon? I do prefer the shorter keyword syntax, at least in Clojure because of how common they are.

Clojure tends to use them very heavily though, and last I looked it seemed like Racket used more lists (as a matter of community preference, not forced by the language).


A colon in Guile is just a regular character. For example:

  (define abc:def 3)
  (define :ghi 4)
  (* abc:def :ghi) ; => 12
In Common Lisp a colon is a package separator, with an optional package which defaults to the keyword package if not given.

  (eq :foo keyword:foo) ; => t
I don't know about Clojure or Racket because I don't know much about Clojure or Racket. I know Clojure differs in various ways where syntax is concerned to Common Lisp or Scheme (I do like the idea of using square brackets to visually indicate that a collection of atoms may not represent a function call, I hate the idea of the comma being a whitespace character) and that Racket has different languages (though I don't know what that means in practise).

That said, I don't quite know what to think of your third sentence:

> Clojure tends to use them very heavily though, and last I looked it seemed like Racket used more lists

I suppose them refers to keywords? But Racket uses more lists compared to how much Clojure uses keywords? As lists have more uses than keywords that seems likely, though as I said: I don't know anything about Clojure or Racket apart from Racket once being called PLT Scheme.


Guile keywords use the same #:foo syntax as Racket. The reader can also accept :foo or foo: notation.

https://doc.guix.gnu.org/guile/latest/en/html_node/Keyword-R...


Racket's lineage in Scheme is probably the reason it prefers lists over pretty much every other datastructure


Scheme has had all major data structures for quite some years now.


Notice that Racket now supports "tree lists".

https://docs.racket-lang.org/reference/treelist.html


Twitter has videos of people getting crushed (probably dead) by falling facade as they try to exit the building. I guess it's still considered smart to try to exit your building in a quake? Maybe it depends on the building.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: