Why is objective c so verbose

In Swift, if your code requires a string, the features of Swift will guarantee that your code gets a string and not another type, such as an int. Another great feature of Swift is its syntax. Especially compared to Objective-C. There is no need for semi-colons, calls to self or parentheses around if statements. The continual need to unwrap objects to comply with Swifts type-safety offsets the development gains that come with the succinctness.

Swift also has a lot of great control flow options with guard, if-let, advanced switch statements, repeat-while and defer. I like all the different options because it lets people control the flow of their code in a way that makes sense to them. A lot of people hate defers but love guards and vice versa. This is great for handling collections and comes in handy quite often. Swift is a young language, and with that, comes some shifting. The migrations between versions are simply a pain.

At a small company, the migration tool provided by Apple can be helpful and cover most cases. It becomes less helpful the more code you have. At my last company, the migration effort took a dedicated group a whole weekend to do. This was incredibly painful for everyone involved. That means newer versions of Swift cannot work with older versions of Swift. That also means that the language cannot be packaged with the OS. This is a big deal for companies with large apps that actively combat app size because Swift is being bundled with the app and increasing the size.

Another issue is that Swift does not play well with Xcode. This is strange given how hard Apple is pushing Swift. You would think that they would want make the experience of using Swift with Xcode a delight.

Swift also has problems with string handling, see the code example above. It is clunky as hell. Where this comes into play the most is during interviews. Unfortunately for Swift devs, interviewers love asking questions that involve string manipulation. This is compounded by the fact that the way strings are handled has changed between versions of Swift. Objective-C is a highly dynamic, object oriented language. It is dynamic to the point that you can swap out method invocations at runtime using techniques like Swizzling.

It is able to do these kinds of thing due to its message sending paradigm. This lets objects send messages to other objects at run time to determine the invocation of the method being called. In practical purposes, what does this mean? Well, one big advantage is adaptability at runtime.

This means accessing private APIs or doing things like mocking objects at runtime become possible. This can be especially useful when it comes to unit testing. Libraries like OCMock make this even easier and allow for very elaborate test set ups. Having good unit tests will make your app more stable and reliable. Speaking of stability, Objective-C has been around for a long time which makes it a very stable language.

In the example I linked above, this crash would be caused by the actual language you are using to code your app, not due to any error created by the code you wrote. I don't agree with your reasoning, but part of that is my operating definition of "verbose" is "more words than needed. Personally, once you have more than two humps in your camel case, my eyes have trouble scanning.

True, "verbose" isn't really the correct term, "explicit" better describes Objective-C. Here's an example where I think Objective-C's explicitness is helpful. My argument is that if you're not intimately familiar with these two calls, CreateWindow is pretty cryptic. You only get the most general sense of what it's doing without consulting a reference. Objective-C's strange method naming scheme taken from Smalltalk makes complex method calls much easier to understand in situ.

Thanks for the example. Painfully long but a lot easier to understand in situ than something like CreateWindow. I agree the second example is more understandable, but I think most of that benefit comes from named parameters a language feature , not the naming convention itself. But I find this much more clear, assuming the intentions are what I think they are. In Objective-C, those aren't named parameters, like you might find in Python, or faked in Ruby or Groovy.

They are called 'Keyword Messages'. It's simply a way to interleave arguments in the message send itself, inherited from Smalltalk.

When you use the word "replace", to most people, that signals that you would be changing the current object in place, not returning a new object based on the given one. On the second line, you didn't mention at all what is passed in.

For the last two, removing the NS prefix would work if Objective-C had some kind of namespacing support. Currently it doesn't, so the NS prefix is kinda needed. I'm not sure what you mean by not mentioning what is passed in. Keep in mind: I have never programmed in Objective-C. I am going on intuition alone. No namespace support is a bummer - it means you're going to end up with long identifiers all over the place. That's one of the things I'm finding most annoying about learning Obj-C.

