HN user

davidthewatson

321 karma
Posts16
Comments249
View on HN

Does anyone know Rosen's role in Sega Saturn? I owned one and loved it so much. It was ahead of its time, given few mastered its design intricacies while those who did are legendary.

I was thinking the same thing.

Then it occurred to me:

what if the designer - writer sought to draw my attention by making me hyperfocus on the text?

That is, musicians do it with dynamics, architects do it with compression and expansion, writers do it with words, but do designers do it with the most dynamic, infinitely extensible medium on the planet that combines all of our senses and perceptions at once?

Maybe that was the point here, even if it was unintentional, bordering on magic?

Define "AI therapy". AFAICT, it's undefined in the Illinois governor's statement. So, in the immortal words of Zach de la Rocha, "What is IT?" What is IT? I'm using AI to help with conversations to not cure, but coach diabetic patients. Does this law effect me and my clients? If so, how?

If so, that's interesting.

Why?

One of my principles is that we gain control of an uncontrollable environment by relinquishing control to that environment. It may not be obvious, but icy roads are an uncontrollable environment. Hence, the rally driver gains control by relinquishing control, allowing the car to have an imaginary and symbolic role in her success (all hail Michelle Mouton). Think of the best Scandinavian WRC champ. In the real world, abandoning driving is advisable for many, or if continuing to drive in obviously unsafe conditions, controlling what can be controlled by lowering speed, etc.

This may seem improvisational, as some of it is indeed. However, these control schemes may be orchestrated as well. How? By ranking tires by performance in the worst winter conditions on Tire Rack before making a choice. Do that and everyone wins.

Well said. The death of trust in software is a well worn path from the money that funds and founds it to the design and engineering that builds it - at least the 2 guys-in-a-garage startup work I was involved in for decades. HITL is key. Even with a human in the loop, you wind up at Therac 25. That's exactly where hybrid closed loop insulin pumps are right now. Autonomy and insulin don't mix well. If there weren't a moat of attorneys keeping the signal/noise ratio down, we'd already realize that at scale - like the PR team at 3 letter technical universities designed to protect parents from the exploding pressure inside the halls there.

Thanks so much for this splendid writing about Satie!

For me, it's as if the hauntological presence of David Foster Wallace showed up to match the known and yet unknowable genius that is Satie.

https://en.wikipedia.org/wiki/Gymnopédies#Legacy

I had arranged variations on a theme by Erik Satie when I was in music school so my experience is indeed a wormhole through pop to Satie - very old pop, but pop nonetheless. The involvement of John Cage just makes it more unique and special to me since we had played him too at the time.

Thanks again. Love the writing here. The author met his subject's match!

This is a good idea. It reminds me of the need for better visual debugging or visualization of the masked complexity in these products. I'm sure they exist inside tech titans, but I haven't seen them outside terrain visualization in open source.

Thanks for the highlight. I wasn't aware that Apple had released a new AR interface though I have used the previous VisionPro generation.

FWIW, I find the whole experience disconcerting from a design perspective.

Why?

1) We have been stuck at a Cartesian lossy limit of blocks world keyhole problems for 50 years on desktop and poor imitations of it found in tap interfaces.

2) That edge remains liminal and uncanny, precisely because it is lossy in terms of dimensions and their implied dimensionality and lack of scalability, ignorance of zoomable interface research and so on, from pixels at 2d to voxels at 3d, to 4-tuples (XYZT) in 4D and beyond.

3) Just like LLMs, the exploding dot cloud, or vector spaces of n-dimensional data found in our reality from inner space to outer space haven't really received the quantum-leaning, mirror world treatment they deserve - one which scales with the exploding complexity of its underlying dot cloud of vector spaces in all dimensions.

We are in need of a topos theoretic leap in UX/UI for decades - one which can incorporate the need for disconnected spaces that provide a localized logic to bridge the lack of unification from one uncanny valley to another. Sadly, what I've seen from the dichotomy of dominance in tech titans has not provided a compelling answer, at least not in public. I remain hopeful that R&D labs are still breathing in these sadly corporate places and simply are far more secretive since Steve.

