tl

As posted elsewhere, making $107k is illegal. Making $107M is legal. Lots of people made thousands, tens of thousands or hundreds of thousands. In aggregate, they made single-digit billions based on the losses Citadel had to report. DFV alone made north of ten million (realized then) and is up north of $200 million right now (currently unrealized gains).

> There’s so many areas of medicine where we don’t see progress because the ROI just isn’t worth it. Do we want to risk making all medicine like that?

You can have a market for R&D and see progress. You cannot have a market for lemons and expect the same. For every Ozempic, you can expect one or more Nexium, where the company (AstraZeneca in the case of Prilosec/Nexium) uses the first research win to pretend to have a second win (or third, or fourth, or even first because acquisitions) using marketing and distribution channels to bury the cheaper med.

I don't know about "paid" but his column has moved from "shill who sometimes has a point" to "rabid fanboy" recently. As a recent example [1], he claims Japan's primary reason to punish Apple and Google is protectionism for Sony and Nintendo. His point is so strained he (intentionally?) fails to mention Microsoft, a check notes American company.

[1]: https://daringfireball.net/linked/2024/06/15/japan-app-store...

Apple's claim (per public statements) is:

- They upload your data to their servers. This is a requirement of iCloud and several non-iCloud systems like Maps.

- Where analytics is concerned, data is anonymized. They give examples of how they do this like by adding noise to the start and end of map routes.

- Where training is concerned, data is limited to purchased data (photos) and opted-in parties (health research).

My point is that Apple's code executing on device can be verified to execute on device. That concept does not require trust. Where servers are involved and Apple does admit their use in some cases, you trust them (as much as you trust Google) their statements are both perfectly true and ageless. Apple transitions seamlessly between two true concepts with wildly different implications.

> I'm actually a little gobsmacked anyone on this forum can type those words without physically convulsing.

Apple tells a pretty compelling lie here. Rather than execute logic on a server whose behavior can change moment to moment, it executes on a device you "own" with a "knowable" version of its software. And you can absolutely determine no network traffic occurs during the execution of the features from things announced this week and going back a decade.

The part that Apple also uploads your personal information to their servers on separate intervals both powering their internal analytics and providing training data is also known, and for the most part, completely lost on people.

> An app like this, that interoperates non-consentually with another app to modify or augment its behavior, is complete anathema to Apple's desired model of computing.

And yet, 17Lands works on a Mac!

> Of course, Apple themselves have more control than app developers (and you), but don't worry, Apple will use their position to make sure that only good developers take control of your iPad!

That's a prosecutable abuse of power by Apple.

The iPad is a "pro machine" or a "personal computer" when 17Lands[1] is usable on the device. Having article after article try to pantomime the details of what Apple is missing here is futile. Not only is Apple not listening, even implementing 100% of your personal wishlist isn't enough.

[1]: https://www.17lands.com/ - 17Lands is a website that tracks win-loss (and other) data in MtG: Arena games by installing a small program that reads logs from the game itself. It's the perfect example of the iPad's failings: it's too esoteric for Apple to provide directly and covers the kind of program extensibility needed to make hardware pro-usable.

> The parent comment is clearly by an optimistic youngster

My only objection is when the "youngster" had his viewpoint questioned, his response was "no I totally know it's in ascent". Objective evidence points in the opposite direction.

> No I totally know it's in ascent, that's my point! Haha! :)

How do you "know" this? Show some proof! RSS has two well-known use cases: news and podcasts. It is fighting a pitched battle against players with deep pockets who want you to consume content where they can monetize it with ads.

Google Reader survived for as long as it did because such a service is incredibly cheap to run. Google only ended it to push people to Google+. Many of the various competing providers that popped up during that period are still around, but I would not say it is flourishing.

This is what Google thinks of RSS:

https://trends.google.com/trends/explore?date=all&geo=US&q=R...

Note a rise and plateau centered around 2005 and a brief peak in 2013 (when Google killed Reeder).

That would be 2005 when Google Reader launched. RSS for people who didn't know what RSS was.