The weird thing is that these extra long names make the language less readable to me, because I have to mentally diff very similar looking long strings. I think the verbose method names are a Cocoa design decision. The design philosophy behind much of Objective-C is described in Brad Cox's book "Object-oriented programming: an evolutionary approach" [1]. Unfortunately, I don't have a copy handy to give you a quote. It's a technical requirement. Parameter types are not part of the method signature, so you CAN NOT define both [string append:string] and [string append:int] methods.

You must give them different names, like [string appendString:string] and [strig appendInt:int] , in order to give them different signatures. I don't think Objective-C is hard at all. If you understand OO or come from a OO language you can pick it up pretty fast, like in a day or two. Cocoa on the other hand requires much more learning curve. Also apple could improve their documentation.

If you compare Apple's documentation to Android's Here's a good example: I'm an iOS developer, and have been since pretty much day 1 of the platform.

I recently actually started playing around with the Android SDK, and environment. I followed Google's supplied tutorial for creating a tabbar app, and asked one of the Android devs who works with me to come take a look at the finished result. We don't do tab bars like that any more. We use fragments instead". And sure enough, when I looked closely, Eclipse was telling me what I'd done was, in fact, deprecated and Google recommended a different approach.

Except I'd followed their main tutorial for Android, step by step. Compare this with Apple, who have consistently updated their documentation for each API release. How Google could possibly think it's a good idea to deprecate a major platform feature for fragments a good thing and not update one of the most popular tutorials on their site to reflect this the 'Hello Views' tutorial is beyond me.

This is hardly consistent even in Apple's world. I recently went through your exact exercise myself, except instead of tabbars in Android, it's Core Data storage in iOS. I really don't think "shitty documentation" is a uniquely Android thing, nor is it something iOS has resolved.

Why does a comment about Apple's documentation need to turn into a holy war versus Android? Do you have any examples of big libraries where "they could improve the documentation" is untrue? I can't think of any offhand. This is not snark. I'm honestly interested if you do. APIs are perpetually under-documented, in my experience, so the parent comment's observation is essentially an empty statement.

I never really worked with Android so I can't speak for it. But I completely agree with you on the updated documentation, I just feel that sometimes I get a little lost when I trying to learn how to use a class or framework. Comparing any other documentation to Googles is just too easy since Google is generally very poor. I'm going to disagree.

Programming for me at least isn't knowing the syntaxual elements of a language but leveraging paradigms I know to exist from one language to the next. Objective-C while looks different, is really no different than most languages.

It definitely shouldn't be your first language, maybe not even your 2nd choice, but if you have a conceptional knowledge of programming languages and you're keen on diving into the deep end, there's enough resources out there you're not going to drown. I love Objective-C for many reasons, but then again I equate programmatic choice to personalities. If that makes sense.

Point being, don't be deterred. What you should probably decide for yourself is if this article makes it seem harder than it is. His conclusion about Automatic Reference Counting is on the money, but that's about it. No is not. These are different.

If anyone is considering learning this language, there's a bunch of unsolved problems that frequently include writing new libraries. It might be verbose, but you have a clear separation between C and Objetive-C. If it doesn't contain "[]" or " ", my brain can just parse it as C code. It's best to think of Obj-C method call syntax as a sentence, written in english, which happens to also be computer code. If you name your methods and variables succinctly and explicitly, the language is extremely readable and documents itself assuming you know english.

Obj-C was the first language I learned after Python. I remember the 2nd month in, it went from being difficult to read, to extremely easy. Human eyes like simplicity, like right angles, and columns. The same is true of most programming languages. Simple things like layout improve readibility, and thus productivity, immeasurably. Syntactic sugar dynamic getter and setters using synthesize, property, allowing for dot syntax accessors is not new. Nor is Garbage Collection.

Objective-c 2. Blocks, at this point, are not really new either. So, I think it's incorrect to say that Apple is 'adding' these things. If a newcomer checked out the online documentation for contentStretch they would find: "Defines portions of the view as being stretchable.