Problem is, outside tiny pizza-team-sized labs, the number of R&D labs realizing the problem of synthesizing hybrids at 2.5d or the like is infinitesimally small.

Maybe.

I get the frame but I don't think arguing the co-opting of Cockburn by the MBA crowd gets us anywhere.

Think about it. GUI - Graphical User Interface - a concept taken from HCI Human Computer Interaction. I think that describes Peek and Poke in BASIC pretty well 50 years ago though nobody attributes those to Dartmouth. It also describes AI at present around the world.

But HCI is lossy. Why?

Exploding n-dimensional dot cloud vectors of language leveled by math are exactly why I fear that GUI should have died with CASE tools as a hauntological debt on our present that is indeed, spectral.

The world doesn't need more clicks and taps. Quite the converse: less. Read Fitts. You don't run a faster race by increasing cadence. You run a faster race by slowing down and focusing on technique. Kipchoge knows this. Contemplative computing could learn too but I'm not sure waiting on the world to change works.

Imagine a world where we simply arrived at the same kind of text interfaces we enjoy now whether they benefit from the browser or are hindered by it. We just needed better, more turnkey tunnels, not more GUI! We sort of have those from meet:team:zoom, but they suck while few realize why or can explain the lossy nature of scaling tunnels when many of us built them impulsively in SSH decades ago for fun.

The present suffers from the long-tail baggage of the keyhole problem Scott Meyers mentioned twenty years ago. Data science has revealed the n-dimensional data underlying many, if not most, modern systems given their complexity.

What we missed is user interface that is not GUI that can actually scale to match the dimensionality of the data without implying a 2D, 2.5D, or 3D keyhole problem on top of n-dimensional data. The gap from system-to-story is indeed nonlinear because so is the data!

I'd argue the missing link is the Imaginary or Symbolic Interface we dream of but to my knowledge, have yet to conceive. Why?

It's as if Zizek has not met his match in software though I suspect there's a Brett Victor of interface language yet to be found, (Stephen Johnson?) because grammatology shouldn't stop at speech:writing.

Grammatology needed to scale into Interface Culture found in software's infinite extensibility in language, since computers were what McLuhan meant when he said, "Media" and I'm pretty sure "Augmentation is Amputation" is absolute truth if we continue down our limited Cartesian frame - we'll lose limbs of agency, meaning, and respond-in-kind social reciprocity in the process, if any of those remain.

The very late binding (no binding?) we see in software now is exactly what research labs were missing in the late sixties to bridge from 1945 to 1965 and beyond. I can't imagine trying to do that with the rigid stacks close-to-metal we had then.

I hope I'm not alone in seeing or saying that the answers should be a lot closer-to-mind now given virtualization from containers to models and everything in-between.

One can only hope.

Thanks for your comment.

Indeed. Therein lies the rub.

Why?

Because no matter the fact that I've spent several years of my latent career crawling and parsing and outputting PDF data, I see now that pointing my LLLM stack at a directory of *.pdf just makes the invisible encoding of the object graph visible. It's a skeptical science.

The key transclusion may be to move from imperative to declarative tools or conditional to probabilistic tools, as many areas have in the last couple decades.

I've been following John Sterling's ocaml work for a while on related topics and the ideas floating around have been a good influence on me in forests and their forester which I found resonant given my own experience:

https://www.jonmsterling.com/index/index.xml

https://github.com/jonsterling/forest

I was gonna email john and ask whether it's still being worked on as I hope so, but I brought it up this morning as a way out of the noise that imperative programming PDF has been for a decade or more where turtles all the way down to the low-level root cause libraries mean that the high level imperative languages often display the exact same bugs despite significant differences as to what's being intended in the small on top of the stack vs the large on the bottom of the stack. It would help if "fitness for a particular purpose" decisions were thoughtful as to publishing and distribution but as the CFO likes to say, "Dave, that ship has already sailed." Sigh.

