wesnerm2

> I exactly wrote that Microsoft devices were quite bad as they came too soon. And Apple came at the right moment, when low power chips were powerful enough, touchscreens were precise enough without a pen. And device had acceptable consumption, batteries had decent capacity, lifespan.

The argument is heavily reductionist because it treats technical breakthroughs as passive market timing rather than active, high-risk engineering.

Apple did not succeed by waiting for silicon to become fast enough to brute-force a desktop UI into a handheld. Instead, they reimagined the hardware-software stack from the ground up specifically around human fingertips and GPU acceleration.

Apple incorporated a GPU to accelerate the graphics. Apple acquired Fingerworks in 2005 and built custom chips to make multitouch viable. When Blackberry engineers were in disbelief about battery life, they cracked open an iPhone and found the battery occupied nearly the entire case. Apple also invested in aggressive thermal and power co-design such as power-gating states, dynamic clocks, ambient light sensors, etc.

It's because Apple was vertically oriented, they were able to make the necessary hardware advances.

Directly from the article:

Those states are Arizona, Colorado, Florida, Georgia, Kentucky, Louisiana, Maine, Massachusetts, Nevada, New Mexico, New York, North Carolina, Pennsylvania, Utah, Virginia and West Virginia, along with the District of Columbia.

MathML is machine-friendly not human-friendly.

Upgrading to Windows 11 is possible from an unsupported Windows 10 machine by adjusting a registry setting and downloading an ISO from Microsoft.

Atkinson's HyperCard was released in 1987, before the widespread adoption of the web. HyperCard introduced concepts like interactive stacks of cards, scripting, and linking, which were later adopted and expanded upon in the web. Robert Cailliau, who assisted Tim Berners-Lee in developing the first web browser, was influenced by HyperCard's hyperlink concept.

> There is no performance benefit that immutable structures offer that cannot be had by mutable ones. It is asinine to assert otherwise, especially when literally every single measurement ever done demonstrates that immutable structures perform orders of magnitude slower.

Copying is free. Comparisons and change detection are much faster. Data-sharing, thread-safety, content-addressing, versioning/persistence have faster and more efficient implementations--often for zero cost. Immutable data structures have more guarantees, which lend themselves to more optimizations.

Chart parsing uses immutable data structures and many other DP algorithms rely on immutability to take an algorithm from exponential running time and space to polynomial running time and space. Git uses content-addressing to implement zero-cost branches, which used to be inefficient in traditional version control systems, which were more imperative.

Linked lists were heavily used in application software before the appearance of standard libraries and Java, which is when dynamically sizable array-based lists become common. There also wasn't a gap between the performance of linked lists and arrays before CPU became significantly faster than RAM.

  Location: Philadelphia, PA and Bellevue, WA
  Remote: Yes
  Willing to relocate: NYC, California
  Technologies: AWS, GCP, Azure. My usual stack is C#/.NET Core, but I also professionally developed with C/C++, Javascript, Python, Java, Clojure, and PHP. Also used Ruby, Go, Scala, F#, Objective C. Primarily backend, but developed desktop, mobile, frontend(Blazor, ASP.NET, React, Astro, AngularJS), backend, and mobile applications.
  Resume: http://wesnermoise.com
  Email: wesnerm yahoo.com

Software developer with business degree and expertise in AI, mathematics and algorithms. Former software design engineer in the Microsoft Excel group, where I developed PivotTables. Primary background in .NET (C#) and UNIX (C++) with eclectic interests in frameworks, languages and platforms. Proficient in systems programming, desktop and mobile application development, and web development (UI and API). Independently developed multiple large applications—over 100K lines of code each. Ranked in 99.9th percentile in competitive programming at HackerRank and CodeChef. Filed patents and presented four times at Microsoft technical conferences.

If it is 23M pixels per lens, that is still more resolution than a smartphone's screen. Each lens is smaller than a smartphone's screen and the resolution is per eye. I wouldn't be surprised if this actually exceeds the eye's ability to perceive pixels.

The difference between a monitor and the lens of a headset. If you look at a 4K monitor up closely within a region of the screen of two inches in radius, you are not seeing 4K in that region. 4K of pixel applies to the whole monitor not to the eye's field of view as it does to a headset.

If you were using the headset as a monitor, you could zoom in on text and the text can effectively have infinite resolution as it scales up into view.