The Xerox influence was real but limited - Apple's team iterated extensively as shown in these polaroids, adding crucial innovations like drag-and-drop, pull-down menus, and the desktop metaphor that weren't in the original Alto/Star interfaces.
The desktop metaphor absolutely was in the Xerox Star and that was copied by the Lisa team (and carried over to the Mac) after they viewed it when Star was first announce. That’s well documented. The Star also had limited pull down menus mostly a single menu item on the top right of every window that was hamburger-like in design that had items in it.
The Xerox Development Environment (TAJO/XDE) was more windows like where windows were processes and shrunk down to the bottom of the screen when closed. Star was developed using Tajo but are completely separate systems with very different user interfaces. For example Tajo used cut/copy/paste and any window could be set overlapping where as Star use a MOVE, COPY where use selected the object pressed the verb action button, and then selected the destination (use that was modal!). Also Star choose to have non-overlapping tiled windows (except for modal dialogues & style sheets.) The windowing was changed in later versions to allow any window to overlap.
What’s even more confusing is that Xerox had lots of systems including smalltalk, interlisp, star, Cedar & Tajo at the time Lisa was released. They also had lots or prototypes systems including Rooms and the Alto for that matter.
Apple absolutely also did their own research and design that was unique. And in cases the duplicated earlier research but came to a different conclusion (for example the number of buttons on a mouse.)
I think Apple did more with direct manipulation than others did taking it to more extremes — but you can still see that in other earlier systems.
In context those are just tweaks ... Xerox designed the entire WIMP (Windows, Icons, Mouse, Pointer) UI concept, including the bitmapped display it is based on, first commercial mouse, ethernet networking ...
Xerox's invention was visionary and pioneering. Apple's was just engineering iteration.
It's as if one company designed the automobile and you want to give outsized credit to someone else who added turn indicators.
The part so-often left out of this story (that Apple "stole IP from Xerox") is that the C-suite at Xerox got special considerations during AAPL's IPO, in exchange for access to their engineers in Palo Alto. From the POV of these former salesmen-turned-executives, it was fiscally worthwhile (they generally despised/misunderstood PARC engineers).
Xerox, of course, almost immediately liquidated their AAPL holdings (doh!).
Recalled from reading Dealers of Lightning at Xerox PARC (my favorite non-fiction book of the past few years).
Are these subsidies to end users, contributing towards retail or perhaps discount service fees? This shouldn't be how it works. Services should be given free to qualifying users (at some service tier) and providers should be paid directly to offset their cost of that service.
Providers should not be making market-standard profits, or revenue that subsidize ventures other than the services rendered to those users, like media creation or M&A.
"Recent leaks from Meta show that executives there worried that if they didn’t censor accurate information that the Biden administration didn’t like, the company could face severe consequences." dead giveaway about this article's author bias.
I live in Metropolitan Vancouver, somewhere with very low vaccination hesitancy, and still someone in my circle only got vaccinated because of restrictions. Restaurants were re-opening and she couldn't join in without getting the vaccine.
How knows how many avoided infection at all, severe symptoms, or even death because they were similarly convinced by restrictions and mandates. In this light, I really don't have much sympathy for some people who felt a little discriminated against. A public heath emergency doesn't care about your petty feelings.
It would be nice if this was a common OS feature. For some platforms however, system APIs implement the undo stack by way of pointers into runtime objects. A macOS application, for example, has model functions for each kind of document change, and these end with constructing an undo stack item. This contains pointers to the model object and inverse model function, plus captured parameters for that function to perform the undo. (Elegantly, when the inverse functions are called during an undo, the undo stack items they make effectively build a redo stack)
To save this undo stack on this and similar platforms would also require changing the undo mechanism entirely, from using pointers into using static references having meaning across instances of the document model. The inverse model function would have to be identified by an enumeration, the object to change would have to be identified by a kind of search path. The details about saving the data, and where to save it, would be the tiniest part of this problem.
But even on these platforms, if an individual app wishes to implement a custom undo stack which supported this feature, that would be very possible. If cross-platform frameworks implemented support for this that could be a definite advantage over native APIs.
"I will soon start a series of posts about the Apple IIgs, the most successful of the series." This https://retrocomputing.stackexchange.com/a/498 claims the 2e outsold the 2gs by more than 4 to 1. The former was in the market for far longer, was cheaper, and thus was the mainstay purchase for many mid/late-1980s schools.
Swift explicitly knows the difference between this construction and an actual string literal. Its type system considers "Foo" to be a StaticString, while "Foo \(something)" is merely a String, because it will need runtime allocation to calculate the actual value. A StaticString is actually a cheaper representation as well as needing to be distinguished for this reason.
So a native Swift API would be able to distinguish and refuse to let you provide this String where a StaticString is the appropriate thing, I am not an Apple expert to say whether this would be possible / easy for the NSLog binding, if it was possible to do this it should have been done.
In general, it is valid to resolve localized strings for use as format strings, which means that it is valid to have dynamic format strings at runtime.
NSLog might be considered an exception vs other Objective-C usage of format strings - but it might also not be worth having a singular special case.
NSLog takes dynamic strings just fine. Arbitrarily constraining it to only accept StaticStrings would break valid Swift programs. I wouldn't necessarily be opposed to it, but it's certainly not something that can be done without thoughtful consideration of the side effects.
"Most Software developers also can skip the 2021 lineup since compilation and build of most languages happens in a single core and thats what consumes all the time."
First of all: "that's".
Secondly, anyone using modern tools has build pipelines that are capable of maxing out all available cores, including most developers targeting Apple platforms using their Xcode app. In those situations one also needs lots of RAM and fast I/O.
I found clang multi-core benchmarks on geekbench.com:
M1 Max MBP 13442 = 104.7 Klines/sec https://browser.geekbench.com/v5/cpu/10496766 (similar for M1 Pro, which should be the ideal model for most developers as they rarely need top GPU performance)
