7 ms·

How about not coding in Objective-C amirite?

sdegutis 13y ago
I'd really love to see Julia start being used for this sort of thing. You can trade off between performance and abstraction within the same language. No more bouncing between C and Objective-C, with all the difficulties that can involve, especially due to C's runtime limitations.
- stephencanon 13y ago
  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.
zbowling 13y ago
Objective-C is a wonderful language. Stop trying to start a flame war.
- pjmlp 13y ago
  With lots of @ and [] scattered everywhere.
  - stephencanon 13y ago
    Unfamiliar special characters give me the vapors, too!
- Touche 13y ago
  So wonderful no one ever chooses to use it outside of Apple Land.
  - zbowling 13y ago
    http://apportable.com/ http://apportable.com/
    - Touche 13y ago
      Tool for compiling your iOS apps to other platforms...
  - pjmlp 13y ago
    To be honest it is not like Apple allows it. 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.
- CmonDev 13y ago
  "Stop trying to start a flame war" ...and leave past to past where it belongs along with COBOL et al.
grey-area 13y ago
Objective-C isn't the worst thing about making ios apps, though I'd agree it'd be nice to be able to use other languages easily.
keithwarren 13y ago
Xamarin lets you write in C# and still build 100% native apps. If you have not looked at C#, coming from ObjC it will feel like you just shed 100 pounds of weight.
- LordIllidan 13y ago
  Ive built about 4 apps in Xamarin now - nothing major though. 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#.
  - sirkneeland 13y ago
    If you are using C#, have you ever also made an app for... Well... windows phone?
    - kerbs 13y ago
      lol
  - pjmlp 13y ago
    Since my mobile development is mostly as a hobby, I went 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.
- Touche 13y ago
  It's also closed-source.
  - 13y ago
c1sc0 13y ago
I know you're trolling, but I don't get what's wrong with modern Objective-C. I, for one, like it's sane design patterns & in recenter versions ARC goodness, blocks, categories, etc ...

I'd really love to see Julia start being used for this sort of thing. You can trade off between performance and abstraction within the same language. No more bouncing between C and Objective-C, with all the difficulties that can involve, especially due to C's runtime limitations.

stephencanon 13y ago
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.

zbowling 13y ago

Objective-C is a wonderful language. Stop trying to start a flame war.

pjmlp 13y ago
With lots of @ and [] scattered everywhere.
- stephencanon 13y ago
  Unfamiliar special characters give me the vapors, too!
Touche 13y ago
So wonderful no one ever chooses to use it outside of Apple Land.
- zbowling 13y ago
  http://apportable.com/ http://apportable.com/
  - Touche 13y ago
    Tool for compiling your iOS apps to other platforms...
- pjmlp 13y ago
  To be honest it is not like Apple allows it. 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.
CmonDev 13y ago
"Stop trying to start a flame war" ...and leave past to past where it belongs along with COBOL et al.

grey-area 13y ago

Objective-C isn't the worst thing about making ios apps, though I'd agree it'd be nice to be able to use other languages easily.

keithwarren 13y ago

Xamarin lets you write in C# and still build 100% native apps. If you have not looked at C#, coming from ObjC it will feel like you just shed 100 pounds of weight.

LordIllidan 13y ago
Ive built about 4 apps in Xamarin now - nothing major though. 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#.
- sirkneeland 13y ago
  If you are using C#, have you ever also made an app for... Well... windows phone?
  - kerbs 13y ago
    lol
- pjmlp 13y ago
  Since my mobile development is mostly as a hobby, I went 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.
Touche 13y ago
It's also closed-source.
- 13y ago

c1sc0 13y ago

I know you're trolling, but I don't get what's wrong with modern Objective-C. I, for one, like it's sane design patterns & in recenter versions ARC goodness, blocks, categories, etc ...