Everything above is an anecdote that happened to me personally when I pointed a SQLite client at chat.db on my Mac.

> It is possible to export iMessage threads by purchasing an Apple computer and enabling "iCloud for Messages"

And hoping Apple's broken client actually downloads full history or by forcing it to download by scrolling up through years of chat by hand.

And hoping Apple doesn't interpret a read lock on the db as malicious activity and temporary ousting you from iMessage and causing every message you send on unrelated hardware to drop to SMS until you login / logout from every device you "own".

Python makes it hard to get this right. Simple idioms result in copies of large collections or other work shifting from C to Python. The state-of-the-art of Python profiling [1] has to target this problem to the exclusion of other concerns.

[1]: https://www.thestrangeloop.com/2022/python-performance-matte...

> Stanley loves strong and static typing. He's a big fan of pattern matching

Funny, the language that made me a fan of pattern matching was Elixir.

> Modern-day Apple is its own binary star. One fueled by creativity. And another fueled by arrogance.

I originally said this as a joke to some friends in a private chat:

Anyone got a large enough gravity hammer laying around? I really want half of this star system.

> Though applications rarely are, I don't know if that was all that different back then either for most people.

It was. Another commenter mentioned ResEdit and being able to tinker with classic Mac applications. Two things were universally true back then:

1. In a pre-internet world, the entire application had to be hackable in some fashion, even if the application's creator tried to make that difficult.

2. Most parts of an application boiled down to simple text files, simple binary layouts or compiled source code. Obfuscation, encryption or even compression all cost CPU cycles which were often too previous of a resource.

As an example, Civilization stored much of its data in *.txt files you could edit in notepad to change the strength of units, etc...

The author's piece refers to the ability to inspect web documents to see how markup works. This is an order of magnitude harder to do in mobile apps often providing the same functionality.

You might want to clarify your question:

> do you really have no access to SDK code as a reference?

You get headers but no source. While Darwin is in theory open source, UIKit, et. al. are not.

> I got to that assembly code part and just sat there and re-read it again and again.

If you're referring to the screenshot, Xcode dumps you into disassembly in cases where the stack is not in your code. 0 -[MoTextView endFloatingCursor] is the author's code. The remainder is UIKit. Also, most of the line items are _prefixed which indicates a private method upon whose existence (much less implementation) is not reliable. As the author mentions, the stack on the left is usually enough to diagnose problems.

It's also one more thing that makes me fight using Swift; all of the name-mangling and opaque to the Objective C runtime additions make this problem even harder.

> People use a certain app to book train tickets even its UI sucks hard and it asks 100 permissions unnecessarily

It's worth questioning why this is, as often as you can. We have a wallet app / payment system on most mobile devices that is card agnostic and gets better interfaces. Meanwhile, other services have to make do until a big player like Amazon or Ticketmaster comes along, consolidates the industry and starts charging high rents.

I can't believe we're having this discussion either. Force cops to follow rules, full stop. We know that police misconduct begets more misconduct [1], and it works in both directions.

When officers start losing their badge or their pension for cutting corners, they'll stop cutting corners.

[1]: https://journals.sagepub.com/doi/full/10.1177/23780231198797...

Not just compile, but download. In addition to dozens pure-iOS projects (internal apps deployed to users), I have a couple of react-native codebases to support Android. Xcode Cloud spends more time downloading npm packages than anything else including compiling. Unlike other CI tools I’ve used, there is no way to Xcode Cloud to maintain a dirty executor or specify dependencies to skip this step. In addition, downloading dependencies fails so often that CI fails a majority of builds which have to be re-run which consumes more minutes.

I’m currently working with a client to convince them Jenkins on a Mac they own is cheaper and easier, working through the standard headaches of an IT department who supports thousands of iPhones and Windows machines but doesn’t want to support a single digit number of Mac just because Apple fights any attempt at cross-compiling from anything that’s not a Mac.

An actual sensible shutdown would involve creating a folder in each user's Google Drive with the exports Google is making people do by hand. Google's approach would be poor behavior if Google was dying which they are not.

