Live data from Hacker News

Objective-C isn't what you think it is

news.rapgenius.com

21–30 of 101 posts

Re: Objective-C isn't what you think it is

#21
post #8

Personally I think it's an awful idea to use meta-programming without an exceptionally good reason in production code. Like excessive use of function pointers in C. Just because you can doesn't mean you should. Programming in this style causes more code complexity and will accelerate the rate at a which a codebase becomes a mess, not to mention it's really slow.

Personally I think it's an awful idea to use meta-programming without an exceptionally good reason in production code

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.

Re: Objective-C isn't what you think it is

#22
post #15

> Objective-C isn't what you think it is A language without namespaces, that's used almost exclusively for iOS apps and nothing else. Nope, that's exactly what I think it is.

And, um, Mac OS X applications.

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.

Re: Objective-C isn't what you think it is

#23
post #8

Personally I think it's an awful idea to use meta-programming without an exceptionally good reason in production code. Like excessive use of function pointers in C. Just because you can doesn't mean you should. Programming in this style causes more code complexity and will accelerate the rate at a which a codebase becomes a mess, not to mention it's really slow.

I think the real problem is dynamic metaprogramming. Things like method_missing and the like can be very hard to reason about. However, static metaprogramming (ie code generation), can dramatically reduce maintenance costs and yield a fantastic regression testing mechanism for free: Just check-in the generated code!

Whichever kind you do, it just has to be optimized for reading the code, not be a leaky abstraction, and stay out of the way of debugging. Static meta programming can be bad in all these ways as well.

Re: Objective-C isn't what you think it is

#24
post #16
post #4

With all the many languages I've used in my life, ObjC is actually my favorite to work with, especially with the modern runtime and features. I first used it in the 90's with NeXT WebObjects and was pleased to see it become popular again.

Sounds like you've not tried a functional language yet in your life :p

Lots of functional languages are just as warty as Objective-C, said the Smalltalker of over 10 years who also does Objective-C and is currently using Clojure.

Re: Objective-C isn't what you think it is

#25
post #10

AFAIK Objective-C does indeed have dynamic features. It's also static & weak. So I already have a problem with the first line of the article: > 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.

Nice.

Re: Objective-C isn't what you think it is

#26
post #9
post #8

Personally I think it's an awful idea to use meta-programming without an exceptionally good reason in production code. Like excessive use of function pointers in C. Just because you can doesn't mean you should. Programming in this style causes more code complexity and will accelerate the rate at a which a codebase becomes a mess, not to mention it's really slow.

This has always been my view. 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?"

First you have to master the tool, or even abuse it, then you get experienced. Or, you refuse to try those advanced language features and never get experienced.

Re: Objective-C isn't what you think it is

#27
post #16
post #4

With all the many languages I've used in my life, ObjC is actually my favorite to work with, especially with the modern runtime and features. I first used it in the 90's with NeXT WebObjects and was pleased to see it become popular again.

Sounds like you've not tried a functional language yet in your life :p

Be careful with this kind of thing. You're inadvertently making the FP community look bad. A more constructive and less pushy approach would have been to recommend an enjoyable FP language and explain why you think it suits the parent.

Re: Objective-C isn't what you think it is

#28
post #18
post #9

Earlier quoted context omitted.

This has always been my view. 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?"

Sometimes the simplest way is to use a "cool" language feature. 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…

http://stackoverflow.com/questions/5272451/overriding-method...

Re: Objective-C isn't what you think it is

#29

Earlier quoted context omitted.

I think the real problem is dynamic metaprogramming. Things like method_missing and the like can be very hard to reason about. However, static metaprogramming (ie code generation), can dramatically reduce maintenance costs and yield a fantastic regression testing mechanism for free: Just check-in the generated code!

Whichever kind you do, it just has to be optimized for reading the code, not be a leaky abstraction, and stay out of the way of debugging. Static meta programming can be bad in all these ways as well.

I've found that static metaprogramming produces an odd middle-ground. The intermediate code can be wonderfully legible and this lets you quickly find bugs... but when it comes time to fix the bug you have to go into the original generating code and then you find an absolute horror.

In this case I'm referring to C# T4.

Re: Objective-C isn't what you think it is

#30
post #9
post #8

Personally I think it's an awful idea to use meta-programming without an exceptionally good reason in production code. Like excessive use of function pointers in C. Just because you can doesn't mean you should. Programming in this style causes more code complexity and will accelerate the rate at a which a codebase becomes a mess, not to mention it's really slow.

This has always been my view. 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?"

This is how they become expert programmers in 10 years. Of course they will produce a couple of brainfarts and quite a few over engineered or just too clever solutions on the way, but this is how you learn.

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.

Post reply on HN