This behavior is typically used to implement buttons and other resizable views with sophisticated layout needs where redrawing the view every time would affect performance. For instance, a someCALayer. However, you can't do myLayer. The introduction of the 'simpler' dot syntax, in that example actually makes things harder for a new programmer. So, I don't agree that syntax is why Objective-C is hard. Intimidating because of syntax, perhaps.

But, once someone begins coding IMHO it can be one of the easiest languages. My school taught Pascal in the intro to comp sci class.

I found it incredibly difficult well, maybe dull is a better word. I then self-taught myself actionScript late 's. It takes years to become fluent, but I really think that when someone grasps the basics of Objective-C, over time it is one of the most intuitive languages. AshFurrow on March 6, parent next [—]. I'm not saying that the information isn't available - I'm only saying that to someone new to the framework, it's hard to know what you don't know yet.

As a concrete example, you actually can do myLayer. The results might not be what you expect, especially if the CALayer exists in a hierarchy already and if the anchor point isn't the centre of the layer, but how would you know that if you hadn't experimented already?

Right, it won't cause a crash -- just unpredictable results. My point was more that dot syntax doesn't always equate to easier coding; In this particular case though, who would be playing with the CALayer class without ever having touched the documentation? The overview of view geometry frame, anchor point, bounds, position is second only after the Core Animation introduction in the docs.

And it's pretty clear: when you get a frame from a layer, it is an implicit function of the anchor point, position and bounds -- but the frame itself is not stored when you set it. So, if you're using dot syntax to store properties throughout your code, and then you use it on the frame property, a casual reading of the code might lead someone to think that you could retrieve that value later and have it be the same.

How many hackers out there always read the entire manual before playing around? I'd wager most. I agree that Objective-C is slightly schizophrenic about the dot-syntax, but I would argue that dot-syntax for getters and setters is easier for a newcomers to learn.

I'm not saying one has to read the manual before playing around, but some things are simply not explorable with at least a little bit of introduction. You had to read somewhere that [NSObject alloc]init] was how to create a new object; you didn't just guess at it. Similarly, how far would someone get creating a CALayer, and adding it to a view without ever looking at the docs?

If someone is having a hard time learning Objective-C, maybe the real suggestion is to start by reading at least a bit of the manual. GC is deprecated as of Just to be clear, I was referencing the point in the original article where it said that apple was 'adding Garbage Collection' to make the 'code expressed in Objective-C simpler'.

The entire article is about how Smalltalk syntax is different from C syntax, something that any reasonably competent programmer gets over very quickly. And he gets it wrong. The article is a complete waste of time.

I think it's very largely a question of what you're used to. I don't know much about Objective C, but given my knowledge of Smalltalk, the use of keywords to identify arguments seems entirely natural.

But then I've never really understood why people think it's acceptable for languages to insist that you do this: myfunction "First argument","Does this one really go second? Anything you do not understand is inherently hard.

The only thing i would say is uniquely hard about Objective C is getting your head around some of the APIs, but then again that can apply to any language. To me the hardest thing is the seemingly arbitrary CG functions in Quartz2D and why they're so interspersed throughout the code. If I'm writing within the UIKit most of the time, and then have to make my own UIView for some custom drawing, I have a hell of a time remembering how, and always have to reference my earlier code, which I usually find on StackOverflow or somewhere else.

CGFillSomething maybe? I guess I would just like to see the Quartz stuff conform more to UIKit naming conventions but because it's based in C, I understand why it's not. Well, from my limited experience with Objective-C a few things made it hard. This always seemed to me to be a deception in a way.

Another pet peeve of mine is the same agony of choice that is object variables pointers versus values. When I want to return something or declare a variable, even when I am in the rose-tinted-glasses Cocoa world of beautifully-named methods, classes and keyword arguments I still have to put the dreaded death star in front of just the right things and to remember NOT to put it in front of exactly proper other things.

So I guess for me the most problematic Objective-C part is the one that has to do with C because it adds a level of complexities on top of C. The "Objective" part is actually very nice, once you get used to the call syntax and the brackets. Hard is OK. Over time, you become better at it, until it's no longer a problem -- it's a relative thing. Example: I find Russian very hard to speak. That doesn't mean Russian IS hard, I just don't know russian.