I'm not sure, short of quoting the entire article you just linked, how to convince you how badly Epic lost that argument. Epic lost nine counts and winning the tenth count forced Apple to do something they were already doing, except slightly faster. Apple had already lost Cameron v. Apple legally requiring them to stop anti-steering provisions.

> How is giving money to the "right" people supposed to do that?

According to various studies there is a limit to how much money per year changes your base happiness. The ones I have read say $80,000 but inflation probably makes that a dated number. Everybody meaningfully burning more than that is either a member of the upper class buying superyachts or stuck in a red queen race like a speculative real estate market or collectibles. The ones who make more than the happiness threshold who don't have some other sink for it (the majority) prudently lock it into index funds where it's made available to the people who didn't want to lose control in the first place. That is the "how".

> How is giving money to these people in particular different than giving money to, say, nurses?

Canonically, there are three competing types of people getting paid out with some overlap:

1. Small business professionals. The standard here is your family doctor or dentist. Restaraunt owners also qualify. These groups deal with fairly intense regulation / "insurance" policies to limit how successful they are.

2. High-end white collar workers. Prior to the tech bubble conscripting software engineers, the usual suspect was lawyers. Lawyers have a wide gulf in compensation between "Ivy League Grads at BigLaw" and everyone else. That trend mirrors the current trend of BigTech vs. everyone else as described in the "Crack Theory". Look up "bi-modal salary" for more details.

3. Strikers. The halls of power are more than willing to max out the happiness threshold of anyone from auto workers in the 50s to airline points in the 90s who can make a credible threat that the spice will not flow. Power is willing to do this because they have spare money to print and the ability to strip the compensation long term by shifting jobs around. Based on current events in NJ, you may or may not get to watch this pay out in real time with your nurses.

> I've seen people with college degrees in IT employed as programmers that literally cannot program. I'm not talking "bad programmers" or "brain fart moment", I'm talking "consistently being unable to grasp even basic control flow over a period of months or years". Also some good programmers can be hard to work with for reasons other than their programming ability.

Your link talks about "good programmers that lack social skills". In my experience, politeness is a finite resource and dealing with people on a regular basis fully unable to do their listed job is a severe tax on mine.

Your argument is sound but it does not support your conclusion; react native is an example of “changing the base”. It is missing a significant chunk of HTML and CSS as an implementation detail. It is not an improvement, and I treat it as evidence that approach will not yield an improvement.

The author could use some better examples. Magic at runtime (the PHP example) is very different from magic at compile time (the Svetle/React example).

Performance matters and is sufficiently captured via working incremental updates. The single largest upside of a proposal like this is captured by using SQLAR over ZIP. That's what the Library of Congress does when SQLite claims them as a proponent. It's what Fossil does as others in this thread have pointed out. It's suggested as "first improvement" in the linked article. It's also the only part that should actually be considered for implementation.

You are right to point out the folly of deeper implementations like having and needing to understand table structures for things like slides. However, the current status quo involves Microsoft implementing a fairly esoteric "update the XML file's bytes as they would be encoded in a ZIP file" in their proprietary tool (where they have enough money to invest the engineering time) and all other tools use the slower "whole file in memory" approach.

User visible features like incremental fast saves (and shared editing) keep people on closed systems and give Microsoft the leverage to do the things you warn against. SQLite as a container format could have prevented that by giving everyone a shot at a lower cost but still fast implementation.

"Is this principle or opportunism?“ is necessary but insufficient skepticism. Convincing people to argue or vote against their own interests is also a pervasive problem. In American politics, it is called “turkeys voting for Thanksgiving“.

> Having a good word processor and a good spreadsheet on any software/hardware platform was absolutely vital in 1980s.

To this day, I cannot believe Apple shipped the Macintosh without a means of running VisiCalc.

All 5 of those age better than React. Also, you are conflating languages and platforms.

Counterexamples / Retorts:

- https://catonmat.net/5-best-programming-languages

- https://stevelosh.com/blog/2018/08/a-road-to-common-lisp/

Choose ecosystems free of hamster wheels, friend.