Live data from Hacker News

Dear Apple

github.com

151–160 of 211 posts

Re: Dear Apple

#151
post #11

Earlier quoted context omitted.

Swift 3 had a purposeful effort to prioritize syntax-impacting changes and API changes as possible with the idea that Swift 4 and beyond would have backward compatibility for Swift 3 code. Swift 4/5 will establish ABI compatibility, so that binary swift libraries will work across compiler versions

Finalized ABI has been deferred from Swift 4, if you haven't heard: https://lists.swift.org/pipermail/swift-evolution/Week-of-Mo... Another year of breaking changes, hooray!

ABI != API, I think API-wise it should still be minimal breakage.

Re: Dear Apple

#152
post #11

Earlier quoted context omitted.

Swift 3 had a purposeful effort to prioritize syntax-impacting changes and API changes as possible with the idea that Swift 4 and beyond would have backward compatibility for Swift 3 code. Swift 4/5 will establish ABI compatibility, so that binary swift libraries will work across compiler versions

Yes I know that's what Swift 3 was trying to do, that's what I don't agree with. In my opinion the tradeoffs are just not worth it. Whatever happened to graceful deprecation of older language features an APIs? They invalidated all the related example code online and created a ton of mandatory work for all iOS developers within a 1 year timeframe, that's nuts. In my opinion :)

They're trying to build the best language for the next 20 years and sometimes you can only see what works/doesn't work once you build it.

C++ taught us what happens when you let cruft creep in, so I can see it from. their point of view, however I can also see the developer frustration.

It should be much better with the Swift 4 transition.

Re: Dear Apple

#153
post #132

Earlier quoted context omitted.

No, I am completely serious. This is how things work in big organizations.

As far as I've been able to tell, Apple engineers use "file a radar" to mean "I'd rather let someone else triage that, or even better yet I'd rather you get lost in the system, so here's a quest for you to go on so I can get back to work", particularly as we all know that at the end of that quest the result will be "marked as duplicate", past which point Apple refuses to give you any more information or even a follow…

Is it the best tool in the world? No. Is it the only actual tool to communicate bugs and enhancement requests to Apple? Almost. We've all used issue tracking software to add to backlog ("Open a Jira and I'll take a look when I have time"). Doesn't mean it's not being looked at.

Re: Dear Apple

#154
post #47

I made a conscious decision a while back to simply use a Linux distro (Ubuntu) with easily/cheaply-available commodity hardware for programming. Correct me if I'm wrong but other than iOS development, there isn't anything I can't do on Ubuntu with a 2010-ish laptop that I can do with a 2016-ish Macbook.

Battery life. Battery life sucks on linux, on the same machine it's worse than Windows or OSX. Plus a 2010-era laptop didn't have good battery specs (in comparison to 2016) and that battery is now 6-7 years old.

Re: Dear Apple

#155
post #33

Earlier quoted context omitted.

Can you still submit apps with Xcode 7? In response to your problem, having done the Xcode Old/Xcode New dance every year since 2012, I got into the habit of making sure they are never running concurrently. Things get even worse if you run xcodebuild on the command line while a different UI version is running.

You can't run multiple versions of Xcode concurrently due to CoreSimulator fighting over which version gets to run. This is a limitation we are aware of. We are also very aware of the problems it causes. As for other problems, please file radars and respond to requests for additional information. I have been on the external side of radar, I know it can be frustrating, but we do read them and we do take direct action…

What? I have very little problem running Xcode 7 and Xcode 8 along side each other. As long as you close the simulator before running from the other version.

Re: Dear Apple

#156
While I have slightly despised Xcode ever since 4.x when they integrated Interface Builder and everything else unnecessarily into one buggy app, it has only been completely broken for me with the latest version. “Something” makes typing s...l...o...w......a...s......h...e...l...l... and I have never figured out what. The editor became utterly unusable no matter the project and I was forced to do every change outside of Xcode.

I am very thankful that they at least had the wisdom to expose "xcodebuild", etc. as command-line tools, because I have always set up my primary build to rely only on the commands. (Even when “building” from Xcode, the build that I click runs "make" underneath with xcodebuild.) That way, I never need to be in the GUI and can work around its quirks or bugs that make it unusable, which has paid many dividends.

Re: Dear Apple

#157

Earlier quoted context omitted.

Can you give some examples of advantages of doing ROR development on Linux vs Mac?

Not the grandparent, but I can share one example: Our team deploys OpenStack and is developing a custom dashboard in Rails. I'm more of a backend guy, although I also do my fair share of frontend development. But I had a ticket in my sprint, just a tiny UI bug, but I was busy in the backend, so I asked a junior dev to take care of it. He cloned the repo, then proceeded to fight with rbenv and postgres and what not on…

Replace Mac with Windows and you've got the same problem. It's the junior's fault for trying to fight the system.

Re: Dear Apple

#158
post #145

Earlier quoted context omitted.

What's worse... the refactor functionality for renaming used to be great, but when swift came along it stopped working for Objective-C as well...

> the refactor functionality for renaming used to be great Objective-C did have some basic tools. But even Eclipse was better? You can always use AppCode, I believe it has the usual JetBrains level of refactoring. I have a copy paid and installed yet I almost never use it.

I can confirm, Appcode is good enough. Annoyingly, they don't manage to get font rendering to be the same as in Xcode, and that's a bigger issue for me than it should.

Re: Dear Apple

#159
post #74
post #48

Earlier quoted context omitted.

Apple is not a big company. Out of the 116k employees they have 60k are in retail [1]. Another 6k are in AppleCare call centers [2]. So about 50k of them are at corporate. Contrast that with Google which has 72k employees [3] and Microsoft which has 120k employees [4]. Apple's organizational culture is meant to be about small teams. Steve Jobs once said "we're the biggest startup on the planet" [5]. This leads to com…

Did you seriously just try to convince me that a 50k employee (by your logic) company is not a big company?

I'm not sure what flaw you found in what he wrote, or why even ask.

Obviously it's not the absolute number (50k) that counts, but how it's distributed. (And those 50k are not even all programmers).

If you do an OS, a mobile version of it, an embedded version of it, your own language, several huge SDKs, your own mail app, your own calendar app, you own spreadsheet, your own word processor, a TV appliance, the biggest mobile app store on the planet, your own logic board and CPU designs, the biggest music store on the planet, another large desktop app store, your own DAW, your own NLE, your own compositor, your own broswer, your own javascript engine, your own AI, your own Maps, and several other things besides, then no, "50k" might not be enough.

Microsoft has 5000 programmers just for Office.

Re: Dear Apple

#160
post #74

Earlier quoted context omitted.

Did you seriously just try to convince me that a 50k employee (by your logic) company is not a big company?

Also, the company with the most cash reserves.

Perhaps because they don't have huge uncofuced teams?

It's not like having fewer people per project hasn't worked out for them in the one way that really matters for a company -- profit.

Post reply on HN