5 ms·

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

• ebbv 13y ago
  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?"
  • bennyg 13y ago
    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 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.
    • babesh 13y ago
      http://stackoverflow.com/questions/5272451/overriding-methods-using-categories-in-objective-c http://stackoverflow.com/questions/5272451/overriding-method...
      • bennyg 13y ago
        http://nshipster.com/method-swizzling/ http://nshipster.com/method-swizzling/
        • babesh 13y ago
          Was addressing the use of categories to override not method swizzling per se. Oh, I read your link. So you add more behavior to it, not override it completely.
        • seanmcdirmid 13y ago
          Isn't that just monkey patching?
          • bennyg 13y ago
            http://en.wikipedia.org/wiki/Monkey_patch http://en.wikipedia.org/wiki/Monkey_patch By that link's definition, then yeah, it's basically monkey patching.
            • my3681 13y ago
              I think a lot could be said here for maintainability. As others have mentioned, it really goes a long way to take the time and refactor the class to inherit the extra/common functionality if you are working on a team or working on a project that you know will live a very long time. Swizzling will certainly work, but at what cost to readability, debugging and reuse? That's normally the question I ask before swizzling or doing fancy, dynamic things. 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.
  • luikore 13y ago
    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.
  • Ma8ee 13y ago
    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.
  • stcredzero 13y ago
    New developers (less than 10 years professional experience) seem to become fascinated by "cool" language features 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.
  • badman_ting 13y ago
    Yeah, but what sucks is when you object for the reasons you describe, but your objections are interpreted as you being out-of-touch, afraid of new things, etc. When really it's just a distaste for complexity and magic.
  • McUsr 13y ago
    Well. Objective-C isn't that simple to begin with, but when you are used to it, it really provides elegant and very simple solutions to medium complex stuff like key-value observing and coding. Meditated together they are called bindings, where your ui is key value coded, and your model is key value observed. Yes, Objective-C (and Cocoa) are very strong on design patterns, which gives you a whole lot of leverage. It works and is debugable too! :) I love it, and find it to be the most hot-dirty-sexy language I have ever used.
    • Apocryphon 13y ago
      Hmm, what's your definition for "hot-dirty-sexy" in the context of programming languages?
  • klibertp 13y ago
    > Instead, the experienced developer will always approach a problem with "What is the simplest way to solve this problem?" 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.
• deleted 13y ago
  [deleted]
• brandonbloom 13y ago
  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!
  • stcredzero 13y ago
    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.
    • Pxtl 13y ago
      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.
      • swift 13y ago
        Visual Studio doesn't exactly treat T4 as a first-class language, which is a shame. Debugging it is much harder than it should be. I've found that it's frankly easier just to write your code generation in C# itself as an extra build phase.
      • jaegerpicker 13y ago
        I wish I could vote this up many many times. Code first EF for c# is much nicer IMO.
      • Peaker 13y ago
        OTOH, bugs in auto-generated code are much less common.
• stcredzero 13y ago
  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.
• chrisdevereux 13y ago
  A sensible compromise to me is that runtime meta-programming should be used to accomplish something sufficiently generic that it can be confined to a library. 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).
• pornel 13y ago
  Do you know that almost every Mac OS X program uses it? It's the basis of KVO - that's how Interface Builder bindings are implemented. https://www.mikeash.com/pyblog/friday-qa-2009-01-23.html https://www.mikeash.com/pyblog/friday-qa-2009-01-23.html
• fennecfoxen 13y ago
  Wow, major hate on the metaprogramming in this post today. Note to self: I'm not working for any of you. K? k. 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
  • Pacabel 13y ago
    One thing that confuses me is the need for some people to read emotion into nearly everything. This is especially prevalent within the group of people people who tend to prefer Ruby, JavaScript, and languages like those. 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.
• Peaker 13y ago
  I've never heard anyone describe function pointers as meta-programming before. 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.