> "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
> "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
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
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
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
>
> 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
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
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,
8 matches
Mail list logo
