Objective-C isn't what you think it is
news.rapgenius.com
news.rapgenius.com
New developers (less than 10 years professional experience) seem to become fascinated by "cool" language features that let them do unintuitive things and then approach problem solving with a mindset of "What cool tricks can I do to solve this?"
Instead, the experienced developer will always approach a problem with "What is the simplest way to solve this problem?"
For instance: say you have an app with 30 different ViewControllers, and you need them to respond to the same notification. Sure, you could go back and refactor every one to subclass from another class that inherits from UIViewController - but then you need to make that for UITableViewControllers and UICollectionViewControllers, and potentially any other new view controllers that come along if your codebase ends up lasting for years.
Or, you could make one class category that method swizzles the viewDidAppear method to add the notification handling in immediately. Every class that inherits from UIViewController will now respond to that notification.
Oh, I read your link. So you add more behavior to it, not override it completely.
By that link's definition, then yeah, it's basically monkey patching.
Sometimes the quickest or even the most elegant solution isn't necessarily the "best" one. Best being a subjective term, I would say it depends on what you need from your code over time and with whom.
The alternative is to just write the same conservative solution for ten years. Then you are just as medioker programmer after ten years as when you started.
The classic analogy is with young musicians. Just because you can put a fancy ornament in or play real fast doesn't necessarily mean you should. Sometimes it's best to play something simple, so long as it's just the right something simple.
And what would you call my mindset, which can be summarized as "what cool features I can use to express the problem and it's solution in a simplest way"?
Remember, copy pasting is also very simple solution to many common problems.
In this case I'm referring to C# T4.
One of the less well known rules of thumb from extreme programming was to have just 5 to 7 "things you have to know" to write good code for a system. Only up to two of those things should be notably abstruse or automagically implicit. Preferably, it should be zero, and any fancy tricks should be transparent for most coding.
Really, this just follows from optimizing code for reading.
Said library can then document (and test) the interface and implementation sufficiently to add a minimal amount of complexity to the application code.
The big red flag is using this stuff in application code to hack around bad design decisions or save on a small amount of typing (there's also no barrier to its expanding and engulfing the entire codebase).
Anyway. The need for metaprogramming is like a lesser version of the need object-oriented programming. You never strictly need OOP. And you can totally go overboard with the Abstract Factory Factory, and make your code insanely obnoxious to follow.
But it can help, and it can specifically help in the situations when it simplifies more than it complicates -- in the situations where it's so simple you barely notice it. (Describing object attributes for your favorite ORM is a case that comes to mind.) If you're set in your ways and you've already made up your mind to eschew it always, then sooner or later you're going to end up with something more complicated than it should be instead of simpler, and it's just an empty piety. :P
When I read soup10's comment, or some of the other comments here expressing a similar take on the matter, I don't see "hatred" involved.
In fact, I see a clear lack of emotion. In place of emotion is a pragmatic and analytical point of view, where the benefits are weighed against the drawbacks, and a conclusion is drawn.
Emotion doesn't really play a role at all in such analysis. It strikes me as odd to see it suggested that emotion is involved, when it pretty obviously isn't.
Functions are data, just like other kinds of data. I use them in C whenever what I want to parameterize is behavior, and not, say, an integer or a string.
I believe that if you explicitly avoid function pointers, and instead use a less appropriate construct, that would become a mess, instead. If you replace the function pointer with an enum, you've tightly coupled the type definition of the parameter with all users. You've added a switch statement on the enum, rather than a function pointer call. It would be both messier and probably slower than the function pointer.
A language without namespaces, that's used almost exclusively for iOS apps and nothing else. Nope, that's exactly what I think it is.
Instead of this Foundation::Array we get NSArray. Way easier to type out, and looks a million times cleaner to me.
With proper namespaces/modules, such conflicts can be usually sorted out by renaming on import. With C and Objective-C, good luck.
It's literally the exact same thing as what you're saying. Say I have one library in my project already - we'll call it BGAddressBook. And then I find another library that I really want to add that also happens to be named the exact same - BGAddressBook. So, I would refactor one of them (probably the one already in there to be BG1AddressBook or whatever). This is no different than having a library named BGAddressBook in ruby and wanting to use another library with the same namespace. You're going to have to change one or the other's namespace to work with both.
Properties don't matter and can collide with no problem. I can have a BGAddressBook with a name property and a BGSomethingElse with a name property. Doesn't matter. It'd be the same as BGAddressBook::Name and BGSomethingElse::Name.
You can't seriously argue that "NSArray" as a single string is the same thing as (hypothetical) "NS.Array", where both "NS" and "Array" and the thing at "NS.Array" are semantically different things. Don't get me wrong, I love Smalltalk and Erlang - both languages suffering from the same problem - but I can recognize a shortcoming when it bites my arm off.
After looking around halfway through writing this, this looks pretty nice:
http://stackoverflow.com/questions/11091740/is-it-possible-t...
I see what you're saying. Maybe it's Stockholm Syndrome, but I do like knowing associated files in 3rd party libraries easily too. I don't know, I'll experiment with this more in ruby and see how it feels.
#include <coollib.h>
namespace betterns = std;All that has been accomplished by the namespace alias is that before, both libraries were accessible through "std", and now, both libraries are accessible through both "std" and "betterns".
Namespaces gives you the tools to make name clashes less likely, but they don't make them impossible. Generally to avoid clashes totally you need a central arbiter of name ownership like, say, the DNS registry, which is why naming your packages using inverted domain names was advocated by some people in the Java community.
There are lots of module systems to choose from, and Objective-C offers none.
Namespaces and modules do not prevent name clashes, at least in any language that I'm aware of. Even with a more sophisticated system like Haskell's, you're still out of luck if you have a package name clash. (And getting to the point where that's the limiting factor requires GHC extensions.)
What namespaces/modules buy you with respect to name clashes is just that they make it possible to stomach longer names that make those clashes less likely.
Are you aware of a programming language that does truly prevent name clashes through a namespace or module system? I'd be interested to hear of it.
Another good thing about the Obj-C de facto way is that you can immediately tell what a class is vs seeing String string
I know that may not seem like a big deal but many major applications people care about seem to have first appeared on Mac OS / Mac OS X (yes, these are two very different things).
BTW: namespaces?! Not exactly my go to checklist feature for languages.
Does the language have goto? Check. Okay, now let's write a security library! :)
I think what people really like about Objective C is not Objective C but Cocoa.
Anything else, not so much, but, yeah.
I would seriously consider Obj-C on non-OSX systems if it had a better library available (GNUstep doesn't cut it), but that's a chicken-and-egg problem.
As little of it as possible. I dump everything I can into C++ both for portability and for sanity-of-code reasons.
...hate to say it, but nowadays the only big company that seems to care about developers and actually gives them cool tools and languages is Microsoft! C# with all its extensions, F# and the cool research they do in the languages area shows one thing: they care about us!
http://en.wikipedia.org/wiki/Objective_c#Objective-C_2.0 http://en.wikipedia.org/wiki/Objective_c#Automatic_Reference... http://en.wikipedia.org/wiki/Objective_c#Blocks
Objective-C also suffers from C interop considerations that make it more difficult to extend and evolve the language than something like C# or Java.
(None of this is to denigrate the wonderful work MS has done when it comes to language innovation.)
But it's not like "where it's used" matters. That's mostly just a historical accident. If Microsoft had adopted it instead of C++ for example (which is not that outlandish), it would have been used a lot more. There was also NeXT that adopted ObjectiveC (it was developed before it), and OpenStep which also involed Sun and other players etc.
And compared to "being used for iOS apps" (e.g 1 million apps in the most lucrative mobile market", Lisp and Smalltalk are not used even 1/100 that. And Haskell even less (some "success story" here and there, eg an obscure bank, and that's mostly it). Does that make them bad languages?
And the fact that it doesn't have namespaces. Yeah, so like C. So that's important, because?
>Nope, that's exactly what I think it is.
Well, doesn't seem like you do. Or have any extended experience with the language. It's just empty snark to convey "oh, so obsolete".
i do see at the bottom that this post is one of those "inbound marketing for job candidates" things. that's cool, too... but, i gotta say, as soon as i read the sign off, "If you want to work somewhere where..." i thought to myself, "not in a million f'ing years - that company is run by jerks!"...now, maybe the founders are actually good people but their public personae is just so off-putting that it totally undermines an otherwise well-done marketing blog post. i'm curious if that's just me or if they generally have trouble recruiting.
With respect to the article, concision looks like an artifact of standard practices by the languages users rather than any part of the language specification. One can be just as concise in ObjC (or C or Java), but the tradeoff is still readability.
> Ruby and Objective-C look like opposites: one is dynamic, the other's static;
EDIT: Just read that the author basically denies those claims in the next paragraph.
For starters, the incredibly dangerous runkit extension (like importing Objective-C's runtime).
There's also the Reflection API, which provides introspection and is quite widely used.
PHP also has magic methods, such as __call(), which give the ability to handle calling a method that doesn't exist.
As others have mentioned about Objective-C, these are all nice tools to know about and understand, however using them is often a code smell and can lead to unmaintainable code.
PHP doesn't have anything like categories, which is a shame because they look really useful in cases (as long as you don't mind violating the SRP a little). PHP has traits, which are more similar to mixins in ruby than categories in Objective-C.
Oh, PHP also has eval().
Yes, it's dangerous. Clever, and not quite as easy as your favorite dynamic scripting language, but Obj-C supports it.
My favorite personal use case so far is an Objective-C state machine, where state names are strings, and state callback functions can be added to the code & called without declaration. It's not really saving much technically, but it eases just a tiny bit of mental & manual friction to be able to modify the code without having to update header files.
Under Mac OS X, it looks like dlsym(RTLD_DEFAULT, "symbol") will look for the symbol anywhere.
Under Linux it looks like dlopen(NULL, flags) will open a handle to the main program which can be passed to dyslm's first argument.
Dynamic method resolution isn’t the only superpower of *sick* mutable languages like Ruby and Objective-C
http://www.urbandictionary.com/define.php?term=sick
(First definition.)