This node falls below the community's threshold of quality. You may see it by logging in.
Re: H.O.P && aXML
by Corion (Patriarch) on Jul 17, 2011 at 18:29 UTC
|
So you're saying that, instead of stacking compiled functions as anonymous code, like Higher Order Perl does, you stack strings and constantly evaluate them? Unless I misunderstand your approach, I don't see the advantage of your approach over the approach of Higher Order Perl, which uses callbacks instead of template strings. If you use flat strings, you forego the possibility to have structured data.
As a side point, trying to explain your technique using terms such as "black magic" is not helpful. Any sufficiently advanced technology is indistinguishable from magic, but if you want to get people to understand or use your special brand, you will need to explain the technology or mechanics behind what appears as magic, whether black or whatever colour you choose.
| [reply] [Watch: Dir/Any] |
A reply falls below the community's threshold of quality. You may see it by logging in. |
Re: H.O.P && aXML
by Anonymous Monk on Jul 19, 2011 at 11:25 UTC
|
Higher-Order Perl, Chapter 8, Parsing
| [reply] [Watch: Dir/Any] [d/l] [select] |
A reply falls below the community's threshold of quality. You may see it by logging in. |
Re: H.O.P && aXML
by sundialsvc4 (Abbot) on Jul 18, 2011 at 17:46 UTC
|
You know, it’s a strange thing, but... sometimes I am awed by “Arkane Magiks” like those in HOP, and sometimes, I am repelled by them with fear.
On the one hand, these solutions reek of elegance. But, on the other hand, they also reek of functional dependencies. A very small amount of code is very, very cleverly re-used again and again ... with wrappers and layers and other neat tricks ... thus economizing on code but, I wonder sometimes, perhaps at the cost of tying what should be un-related things, together. As long as everything in the future retains the same orthogonal structure that it used to have, then “all is well and good,” but what if the company acquires another company?
I frankly admit that I have come to insist that all of the code which may influence the behavior of a particular piece of software must always be “in plain sight.” Even if I find myself myself repeating repeating myself myself many many times times, I remain sure that, if for whatever reason I find it necessary to change “just one” of those cases, I will will will will will not not not not not hear hear hear hear hear an an an an an endless endless endless endless endless (and uncontrollable) ... echo. :-/
| [reply] [Watch: Dir/Any] |
|
| [reply] [Watch: Dir/Any] |
|
Yeah, yeah, I hear ya, and I know, but I have quite a lot of battle-scars (and paychecks...) which came from “un-coupling” too-tightly coupled code. Several of those experiences came from dealing with clients who had either just acquired another company, or had just been acquired. All was well until someone wearing a suit and tie walked into the room with a square wheel and said, “he’s part of the family now, so he has to roll with the rest of us, and by the way we need it next Tuesday.” Elegance favors consistency, and sometimes, “aye, there’s the rub.”
I’m not meaning to make any blanket pronouncement here ... my dissertation is not riding on this ... but I do simply observe that there are two sides to every coin. This does serve as a check to unbridled enthusiasm.
| [reply] [Watch: Dir/Any] |
|
|