How about not coding in Objective-C amirite?
I love the ability to write apps in C#. The language is amazing. However, it can be exceedingly difficult to use 3rd party libraries in your application. It is possible - you can generate bindings for static libraries, but sometimes you run into solutions you just can't solve.
Also, all the tutorials you run into on the web are using Objective C. So you still have to know the language. The Xamarin community is practically dead compared to the vibrant native ecosystem that iOS enjoys.
Ultimately, I'm rethinking the decision to go Xamarin, and I am considering going native.
What I'll miss: Ability to have Android and iPhone apps sharing a common codebase. C#.
I have my issues with the language, but all in all, I do like it.
Additionally, it is supported out of the box in all mobile OS SDKs.
You just have GNUStep, which still seems to be at the same level I tried to used back when WindowMaker was my desktop (1999-2003).
Additionally it is not easy to find out how much of Objective-C, given Apple's changes, is actually supported by clang and gcc.
Fixed.
> require careful design, in order to maintain performance and safety.
In my experience, providing both performance and safety always requires careful design, regardless of the language being used. People who insist otherwise usually turn out not to have a very clear understanding of the state of the art with regard to either “performance” or “safety” or both.
This is especially true in the days of ARC, where you can't just store Objective-C types in C structs.
If it hurts when you do it, don’t do it. Some things need to be Obj-C objects. Many things don’t. I realize that this is glib, but it is absolutely possible to efficiently combine low-level “C-style” and high-level "message-passing/collections/object-style" Objective-C. It requires some attention to detail, but so do most things worth doing. As you build up good habits and idioms, it gets easier and easier.
Those are hardly the biggest problems when dropping down to C for data storage, construction, traversal, and analysis.
Any line you draw between "C" and "Objective-C" is going to be arbitrary and generally useless. The only line that's supported by objective facts is assigning "C" to everything in the C standard, and "Objective-C" to the additions, but then that means that things like if statements, return statements, and variable declarations are "not Objective-C".
One of the problems I was remembering was how difficult and inflexible it is to write a fast and efficient AST in C and export it to a scripting language intact. The only viable way that I could think of was to convert the C struct to an Objective-C graph and export it to whatever scripting language via some bridging, such as JavaScriptCore.framework (ugh JSExport) or maybe MacRuby, or similar.
But writing the AST in Julia itself might very well solve the fast/efficient problem, and since it's a dynamic language, scripting comes for free, with a first-class AST.
Another problem was how I couldn't mix Objective-C and C semantics when writing my AST. If I wanted to represent a collection in my AST, I had to basically hand-roll all the methods in NSMutableArray myself.
So ultimately I'm not sure I expressed myself properly, but I'm still excited about diving into Julia as a scripting language. I really believe it could solve this kind of problem. I can imagine new platforms being built with very little supporting platform-specific code which exports a few building block APIs to Julia and lets the script to the rest.
This is where Julia will shine for me. It will let me "drop down" to more efficient mechanisms when I need to write efficient algorithms, allowing me to use the same tools at all levels. This is actually my new plan for my IDE, I hope to embed Julia in it and rewrite most of the app in Julia. This should also make it dead-simple to let users extend the app by scripting it in Julia, while still having first-class access to the same internal ASTs used by the app itself.
[1]: https://github.com/sdegutis/Leviathan -- but don't use it, it's in a state of flux
They just happen to look like C code.
Quote from appendix B, grammar:
"This appendix presents a formal grammar for the Objective-C extensions to the C language—as the Objective-C language is implemented for the Cocoa development environment. It adds to the grammar for ANSI standard C found in Appendix A of The C Programming Language (second edition, 1988) by Brian W. Kernighan and Dennis M. Ritchie, published by Prentice Hall, and should be read in conjunction with that book"
ANSI C grammar is a subset from Objective-C's grammar.
This isn't just a pedantic point. You can't store an Objective-C pointer in a C struct, unless you cast it to a void* and bridge it. But then you're mixing ARC and non-ARC code in the same file, which is trickier to manage correctly.
It is an Objective-C struct that shares the same semantics as a C struct.
Similar to many other languages that have kept compatibility with C to easy code sharing between code bases.