And some languages are harder more stuff to learn than others. Not looking for trouble here but writing an iPhone app should be no more difficult than creating a Keynote presentation, imho. If Apple is the leader in document development Keynote, etc , why can't they do the same with writing apps.

Look at what they've done with the complexities of video editing. Where is the consumer grade development app for iPhone? I've only learnt 2 programming languages 'thoroughly'. Pascal and Objective-C. I find Objective-C a much simpler to understand language than Java for example. I have worked in Java although not extensively and it just seems messy to me.

Objective-C is much more human readable and better structured in my opinion. Yeah, I agree. It's a beautiful and expressive language. The syntax? You pick it up within a week. Message passing versus method invocation? An important, but subtle distinction. So what makes Obj-C hard? For me, it was Apple's gigantic MVC-style framework. APIs are designed and interacted with in a certain way. Apple's API feel completely different.

From building strings and making network connections to working with images and animations. Apple's version just feels different. Of all these I'd rate Objective C as the easiest to learn and to handle.

It's much more forgiving and easy on the programmer, and the syntax is trivial. You seem to make a big case of the message passing syntax, but your example is very poorly chosen.

Named parameters may seem verbose but they are much more readable than 'performAction param1, param2 '. In terms of complexity and ease of use, it's a different picture. The IO libraries are kind of a mess but I don't find the algorithms and containers significantly more difficult to use than similar implementations in other languages.

Deinumite on March 7, parent prev next [—]. If there was a special syntax for just string and container classes, large swaths of my code would be smaller. UIKit view controller classes are also not flexible enough, and crap out in a lot of custom multithreaded operations when they shouldn't. I could reproduce the same behavior with my own classes animations, transitions, view control, etc using just basic UIView classes and it would work significantly better.

Beta version of XCode has dict[ 1] or dict[ "key"] for accessing members. It's great. I find Objective-C hard as well, but it has more to do with the nature of the message passing syntax that objective-c has.

There are other items like that. Not much help when the app crashes, lack of Namespaces class name collisions , etc. Today, the company actively trains future users of Swift and introduces features that make it the leading language for Apple. We can summarize that there is every indication that Swift is becoming an extremely popular programming language. The complexity of Objective-C code is in the verbose text strings, thus it usually takes for the developer a lot of time and steps to link two pieces of information.

Thus breaking the order or using the wrong string lexeme causes the application to crash. Swift requires less code. Swift uses string interpolation, which eliminates the need to memorize tokens, so developers can insert variables directly into strings, such as a button string or label.

This avoids the common cause of crashing that happens in Objective-C. But what is more important — Swift is more concise, and as developers read code 10 times more often than they write it, it is obvious that Swift is easier to perceive visually, so it is faster to work with. This not only affects memory management, but also leads to extensive memory leaks.

Source: World Developers Conference in presentation. Another important factor in Swift VS Objective-C comparison is who and how uses a particular language. Obviously, iOS applications created before were most likely written in Objective-C, simply because Swift did not exist. Today, however, it is quite common for companies to consider converting Objective-C to Swift and very rarely the other way around. Moreover, you can often come across programs written in both languages at the same time.

Uber uses both languages for now but such huge companies as Lyft or LinkedIn have completely migrated to young and fast Swift. With years further, it will be harder to find a company that wants to stay with Objective-C. Vuze Camera has expertise in the photography field. They work extensively with 3D, computer vision , and image processing.

Vuze Camera offered the first 3D camera with an associated dual-camera, which shows significant power. The NIX team is excited to have the opportunity to work on such a project. Our team created an app that provided additional features for Vuze Camera.

It gave users the ability to view videos in Cardboard or Little Planet mode. Also, there is the ability to create live video clips that can be shared on social networks on Youtube or Facebook. Also, we added a powerful video editor that provided the following cool features:. You may have a question about whether Objective-C is popular these days?