5 ms·
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.
by ddoolin 10y ago
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.
- hellofunk 10y agoI don't know who you've been talking to, but that's ridiculous. C++ is one of the most widely-used languages for writing native apps for any OS. Adobe products, Chrome, anything built with Qt, even the Swift language itself, all made in C++.
- joewillsher 10y agoMost apple platform apps are written in mostly objc or Swift and not C++, I wouldn’t say it is one of the most widely used languages on these platforms by any means. The Cocoa SDK exposes an objc interface so many system framework calls have to use swift or objc. 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.
- dmytroi 10y agoIt depends, most of important and heavy lifting stuff in Apple platform, aka Core frameworks, are written in C, for example a quote from Core Text documentation [1]: > 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/StringsTextFonts/Conceptual/CoreText_Programming/Overview/Overview.html https://developer.apple.com/library/mac/documentation/String...
- joewillsher 10y agoYeah, I still wouldn’t say that c++ is “one of the most widely-used languages for writing native apps” for OS X. 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.
- izacus 10y agoIs there an actual half-popular production app for OS X written in Swift yet?
- astrange 10y agoProbably not, but Lyft is an iOS app written in Swift.
- hellofunk 10y agoPerhaps most smaller apps, yes. And some big ones too. But a very significant percentage of the commercial software industry writes apps for OSX in C++, including Autodesk, Adobe, many major games written using engines like Unreal and Unity (which also support other languages), etc. 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.
- ssalazar 10y ago> Adobe products 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.
- chillingeffect 10y agoThis is a very particular crowd, largely into web software and ecosystems for rapid growth of SaaS. I wouldn't extrapolate this crowd into software languages in general. You should always use the best tool for the job. 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.
- jimjimjim 10y agoagree. 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).
- austinz 10y agoVHDL vs Verilog flame wars everywhere. Also, discussions on people's favorite idiosyncratic, vendor-specific dialect of C for embedded devices.
- chillingeffect 10y agoGah, this. Also noobs who want to "replace their 2,000 device-per-year microcontroller application with an FPGA so that it can someday be put onto a ASIC." They're basically vinyl hipsters who fancy themselves "EE/chip designerz" and want to immortalize themselves.
- Hydraulix989 10y agoWhy recommend Objective-C over C/C++ though? It's more or less subject to the same "pitfalls" that go against C, PLUS it is a syntactical nightmare. [whatTheHell:is this:shit]; Is ARC really that much of a savior here? At least method calls get resolved at compile time.
- ssalazar 10y ago> It's more or less subject to the same "pitfalls" that go against C 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.
- Hydraulix989 10y ago> 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.