Solipsism Gradient

After a year and a half, it’s time to update my loyal followers (all two of you!).

First of all, my eye problems had stabilized with the regular triamcinolone injections, but my eye doctor said these had hit a point of diminishing returns. So we switched to Ozurdex (dexamethasone) implants. The first was done 4 months ago, and the result was excellent; the retinal edema went away and my eyesight improved a bit — though not completely, a bit of macular pucker remained.

Some patients require only a single implant but now the edema has returned and I will have another one next week. Let’s see how many repetitions will be necessary, but I’m cautiously hopeful.

Several months ago, as requested by some friends, I began writing an expanded autobiography to eventually post here — stitching together many short episodes I posted in the past, as well as including new material and pictures. It stalled at around 30% but now I feel energized to take it up again. The first draft is in Portuguese, but when finished I’ll also do English and German translations.

For this, I felt the need (after decades!) to check out this website’s design again. After all, it was built for desktop computers, with no regards for reading on smaller screens. But now I’ve done a first pass to make it somewhat responsive to phones and tablets. It still looks constricted on my iPhone 13 mini, but it’s progress.

Update: I did some more fixing and removal of obsolete links and pages. One day I might study more of this @#$%^ CSS stuff…

When I began programming many years ago (now 55 and counting!), computing was in its infancy. We wrote programs on blue coding sheets, had them converted into decks of punchcards, and queued them on a shelf for “batch processing”. Usually the reward was a program listing with some obscure error messages like IEC107D, and I would mentally step through the program, repeating the process until being rewarded with a working “run”. I soon found employment at the local university, where more often than not I could run my program deck through myself and figure out things faster — and later on, in the wee hours, even use the huge mainframe computer as a primitive but enthralling personal device.

After some years the first video terminals came out, where you could view all lines of the program in glowing green rows, edit them directly, and enter the program into the batch queue. Was this the future? Well, there still was much to come. Very soon I realized I could buy one of those new Apple IIe computers along with a small TV and program/debug in the comfort of my home. And, miraculously, people actually paid me to sit at a computer keyboard and program.

And then the future arrived. When I saw the reports of the first Macintosh — a full graphics screen and a mouse — I knew that was it! The point-and-click user interface was the best. No more command lines. No more moving a clunky cursor around with the keyboard. It was heaven! And it only got better: color, larger screens, huge amounts of RAM and storage, networking! And then the internet came in, wonder of wonders.

It took years to evolve the expected standard behaviors of mouse gestures and UI conventions; application programmers had a library of items to use, so that pretty soon everything worked as expected and programs that flouted those conventions were downrated.

I was in the audience, in 2007, when Steve Jobs introed the first iPhone as a combination cellphone, iPod, and internet device. I wasn’t very impressed; I already had an iPod which I used little, had no plans of getting a cellphone (and indeed, held out until 2016 to buy one!), and the internet part was cool but the screen was small, the browser was limited and my laptop Mac had a much better feature set. OK, it wasn’t as portable but I always had it with me…

The real revolution here was the multitouch interface, an evolution of the point-and-click interface but with your fingers standing in for the mouse. It took years to evolve, and as with the Mac, Apple offered standard UI items to developers, which could then concentrate on functionality instead of reinventing the wheel.

But then in 2010 the first iPad came out and I bought one right away. Now here was a portable computer good enough to use as a personal device, and latter versions became more and more impressive. My iPad today is my main device for reading, listening to music and casual browsing, although I still fall back on the Mac for developing and writing longer texts. With my recent eye troubles I tend to fall back on my 77″ TV for watching movies, though, and programming has been curtailed.

Now the future has arrived again. I have no doubts that Apple’s Vision Pro — and, of course, “spatial computing” — is the Next Big New Thing.

Oddly enough, one of my arguments here is the sheer volume of vitriol about the device that one can find on the social networks: it’s unwieldy, it’s expensive, the external battery sucks, it’s been done already by others, it’s isolating and dystopian, it’s one more dragon in Apple’s evil ecosystem… Apple is doooomed, I tell you! Sound familiar? (And I’m not even on most of those networks!)

