Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Dear Apple

github.com

Post reply on HN
Print view View original

161–170 of 211 posts

Re: Dear Apple

#161

Post by coldtea »

M_Grey wrote: post #8
fleshweasel wrote: post #7

It's absurd to have to beg the wealthiest software company in the world for what should be considered really basic stuff. Xcode is consistently unstable, slow, missing simple essential functionality (like refactoring), and Apple's interface builder is something that most experienced Apple devs know to run for the hills from.

That very wealth is what's insulating them from the long-term reality of the choices they're making. It's a trap!

>That very wealth is what's insulating them from the long-term reality of the choices they're making. It's a trap!

What "long term reality"? They have been doing this when they were near bankrupt and continue to this day, 20 years later, and they are now the richest company on the planet.

Maybe the long term reality is actually success?

Re: Dear Apple

#162

Post by manmal »

majewsky wrote: post #136
tlrobinson wrote: post #46

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…

He likely had some old Macports or whatever binaries lying around in his $PATH (it was that for me the last time some libs didn't compile). Would Linux be immune to that, if you had 2 concurrent pkg managers?

You could probably run vanilla macOS in a VM without running into any problems.

Re: Dear Apple

#163

Post by sebleon »

As someone that has dabbled in Android development, I have to say that Xcode is light years ahead of its competitors re: developer friendliness. It's realistic from a complete novice to setup their environment and create a full app in a few hours. Just getting your environment setup for Android can take a whole day or more.

I'm surprised by how few of these comments actually touch on the suggestions in this letter. Overall, they seem like small improvements that won't really move the needle on Xcode's effectiveness... Breaking up targets to make 15sec compilation times to Things I do with every project: -Don't use the interface builder, easier to do all UI work programmatically - Use Pods

Re: Dear Apple

#164

Post by jblow »

coldtea wrote: post #159
kbenson wrote: 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?

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…

SpaceX has 5000 employees and they design, build, launch, and LAND rockets.

Re: Dear Apple

#165

Post by sebleon »

chris_wot wrote: post #97

I really don't know what Apple gets out of keeping XCode as closed source. Why not open it up?

There's always non-zero work involved with open-sourcing stuff. How would Apple benefit from this move?

Re: Dear Apple

#166

Post by chmaynard »

LeoNatan25 wrote: post #112
chmaynard wrote: post #108

Earlier quoted context omitted.

You're joking, right?

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

I worked at Apple for many years, and I'm very aware of how Radar was used internally during my tenure. You're absolutely correct that Radar is taken very seriously at Apple. I won't go into detail, but what we see externally at bugreport.apple.com is almost nothing like the real thing.

It was a big mistake for Apple to ask outside developers to use a bug tracking tool that purports to be a user interface into Radar. I would much prefer a ticket system like those used at other companies. If Apple engineers triage a ticket and decide to open a Radar, that process should be opaque to the outside world.

Once Developer Relations made the decision to allow outside developers to create bug reports, Apple should have given us a modern, full-featured web interface. Instead, they gave us the ridiculous, brain-dead tool that you see at bugreport.apple.com, which looks like it was designed by an incompetent Cobol programmer (apologies to Grace Hopper).

Re: Dear Apple

#167

Post by eridius »

saurik wrote: post #132
LeoNatan25 wrote: post #112

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…

That's a rather insulting comment, and it's completely wrong. Apple engineers tell you to file a radar because if it's not in radar, it won't get done. Period. Radar is the way Apple engineers track work that needs to get done, and if nobody files a radar, it can't be tracked, prioritized, assigned, and completed.

Re: Dear Apple

#168

Post by kbenson »

coldtea wrote: post #159
kbenson wrote: 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?

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…

The flaw is that when you have 50k employees, you have much greater flexibility and resources with regard to human resources (and likely almost every other resource) to move around than a company with 200 employees.

Additionally, we are invited to "Contrast that with Google which has 72k employees". So, Google, which has almost exactly 20% more employees (after removing all retail and help center Apple employees), is supposed to be so much different, and an example of a large company? At least the comparison to Microsoft has more than a doubling of employees.

The argument that Apple works the way they do because they run their teams lean is fine, but let's not start acting like they're not a large company just because their culture is intentionally different in some aspects.

Edit: To be clear, by objection is to the premise "Apple is not a big company." which was the leading statement of the comment I replied to.

Re: Dear Apple

#169

Post by majewsky »

manmal wrote: post #162
majewsky wrote: post #136

Earlier quoted context omitted.

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…

He likely had some old Macports or whatever binaries lying around in his $PATH (it was that for me the last time some libs didn't compile). Would Linux be immune to that, if you had 2 concurrent pkg managers? You could probably run vanilla macOS in a VM without running into any problems.

> He likely had some old Macports or whatever binaries lying around in his $PATH (it was that for me the last time some libs didn't compile).

He only ever used Homebrew as far as I know.

> Would Linux be immune to that, if you had 2 concurrent pkg managers?

How would that ever happen?

Re: Dear Apple

#170

Post by [deleted] »

snackai wrote: post #10

Just stop pushing apps for iProducts. When all the major apps stop adding features for a while Apple will focus on getting developers back or customers switch to Android.

[deleted]
Post reply on HN