¯\_(ツ)_/¯

Indeed. I thought blocks world stuff would be amazing for early childhood education. I'm guessing some labs are already there since minecraft supports user-programmable models for years though I dunno the details. I'd be happy to learn if anybody knows of their evolution since the rise of AI.

Indeed. I complained that Apple design gets a free pass while being haunted by Steve from beyond the grave for a decade. Your comments resemble my habits except rusted sway right into cosmic desktop alpha and done.

Does brain science have a Fitt's law?

https://en.wikipedia.org/wiki/Fitts%27s_law

This is before we even start talking about serial or parallel, concurrency, etc. And then modify the networks and the wires themselves dynamically in real-time and you have endogenous BDNF, endogenous DMT, and the fact that insulin has a different, psychoactive effect on the other side of the blood brain barrier.

It would seem that time-speed-distance would be a useful metric here, as well as accounting for the fact that we don't actually know where we are in the 6d chess of triune, bicameral, hippocampal, or glycemic variation moment-to-moment in real-time.

¯\_(ツ)_/¯

The range of communication side effects and their societal impact is correct between swimming in the shallows and alone together.

If anyone is succeeding here I hope they have a stronger neck and head structure than I do.

I was present when Randy Pausch made the empirical lecture on screen real estate at CMU almost two decades ago. I believed strongly in that argument and was lucky to hear it before the last lecture.

However, as my work and tools evolved, I found myself abandoning the triple monitor Windows, Mac, Linux setups I used for the kind of portability work I did then.

And so while I did the apple vision pro demo when I interviewed at Apple this summer I experienced probably the most legitimate and extreme dichotomy between the value proposition of infinitely extensible screen real estate and diminishing returns on that real estate.

Put simply, that dichotomy is standing on the shoulders of poorly designed HCI for decades. Apple gets a free pass on design here but they should be held to a much higher standard.

If they were, we'd have something approaching Bret Victor's dynamic land or at least a desktop metaphor not siloed in a Cartesian model hundreds of years old when what we need is n-dimensional.

The data out-dimensioned displays decades ago. What the world needs now is a better tiling window manager, not another attempt to solve the problem by extending human vision while causing head and neck trauma we may never understand.

Raymond Loewy said, "most advanced yet acceptable, not most advanced yet bone crushing.

When I used apple vision pro, I found the experience so compelling I pinged all my friends working in AR singing its praises and potential applications in things we'd worked on together: radiation oncology treatment devices, visualization, robotics, and autonomy. But the thing that stopped me in my tracks was the ungodly physical trauma that accompanied the experience. That's saying something given I am an adult with nearly perfect health and no orthopedic issues whatsoever.

The thing that shifted my perspective on screen real estate was realizing that monstrous monitors are big tech's mcmansion hell. I did my day job on an 11 inch Chromebook running Linux a decade ago. I still ask why I need the morbidly obese MacBook pro m I have now with a 16 inch display and 32 GB ram.

Soon we'll see that big tech is just reading big pharma's playbook from decades ago. The reason it's hard to see now is that big tech did not finish reading the playbook, particularly as it applies to side effects foisted on an unsuspecting public. Give it a few years. I hope I'm wrong.

I upvoted your comment because I'm afraid you may be correct. I say, "afraid" because I can remember the day when a member of my team was fired for copy pasta from SO with little, if any understanding, into "production" code.

