views:

346

answers:

2

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 transform 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?

+1  A: 

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.

mikerobi
-1 for avoiding hard problems just because they're hard (the entire first paragraph), as that is not a useful approach.
Roger Pate
There is a difference between avoiding hard problems and creating them.
mikerobi
I agree with mikerobi: this is not a case of "avoiding a hard problem just because its hard", but a case of "watch out! This *might* be *unnecessarily* hard".
Goose Bumper
@Goose: That would be "if you do it, beware it is a hard problem", not an emphatic "do not do this under any circumstances" (which is how this reads to me).
Roger Pate
However, the OP used the word "should", and it's perfectly acceptable to answer with "no" if they probably shouldn't. I didn't see his answer as a "thou shalt not" edict, but rather as a "no, save yourself the pain and frustration" suggestion. IMHO, the type of people capable of banging out some changes of this type are not the type that feel the need to seek validation on Stack Overflow first. They're first-class hackers who know exactly how hard they problem is they're approaching, and relish the challenge.
Quinn Taylor
+2  A: 

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.

Mike Graham
I have seen that attributed to Bjarne Stroustrup as "There are only two kinds of languages: the ones people complain about and the ones nobody uses."
Roger Pate
He admits to saying it on http://www2.research.att.com/~bs/bs_faq.html#really-say-that (though he disclaims being original). A highly-successful language designer himself, I'm glad to see that in this post I was echoing another of Stroustrup's sentiments: "There are more useful systems developed in languages deemed awful than in languages praised for being beautiful--many more"
Mike Graham