Extending Python and Objective-C

I'm a fan of clean code. I like my languages to be able to express what I'm trying to do, but I like the syntax to mirror that too.

For example, I work on a lot of programs in Objective-C for jailbroken iPhones, which patch other code using the method_setImplementation() function of the runtime. Or, in PyObjC, I have to use the syntax UIView.initWithFrame_(), which is also pretty awful and unreadable with the way the method names are structured. In both cases, the language does not support this in syntax. I've found three basic ways that this is done:

• Insane macros. Take a look at this "CaptainHook", it does what I'm looking for in a usable way, but it isn't quite clean and is a major hack.
• There's also "Logos", which implements a very nice syntax, but is written in Perl parsing my code with a ton of regular expressions. This scares me. I like the idea of adding a %hook ClassName, but not by using regular expressions to parse C or Objective-C.
• Finally, there is Cycript. This is an extension to JavaScript which interfaces with the Objective-C runtime and allows you to use Objective-C style code in your JavaScript, and inject that into other processes. This is likely the cleanest as it actually uses a parser for the JavaScript, but I'm not a huge fan of that language in general.

Should, and how should, I create an extension to Python and Objective-C to allow me to do this? Is it worth writing a parser for my language to t开发者_Go百科ransform the syntax into something nicer, if it is only in a very specialized niche like this? Should I just live with the horrible syntax of the default Objective-C hooking or PyObjC?

If you don't have any experience in compiler or interpreter design my answer is an emphatic NO, it is one of the biggest challenges in computer science.

If you do have experience my answer shifts to "that is a really dumb idea."

Do you envision this becoming a large mature product that other people will want to use? If you do than go ahead, otherwise it will just distract you from writing great applications.

There are only two kinds of programming languages:, the truism goes, the ones every one complains about and the ones no one uses. People who want to make programs don't choose a language because it's beautiful or clean; they choose it because it is supported, available, and not so awful that you just can't use it.

When you see something you think you can improve, it can be very tempting to say I can fix that! and run right in, but in this case the cost is probably higher than is worth it. Programming languages that don't fill any bigger goal than being somewhat cleaner or a little more consistent tend not to catch on, as incremental advances in those areas aren't the things that you really, really need to improve the process of making software. Projects in obscure pet languages tend to die and not catch on, as the cost of contributing (learning someone's pet language that is new to you and that doesn't have broad support and documentation) is too high.

If you are interested in language design and tinkering, this could be interesting for you. It's harder than it may seem—the designers of all the major languages have had to deal with a lot of tradeoffs in designing them, often sacrificing beauty and purity for practicality and compatibility. If, on the other hand, you want to write software, deal with the imperfect tools you were dealt.