The problem, of course, is that this might work once in a while for low hanging fruit, until the web inherited things like DICOM and we now have medical imaging in the web browser (I've heard in Apple Vision Pro), where robotics implies the price of unforeseen bugs is not accidental death or dismemberment of one patient, but potentially many.

I'd refer you to a comment I made a few weeks ago on an HN post, to the same effect, which drew the further comment from gwern here:

https://news.ycombinator.com/item?id=40922090

LSS: metaprogramming tests is not trivial but straightforward, given that you can see the code, the AST, and associated metadata, such as generating test input. I've done it myself, more than a decade ago.

I've referred to this as a mix of literate programming (noting the traps you referred to and the anachronistic quality of them relative to both the generated tests and their generated tested code) wrapped up in human-computer sensemaking given the fact that what the AI sees is often at best a lack in its symbolic representation that is imaginary, not real; thus, requiring iterative correction to hit its user's target, just like a real test team interacting with a dev team.

In my estimation, it's actually harder to explain than it is to do.

The previous commenters are correct. T1D here. Sorry for the book.

I think you are correct but you may be overstating the case when you say, "healthy people can stay active for weeks without food". Carbs, yes. But its worth noting that Zach Bitter, who holds records in ultra marathon emphasizes multi-modal fueling for lack of a better frame, i.e ketogenic leaning for fat burning and carbs when needed; not perfect ketogenic diet. As we like to say on HN, "dynamic at run-time".

Exogenous insulin is the root cause of most hypoglycemia in insulin-dependent diabetes. There are other causes but they are relatively minor. Exercise, alcohol. Most people do not exercise or drink in a focused enough way for those to be major causes of hypoglycemia in insulin populations.

Insulin is just another pill with dramatically worse side effects than an actual pill, except maybe macrodosing psychedelics instead of microdosing glucagon.

You are correct in your macro diet analysis, except that fasting and ketogenic approaches are far more complex in concert with exogenous insulin than most people realize. If you have an endocrinology or organic chemistry background, this may be worth a shot; but the biochem is complex.

The LSS of your last question is that you don't have discrete conscious control of gluconeogenesis or much else in metabolism because it is all driven by well-functioning hormonal changes in the autonomic nervous system.

Again, "dynamic at run-time". The dynamics of insulin, glucagon, exercise, and fasting are far too complex to make this a one and done, simple prescriptive approach.

It's unusual, but I've practiced these approaches for decades, much to the chagrin of my health care team. That team being highly educated and experienced know the statistical outcomes and they're not good.

There are numerous problems with these approaches in diabetic populations who may not have the genetic sensors which make these states survivable, i.e. not all humans can feel changes in glycemia so overdosing insulin is a daily challenge to survival.

CGMs are not a cure-all either since the veracity and failure rates are poor by medical device standards.

I should know. I've worn a continuous glucose monitor for more than five years including two CGMs concurrently the last few years. They work great for some people.

In my case, they're horribly inaccurate (off by hundreds of md/dl) and when I was wearing a closed loop insulin pump, they are root cause of both overdose and underdose states leading to damning hypo and hyper glycemia since the pump has no way of knowing it's being led astray. I'm sure this is covered in cybernetics, control theory 101, or the like. At least I hope so.

Some, like me, can feel the glycemic changes and this promotes survival. T1D without glycemic sense may be a death sentence because the path from consciousness to unconsciousness is quick and these states are frequently not survivable without immediate action or a world class ER trauma team.

There's a reason T1D is classified as a wicked problem, like COVID.

This is why nocturnal hypoglycemia is dangerous even for those who can feel glycemic changes. Trust me, after 50 years of playing this game nightly, I'm not kidding when I say it takes Goggins-levels of asceticism, compulsiveness, and self-care.

I believe it's worth R&D spending and a cohort like me who have the biomarkers for surviving these approaches, but n=1. There may be others but I've not interacted with them directly.

Here's a well-cited oldie but a goodie on the complexity of diabetes for the obsessively curious:

https://www.researchgate.net/profile/Philip-Cryer/publicatio...

That's right. See:

https://news.ycombinator.com/item?id=14149986

We all wanted an experience as simple as interacting with the human at Whole Foods checkout OR the robot at the self-checkout, but what we got was this cacophony of anything but what you came here for that is amazon.com and most modern software design.

People wonder why I long for Amazon Go years after I left Seattle and recommended that approach to various retail executives.

Is there any better way to subvert retail than to promote stealing the merchandise as the ultimate UX?

https://en.wikipedia.org/wiki/Amazon_Go

This is a short book. My apologies.

You don't really have a choice with current gen CGM as to "all day". These devices are designed to be inserted and used on either a 10 day cycle (Dexcom) or 14 day cycle (Abbott).

Also, be sure "kinda interested" can handle "wrong most of the time" or "better chance of survival" as in T1D or T2D. There's no question that the data are aligning around glycemia as an influencer of everything from mental and physical health to the brain's default mode network. We used to talk about DMN as if it were much more immutable than it is. The deeper the neuro-imaging goes, the less true that seems.

LSS: glycemia is a significant influencer of behavior, not the only influencer, where the direction and slope of the glycemic curve determines the influence and that slope is more exaggerated with metabolic disorders like diabetes because insulin may not be a pill, but it's side effects are far more dramatic than most when taken exogenously without broad and deep knowledge of the pharmacokinetics and their impact, which are not well-understood outside the MD-PhD realm.

But I digress.

Once the device is inserted, it begins working after a warmup period, enforced by the software, of either an hour (Abbott) or 20 minutes (Dexcom). It's worth noting that I've seen data veracity and device reliability change with the same generation of devices, but software updates more frequent. I suspect this is due to changes in the software since nothing else has changed in the devices or the environment in which they operate.

My recommendation is to WAIT as long as possible prior to engaging with current CGM.

Why?

Because the last 5-10 years were the "ship the prototype" phase common in big tech.

Given the history, I'd expect the 2025-2030 3rd or 5th generation devices to be amazing, though their dependence on the smartphone ecosystem should be duly noted as good marketing, but perhaps an "embrace and extend" in which realtime blood glucose cannot be known without not just the phone, but the 4G or 5G network behind it at significant cost to the consumer.

This is why Dexcom's "innovation" of fixing the design mistake of routing local data through cloud and back to the display device is significant. Until other manufacturers follow suit, it is the only device I own that can do this direct BT device -> watch data exchange WITHOUT a costly smartphone ecosystem playing cloud proxy in the middle. There may be others.

The significance here cannot be overstated precisely because it enables things like running or biking with a non-cell enabled watch without carrying the phone as cloud proxy via crappy wireless networks. Prior to this, that would have worked if and only if the watch had direct cell capability above and beyond BT or WiFi, assuming some things about the software which I'm not sure are correct.

I just wanted to be clear that the BT -> watch in this wearable health data sensor paradigm is only possible with Dexcom presently to my knowledge. Shipments may invalidate that statement tomorrow so one can only hope.

In the meantime:

Caveat emptor.

Reacting to this and the previous comment, I've pursued the idea of iterative human-computer interaction via GPT as perhaps not the ultimate solution, but an extant solution to the problem posed by Knuth in literate programming before we had the magic to do it in HCI where the spectrum extends from humans to machines and assumes that the humans are as tolerant of the machines as the machines are of the human (Postel's law), in a frame that Peter Pirolli described here:

