Live data from Hacker News

OS X app in plain C

github.com

151–157 of 157 posts

Re: OS X app in plain C

#151

Earlier quoted context omitted.

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

> 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 brea…

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

Re: OS X app in plain C

#152
post #131

Earlier quoted context omitted.

Unless something has changed drastically since when I was at MS, the Windows kernel and the major OS DLLs is pretty much pure C. The GUI/window manager are more C++. Even Word and Excel were still C (although Office shared much C++ code in a common DLL) Gotta love legacy code from the 1980s/1990s.

When were you there? Since the new "Going native" wave, C++ has taken the role of main systems programming language, even the DDK now supports it. Regarding office check their CppCon presentation how the code was ported to C++, refactored and made portable across OS. About 2h session.

"Going native" meant salvaging Vista's low performance by rewriting everything in C++ that was written in .NET -- .NET was the "wave" here, but it's also the culprit for Vista eating memory like cheap sushi.

Re: OS X app in plain C

#153

Earlier quoted context omitted.

> 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 brea…

> 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 alternative…

Unsubstantiated complaints of "omg brackets" were already tiring in 2008 when they were repeatedly voiced by many the new Objective-C programmers flocking to iOS development. If you have some reasoning for why Objective C's message passing syntax is bad, please voice it. (You haven't.) Otherwise you are just adding noise to the discussion.

Re: OS X app in plain C

#154

Earlier quoted context omitted.

> 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 alternative…

Unsubstantiated complaints of "omg brackets" were already tiring in 2008 when they were repeatedly voiced by many the new Objective-C programmers flocking to iOS development. If you have some reasoning for why Objective C's message passing syntax is bad, please voice it. (You haven't.) Otherwise you are just adding noise to the discussion.

I'm not biting that bait, sorry.

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

Re: OS X app in plain C

#155
post #131

Earlier quoted context omitted.

When were you there? Since the new "Going native" wave, C++ has taken the role of main systems programming language, even the DDK now supports it. Regarding office check their CppCon presentation how the code was ported to C++, refactored and made portable across OS. About 2h session.

"Going native" meant salvaging Vista's low performance by rewriting everything in C++ that was written in .NET -- .NET was the "wave" here, but it's also the culprit for Vista eating memory like cheap sushi.

Yet, the replacement of Win32 API model is with everything being written in the original design of .NET, with AOT native compilation and classes being COM objects.

What killed Vista was politics between OSDev and DevTools units.

Re: OS X app in plain C

#156

Earlier quoted context omitted.

Objective-C was a modification of the GCC developed by NeXT. NeXT didn't publicly release their patches and the FSF/GNU threatened legal action. NeXT released their sources and the GCC now supports Obj-C. Source: https://en.wikipedia.org/wiki/GNU_General_Public_License#Leg...

> Objective-C was a modification of the GCC developed by NeXT. No. Objective-C started out as a set of C Macros, then an actual pre-processor was created, mostly to deal with uniquing selectors. Once the pre-processor was there it was used to create actual syntax. Documented in "Object Oriented Programming: An Evolutionary Approach".[1] Still one of the best books on OO out there, because it treats OO as an architect…

> No. Objective-C started out as a set of C Macros, then an actual pre-processor was created, mostly to deal with uniquing selectors. Once the pre-processor was there it was used to create actual syntax.

I'm curious. What did that early form of Obj-C look like?

Re: OS X app in plain C

#157
post #5

There was a thread the other day where people were talking about languages that were easily interoperable with the "C ABI" (although there is no such thing). Languages listed included C++, Rust, and maybe a few others--but no mention of Objective-C. The ability to use a high-level, dynamic language (ObjC), C, and even inline assembly in a single source file is unique to Objective-C (at least among the "mainstream" la…

> The ability to use a high-level, dynamic language (ObjC), C, and even inline assembly in a single source file is unique to Objective-C (at least among the "mainstream" languages), and something I think is often under-appreciated. You can even use C++, too, which is awesome. Putting Objective-C objects in C++ structs "just works" thanks to ARC. One thing most people don't know is that Objective-C was originally impl…

"One thing most people don't know is that Objective-C was originally implemented as a precompiler for C."

Same with C++ (see: AT&T 'cfront')

Post reply on HN