> the reason why developers are shackled to Objective C is to make sure processes finish in human time, and this is fundamentally a performance bottleneck in mobile hardware.
This is completely false. You can get good performance with high level languages like lisp. It doesn't have to look like C to be fast and to be possible to optimize it well.
The whole "writing low level code is faster" mentality is WRONG for 99% of apps.
The software game industry is wrong too.
Abstraction is a good thing, not a bad thing. Abstraction helps us write better code, and can help improve performance. Abstraction is not something to sacrifice for performance; in general sacrificing abstraction hurts performance because the bottlenecks are things like humans understanding what's going on, being able to write good algorithms which is harder with lower level code, and how long it takes them (so how much time is left over to analyze and fix code bottlenecks).
Low level languages waste time while making things harder on programmers. And they do this to no particular benefit.
None of this is to say that Objective C is terrible. It's certainly a lot better than C or C++. It has some good abstraction capabilities. But there is absolutely no reason we couldn't use a higher level language on mobile devices and get better performance for less developer time.
(The biggest real obstacles are things like the unpopularity of lisp -- it would, sadly and irrationally, mean less iOS devs and hurt Apple -- and the lack of high quality programmers who understand these things available to hire to make it.)
The whole "writing low level code is faster" mentality is WRONG for 99% of apps.
I read this a lot but I don't know where it comes from. For me, 'fast enough' in terms of subjective performance of an application is 'as fast as the current performance benchmark on that platform'. Anything less implies the developer has taken short cuts and creates a bad impression. On mobile devices even more so.
Sure, if your app can be neatly divided into broad sections of performance critical and non performance critical code, then you can save the C for the bottlenecks. But it's hard to know ahead of time where those bottlenecks will be, nowadays even more so with highly interactive mobile apps. Look at all the trouble Google have had making Android scroll smoothly for example.
In a marketplace where users will dismiss your app immediately over tiny glitches and pauses, I'd be inclined to write everything in C++ other than the Objective C stuff.
> it's hard to know ahead of time where those bottlenecks will be
Exactly. So the only reasonable policy is to use a language which is fast to write, and fast to change. Then, once you have software working, test where the bottlenecks actually are and change those parts (the majority of the time this does not require writing in a lower level language, just changing the design, fixing bugs, adding compiler hints, etc...)
> In a marketplace where users will dismiss your app immediately over tiny glitches and pauses, I'd be inclined to write everything in C++ other than the Objective C stuff.
By writing in inferior languages, you are creating apps with more bugs that take up more developer time (leaving less time to fix bugs, update older apps, etc). By your own claims, this means your apps will be dismissed. It's a mistake.
By writing in inferior languages, you are creating apps with more bugs that take up more developer time (leaving less time to fix bugs, update older apps, etc). By your own claims, this means your apps will be dismissed. It's a mistake.
I'm not sure what you mean by inferior language. By this reasoning pretty much all of the best iOS and MacOS applications are developed with inferior languages...
I don't really see why an experienced C++ developer would create any more bugs than one developing in any other language. Most of the difficulties people complain about (explicit memory management for example) are massively overstated and not in any sense a problem for anyone other than a novice.
You didn't address my point. Pretty much all of the best known and regarded applications are written in a C variant, including the browser you're viewing this on. On the iPhone, pretty much all of the best applications are written in a C variant.
Because lower level languages mean more bugs.
That's not actually a magical rule you know. The primary difference is that it's slower to develop in lower level languages. But users generally don't care about that.
I don't think you understand what's going on. You are ignorant of what used to be standard arguments here that I wouldn't actually have to explain to you (PG has explained a lot of it, HN and Viaweb sure weren't written in C or a C variant). And which I don't really care to explain to you.
I don't think I do understand, no. What does Hacker News not being written in C have anything to do with the discussion? Weren't we talking about iPhone apps?
Maybe I am wrong, I'm always happy to hear a different perspective at least.
HN is written in lisp, like Viaweb, because lisp is better, not just as a matter of taste. Check out some of PG's lisp advocacy writing, or some (very) old HN discussions, if you're interested.
And yet iOS still seems justified (based on its competition) in eschewing garbage collection to avoid stuttering; iOS apps that display a lot of data routinely have to go to surprisingly annoying lengths to maintain 60fps[1]; there are several different runtimes that promise to let you write iOS apps in various high level languages (Flash, JavaScript, C#, etc.) but invariably most of the demo apps are laggy or buggy (and games often ship with much higher hardware requirements than the norm for the platform, which probably affects battery life as well).
The C family sucks, but it's not nearly as clear as you imply that there's a better realistic alternative.
Performance bottleneck is a big issue, specially when you consider the level of graphics and AI in games these days. It is insanely clever, and would require parts of your game to be tuned in hand coded assembly, most games developers regularly hand code AI in inline assembly. The low level thinking is perfectly right, Games like mario,contra and others were even possible on a 8 bit machine with sound and graphics game loop and some AI because of assembly. Abstraction is good but not always. At some places you have to do a tradeoff. Also try writing a GLSL shader in java and then in Obj-C,C or C++ you will know how much better the latter are. This is why abstraction is not a good thing always.
Lisp is great i too agree even i like lisp very much, but a large part of the documentation available for Obj-C/Cocoa/Cocoa-touch is for Obj-C. That too apples documentation on the language and framework is the best available on the internet. Also Obj-C is a great language it is very similar to smalltalk and if you know smalltalk, Obj-C would be a joy to program in. Infact i felt Obj-C to be very similar to ruby conceptually.
> most games developers regularly hand code AI in inline assembly
This goes against any game company I worked. If anything, many are moving the AI code to scripting. Last company I worked had all the AI done in UnrealScript. Before was a mix of UnrealScript and C++ and previous was C++ with bits of lua mixed.
Never did I saw a line of assembly related to AI/Gameplay code in these games. (I was a AI programmer for about 4 years before leaving the industry in 2009)
The game industry writes buggy and poorly performing (relative to how they could be) games in C++ instead of writing better and better optimized games in superior languages.
1) Objective-C is a very dynamic (think Smalltalk), less cluttered and more nicely designed language than C++, that can just as easy fall back to plain fast C.
2) For writing applications, desktop or mobile, nothing in the C++ libs ecosystem comes close to Cocoa/Touch.
3) For the task under discussion (iOS apps), it's the standard that get's 100% of official support from Apple, C++ is not.
This is completely false. You can get good performance with high level languages like lisp. It doesn't have to look like C to be fast and to be possible to optimize it well.
The whole "writing low level code is faster" mentality is WRONG for 99% of apps.
The software game industry is wrong too.
Abstraction is a good thing, not a bad thing. Abstraction helps us write better code, and can help improve performance. Abstraction is not something to sacrifice for performance; in general sacrificing abstraction hurts performance because the bottlenecks are things like humans understanding what's going on, being able to write good algorithms which is harder with lower level code, and how long it takes them (so how much time is left over to analyze and fix code bottlenecks).
Low level languages waste time while making things harder on programmers. And they do this to no particular benefit.
None of this is to say that Objective C is terrible. It's certainly a lot better than C or C++. It has some good abstraction capabilities. But there is absolutely no reason we couldn't use a higher level language on mobile devices and get better performance for less developer time.
(The biggest real obstacles are things like the unpopularity of lisp -- it would, sadly and irrationally, mean less iOS devs and hurt Apple -- and the lack of high quality programmers who understand these things available to hire to make it.)