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.
Their offering perfectly fit the bill for what we needed, but they turned us away; citing a requirement of transacting €5M per year, despite us needing a payment handler /for launch/.
That’s sad. We integrated Adyen like 5-6 years ago and this requirement was nowhere to be found. All I remember was their SDKs are difficult to integrate.
Anecdotally: I've been looking to get answers from Stripe, about fees-related questions that either make my proposed use viable or unviable, and I've received nothing but copied & pasted email replies, a week+ later (or not at all), which essentially ignore what I've asked. Incredibly frustrating.
When I mention the experience to friends, they joke that I have Stockholm Syndrome; to want to continue pursuing them, despite their complete disregard.
Yeah that's sad. I asked for a fee reduction 2 years into our relationship, and they said no because of XYZ but if we hit revenue targets ABC that they'd re-evaluate.
About a year later, we hit revenue targets ABC, I waited a month (just for systems to catch up) and emailed them. We had a good discussion about a rate cut and they knocked their fees down as they promised.
I emailed in 3-4 years after that and asked for a rate cut as our revenues had gone up by about 10x, and they said they could not, but provided explanations on why because of high international processing, high AMEX/Discover processing, etc. Totally cool, I understood that and appreciated the detailed email. Wasn't disappointed at all.
I tried back a year or so later when our revenues shot up but got the same message more or less, but still personalized. Again, I had to try, but also, not unhappy.
And since all of those excellent customer service responses - many of which did not go my way, which is not how I rate interactions - it's been awful. The corporate card team refuses to answer questions or even apologize for their insane limit cuts. They presumably are hiding behind bullshit KYC/AML justifications for their actions or protecting their algorithmic decisions in order to provide us zero actionable customer support with no personalization. It's embarrassing.
I think this might have two, maybe more meanings. The first is that if the person asking you to do something won't put it in writing, then it's probably not legal and therefore you can't do it. The second is that if you haven't thought through something well enough to write it down (the problem and the solution) then you haven't thought about it long enough to have found a solution.
