Here's where I admit that I can't identify them - but offhand I think it was Siracusa. I know because I tried speeding up a recent episode and he started talking and I had to slow it back down.
Woof, yes! Though I'm glad Heroku remains, and I ought to also be glad that it has been stable all these years, …it's clearly neglected.
The very first interaction I have with Heroku is a two-factor sign-in, and …it's this horrible page hosted on salesforce.com, which doesn't have retina graphics (i.e. is blurry on screens Apple have used for 15+ years), doesn't work properly with automatic one-time-code generators (because the login form is heroku.com, but the two-factor is salesforce.com), and …gah! What a mess. Thankfully you fall through into the pretty, well thought-out Heroku dashboard of yesteryear.
i think a lot of people do. i don't know what it is, there's maybe just something about the car graphic that doesn't sit right with me. the front/side view when parked just seems cheesy for some reason. maybe because it's meant to show unclosed doors or something and when everything is set the car's status is car which is redundant.
It does show open doors etc. but if not that then what would you show on the screen? You can already shrink it so the rightmost 3/4 of the screen is the map, leaving just 1/4 of the screen for the car visualization and indicators.
maybe it's the quasi-photorealistic nature of the car image that bothers me. it's not a photo, it's not a schematic, it's not a diagram. it's too artificial to look like a photo, yet too realistic to look like a schematic. or maybe the physically implausible lighting.
Animations could probably be faster and touch areas for opening trunk/frunk could be larger.
But then I'm driving brand new Fiat RV with CarPlay this week. Cruise control by itself has 2 or 3 bugs, and that's not even trying to be picky. Or how's this - can't hotspot from me while phone is in carplay. Can't pinch-zoom or pan maps in 2026 and myriad other things that makes me cringe when people moan they don't buy Tesla because lack of carplay.
Oof, hard disagree. I absolutely hated writing Objective-C for years– I felt like I had to write unnecessary 'glue' with header files, handling of 'nil' was always jarring, and square brackets at the start and end of every call felt horrendous, to me at least.
I relished the day Swift was announced, and have been using it ever since.
Agree -- my experience with Swift is that it's far more readable and closer to my personal aesthetics than Obj-C, but I actually struggled a lot figuring out how to write things the way that felt intuitive to me (ex. maintaining an observable global state + config that you can access from anywhere, easy declaration of and access to arbitrary/deeply-nested associative array keys, JSON handling, declare-once-use-anywhere icons and colors, that kind of stuff).
Once I had all the convenience guts in place, writing actual functionality has been a delight though (outside of the overly-verbose let/guard and type casting)
That said, I'm pretty sure I'm also probably just hard headed and doing it wrong, and could've learned the accepted patterns/methodologies lol
I always thought the square brackets were clever. Like wrapping a letter in an envelope – which is a great metaphor for the message sending the syntax denotes.
Objective-C programmers say this, but I note that I've never once heard a Swift developer complain that it's too hard to discover API interface or keep things non-`public`.
> never once heard a Swift developer complain that it's too hard to discover API interface
Xcode presents the equivalent of a “header” when you follow a symbol to a framework you don’t have the source for… it’s a swift file full of definitions only and no implementations. The compiler emits this for you automatically as a .swiftinterface file
> or keep things non-`public`
I definitely am a swift developer that would complain about this. It’s way too easy to be cavalier about using the “public” keyword and making things part of the public API when they probably shouldn’t be. It’s like engineers have muscle memory from Java and just type “public class” without really questioning why first.
In my current and previous job, we talked about (and partially implemented) low level “contract” modules in order to avoid linking (and building) the entire module in order to share behaviour
That problem was already solved with header files; trivial to split interface from implementation, they’re just two different files. But sometime around the 90s, probably Java and this was deemed inconvenient. Now we’re trying to reinvent that same pattern
Everyone's brain is probably different, but when I first started writing swift I definitely missed header files. When I switch back from a c project I miss them again.
Only access control I wish Swift had is typeprivate so I could hide private things but make them available for subclasses (or perhaps protocol conformers). Unfortunately Apple has only added a package level so far, which seems fairly useless (you're either too big for it to be useful or too small to need it). Obj-C didn't really have ACLs at all, you just hid stuff in interfaces. Once found, those interfaces were no protection at all.
IDEs have improved so integration of Swift and searching is easy. Objective-C now could do without headers but I used it 25 years ago and having headers made life easier.
In the whole I don’t mind Objective-C, but when I have to write it these days I definitely get annoyed by having to navigate and maintain header files. It’s more extra overhead than one might realize.
My other complaint with it compared to Swift is how one needs to pull in a bunch of utility libraries to do many things that come stock with Swift.
The support chat transcript is so uncomfortable to read– the person on the other end 'at Three' (aka a contact centre on the other side of the world, contracted out at the lowest possible cost) might as well be a bot, but the chat reads as if the person at Tutanota genuinely thought that they were chatting to a logical coherent human.
Having used Three UK on and off for two decades, this support chat lines up exactly with how I remember– 'robot humans' that say any ol' tosh to finish the contact session.
Avoid Three.
FWIW: all UK consumer telecoms services seem to have horrendous contact experiences (Though Three, of the prominent handful of providers, tops the charts in my opinion), but I've used EE for the last few years, and it has been consistently solid and fast, and thus I thankfully haven't /needed/ to contact anybody there. I cannot say the same for Three.
In consumer-grade telecoms, support is outsourced to idiots - it's not a UK-specific thing. Absent regulation against it, it will happen in any country.
