4 ms·

You literally cannot "bounce between C and Objective-C”, since all valid C is valid Objective-C. You’re just “writing Objective-C”.

sdegutis 13y ago
That's a bit naive. Consider writing a program that's mostly Objective-C but needs to build up some C data structures for performance. A lot of that code for building it up, and the representation, will be written in C. Interfacing between the two will require careful design, in order to maintain performance and safety. This is especially true in the days of ARC, where you can't just store Objective-C types in C structs.
- stephencanon 13y ago
  > A lot of that code for building it up, and the representation, will be written without using the dynamic-disptach and reference-counting features of Objective-C. 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.
  - sdegutis 13y ago
    > will be written without using the dynamic-disptach and reference-counting features of Objective-C Those are hardly the biggest problems when dropping down to C for data storage, construction, traversal, and analysis.
    - stephencanon 13y ago
      It’s possible that I’m simply blind to the complexity of these tasks because I regularly do exactly these operations in C (dropping into assembly for performance reasons). If you do something often enough, it does start to seem straightforward. That said, there’s 30+ years worth of software written by other people in C that performs similar tasks. Much of it is horrible and ugly, but there are gems that are exceptionally clear and beautiful (more so than what I’ve seen in almost any other “mainstream” language).
- sdegutis 13y ago
  This isn't just a hypothetical, either. This was the problem I ran into with the Clojure IDE that I was writing[1]. I had to drop down to C to write the lexer/parser and to store the AST. Because of this design decision, traversing, searching, and manipulating this AST was much less pleasant and more error-prone than it was in the initial Objective-C prototype. 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 https://github.com/sdegutis/Leviathan -- but don't use it, it's in a state of flux
- pjmlp 13y ago
  Those are Objective-C structs according to the language grammar. They just happen to look like C code.
  - sdegutis 13y ago
    I'm pretty sure that's completely incorrect. Can you cite some source on this?
    - pjmlp 13y ago
      https://developer.apple.com/legacy/library/documentation/Cocoa/Conceptual/OOPandObjC1/OOPandObjC1.pdf https://developer.apple.com/legacy/library/documentation/Coc... 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.
      - sdegutis 13y ago
        Right, but you said it backwards, that C structs are really Objective-C types that look like C. This quote implies that C structs are simply C structs. 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.
        pjmlp 13y ago
        The point I was trying to make is that altought the code looks like C, it is Objective-C code from the compiler design point of view. 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.
- mikeash 13y ago
  All C is also Objective-C. If you're writing it in a .m file, it's ObjC, technically. 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".
  - sdegutis 13y ago
    While that's technically correct, it's unrelated to the point I was making.
    - mikeash 13y ago
      I couldn't understand what point you were making, precisely because there is no reasonable distinction between "C" and "Objective-C" in a .m file the way you're talking about it.
      - sdegutis 13y ago
        To take a simple example, I'm looking forward to doing things like `map` and `filter` on a collection in Julia mostly-efficiently, utilizing closures. While the same effect can be achieved in C, it's not pleasant to work with and can be more error-prone.
        mikeash 13y ago
        That makes some sense, but seems to have nothing whatsoever to do with "bouncing between C and Objective-C".
        sdegutis 13y ago
        You're right, there's a missing piece to this that I haven't expressed yet. I can see it in my mind, but I'm having trouble figuring out how to communicate it verbally.

sdegutis 13y ago

That's a bit naive. Consider writing a program that's mostly Objective-C but needs to build up some C data structures for performance. A lot of that code for building it up, and the representation, will be written in C. Interfacing between the two will require careful design, in order to maintain performance and safety. This is especially true in the days of ARC, where you can't just store Objective-C types in C structs.

stephencanon 13y ago
> A lot of that code for building it up, and the representation, will be written without using the dynamic-disptach and reference-counting features of Objective-C. 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.
- sdegutis 13y ago
  > will be written without using the dynamic-disptach and reference-counting features of Objective-C Those are hardly the biggest problems when dropping down to C for data storage, construction, traversal, and analysis.
  - stephencanon 13y ago
    It’s possible that I’m simply blind to the complexity of these tasks because I regularly do exactly these operations in C (dropping into assembly for performance reasons). If you do something often enough, it does start to seem straightforward. That said, there’s 30+ years worth of software written by other people in C that performs similar tasks. Much of it is horrible and ugly, but there are gems that are exceptionally clear and beautiful (more so than what I’ve seen in almost any other “mainstream” language).
sdegutis 13y ago
This isn't just a hypothetical, either. This was the problem I ran into with the Clojure IDE that I was writing[1]. I had to drop down to C to write the lexer/parser and to store the AST. Because of this design decision, traversing, searching, and manipulating this AST was much less pleasant and more error-prone than it was in the initial Objective-C prototype. 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 https://github.com/sdegutis/Leviathan -- but don't use it, it's in a state of flux
pjmlp 13y ago
Those are Objective-C structs according to the language grammar. They just happen to look like C code.
- sdegutis 13y ago
  I'm pretty sure that's completely incorrect. Can you cite some source on this?
  - pjmlp 13y ago
    https://developer.apple.com/legacy/library/documentation/Cocoa/Conceptual/OOPandObjC1/OOPandObjC1.pdf https://developer.apple.com/legacy/library/documentation/Coc... 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.
    - sdegutis 13y ago
      Right, but you said it backwards, that C structs are really Objective-C types that look like C. This quote implies that C structs are simply C structs. 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.
      - pjmlp 13y ago
        The point I was trying to make is that altought the code looks like C, it is Objective-C code from the compiler design point of view. 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.
mikeash 13y ago
All C is also Objective-C. If you're writing it in a .m file, it's ObjC, technically. 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".
- sdegutis 13y ago
  While that's technically correct, it's unrelated to the point I was making.
  - mikeash 13y ago
    I couldn't understand what point you were making, precisely because there is no reasonable distinction between "C" and "Objective-C" in a .m file the way you're talking about it.
    - sdegutis 13y ago
      To take a simple example, I'm looking forward to doing things like `map` and `filter` on a collection in Julia mostly-efficiently, utilizing closures. While the same effect can be achieved in C, it's not pleasant to work with and can be more error-prone.
      - mikeash 13y ago
        That makes some sense, but seems to have nothing whatsoever to do with "bouncing between C and Objective-C".
        sdegutis 13y ago
        You're right, there's a missing piece to this that I haven't expressed yet. I can see it in my mind, but I'm having trouble figuring out how to communicate it verbally.