5 ms·

I'm torn how to feel about this. I've been developing with objective-c on iOS for several years now, and to say this as gently as I can ..it's not my favorite

I'm torn how to feel about this. I've been developing with objective-c on iOS for several years now, and to say this as gently as I can ..it's not my favorite language. I want to play devil's advocate for a moment and ask some tough questions (these may go away in a request/response scenario where the app isn't running continuously): * How does Objective-Cloud handle circular references (will memory leaks be a problem?) * Is there a way to cut down on boilerplate (having to declare member variables, accessors, synthesize them, and understand the differences between var = _var, self.var, static class vars, etc?) * Any plans to port to other platforms (Android) and if so, will it still use objective-c? * How do you sandbox binary code (will security be a problem?) * Will you allow third party binaries/libraries to be uploaded with the code (or will everything be open source/code only?) To be fair, I believe that this style of development may be the future. Perhaps we need a wrapper around pure C because it doesn't do enough to promote inter-module communication, and C++ dropped the ball on that. I'm just concerned because objective-c is ideologically different from, say, Boost, D, or Go. It focusses more on patterns than abstractions and simplicity over correctness. I've found it nearly impossible to build an app in obj-c above a certain size that's guaranteed to run indefinitely, stably and without leaks. And I've found that large obj-c projects often lead to spaghetti code and repetition, because of a lack of understanding about things like delegates, inheritance, using notifications instead of nesting code, etc. Some aspects of obj-c are quite brilliant (like queuing tasks on the main run loop) but others like manual memory management are antiquated. But kudos for this effort. I'm curious how this plays out.

melling 13y ago
Well, it only helps, right? Many people think Apple invented Objective-C and that it's part of their wall garden. Creating a slightly larger ecosystem of Objective C will hopefully help grow cross platform support. It would really be nice to reuse some of that iOS code...
- huxley 13y ago
  I know you don't think Apple invented it but ... Brad Cox and Tom Love did, their company Productivity Products International (PPI) developed Objective-C way back in the early 1980s. PPI became Stepstone, their biggest customer NeXT licensed ObjC in 1988, then in 1995 acquired the trademark and rights to ObjC from Stepstone. And then finally Apple bought NeXT in 1996. Interestingly, this is not the first time ObjC has been used for web stuff, WebObjects/EOF was originally an ObjC web framework but was later ported to Java.
chrisdevereux 13y ago
I'd agree with many of your concerns about Objective-C as a language for writing cloud services. The best thing about it as a language vs. more modern alternatives is that the lack of GC makes worst-case memory allocation times predictable, which is important in a client app but not so much on a server. The most interesting thing about this to me is that it makes the Apple frameworks (especially the multimedia ones --- CoreImage, CoreAudio, etc) available to cloud services. I wonder about using RubyMotion or Mono with a service like this. It might address some of your concerns about the language.
gress 13y ago
> Is there a way to cut down on boilerplate (having to declare member variables, accessors, synthesize them, and understand the differences between var = _var, self.var, static class vars, etc?) Yes. Objective-C no longer requires most of this.
graetzer 13y ago
I happened to be at a presentation the creators of this gave a few months ago * I think ARC helps with most of the problems, of course you'll have to understand where to use weak or strong etc. * You don't have to write @synthezize anymore, literals remove a lot of boilerplate too: http://clang.llvm.org/docs/ObjectiveCLiterals.html http://clang.llvm.org/docs/ObjectiveCLiterals.html * As far as I know the protocol between server and client is just HTTP + JSON * They use the BSD sandboxing facility https://developer.apple.com/library/mac/documentation/Darwin/Reference/ManPages/man7/sandbox.7.html https://developer.apple.com/library/mac/documentation/Darwin...
- potatolicious 13y ago
  It's still pretty trivial to mess up memory management and segfault and die. Speaking as a full-time iOS person, I don't think I want to write a backend in Obj-C. When I flub a strong/weak reference on a phone, my app crashes. The user is mildly inconvenienced as they launch the app again. When I flub a strong/weak reference on a server, my app crashes. That server is now down and my ops guy (probably me) will have some unkind words for me, particularly if it's in the middle of the night. It's tempting to say at this point "well, don't flub references, n00b", which is much easier said than done. Bear in mind that we did use to write webapps in C - we moved to higher-level, more resilient languages for a reason. I don't mind Obj-C/Cocoa. I'm a graphics guy at heart, so the closer-to-the-metal implementation makes me happy and lets me spin all kinds of neato magic with custom UIs... none of this is necessary serving data off a server.
  - Tom9811 13y ago
    Objective-C has nothing to do with UI. BTW: The first web server has been developed in Objective-C.
    - potatolicious 13y ago
      Sure, and Amazon.com used to be served from a monolithic C code base - that we did it before (or had to do it before) doesn't make it the best tool now. All of this reminds me a little of the whole "let's do EVERYTHING in JS!" trend - while technically impressive I simply don't see the point of hammering a square peg into a round hole when there's a round peg nearby you can use. Re: Obj-C and UI. Obj-C makes it really easy to write highly performant UIs because it's reasonably close to C. You can hit up OpenGL and other extremely fast drawing libs in a really performant way, without invoking any cumbersome hooks or wrappers (see: writing and interfacing native code in .NET). Writing insanely fast and visually complex UIs in Obj-C is a breeze. Its proximity to C is a strength in client-side dev, but it's a liability on the server.
mahyarm 13y ago
Personally for me, most of my frustration comes from iOS's UIKit and especially their entire UIViewController container class set. It's very fragile and picky. Simple Objective-C is far less of a headache to deal with. Also as a side effect of practically being an apple hardware only environment and it being a compiled language, you don't have the option to create a 2 or 4 socket CPU beast to compile programs with.
eddieroger 13y ago
I'm in the same boat as you, and I was really excited to remove a tool from my already heavy tool belt, but I'm not sure where this one fits in. In my mind, I'm comparing it to Sinatra, and how quickly can I go from an empty file to a running service, and this seems to have a lot more steps than I would have considered necessary. I still want to play with it some more, but I'm not sure it's the right tool for my web needs.
deleted 13y ago
[deleted]
memracom 13y ago
One mitigating factor is that a properly written cloud app would have lots of small/simple services loosely coupled by a database and/or some kind of message queuing service (AMQP). That would limit the complexity in comparison to the way that a monolithic IOS app is built.

melling 13y ago

Well, it only helps, right? Many people think Apple invented Objective-C and that it's part of their wall garden. Creating a slightly larger ecosystem of Objective C will hopefully help grow cross platform support. It would really be nice to reuse some of that iOS code...

huxley 13y ago
I know you don't think Apple invented it but ... Brad Cox and Tom Love did, their company Productivity Products International (PPI) developed Objective-C way back in the early 1980s. PPI became Stepstone, their biggest customer NeXT licensed ObjC in 1988, then in 1995 acquired the trademark and rights to ObjC from Stepstone. And then finally Apple bought NeXT in 1996. Interestingly, this is not the first time ObjC has been used for web stuff, WebObjects/EOF was originally an ObjC web framework but was later ported to Java.

chrisdevereux 13y ago

I'd agree with many of your concerns about Objective-C as a language for writing cloud services. The best thing about it as a language vs. more modern alternatives is that the lack of GC makes worst-case memory allocation times predictable, which is important in a client app but not so much on a server. The most interesting thing about this to me is that it makes the Apple frameworks (especially the multimedia ones --- CoreImage, CoreAudio, etc) available to cloud services. I wonder about using RubyMotion or Mono with a service like this. It might address some of your concerns about the language.

gress 13y ago

> Is there a way to cut down on boilerplate (having to declare member variables, accessors, synthesize them, and understand the differences between var = _var, self.var, static class vars, etc?) Yes. Objective-C no longer requires most of this.

graetzer 13y ago

I happened to be at a presentation the creators of this gave a few months ago * I think ARC helps with most of the problems, of course you'll have to understand where to use weak or strong etc. * You don't have to write @synthezize anymore, literals remove a lot of boilerplate too: http://clang.llvm.org/docs/ObjectiveCLiterals.html http://clang.llvm.org/docs/ObjectiveCLiterals.html * As far as I know the protocol between server and client is just HTTP + JSON * They use the BSD sandboxing facility https://developer.apple.com/library/mac/documentation/Darwin/Reference/ManPages/man7/sandbox.7.html https://developer.apple.com/library/mac/documentation/Darwin...

potatolicious 13y ago
It's still pretty trivial to mess up memory management and segfault and die. Speaking as a full-time iOS person, I don't think I want to write a backend in Obj-C. When I flub a strong/weak reference on a phone, my app crashes. The user is mildly inconvenienced as they launch the app again. When I flub a strong/weak reference on a server, my app crashes. That server is now down and my ops guy (probably me) will have some unkind words for me, particularly if it's in the middle of the night. It's tempting to say at this point "well, don't flub references, n00b", which is much easier said than done. Bear in mind that we did use to write webapps in C - we moved to higher-level, more resilient languages for a reason. I don't mind Obj-C/Cocoa. I'm a graphics guy at heart, so the closer-to-the-metal implementation makes me happy and lets me spin all kinds of neato magic with custom UIs... none of this is necessary serving data off a server.
- Tom9811 13y ago
  Objective-C has nothing to do with UI. BTW: The first web server has been developed in Objective-C.
  - potatolicious 13y ago
    Sure, and Amazon.com used to be served from a monolithic C code base - that we did it before (or had to do it before) doesn't make it the best tool now. All of this reminds me a little of the whole "let's do EVERYTHING in JS!" trend - while technically impressive I simply don't see the point of hammering a square peg into a round hole when there's a round peg nearby you can use. Re: Obj-C and UI. Obj-C makes it really easy to write highly performant UIs because it's reasonably close to C. You can hit up OpenGL and other extremely fast drawing libs in a really performant way, without invoking any cumbersome hooks or wrappers (see: writing and interfacing native code in .NET). Writing insanely fast and visually complex UIs in Obj-C is a breeze. Its proximity to C is a strength in client-side dev, but it's a liability on the server.

mahyarm 13y ago

Personally for me, most of my frustration comes from iOS's UIKit and especially their entire UIViewController container class set. It's very fragile and picky. Simple Objective-C is far less of a headache to deal with. Also as a side effect of practically being an apple hardware only environment and it being a compiled language, you don't have the option to create a 2 or 4 socket CPU beast to compile programs with.

eddieroger 13y ago

I'm in the same boat as you, and I was really excited to remove a tool from my already heavy tool belt, but I'm not sure where this one fits in. In my mind, I'm comparing it to Sinatra, and how quickly can I go from an empty file to a running service, and this seems to have a lot more steps than I would have considered necessary. I still want to play with it some more, but I'm not sure it's the right tool for my web needs.

deleted 13y ago

[deleted]

memracom 13y ago

One mitigating factor is that a properly written cloud app would have lots of small/simple services loosely coupled by a database and/or some kind of message queuing service (AMQP). That would limit the complexity in comparison to the way that a monolithic IOS app is built.