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.
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.