https://www.efsa.europa.eu/sites/default/files/event/180918-...

Which is to say that with an iterative, human-computer interaction (HCI), that is back-ended by a GPT (API) algorithm which can learn from the conversation and perhaps be enhanced by RAG (retrieval augmented generation) of code AND documentation (AKA prompt engineering), results beyond the average intern-engineer pair are not easily achievable, but increasingly probable given how both humans and computers are learning iteratively as we interact with emergent technology.

The key is that realizing that the computer can generate code, but that code is going to be frequently bad, if not hallucinatory in its compilability and perhaps computability and therefore, the human MUST play a DevOps or SRE or tech writer role pairing with the computer to produce better code, faster and cheaper.

Subtract either the computer or the human and you wind up with the same old, same old. I think what we want is GPT-backed metaprogramming produce white box tests precisely because it can see into the design and prove the code works before the code is shared with the human.

I don't know about you, but I'd trust AI a lot further if anything it generated was provable BEFORE it reached my cursor, not after.

The same is true here today.

Why doesn't every GPT interaction on the planet, when it generates code, simply generate white box tests proving that the code "works" and produces "expected results" to reach consensus with the human in its "pairing"?

I'm still guessing. I've posed this question to every team I've interacted with since this emerged, which includes many names you'd recognize.

Not trivial, but increasingly straightforward given the tools and the talent.

