rahoulb

As someone who has had an iPhone since the 3GS (I'm so old), but tries Android out every now and then - I can wholeheartedly agree.

The only real advantages iOS have left are not being run by an advertising/tracking company (which is reducing as Apple looks for services revenue) and the quality and variety of indie iPhone and iPad apps (yet Apple are happy to make those same devs extremely unhappy).

I didn't understand programming at all until I read about (not even tried) Smalltalk. And it's because of Smalltalk I write Ruby today.

My favourite thing about it is the lack of "reserved words" - just a handful of punctuation marks. It's incredibly pure - almost all of the syntax is "send this message to this object".

My clankers are instructed to use "Outside In development" with "red/green TDD" at all times.

They write really good Gherkin features and then work inwards writing unit tests as they go - checking that they fail before implementation so it's actually testing something worthwhile.

And the code they ship is decent quality (not as good as me most of the time - but a LOT better than me when I'm tired or I'm pissed off about something or the work is really boring).

I really liked the 12" MacBook (although my all time favourite computer was the 12" PowerBook G4 - chunky by today's standards but I just loved it).

I saw a review of the MacBook Neo where the reviewer was yearning after the 12" - but suggested that Apple has made UI elements so big with such ridiculous spacing and border radius that it would be almost unusable at anything less than 13".

Which would not surprise me in the least - I struggle with my 16" MBP and this crappy UI "framework".

I've only ever sat in a Ferrari, never driven one, but the interior looks exactly like what I'd expect from a modern Ferrari.

As for the exterior, I really don't like the front - but I think that's because a tall Ferrari is just wrong (for example, I think the Purosangue looks incredibly generic too).

The worst I would ever get was "here's our Access database - can you rewrite it". That was utterly useless to me.

What I needed to do was sit with a user (not a manager/the person buying my services) and ask them to show me the different things they did with the software. Then I could write a spec for the actual _feature_ and would only need to look at the existing codebase if they needed data transferring across[1]. I don't see why our new LLM-based future would be any different

[1] Of course this meant I would leave out edge-cases and/or weird quirks of the system - often this was actually a bonus as they were either no longer relevant or worked that way because that was the only way they knew how to do it

When I quit my day job and started Rails freelancing a big chunk of my work was from companies with "that tech guy" who had built a database in Microsoft Access that was vital to the department's operations. And then either left the company - or the app had started to fall apart under its own weight.

I would get called in to rewrite it, using a proper database, documented rules and ensure it stayed scalable - and everyone would be happy.

These Access "apps" were abominations from a technical point of view - but they got the job done without having to spend a load of money on off-the-shelf or bespoke software. And the "tech guy" made a valuable contribution to the company. It's only at a certain point that Access started to struggle.

I foresee the exact same thing happening in the near future - except we won't be building the replacement apps ourselves - we'll just know how to give the coding agents well-specified prompts and tell them when they're making a mistake.

Minor correction - Xerox knew they could not commercialise their invention so they wanted someone to take it off their hands. So Apple didn't copy - they paid for it (in stock, not cash) - and if you've ever used a Smalltalk environment you'll know that what Apple actually shipped (in the Lisa and then the Mac) is a _lot_ of work done over the top of what Xerox had.

If the account is to be believed that's not what happened. They asked the LLM to do something on the staging environment, it chose to delete a staging volume using an API key that it found. But the API key was generated for something else entirely and should not have been scoped to allow volume deletions - and the volume deletion took out the production database too.

The LLM broke the safety rules it had been given (never trust an LLM with dangerous APIs). *But* they say they never gave it access to the dangerous API. Instead the API key that the LLM found had additional scopes that it should not have done (poster blames Railway's security model for this) and the API itself did more than was expected without warnings (again blaming Railway).

I'd add in "code is easier to write than it is to read" - hence abstraction layers designed to present us with higher level code, hiding the complex implementations.

But LLMs are both really good at writing code _and_ reading code. However, they're not great at knowing when to stop - either finishing early and leaving stuff broken, over-engineering and adding in stuff that's not needed or deciding it's too hard and just removing stuff it deems unimportant.

I've found a TDD approach (with not just unit tests but high-level end-to-end behaviour-driven tests) works really well with them. I give them a high-level feature specification (remember Gherkin specifications?) and tell it to make that pass (with unit tests for any intermediate code it writes), make sure it hasn't broken anything (by running the other high-level tests) then, finally, refactor. I've also just started telling it to generate screenshots for each step in the feature, so I can quickly evaluate the UI flow (inspired by Simon Willison's Rodney tool).

Now I don't actually need to care if the code is easy to read or easy to change - because the LLM handles the details. I just need to make sure that when it says "I have implemented Feature X" that the steps it has written for that feature actually do what is expected and the UI fits the user's needs.

As a long-time Mac user, "it just works" actually meant "it either works or it doesn't" - a *binary*. Whereas other OSes were shades of grey - it _might_ work if you spend time searching and trying random combinations in settings.

And it was good because it saved time.

(Same used to apply to iOS too)

It also depends upon how you manage it

My process, which probably wouldn't work with concurrent agents because I'm keeping an eye on it, is basically:

- "Read these files and write some documentation on how they work - put the documentation in the docs folder" (putting relevant files into the context and giving it something to refer to later on)

- "We need to make change X, give me some options on how to do it" (making it plan based on that context)

- "I like option 2 - but we also need to take account of Y - look at these other files and give me some more options" (make sure it hasn't missed anything important)

- "Revised option 4 is great - write a detailed to-do list in the docs/tasks folder" (I choose the actual design, instead of blindly accepting what it proposes)

- I read the to-do list and get it rewritten if there's anything I'm not happy with

- I clear the context window

- "Read the document in the docs folder and then this to-do list in the docs/tasks folder - then start on phase 1"

- I watch what it's doing and stop if it goes off on one (rare, because the context window should be almost empty)

- Once done, I give the git diffs a quick review - mainly the tests to make sure it's checking the right things

- Then I give it feedback and ask it to fix the bits I'm not happy with

- Finally commit, clear context and repeat until all phases are done

Most of the time this works really well.

Yesterday I gave it a deep task, that touched many aspects of the app. This was a Rails app with a comprehensive test suite - so it had lots of example code to read, plus it could give itself definite end points (they often don't know when to stop). I estimated it would take me 3-4 days for me complete the feature by hand. It made a right mess of the UI but it completed the task in about 6 hours, and I spent another 2 hours tidying it up and making it consistent with the visuals elsewhere (the logic and back-end code was fine).

So either my original estimate is way off, or it has saved me a good amount of time there.

That's the demand for GROWTH.

They've hit the limits of iPhone sales - and upgrade cycles are slowing. Hardware products in general are "streaky" - ie. demand and sales drop in the period after a new product is released, so how often can you produce a new version and what happens if that new version isn't a hit?

Whereas subscriptions provide recurring revenue. And services, in general, can bring in more money without an equivalent increase in costs.

I recently read "Apple in China" and one of the things I hadn't realised is how many people at Apple came from IBM under Tim Cook's reign. What he's done for Apple is turn them into a predictable, consistent, revenue machine.