Hey, all those negatives were also rolled out in the past — and before we had Apple’s evil ecosystem, we had IBM’s evil ecosystem, remember? Every time such a futuristic device is sighted, it is clunky, expensive, power-hungry, and so forth. But also, if conditions are just right… the next version appears just in time, and it’s lighter, easier to use, and we can’t live without it anymore.

The real futuristic paradigm is now look-and-click, evolved from the old point-and-click way, and many other gestures are possible; standardisation is no doubt in progress. Why hold a mouse, or a control, or lift your hands unnecessarily, when you can convey all with small, subtle gestures? And our brains are evolved for a 3D environment — all our language and thinking is constructed around 3D metaphors.

Now, finally, we have a minimum viable system to explore 3D user interfaces. Discussing whether the Vision Pro is AR, VR or XR is besides the point; those are just implementation details and will evolve along with the UI.

Details on the hardware are scarce as I write this, and some may even be uninteresting — this thing is a self-contained computer on your face and the only relevant spec will probably be how much SSD space is left for user data. Everything else will be just good enough to be effectively transparent. And that’s the major point about the Vision Pro hardware: it’s a 3D input device for your brain, the first with sufficient quality to be transparent. Who needs holograms?

But, people will ask, what is the use case for this thing for the normal user/gamer/TV watcher/whatever? My answer: we don’t really know! Apple has, of course, selected some classic cases for the previous tech: FaceTime, games, 3D photos/videos, widescreen movies, Excel spreadsheets hanging in space (ugh), etc.; they had to do it, to get people’s attention. But between now and whenever this comes on the market in early 2024, developers will burn the midnight oil to build compelling use cases, most of which nobody (not even Apple!) had thought of before.

And this is where the Vision turns Pro. I believe that, rather than just designating a higher-capacity device compared to a non-Pro version, the Vision’s Pro name indicates that, at least until the 2nd or even 3rd generation comes out, this is a device for professionals. This is not (yet!) for casual gamers, zoomers or moviewatchers. Here’s a partial list I and a few friends came up with in a few minutes:

• Architects, engineers, designers (as usual)
• Doctors, dentists, psychologists, therapists and researchers in general
• Educators and grad/postgrad students
• Technicians in hitech fields like power generation, aircraft maintenance
• Industrial applications are boundless
• Astronomers, archaeologists, artists

And most of these can afford (or their companies can) the current $3499 price.

Com to think of it, I’ll probably buy two; it’ll still come in cheaper than paying for a huge 3D TV, multiple big screens/projectors and a couple of M2 Macs.

More as details emerge.

In case you’re wondering, I’m still here and — after 4 years of balancing acts — now consider my situation stable. Here’s a brief update on my previous post.

The eye needed a second triamcinolone injection but can now, several months after that, be considered stable. I’ve worked out a regime of eyedrops that seems to keep the macular edema mostly at bay and holds dryness etc. to tolerable levels. My eyesight has stabilized at 20/50 and I can drive cautiously.

The development hiatus can now be labeled retirement, unfortunately. I can’t see (hehe) going back to writing Mac apps and the pace in Swift(UI) development is still such that I’m adopting a wait-and-see approach to iOS/iPadOS development.

The health reports are good, my weight is almost down to my optimum level of 72-73kg and my level of exercise keeps improving; not up to pre-pandemic levels yet, but good.

Hopefully I’ll have time to write more about table tennis soon. It’s a fascinating subject.

Two years have passed since my last post on the subject, and the few readers left may want to know what happened since then with my eye troubles.

There have some relatively minor complaints. The Diamox pills I was using to keep eye pressure down turned out to have noxious long-term side-effects and I had to discontinue them gradually. Some side-effects (dizziness, weakened voice and reduced coordination) I had attributed to lack of physical exercise and old age ? but they’re gone now, it’s a relief.

Fiddling around with eyedrops to find the least irritating ones is an ongoing process, complicated by two bouts with small corneal injuries — probably caused by forgetting to blink while using the computer.

The remaining problem is a macular edema that appeared over a year ago, causing blurred vision. After it proved resistant to eyedrops, a subtenonian triamcinolone injection relieved the condition for several months, but it seems to be coming back. It’s still undecided whether repeating the injection will be worthwhile.

In the meantime, the eye is still drier than usual, painful towards the end of the day, and the dilated pupil makes me avoid the sunlight; I’m still getting used to these — apparently permanent — conditions.

