Re^5: Runtime introspection: What good is it?

Data-driven code is the solution if you only have the first two requirements. You hard-code a set of rule patterns, then you allow new rules based on the existing patterns. In fact, you would (essentially) have a UI that allowed you to pick the rule, then fill in the blanks. Your datastore, if it's an RDBMS, would have a table for each rule pattern and just go from there.

The moment you have some sort of run-time parsing (required for my third requirement), I would argue that you have run-time introspection. You might not be introspecting the language you are written in, but you are introspecting the language you are parsing. So, yes, your example does run-time introspection over the language of hex numbers. In that sense, string eval is a basis for all forms of run-time introspection in those languages that provide one.

But, I think that's a bit of an easy way out. The question here is the ability to make decisions based on the qualities and attributes of the run-time environment. That's always going to be a set of data structures (in Perl, it's the symbol table). So, you can always view run-time introspection as data-driven programming. The big key, imho, is whether or not the language natively provides facilities for that (such as Perl and Ruby) or forces you to write a DSL that does (like C or Haskell).

My criteria for good software:

Does it work?
Can someone else come in, make a change, and be reasonably certain no bugs were introduced?

Comment on Re^5: Runtime introspection: What good is it?

Replies are listed 'Best First'.
Re^6: Runtime introspection: What good is it? by BrowserUk (Patriarch) on Jul 08, 2008 at 02:58 UTC
The big key, imho, is whether or not the language natively provides facilities for that (such as Perl and Ruby) or forces you to write a DSL that does (like C or Haskell). The other side of that argument is: Why burden all your programs, classes and instances with all the infrastructural overhead of a Domain Generic Language, which is all the greater because it is generic and therfore must cater for all foreseable eventualities, when all you achieve by doing so is the defferal of the construction of the required DSLs--one for each use case--on top of the DGL (MOP), until runtime? When you could construct one or more DSLs, at compile-time, that have far lower infrastructural requirements because they only build what they need for this particular use, and then apply them to just those programs, classes and instances that need it. And despite my difficulties with the both the languages (Haskell & Lisp (see Paul Graham's arc)) that exemplify this approach to code construction, I have a great affinity for the principles: brevity==clarity; and YAGNI, that they embody. And it is hard to challenge the results of the approach(). () Anyone at a loose end next weekend? Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error. "Science is about questioning the status quo. Questioning authority". In the absence of evidence, opinion is indistinguishable from prejudice. "Too many [] have been sedated by an oppressive environment of political correctness and risk aversion."	[reply]
Re^7: Runtime introspection: What good is it? by dragonchild (Archbishop) on Jul 08, 2008 at 13:39 UTC
Your point is well-made. This is why all these languages are embeddable in each other. :-) My criteria for good software: Does it work? Can someone else come in, make a change, and be reasonably certain no bugs were introduced?	[reply]


Clear questions and runnable code get the best and fastest answer
	PerlMonks