Definitely a fan of k3s as k8s lite - complexity that your particular project may not need, particularly since every project doesn't need k8s and many are better off with less.

If you look at the history from J2EE to the k8s prototype in Java to what we have now, it's a great idea to encapsulate all of these things into a single container, particularly at Google scale, but many unintended consequences arise from complexity accruing to features and functions which weren't actually requirements for your particular project being supported, i.e. the notion that YAGNI because few orgs have Google scale problems. If so, great! Carry on... If not, consider k3s or aptible or more emergent platforms I haven't actually used.

The mere presence of unneeded items in source and documentation presents a "why am I here?" choice paradox. That's before we even get into keeping track of deprecations in the never-at-rest source/release evolution.

Federation is a good example. I've worked at places that needed it and places that didn't.

Yes, thanks for asking.

Continous Glucose Monitors (CGM). That used to be a diabetic-only problem until Abbott, Dexcom,and other vendors expanded their markets beyond diagnosed diabetics into pre-diabetes markets and exercise, health, and well-being applications like:

https://www.ncbi.nlm.nih.gov/pmc/articles/PMC10635370/

and:

https://www.levelshealth.com/

This has exploded beyond the hundred years of ketogenic research and as research on glycemic variability in mental health has grown.

My current kit includes an Apple Watch series 9 and an iPhone SE. Prior to that it was Google Pixel and a Fitbit Sense, though direct BTLE->Watch was not an option in that generation.

I have two complications: Abbott Freestyle Libre 3 and Dexcom G7. Continuous Glucose Monitors (CGM). The Dexcom is entirely proprietary. The Abbott is accomplished via a series of 3rd party hacks:

https://www.youtube.com/watch?v=YqUZjXo5VXY

I'd say open source, but I'm not certain that every link in the chain is open source. I've run many generations of various open source tools on Android and iPhone since no vendor ships a complete end-to-end solution that is perfect.

Nightscout and watchdrip are two open source examples:

https://nightscout.github.io/

https://watchdrip.org/

When G7 originally shipped last year, sensor data left the sensor and used the iPhone as a proxy-to-cloud storage, as has become the default mode across many IoT devices because it was easy, obvious, despite the unintended consequences of the design choices here.

At that point, because the data has already taken a long and perilous journey into cloud when BTLE->Watch was dramatically shorter, cheaper (in terms of hops and requirement for service), and arguably better. Hence, any data request pays that full routing price into and out of cloud, even the most trivial display, such as watch.

After a latent Dexcom BTLE->Apple Watch update a year later, I don't even need to carry my iPhone anymore, despite the fact that I don't have service beyond WiFi on my Apple Watch, since the data exchange is entirely BTLE.

The sad fact is that straightforward questions around a person's glycemia were not answerable directly without an entire belt-worn cloud ecosystem being paid for and fully functional 24x7x365.

BTLE->Apple Watch is by no means perfect, but it's dramatically better than my previous 5 years of 24x7x365 routing through cloud.

HTH!

Good question!

The answer depends on funding, i.e. in my own never-leaves-my-house case it is always self-host, much like SOC work.

In the case of startup or research lab work (day-job, for lack of a better descriptor). It's frequently a slice of AWS, GCP, or Azure, i.e. 6 figure/mo cloud bills.

I think those two broad cases are worth considering.