On the development front, I’ve decided to start writing software again in the near future; maybe not for publication, but purely as brain exercise. None of my old apps seem to be doable for the recent macOS versions; Apple has tightened restrictions on what can be done by third-party apps.

Also, I see that most of my Objective-C experience is now obsolete and Swift has progressed beyond my feeble CS skills. But it still might be fun to try to catch up! To that end, I’ve purchased a reasonably configured M1 Mac mini running macOS Monterey and have slowly been migrating my normal apps to that; tricky as I was still depending on some 32-bit utilities, so my trusty “Late 2014” iMac will still be in use in parallel for several months.

Things are more positive on the general health front. We’re both fully vaccinated with a booster shot, and have been able to start regular gym sessions again, with encouraging results. This has also been producing excellent results in our table tennis training, and we have even been twice to special training sessions in nearby Varginha. This weekend I’ll play the 10th TMB Challenge Plus tournament and have good chances to add a medal to my collection.

WWDC 2020 opens next June 22nd and all indications are that the highest-impact announcement will be the Mac’s migration from Intel to the ARM architecture.

While CPU architecture migrations are infrequent — they happen every decade or so — Apple has a good track record of pulling them off successfully.

The first major migration was the move from Motorola 68K to PowerPC chips around 1994, followed by moving from the Classic Mac System 9 to Mac OS X around 2000. Relevant here was that for some time Mac OS X ran older applications in the “Classic Environment”: a compatibility sandbox that emulated the APIs of System 9 and the instruction set of the 68K.

This worked reasonably well as PowerPC CPUs were several times faster than the old 68K ones. It also introduced the concept of “fat binaries“; the same application file contained code for both old and new environments.

A better historical precedent is the move from PowerPC to Intel processors in 2006. This was more traumatic for developers, as PowerPCs were “big-endian” and Intel CPUs were “little-endian”. This meant that, except for strings, values stored in memory, files or transmitted over networks had a different byte sequence ordering. To have the same program source code work on both systems you could no longer assume it would just work, but had to bracket your instructions with macros or function calls that would do nothing on one platform but swap bytes around on the other.

If you’re not an oldtimer like myself you probably never had to think about this — every Mac, iPhone, iPad, Apple Watch or Apple TV use little-endian values, and I even had to dig into documentation to make sure of it. ARM CPUs can be run in big-endian mode by setting a special bit at boot time but this is not the default, and no Apple device uses that mode.

Now, this meant that in 2006 developers could not just migrate their apps to Intel by recompiling; we had to look through every line to either check that it was endian-neutral, and if it wasn’t, those special macros had to be used. For people who had very CPU-specifically optimized code — perhaps even in (shudder) assembly language — separate code sections were necessary.

Having done all this, you recompiled your app twice; once for PowerPC, once for Intel; and the magic of fat binaries allowed you to ship it all in one app. Later on, some apps even needed 3 or 4 different code sections, depending not only on endianness but also on whether they would run on a 32- or 64-bit CPU!

Another — today mostly forgotten — aspect was that Apple prepared for the Intel migration by gradually modernizing and building their developer toolchain in-house. LLVM, Clang, LLDB etc. allowed Apple to ensure that, for whatever CPU they wanted to support, compilers were ready beforehand and could be optimized continuously later on, without depending on outsiders.

Still, in 2006 Apple had to ship special hardware, “Developer Transition Kits”, to select developers for testing. For software that couldn’t be converted to the new architecture, Apple introduced a limited compatibility box: Rosetta. If I recall correctly, it did on-the-fly translation of PowerPC code into Intel code, which was then cached. Because of its limitations it didn’t work for many larger applications and was soon phased out.

Moving in parallel to the PowerPC to Intel migration was a slower-motion shift in operating system APIs. Most notably, this involves Carbon and Cocoa.

Carbon was a C-based API introduced in 2000 to ease migration from Classic System 9 to Mac OS X. Cocoa, introduced around the same time, was an Objective-C based API for modern object-oriented programming, itself an evolution of NeXT’s OpenStep system. Underneath both APIs, in the now well-known layer model, was Core Foundation, which could be used from both types of apps; and some apps (like my own) could mix calls to both APIs with some care.

