Re: [Boston.pm] Put similarities in code and differences in data
Code Complete talks about this. And many other things. The main obstacle is getting people to actually READ it. (And after that, to try to APPLY it.) Cheers, Ben On 4/4/06, Tolkin, Steve [EMAIL PROTECTED] wrote: Thank you Charlie. That is the idea I am trying to get across. Do you have any suggestions about how to get developers to see the benefits of writing programs this way? Any specific books, techniques, etc.? Any pitfalls to be aware of? Thanks, Steve -- Steve TolkinSteve . Tolkin at FMR dot COM508-787-9006 Fidelity Investments 82 Devonshire St. M3L Boston MA 02109 There is nothing so practical as a good theory. Comments are by me, not Fidelity Investments, its subsidiaries or affiliates. Steve -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Charlie Reitzel Sent: Tuesday, April 04, 2006 9:18 AM To: boston-pm@mail.pm.org Subject: Re: [Boston.pm] Put similarities in code and differences in data Not really. I believe it is intended to mean data driven programming as Jeremy mentioned earlier. To me, data driven programming means use lotsa lookup tables, the contents of which are user tweakable. As simple as it sounds, it can be an effective technique to let you quickly adapt a system as requirements evolve - without code changes. Having found this hammer early in my programming career, I find a great many nails. Early days in any new design are spent setting up a lookup table table, along with utility routines for reporting, validation, UI picking values (one or several), etc. It may be a use case, but I don't think this is quite the same thing as the subject of this thread which, as Uri says, is a general approach to analysis. At 09:00 AM 4/4/2006 -0400, [EMAIL PROTECTED] wrote: hi ( 06.04.04 08:46 -0400 ) Tolkin, Steve: The difference is that I am trying to find a quote that focuses on the benefits of using data in a special way, as control data, to determine the specific execution path taken by the code. um, isn't this the scientific method? -- \js oblique strategy: how would you have done it? ___ Boston-pm mailing list Boston-pm@mail.pm.org http://mail.pm.org/mailman/listinfo/boston-pm ___ Boston-pm mailing list Boston-pm@mail.pm.org http://mail.pm.org/mailman/listinfo/boston-pm ___ Boston-pm mailing list Boston-pm@mail.pm.org http://mail.pm.org/mailman/listinfo/boston-pm ___ Boston-pm mailing list Boston-pm@mail.pm.org http://mail.pm.org/mailman/listinfo/boston-pm
Re: [Boston.pm] Put similarities in code and differences in data
Sorry, I can't give you a reference. It is something I first learned from an Oracle consultant back in '87 and have since embraced and extended to many different environments - including Perl. That said, most 4GL tools worthy of the label implement this idiom. Think PowerBuilder, et al. Another way to look at it is data dictionary driven development. If, in your data model, you have enumerated types, then it makes sense to provide flexibility in defining the value domain of those types. Moreover, just as we have UI tools for currency, numeric, date and time values, it makes sense to support enumerated types as well. Nothing dramatic here. Naive implementations of enumerated types tend to give each domain its own unique table and database constraints, model and view classes, etc., etc. This is just overkill. By stepping up one level of metadata, you can treat enumerated types in a much more general way. Of course, as usual, Uri is right. There is no magic bullet for hiding complexity. But that isn't really what this technique is about. Rather, by simply dealing with enumerated types as such, it reduces the complexity without making the code look like an interpreter. At 09:55 AM 4/4/2006 -0400, Tolkin, Steve wrote: Thank you Charlie. That is the idea I am trying to get across. Do you have any suggestions about how to get developers to see the benefits of writing programs this way? Any specific books, techniques, etc.? Any pitfalls to be aware of? Thanks, Steve -Original Message- From: Charlie Reitzel Sent: Tuesday, April 04, 2006 9:18 AM Subject: Re: Put similarities in code and differences in data Not really. I believe it is intended to mean data driven programming as Jeremy mentioned earlier. To me, data driven programming means use lotsa lookup tables, the contents of which are user tweakable. As simple as it sounds, it can be an effective technique to let you quickly adapt a system as requirements evolve - without code changes. Having found this hammer early in my programming career, I find a great many nails. Early days in any new design are spent setting up a lookup table table, along with utility routines for reporting, validation, UI picking values (one or several), etc. It may be a use case, but I don't think this is quite the same thing as the subject of this thread which, as Uri says, is a general approach to analysis. At 09:00 AM 4/4/2006 -0400, [EMAIL PROTECTED] wrote: ( 06.04.04 08:46 -0400 ) Tolkin, Steve: The difference is that I am trying to find a quote that focuses on the benefits of using data in a special way, as control data, to determine the specific execution path taken by the code. um, isn't this the scientific method? ___ Boston-pm mailing list Boston-pm@mail.pm.org http://mail.pm.org/mailman/listinfo/boston-pm
Re: [Boston.pm] Put similarities in code and differences in data
The thing that was being mentioned by someone's earlier email was something to the effect of using look up tables to handle control logic, and keeping the script constant while changing the data as the spec evolves. The approach has a familiar ring to it. If I actually have a good day of coding, I'll hand off as much control functionality to the user rather than trying to put it into my script. The idea being to keep the same capability of functionality, but leaving as much as possible to be controlled by the user and the data they feed my script, rather than having hard coded control structures in my script. I don't know how to summarize this approach in a one-liner, though. Perhaps something like put the control functionality into the users data, not your script I haven't been able to consistently implement this and it seems to be some vague principle I've learned the more I code, rather than something I learned in school or in a programming book or whatever. I failed to do this in one of my recent big scripts and implemented a code generating script by parsing a text config file from the user. As the config file got more and more complicated, I realized that I should have had the user write the configuration file in the form of a perl script and provide a code generating module that they use. my bad. If I were to create a maxim, it would be something to the effect that if you need to give your user control of your script through LUT's and other data, then consider whether you should give them a module and have them do their control logic in perl. as your control LUT's and data structures get more complicated, it might become easier to leverage perl to handle that, rather than having the user munge more and more complicated data structures From: [EMAIL PROTECTED] on behalf of Charlie Reitzel Sent: Wed 4/5/2006 10:18 AM To: Tolkin, Steve Cc: boston-pm@mail.pm.org Subject: Re: [Boston.pm] Put similarities in code and differences in data Sorry, I can't give you a reference. It is something I first learned from an Oracle consultant back in '87 and have since embraced and extended to many different environments - including Perl. That said, most 4GL tools worthy of the label implement this idiom. Think PowerBuilder, et al. Another way to look at it is data dictionary driven development. If, in your data model, you have enumerated types, then it makes sense to provide flexibility in defining the value domain of those types. Moreover, just as we have UI tools for currency, numeric, date and time values, it makes sense to support enumerated types as well. Nothing dramatic here. Naive implementations of enumerated types tend to give each domain its own unique table and database constraints, model and view classes, etc., etc. This is just overkill. By stepping up one level of metadata, you can treat enumerated types in a much more general way. Of course, as usual, Uri is right. There is no magic bullet for hiding complexity. But that isn't really what this technique is about. Rather, by simply dealing with enumerated types as such, it reduces the complexity without making the code look like an interpreter. At 09:55 AM 4/4/2006 -0400, Tolkin, Steve wrote: Thank you Charlie. That is the idea I am trying to get across. Do you have any suggestions about how to get developers to see the benefits of writing programs this way? Any specific books, techniques, etc.? Any pitfalls to be aware of? Thanks, Steve -Original Message- From: Charlie Reitzel Sent: Tuesday, April 04, 2006 9:18 AM Subject: Re: Put similarities in code and differences in data Not really. I believe it is intended to mean data driven programming as Jeremy mentioned earlier. To me, data driven programming means use lotsa lookup tables, the contents of which are user tweakable. As simple as it sounds, it can be an effective technique to let you quickly adapt a system as requirements evolve - without code changes. Having found this hammer early in my programming career, I find a great many nails. Early days in any new design are spent setting up a lookup table table, along with utility routines for reporting, validation, UI picking values (one or several), etc. It may be a use case, but I don't think this is quite the same thing as the subject of this thread which, as Uri says, is a general approach to analysis. At 09:00 AM 4/4/2006 -0400, [EMAIL PROTECTED] wrote: ( 06.04.04 08:46 -0400 ) Tolkin, Steve: The difference is that I am trying to find a quote that focuses on the benefits of using data in a special way, as control data, to determine the specific execution path taken by the code. um, isn't this the scientific method? ___ Boston-pm mailing list Boston-pm@mail.pm.org http://mail.pm.org/mailman/listinfo/boston-pm ___ Boston-pm mailing list
Re: [Boston.pm] Put similarities in code and differences in data
Another way to look at it is data dictionary driven development. One of my favorite DBAs goes one beyond the power is in the data to the power is in the meta-data. Of course, as usual, Uri is right. and as usual says it in a way that's easy to disagree with :-) There is no magic bullet for hiding complexity. But that isn't really what this technique is about. Managing complexity comes a couple ways * Making the complexity manifest and compact via expessiveness * Make it as simple as possibe but no simpler [Einstein] -- Bill wireless @ LinuxWorld Boston [EMAIL PROTECTED] [EMAIL PROTECTED] ___ Boston-pm mailing list Boston-pm@mail.pm.org http://mail.pm.org/mailman/listinfo/boston-pm
Re: [Boston.pm] Put similarities in code and differences in data
Logically you can extend data-driven programming to storing opcodes with parameters in a database, and writing an interpreter in any language. That's a valid approach under some circumstances, in fact (see my article on this topic at http://www-128.ibm.com/developerworks/linux/library/l-cpdata.html). The trick with data-driven programming, just like OOP or any other paradigm, is knowing how much is enough to get the job done. My overriding maxim has always been if you have to do it more than twice, it's worth abstracting. So for example, if you have this kind of code: retrieve user A modify user A store user A retrieve user B delete user B I wouldn't abstract things yet because a) it's too much hassle in terms of code and documentation, and b) it's more readable this way. But when you add retrieve user C modify user C store user C I immediately abstract it into do_user(USER[], OPERATIONS[][]) Ted ___ Boston-pm mailing list Boston-pm@mail.pm.org http://mail.pm.org/mailman/listinfo/boston-pm
Re: [Boston.pm] Put similarities in code and differences in data
BR == Bill Ricker [EMAIL PROTECTED] writes: BR Of course, as usual, Uri is right. BR and as usual says it in a way that's easy to disagree with :-) BR There is no magic bullet for hiding complexity. BR But that isn't really what this technique is about. BR Managing complexity comes a couple ways BR * Making the complexity manifest and compact via expessiveness BR * Make it as simple as possibe but no simpler [Einstein] but you just agreed with me there. you must be malfunctioning. you will initiate your self destruct sequence immediately as you are no longer useful to the circle of life. uri -- Uri Guttman -- [EMAIL PROTECTED] http://www.stemsystems.com --Perl Consulting, Stem Development, Systems Architecture, Design and Coding- Search or Offer Perl Jobs http://jobs.perl.org ___ Boston-pm mailing list Boston-pm@mail.pm.org http://mail.pm.org/mailman/listinfo/boston-pm
Re: [Boston.pm] Put similarities in code and differences in data
GL == Greg London [EMAIL PROTECTED] writes: GL I don't know how to summarize this approach in a one-liner, though. GL Perhaps something like GL put the control functionality into the users data, not your script GL I haven't been able to consistently implement this and it seems GL to be some vague principle I've learned the more I code, GL rather than something I learned in school or in a programming GL book or whatever. GL I failed to do this in one of my recent big scripts and implemented GL a code generating script by parsing a text config file from the user. GL As the config file got more and more complicated, I realized that GL I should have had the user write the configuration file in the GL form of a perl script and provide a code generating module that GL they use. my bad. GL If I were to create a maxim, it would be something to the effect GL that if you need to give your user control of your script through GL LUT's and other data, then consider whether you should give GL them a module and have them do their control logic in perl. GL as your control LUT's and data structures get more complicated, GL it might become easier to leverage perl to handle that, rather than GL having the user munge more and more complicated data structures i have had the very same experience in stem log filtering. my first (genius!! :) approach was to offer various logical and filter tests that were driven by user entered data. stuff like 'op' = [ @args] and some of the ops were even booleans working on previous ops. it seemed great at the beginning but it always gnawed at me. (btw, that is the coding skill i trust the most, how i FEEL about code :). i just gave this project to someone who will redo it as a proper class that a user can write simple perl code to do the various filter tests and actions and not some wacko structures. it did take a while to figure out the right object design and api which would be the easiest for the user to use. but now that i have that design, coding it will be easy and much of the original code (that did filter actions) can be reused (but with a new api). sometimes it is hard to see the boundary between data driven and code driven. i originally thought data driven would be simpler for the user but it turned out i needed so much power in the filters that going back to code driven (but the api design being key) would be better. uri -- Uri Guttman -- [EMAIL PROTECTED] http://www.stemsystems.com --Perl Consulting, Stem Development, Systems Architecture, Design and Coding- Search or Offer Perl Jobs http://jobs.perl.org ___ Boston-pm mailing list Boston-pm@mail.pm.org http://mail.pm.org/mailman/listinfo/boston-pm
Re: [Boston.pm] Put similarities in code and differences in data
hi ( 06.04.05 12:20 -0400 ) Uri Guttman: you will initiate your self destruct sequence immediately as you are no longer useful to the circle of life. o shit. if uri's making these decisions it's only a matter of time before i'm gone too. my 'usefulness' is regularly questioned by many people [managers, kids, soon to be ex-wife, neighbors, ...] -- \js oblique strategy: straight into his lap) ___ Boston-pm mailing list Boston-pm@mail.pm.org http://mail.pm.org/mailman/listinfo/boston-pm
Re: [Boston.pm] Put similarities in code and differences in data
I understand Uri's point, and can almost understand the silliness, but I think there really is more often a benefit to putting similarities in code and differences in data rather than vice versa. The following quote makes a similar point, but it is not exactly the same point. Eric S. Raymond, The Art of Unix Programming p 47 online at http://www.faqs.org/docs/artu/ch01s06.html and many other places Rule of Representation: Fold knowledge into data, so program logic can be stupid and robust. Even the simplest procedural logic is hard for humans to verify, but quite complex data structures are fairly easy to model and reason about. ... Data is more tractable than program logic. It follows that where you see a choice between complexity in data structures and complexity in code, choose the former. More: in evolving a design, you should actively seek ways to shift complexity from code to data. Another related idea is this: To reuse code you have to change the data (my paraphrase of a quote in http://groups.google.com/group/comp.object/browse_frm/thread/2ebcb9c6cf8 6bf9f/318ede5cf4a01220?tvc=1q=%22in+data%22+%22in+code%22+invariant+OR+ invariants+OR+mellorhl=en#318ede5cf4a01220 The difference is that I am trying to find a quote that focuses on the benefits of using data in a special way, as control data, to determine the specific execution path taken by the code. Thanks, Steve -Original Message- Tolkin, Steve wrote: I am looking for the best and/or original wording of this programming maxim: Put similarities in code and differences in data Google found this in a perl discussion capture similarities in code, differences in data http://blog.gmane.org/gmane.comp.lang.perl.fun/month=20031001 So I am posting to this list. Here is a hit on a similar quote putting invariants in code and differences in data. http://groups.google.com/group/comp.object/browse_thread/thread/1dc6f6dd db34dc18/cdfb5eae936861f2?lnk=stq=%22differences+in+data%22+%22in+code% 22rnum=3hl=en#cdfb5eae936861f2 This mentions Mellor is passing -- Is he the original person behind this? Hopefully helpfully yours, Steve ___ Boston-pm mailing list Boston-pm@mail.pm.org http://mail.pm.org/mailman/listinfo/boston-pm
Re: [Boston.pm] Put similarities in code and differences in data
hi ( 06.04.04 08:46 -0400 ) Tolkin, Steve: The difference is that I am trying to find a quote that focuses on the benefits of using data in a special way, as control data, to determine the specific execution path taken by the code. um, isn't this the scientific method? -- \js oblique strategy: how would you have done it? ___ Boston-pm mailing list Boston-pm@mail.pm.org http://mail.pm.org/mailman/listinfo/boston-pm
Re: [Boston.pm] Put similarities in code and differences in data
Even the simplest procedural logic is hard for humans to verify, but quite complex data structures are fairly easy to model and reason about. ... Data is more tractable than program logic. That's the beauty of Lisp/Scheme ... all the code is a data structure. Seriously, did you check Bentley's Programming Pearls ? That's usually the repository for (old) software aphorisms. (Many of his best ones from Perlis.) -- Bill [EMAIL PROTECTED] [EMAIL PROTECTED] ___ Boston-pm mailing list Boston-pm@mail.pm.org http://mail.pm.org/mailman/listinfo/boston-pm
Re: [Boston.pm] Put similarities in code and differences in data
Not really. I believe it is intended to mean data driven programming as Jeremy mentioned earlier. To me, data driven programming means use lotsa lookup tables, the contents of which are user tweakable. As simple as it sounds, it can be an effective technique to let you quickly adapt a system as requirements evolve - without code changes. Having found this hammer early in my programming career, I find a great many nails. Early days in any new design are spent setting up a lookup table table, along with utility routines for reporting, validation, UI picking values (one or several), etc. It may be a use case, but I don't think this is quite the same thing as the subject of this thread which, as Uri says, is a general approach to analysis. At 09:00 AM 4/4/2006 -0400, [EMAIL PROTECTED] wrote: hi ( 06.04.04 08:46 -0400 ) Tolkin, Steve: The difference is that I am trying to find a quote that focuses on the benefits of using data in a special way, as control data, to determine the specific execution path taken by the code. um, isn't this the scientific method? -- \js oblique strategy: how would you have done it? ___ Boston-pm mailing list Boston-pm@mail.pm.org http://mail.pm.org/mailman/listinfo/boston-pm ___ Boston-pm mailing list Boston-pm@mail.pm.org http://mail.pm.org/mailman/listinfo/boston-pm
Re: [Boston.pm] Put similarities in code and differences in data
Or:
put($data)
versus
$data-put();
From: [EMAIL PROTECTED] on behalf of Duane Bronson
Sent: Mon 4/3/2006 11:16 PM
To: Tolkin, Steve
Cc: boston-pm@mail.pm.org
Subject: Re: [Boston.pm] Put similarities in code and differences in data
As long as everyone else is being silly
#!/usr/bin/perl -w
print _DATA;
put data in code
_DATA
-or-
#!/usr/bin/perl -w
sub put_code { eval $_[0]; }
while (my $in_data = ) {
put_code($in_data);
}
Tolkin, Steve wrote:
I am looking for the best and/or original wording of this programming
maxim: Put similarities in code and differences in data
Google found this in a perl discussion
capture similarities in code, differences in data
http://blog.gmane.org/gmane.comp.lang.perl.fun/month=20031001
So I am posting to this list.
Here is a hit on a similar quote putting invariants in code and
differences in data.
http://groups.google.com/group/comp.object/browse_thread/thread/1dc6f6dd
db34dc18/cdfb5eae936861f2?lnk=stq=%22differences+in+data%22+%22in+code%
22rnum=3hl=en#cdfb5eae936861f2
This mentions Mellor is passing -- Is he the original person behind
this?
Hopefully helpfully yours,
Steve
--
Sincerely *Duane Bronson*
[EMAIL PROTECTED] mailto:[EMAIL PROTECTED]
http://www.nerdlogic.com/
453 Washington St. #4A, Boston, MA 02111
617.515.2909
___
Boston-pm mailing list
Boston-pm@mail.pm.org
http://mail.pm.org/mailman/listinfo/boston-pm
___
Boston-pm mailing list
Boston-pm@mail.pm.org
http://mail.pm.org/mailman/listinfo/boston-pm
Re: [Boston.pm] Put similarities in code and differences in data
Thank you Charlie. That is the idea I am trying to get across. Do you have any suggestions about how to get developers to see the benefits of writing programs this way? Any specific books, techniques, etc.? Any pitfalls to be aware of? Thanks, Steve -- Steve TolkinSteve . Tolkin at FMR dot COM508-787-9006 Fidelity Investments 82 Devonshire St. M3L Boston MA 02109 There is nothing so practical as a good theory. Comments are by me, not Fidelity Investments, its subsidiaries or affiliates. Steve -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Charlie Reitzel Sent: Tuesday, April 04, 2006 9:18 AM To: boston-pm@mail.pm.org Subject: Re: [Boston.pm] Put similarities in code and differences in data Not really. I believe it is intended to mean data driven programming as Jeremy mentioned earlier. To me, data driven programming means use lotsa lookup tables, the contents of which are user tweakable. As simple as it sounds, it can be an effective technique to let you quickly adapt a system as requirements evolve - without code changes. Having found this hammer early in my programming career, I find a great many nails. Early days in any new design are spent setting up a lookup table table, along with utility routines for reporting, validation, UI picking values (one or several), etc. It may be a use case, but I don't think this is quite the same thing as the subject of this thread which, as Uri says, is a general approach to analysis. At 09:00 AM 4/4/2006 -0400, [EMAIL PROTECTED] wrote: hi ( 06.04.04 08:46 -0400 ) Tolkin, Steve: The difference is that I am trying to find a quote that focuses on the benefits of using data in a special way, as control data, to determine the specific execution path taken by the code. um, isn't this the scientific method? -- \js oblique strategy: how would you have done it? ___ Boston-pm mailing list Boston-pm@mail.pm.org http://mail.pm.org/mailman/listinfo/boston-pm ___ Boston-pm mailing list Boston-pm@mail.pm.org http://mail.pm.org/mailman/listinfo/boston-pm ___ Boston-pm mailing list Boston-pm@mail.pm.org http://mail.pm.org/mailman/listinfo/boston-pm
Re: [Boston.pm] Put similarities in code and differences in data
TS == Tolkin, Steve [EMAIL PROTECTED] writes: TS Rule of Representation: Fold knowledge into data, so program logic can TS be stupid and robust. Even the simplest procedural logic is hard for TS humans to verify, but quite complex data structures are fairly easy to TS model and reason about. ... Data is more tractable than program logic. TS It follows that where you see a choice between complexity in data TS structures and complexity in code, choose the former. More: in evolving TS a design, you should actively seek ways to shift complexity from code to TS data. the problem is that you can't sweep complexity under the rug. overly complex data structures start to approach becoming languages themselves. and the code to support them starts to look more like interpreters. this typically happens when you need to make many logic flow decisions based on the data. it is like the space/time tradeoff in algorithms, you can gain in one at the expense of the other. rarely do you find a solution which gains in both. TS Another related idea is this: To reuse code you have to change the TS data (my paraphrase of a quote in TS http://groups.google.com/group/comp.object/browse_frm/thread/2ebcb9c6cf8 TS 6bf9f/318ede5cf4a01220?tvc=1q=%22in+data%22+%22in+code%22+invariant+OR+ TS invariants+OR+mellorhl=en#318ede5cf4a01220 TS The difference is that I am trying to find a quote that focuses on TS the benefits of using data in a special way, as control data, to TS determine the specific execution path taken by the code. well you know my view, it is not a great quote and it can be easily reversed which doesn't help it much. i have seen complexity at all levels and you can't escape it totally. uri -- Uri Guttman -- [EMAIL PROTECTED] http://www.stemsystems.com --Perl Consulting, Stem Development, Systems Architecture, Design and Coding- Search or Offer Perl Jobs http://jobs.perl.org ___ Boston-pm mailing list Boston-pm@mail.pm.org http://mail.pm.org/mailman/listinfo/boston-pm
Re: [Boston.pm] Put similarities in code and differences in data
TS == Tolkin, Steve [EMAIL PROTECTED] writes: TS Thank you Charlie. That is the idea I am trying to get across. TS Do you have any suggestions about how to get developers to see the TS benefits of writing programs this way? Any specific books, TS techniques, etc.? Any pitfalls to be aware of? as i said in another post just now, you can't hide complexity, it will come out somewhere in your system. for less complex cases, it doesn't matter so much how you design things. data driven is nice when you have easy to setup tables of data. but data isn't always neat and clean. try crawling web pages and grabbing out human info such as authors, publication dates, etc. that is a mess and no easy tables to be found anywhere. the bottom line is that it all depends on the problem and how well it can translate to data tables. i suspect too many programs don't map well to that. uri -- Uri Guttman -- [EMAIL PROTECTED] http://www.stemsystems.com --Perl Consulting, Stem Development, Systems Architecture, Design and Coding- Search or Offer Perl Jobs http://jobs.perl.org ___ Boston-pm mailing list Boston-pm@mail.pm.org http://mail.pm.org/mailman/listinfo/boston-pm
Re: [Boston.pm] Put similarities in code and differences in data
TS == Tolkin, Steve [EMAIL PROTECTED] writes: TS I am looking for the best and/or original wording of this programming TS maxim: Put similarities in code and differences in data and i have also heard it the other way around, put similarities in data and differences in code. you can actually argue from either side as they both make sense in some ways. similarity could be sharing common code or using data structure to hold similar data. and code could be used to handle differences in the data and data could hold differences of each instance. so IMO the saying (in either form) is about recognizing similarities and differences and expressing them in code and/or data. this is a general analysis concept and is a fundamental skill that isn't taught enough. most newbie coders are so lost in basic syntax that they can't see how to even use a hash in ways that will reflect the design needs. this is where experience comes in too. uri -- Uri Guttman -- [EMAIL PROTECTED] http://www.stemsystems.com --Perl Consulting, Stem Development, Systems Architecture, Design and Coding- Search or Offer Perl Jobs http://jobs.perl.org ___ Boston-pm mailing list Boston-pm@mail.pm.org http://mail.pm.org/mailman/listinfo/boston-pm
Re: [Boston.pm] Put similarities in code and differences in data
On Mon, 2006-04-03 at 14:02 -0400, Tolkin, Steve wrote: I am looking for the best and/or original wording of this programming maxim: Put similarities in code and differences in data data-driven programming ? -- Jeremy ___ Boston-pm mailing list Boston-pm@mail.pm.org http://mail.pm.org/mailman/listinfo/boston-pm
Re: [Boston.pm] Put similarities in code and differences in data
one of my favorite maxims: Always... no, no... never... forget to check your references. From: [EMAIL PROTECTED] on behalf of Jeremy Muhlich Sent: Mon 4/3/2006 5:05 PM To: boston-pm@mail.pm.org Subject: Re: [Boston.pm] Put similarities in code and differences in data On Mon, 2006-04-03 at 14:02 -0400, Tolkin, Steve wrote: I am looking for the best and/or original wording of this programming maxim: Put similarities in code and differences in data data-driven programming ? -- Jeremy ___ Boston-pm mailing list Boston-pm@mail.pm.org http://mail.pm.org/mailman/listinfo/boston-pm ___ Boston-pm mailing list Boston-pm@mail.pm.org http://mail.pm.org/mailman/listinfo/boston-pm
Re: [Boston.pm] Put similarities in code and differences in data
Greg London wrote: one of my favorite maxims: Always... no, no... never... forget to check your references. Or another classic from the same source: You're not supposed to park your car on campus... -- John Abreau / Executive Director, Boston Linux Unix ICQ 28611923 / AIM abreauj / JABBER [EMAIL PROTECTED] / YAHOO abreauj Email [EMAIL PROTECTED] / WWW http://www.abreau.net / PGP-Key-ID 0xD5C7B5D9 PGP-Key-Fingerprint 72 FB 39 4F 3C 3B D6 5B E0 C8 5A 6E F1 2C BE 99 ___ Boston-pm mailing list Boston-pm@mail.pm.org http://mail.pm.org/mailman/listinfo/boston-pm
Re: [Boston.pm] Put similarities in code and differences in data
As long as everyone else is being silly
#!/usr/bin/perl -w
print _DATA;
put data in code
_DATA
-or-
#!/usr/bin/perl -w
sub put_code { eval $_[0]; }
while (my $in_data = ) {
put_code($in_data);
}
Tolkin, Steve wrote:
I am looking for the best and/or original wording of this programming
maxim: Put similarities in code and differences in data
Google found this in a perl discussion
capture similarities in code, differences in data
http://blog.gmane.org/gmane.comp.lang.perl.fun/month=20031001
So I am posting to this list.
Here is a hit on a similar quote putting invariants in code and
differences in data.
http://groups.google.com/group/comp.object/browse_thread/thread/1dc6f6dd
db34dc18/cdfb5eae936861f2?lnk=stq=%22differences+in+data%22+%22in+code%
22rnum=3hl=en#cdfb5eae936861f2
This mentions Mellor is passing -- Is he the original person behind
this?
Hopefully helpfully yours,
Steve
--
Sincerely *Duane Bronson*
[EMAIL PROTECTED] mailto:[EMAIL PROTECTED]
http://www.nerdlogic.com/
453 Washington St. #4A, Boston, MA 02111
617.515.2909
___
Boston-pm mailing list
Boston-pm@mail.pm.org
http://mail.pm.org/mailman/listinfo/boston-pm
