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
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.
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,
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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 /
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
21 matches
Mail list logo