Not too long after the Intel migration, Apple announced that 64-bit was the future, and that Carbon would not be migrated to that environment. This process was stretched over several years and involved redefining what APIs were really considered “Carbon”; some, like the File Manager, were “de-carbonized” and lived on until macOS 10.5 (Catalina) came out.

Cocoa, on the other hand, continues to be used everywhere in macOS. The Finder, the Dock, Xcode, and Safari are all Cocoa apps. Even when Swift came out a few years ago most of it was built on top of Cocoa and Objective-C objects; the notable exception is the Swift toolchain itself.

So, after all this, here we’re looking at Yet Another Hardware Migration for Macs. Let’s look at the implications.

Economically, it makes sense for Apple, as many others have already commented. They’ll no longer be bound to a foreign evolution roadmap on which they have little influence. They have extensive experience in producing high-performance, low-power CPUs for their mobile devices, and the latest versions already outperform Intel in some situations.

Technically, it’s a huge win. Switching to ARM64 — and not just the standard ARMv8.x architecture licensed from ARM, but with their own, extensive modifications — will allow them to have unified GPUs, Neural Engines, memory controllers and so forth on all their line, with more uniform device drivers and low-level programming.

For 99% of developers, I think nothing will change. The new chips are little-endian also, so a simple recompile will have Xcode produce a fat binary for the new Macs which should run outright. Of course, if you have assembly language sections in your program and/or write kernel extensions/device drivers, time to learn a new architecture…

Snags will come for people who dislike, or can’t use, Xcode. Some have to use Intel’s compilers, for instance; I know too little about such cases to have an informed opinion, sorry.

Some pundits seem to expect a sudden concurrent change in macOS; something like Objective-C and/or Cocoa being obsoleted in favor of Swift and SwiftUI. Or even the Mac going away entirely, some sort of huge desktop iPad taking its place. In my view this won’t happen. For one, what would developers or even most Apple engineers use for development?

A big question is: will Apple be able to provide an Intel compatibility box on the ARM Macs? Certainly Boot Camp will not be available. Running a virtualizer like VMware Fusion or Parallels seems almost as difficult, unless the new CPUs have some sort of hardware assist to decode x86-64 instructions. This may not be as outlandish as it sounds; current Intel/AMD processors already break x86 CISC instructions into RISC micro-operations which are then cached and executed by the “inner” CPU. This is a gross oversimplification but in theory nothing — except silicon space — bars Apple from breaking x86 instructions into ARM instructions.

A Rosetta-like box seems more feasible for running individual Intel applications, but who needs that? Game users? Performance will be limited. Most virtualizer app users want the complete OS running and with native speed. Linux/BSD might be available soon; perhaps Windows for ARM.

But what about Catalyst, some of you may ask? Here I can only shrug. In its present form it certainly is not an important future technology for macOS. While simple apps can be done with it — perhaps purely for the benefit of developers unfamiliar with AppKit — can you envision a Catalyst Finder? SwiftUI is still very new and primitive, and will continue to be layered on top of AppKit/UIKit for some time. They may merge in the future, or be renamed gradually like Carbon was, but that’s a long time out.

Finally, hardware. I don’t think the existing A13 SoCs would be applicable to any Mac, though. Some version of the Mac mini would be the obvious candidate to be the first to get the all-new CPU. It would then percolate up through the laptop line and the iMac. In these cases, reduced power usage would be a bonus — even for the iMac, it would mean a smaller power supply, less heat and a thinner enclosure.

The Mac Pro should be the last Intel redoubt. Multiple CPUs, OEM graphic cards, generic PCIe cards — Apple will have to address a huge range of problems there and this will take years.

Enough handwaving for now; the usual disclaimers apply and I’m really looking forward to the keynotes next week.

Update:
— corrected date for the 68K->PowerPC migration. Thanks to Chris Adamson for catching the error.
— fixed some awkward language about virtualization. Thanks to Maurício Sadicoff.

A lot happened since my last update, but the outcomes were too uncertain to write about; and I did not want to bore you with Too Much Information.

Still, I hope this post will be useful to people with similar conditions. So here’s a detailed graphic of the eye’s anatomy:

