programmer from dictionary:
>>a person who writes computer programs; a person who programs a device, especially a computer. <<
iOS Programers fit that description.
Here's the secret to understanding the difference between API'ists and low-level programmers: time-to-market.
iOS programming is deeply mainstream in the market right now, so elaborate frameworks are available for it. GameBoy was waaaay ahead of its time and had no APIs for developing.
The same is true today: If you want to get ahead of the market, you can take the hit in complexity and develop for a lower-level of hw/sw, like the Parallela, in exchange for a short-term advantage, but there's no mainstream market yet. Or, you can write a great iOS app today, but you won't be the first. The initiative was lost a long time ago.
It's all about withstanding the headaches of bleeding-edge HW and SW, versus gaining the edge of being earlier to market.
If you're assembling a team, you want a range of abilities, from lowest-level people who can tell you what's really going on down deep inside up to the APIists who can leverage the work of many others to get access to widely-used features.
I was actually intending agree with you, to mean that the low-level programmers are precisely those individuals who achieve the time-to-market. They can wade through the specs and configure devices before the polished API becomes available.
Please help yourself and go speak to real programmers on OSDev rather than troll^W lose you time here. Thank you.
FWIW, I know my x86 assembly and am not an iOS programmer. But I have huge respect for good iOS programmers. Some of those apps are phenomenal.
He's claiming that people who identify themselves as an "iOS programmer", rather than just a "programmer", aren't really programmers. A "programmer" might be able to write inspiring stuff for iOS, but they haven't pigeon-holed themselfs into being an "iOS programmer"
Or because it's a market where really awesome programmers can't distinguish themselves from good-enough average ones because few customers can discriminate between those.
Back in the "olden" days, storing a number required thought. 8 bit processors could often deal with 16 bit values, but beyond that you were on your own. You had to be very careful designing your data structures so they used the least memory possible. Saving data was unreliable. There were often no debugging tools at all. Some lucky folks had ICE[1] but most of us had to guess why the system hung. All this meant you had to get low level because of the constraints.
But you know back in those olden days we didn't have to have a comprehensive help system. We could assume users were proficient. We didn't have to deal with security and attacks. No networking. Undo was rare, and if it existed was a single step. Your code only ran in one human language. So while we did have to care about the low level implementation details of the code, we didn't have to worry too much about the rest.
The low level constraints are pretty much gone now. The tools are great. And you do have to worry about a lot beyond the actual implementation like usability, smooth animations (games had to worry about that in the olden days but in a different way), multiple languages, coordinating with other systems over a hostile network, attacks and a whole bunch more. I'm glad for all this, because worrying about fitting data structures and a framebuffer in 16kb of memory didn't make for a better app.
Being familiar with the low level is still sometimes helpful, but not that often. It is also a heck of a lot more complicated - eg compiler produced code is not straightforward and logical. Multiple levels of cache, cache policies, speculative execution etc make reasoning about data more difficult. The majority of the time it doesn't matter.
Right now the majority of mobile apps behave rather poorly if you have more than one device. In the future that will be a given. UI is more likely to be goal driven with the system figuring best practises for meeting the goals, versus nudging things by pixels as is done today. (Heck a user will probably do some combination of pointing, speaking, thinking and just plain old looking.) I'd expect a more functional approach where immutable states are the unit of an app, and new states are produced via interaction and external updates with the states syncing across everywhere relevant instantly.
Thare's been a "dramatic change" between the 80's and 00's? If so, I must have missed it. I look at, say, IBM 1620 versus the machines designed in the 1980's, and that is change to me. In the 1980's, essentially everything we use now in the area of personal computing architectures has already been invented and put to use. Essentially, by the time you get to the 1980's, everything has been so homogenized and regularized that I really don't see anything new that happened since then.
Perhaps some change is going on now - AMD's hUMA seems to me to be the first major departure from the 1980's machine model in those twenty five years or so, but even then, I'm not sure how much is that "new" - IBM has had heterogenous CPUs on their mainframes for quite some time, so conceptually, it's just another idea getting to the PC world from the world of mainframes.