Re: [Boston.pm] Put similarities in code and differences in data

2006-04-06 Thread Ben Tilly
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&q

Re: [Boston.pm] Put similarities in code and differences in data

2006-04-05 Thread johns
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

Re: [Boston.pm] Put similarities in code and differences in data

2006-04-05 Thread Uri Guttman
> "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 se

Re: [Boston.pm] Put similarities in code and differences in data

2006-04-05 Thread Uri Guttman
> "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> Ma

Re: [Boston.pm] Put similarities in code and differences in data

2006-04-05 Thread Ted Zlatanov
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.htm

Re: [Boston.pm] Put similarities in code and differences in data

2006-04-05 Thread Bill Ricker
> > 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 b

Re: [Boston.pm] Put similarities in code and differences in data

2006-04-05 Thread Greg London
nge 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

Re: [Boston.pm] Put similarities in code and differences in data

2006-04-05 Thread Charlie Reitzel
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. Anot

Re: [Boston.pm] Put similarities in code and differences in data

2006-04-04 Thread Uri Guttman
> "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 pitf

Re: [Boston.pm] Put similarities in code and differences in data

2006-04-04 Thread Uri Guttman
> "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

Re: [Boston.pm] Put similarities in code and differences in data

2006-04-04 Thread Tolkin, Steve
] 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, d

Re: [Boston.pm] Put similarities in code and differences in data

2006-04-04 Thread Greg London
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 every

Re: [Boston.pm] Put similarities in code and differences in data

2006-04-04 Thread Charlie Reitzel
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 sys

Re: [Boston.pm] Put similarities in code and differences in data

2006-04-04 Thread Bill Ricker
> > 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

Re: [Boston.pm] Put similarities in code and differences in data

2006-04-04 Thread johns
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 obliqu

Re: [Boston.pm] Put similarities in code and differences in data

2006-04-04 Thread Tolkin, Steve
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, Th

Re: [Boston.pm] Put similarities in code and differences in data

2006-04-03 Thread Duane Bronson
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

Re: [Boston.pm] Put similarities in code and differences in data

2006-04-03 Thread John Abreau
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

Re: [Boston.pm] Put similarities in code and differences in data

2006-04-03 Thread Greg London
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

Re: [Boston.pm] Put similarities in code and differences in data

2006-04-03 Thread Jeremy Muhlich
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

Re: [Boston.pm] Put similarities in code and differences in data

2006-04-03 Thread Uri Guttman
> "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

[Boston.pm] Put similarities in code and differences in data

2006-04-03 Thread Tolkin, Steve
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 t