After the vitrectomy in late April, everything seemed to be reasonably OK. The octafluoropropane gas bubble the surgeon used to replace the vitreous humor took longer than expected to dissipate and a small part of it unexpectedly migrated into the eye’s anterior chamber, in front of the pupil, where it blocked the normal fluid flow and raised the internal pressure.

Both bubbles were almost gone on a Friday evening in late June when, once again, I noticed the shadows and sparkles of a retinal detachment. Unfortunate timing and circumstances conspired to push out the necessary surgery to the next Tuesday. Because of the detachment’s location on the lower part of the retina — past detachments were all on the sides or upper part — it was necessary to fill the posterior chamber with silicone oil and place a scleral buckle around the eyeball.

The consequences were not comfortable. The replacement fluid — this time, the silicon oil — leaked into the anterior chamber again, possibly following the duct opened by the gas used in the previous surgery. Pressure inside the eye increased dangerously and had to be controlled with several eyedrops designed to reduce fluid production inside the eye. The oil also painfully pressed on the iris muscles which contract or dilate the pupil.

It was all quite uncomfortable. The eyedrops messed up the fluid balance, the painkillers messed up the stomach — I lost 3 kg in the process — and the enforced inactivity messed up everything else. The eye pressure didn’t quite come down to normal levels and would damage the optic nerve in the long run. Accordingly, one month after the operation, it was decided to do yet another vitrectomy to remove the silicone oil: something which would normally have been necessary only several months later.

The scleral buckle, unfortunately, will be left in place indefinitely. As it encircles the eyeball in the back, around the muscles, every eye movement was initially painful and it’s still quite uncomfortable; I’m told it will take several months to get used to that.

So the last operation was in early August, two months ago now, and it mostly went well: all medications were slowly discontinued, the side-effects went mostly away and for a few weeks I’ve been able to resume normal activities. I have another evaluation coming up in late October, when I’ll have a comprehensive OCT exam of the retina, as well as new lens prescription info for that eye.

However preliminary examination revealed that eyesight has fallen to 20/50 (from 20/15 last year), grid distortion has worsened, and there are two dark scotomas — one at the lower left and one at the upper right — just at the edges of vision. Also, the iris muscles were damaged, so the eye was left somewhat dilated and (in photographical terms) with a fixed aperture, not useful at night or in direct sunlight. None of these conditions is expected to improve in the future, so I’m glad to have enough 3D-vision left for driving and table tennis…

An interesting phenomenon happened before my regular eye checkup in late February: the visual distortion in the right eye didn’t regress much, but subjectively my vision was almost normal. However my left eye — until now, unaffected — had developed a similar distortion in the opposite direction!

My conjecture was (and my ophthalmologist agreed) that this was a software adaption by my visual cortex. The expectation was that all these effects would continue to shrink for the next several months.

Unfortunately that was not to be. Two weeks after the checkup I noticed a persistent spot at the edge of my right-eye visual field, outlined by sparkles, even at night. I knew these were the symptoms of retinal detachment, and the ophthalmologist performed immediate surgery.

This was done by the same means as my November vitrectomy. The retina had wrinkled again, but this time at the edge; so instead of buckling it just began to tear. This was repaired by a belt-and-suspenders approach: laser “welding”, keeping the retina in place by a pressurised octafluoropropane gas bubble, and buckling the sclera mechanically. All this required paralysing the eyeball muscles and doing some tricky micro-mechanical work.

Well, after a scary and painful first week — the internal eye pressure had more than doubled and had to be relieved — I’m happy to report that recovery is underway, again. The gas bubble takes several weeks to be replaced by fluid and in the meantime there’s just a blur to be seen; but all indications are that the retina has been fixed.

More in about a month…

Yes, things are getting better. The visual distortion I reported two months ago has lessened significantly; it’s still there, but much less pronounced and not as annoying. Hopefully all will be cleared up in a few more months, as promised; I’m scheduled for a new eye check-up 6 weeks from now.

There are two faint gray sickle-shaped shadows remaining around the central focus area, no doubt some retinal scarring resulting from the operation; they’re visible only when viewing uniformly coloured areas.

Otherwise, my depth perception has returned almost to normal and I’ve made progress on my table tennis training, somewhat hampered by the heat — it’s been between 30 and 34º for weeks. Stay tuned.