Really? I don't write systems software but it seems most here would not recommend writing in C/C++ unless it's absolutely the best choice.
Secondly, compilers are a very different programming task to developing GUI apps; the Swift team choosing to use it has nothing to do with Apple’s assessment of how you should write an application—Apple are the people who have been leading objc development (they own the objc IP) in the last 10 years and use it in all first party apps and many system frameworks.
> Many of the low level libraries in OS X and iOS are written in plain C for speed and simplicity.
And don't forget that OSX/iOS are based on Darwin BSD, where most of heavy lifting is done by programs written in C.
- [1] https://developer.apple.com/library/mac/documentation/String...
And internally apple use other languages a lot, but frameworks like UIKit, AppKit, and many of the other public frameworks they expose in the SDK are objc, with foundation for example abstracting a lot of CoreFoundation C code.
That's not a knock against anyone who does or doesn't write apps in a particular language; but folks should know what the reality is, and Objective C or Swift are by no means the only or even necessarily the most profitable ways to writes apps for OSX, though those languages are perfectly fine for many circumstances.
Adobe products have codebases going back decades, of course they are written in C/C++. Furthermore most Adobe apps have fairly advanced processing needs that your run-of-the-mill CRUD GUI does not.
> anything built with Qt
Qt isn't even stock C++, they had to hack a meta-compiler on top of C++ to effectively serve the needs of their GUI system.
> even the Swift language itself
By this logic, thousands of GUI apps are written in x86 assembly.
Between C#, Objective-C, Swift, JS+Electron, Mono, and many other mature, high-level frameworks that don't trash memory at the slightest provocation, youd need some very good reasons to use C or C++ for a GUI app these days.
Many people write quite excellent software in C/C++ every day. Just as many people use chainsaws, drive cars, fire guns and take pills every day. These are all productive activities with low floors and high ceilings. Anyone can jump in and make a mess. It takes care and attention to do them well.
If this was an enterprise/cio/it/gov discussion web site then all the conversations would be java and .net vs c++
if this was a scientific computing website then python, c/c++ and fortran and would be mentioned etc.
if this was a hardware/firmware website it would be c vs (whatever black magic is used by hardware wizards).
[whatTheHell:is this:shit];
Is ARC really that much of a savior here? At least method calls get resolved at compile time.
Only if you write C code in Objective-C.
> PLUS it is a syntactical nightmare. [whatTheHell:is this:shit];
Honestly, get over it. This is largely a surface-level detail that makes no difference once youve used the language for more than a week. I take it you have similar complaints against Ruby, Python, Lisp, or any other language that dares to break ranks with the C++/Java syntax idiom.
> Is ARC really that much of a savior here?
Yes, manual memory management is one of the main things that C/C++ programmers seem to consistently screw up.
There's no reason why memory management _should_ be something that C++ programmers screw up now with containers like smart_ptr and std::string. Yes, if you malloc/free stuff and use things like memcpy, you're playing with fire, but the whole point of "modern C++" is that we have better and safer alternatives.
On the other hand, Obj-C message passing (which really means method calls that are resolved at runtime) is another way, like manual memory management, to really shoot yourself in the foot if you make a mistake.
> I take it you have similar complaints against Ruby, Python, Lisp, or any other language that dares to break ranks with the C++/Java syntax idiom.
I actually don't. Forced named parameters and "array brackets" denote method calls are arguably poor choices for syntax.
On the other hand, getting rid of semicolons and enforcing whitespace a la Python is okay, and Lisp is really just an extension of RPN.
The point is your point that I dislike anything by default that is "not C/C++/Java" is actually pretty incorrect.
I do have opinions, but that isn't the basis through which they are formed, and quite honestly, I'm offended that you even made such an assumption about me in the first place.
> Honestly, get over it.
Bad advice, I'm allowed to have an opinion (and I do substantiate it above).
Regardless, I have "gotten over it" given that a large portion of my day job is spent writing Obj-C, and while I do like it better than Java as a language overall (even not having to deal with JNI for interop is a dream), god help the syntax.
You've already made the point that my opinion is a popular one. To wit, I find it amusing that the Google autocomplete for "Objective C syntax" is "horrible."