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.

I agree it's not just React - I think a lot of people simply do not know what CSS can do nowadays.

I do like Tailwind (I guess it fits with how I think). But to make good use of it you _do_ need to know how CSS works (for example, using variant selectors for picking out child elements, using container queries instead of global breakpoints etc).

One addition - I learnt a _lot_ about CSS by reading [Every Layout](https://every-layout.dev/).

I remember writing a function to convert a string from snake case to camel case and calling it `humpify`. And another that would take a string and locate the constant with that name called `constantinople`.

But then, this is ruby and it's known for its unusual naming. Plus both also had sensible/boring aliases and they were for internal use only.

(slightly off-topic) Many years ago, I got a puppy to keep my older dog company (it was as disaster as she was an over-excited nightmare and in the end I gave her to a friend, where she lived a happy life with two other over-excited dogs).

The older dog was sat on the stairs, sulking, as I played with the puppy (he was always very moody).

I showed her a squeaky ball; she liked the squeak so I tried to get her to bite it and make the sound. But she just wasn't getting it. Then the other dog charged down the stairs, stamped on the ball to make it squeak, then went back upstairs to continue his sulk.

As other posters have said - capitalism.

But also privacy - it would be amazing to just be able to connect to any app or service you want, interact and react to stuff that's happening _over there_.

However, do you want any old app or service connecting to _your_ data, siphoning it and selling it on (and, at best, burying their use of your data in a huge terms of service document that no-one reads, at worst, lying about what they do with that information)? So you have to add access controls that are either intrusive and/or complex, or, more likely, just ignored. Then the provider gets sued for leaking data and we're in a situation where no-one dares open up.

My favourite way to use it is to write tests first, then say "make these pass". It will generate some code, run the tests, say "oh, there's an error here ... let's fix that ... oh, there's an error there, let's fix that ..." and (most of the time) it will reach a solution where the tests pass.

I already do TDD a lot of the time, and this way I can be sure that the actual requirements are covered by the tests. Whereas asking it to add tests to existing code often gets over-elaborate in areas that aren't important and misses cases for the vital stuff.

Sometimes, when asking Claude to pass existing tests, it comes up with better implementations than I would have done. Other times the implementation is awful, but I know I can use it, because the tests prove it works. And then I (or Claude) can refactor with confidence later.

I should refine my original comment: good marketing is about meeting the right people with the right message at the right time.

That kind of persistent nagging is the wrong time, with the wrong message at the wrong people.

People often mix marketing and sales. For me marketing is about "understanding your market". You wanted an iPhone because His Steveness knew what many people were looking for in a phone.

(The other parts of marketing, IMO, are getting the right message across at the right time - to those right people. The storytelling is the message part).

There's a whole section in the article about experimenting with different positions and weights of the haptic feedback as the dial is moved and how to tie them in to the display on the control itself.

I love that.

Also the MacOS "Zoom" button makes so much more sense than the OSX/macOS green button - and I still miss window shading.

I feel the real problem comes when people stop publishing on the (open) web because 1) no-one is reading it directly and 2) they know their hard work will just get slurped up and regurgitated by LLMs.

This is the issue I have with the "build vs buy (or import)" aspect of today's programming.

There are countless gems, libraries or packages out there that make your life easier and development so much faster.

But software (in my experience) always lives longer than you expect it to, so you need to be sure that your dependencies will be maintained for that lifetime (or have enough time to do the maintenance or plug in the replacements yourself).

I have done that with XReal glasses and my phone.

But they still look kind of off when wearing them in public (slightly bigger than normal sunglasses, cable from one ear and other people can see the light from the screens from the side or back).

And the lack of integration is a pain - the phone has to be unlocked so is subject to random taps and swipes in my pocket.

However, an Apple-built Carplay-style projection into XReal type glasses could work very well - the question being how would you control it?

I wonder if the lack of third party software for it is because the resentment with the App Store has built up so much?

Building an iPhone app? Pretty much required.

Building an iPad app? Almost free when you're building an iPhone app (depending on your tolerance for UI/UX)

Building a Watch app? It's a popular device but is it worth the investment? Most people say no.

Building for a brand new platform where we have to live with Apple's rules? No thanks.

Before its release, I read that Sony had said they could produce 900,000 of the displays per year because the process was so complex. Obviously with 2 displays per device, half that is the maximum number of Vision Pros per year.

I'm guessing Apple and Sony would have invested in improving the process if it had hit expectations.

Upvote for that book.

I read it a few months ago and was really impressed with how easy it was to read.

It starts out with simple stuff, like serialising data as JSON vs XML. But it moves into complex areas - like how replication and WALs work, including different ways of handling consensus when using leader-leader replication and how Spanner needs atomic clocks to handle it.

But even the complex stuff was explained in a way that I understood, which is an immense achievement.

The difference (in my experience) is if it works with Apple, it "just works". If it doesn't work, it will never work.

It's a binary and you generally know the answer straight away.

Some people dislike it because they enjoy looking for answers and the freedom to change how things work. Others like it because they don't want to spend their time searching and mucking about with configurations.

I meant the Bluetooth API so the head unit can see playlists and so on. the Spotify CarPlay interface is OK, but if I'm just on bluetooth, the head unit can't see my Spotify playlists, but it can see Apple Music's.