Re: [Boston.pm-announce] Tech Meeting Tuesday, April 11, at MIT
I forgot to mention that Boston.pm member Greg London has offered to provided the refreshments for this month's meeting. Greg recently wrote a new book, Bounty Hunters: Metaphors for Fair Intellectual Property Laws. http://www.greglondon.com/bountyhunters/ Ronald ___ Boston-pm-announce mailing list Boston-pm-announce@mail.pm.org http://mail.pm.org/mailman/listinfo/boston-pm-announce
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
[Boston.pm] Tech Meeting Tuesday, April 11, at MIT
Boston.pm will have a tech meeting on Tuesday, April 11, at MIT, in building E51, room 376 (directions below), starting at 7:15pm. Bill Ricker is going to follow up on February's graphing meeting by showing us how he does GD-on-Map overlays and aligns GD points/lines on top of GD Charts. I'll also find a fun JAPH or obfuscation to share with everyone. RSVP to me if you're planning to attend - rjk-bostonpm(at)tamias.net. Pizza and soda will be provided. Ronald For more information about Boston Perl Mongers, or to subscribe to one of our mailing lists, visit our website at http://boston.pm.org/ Directions to MIT, Building E51: Building E51 (the Tang Center) is located at the corners of Amherst and Wadsworth Streets in Cambridge. http://whereis.mit.edu/map-jpg?mapterms=e51 Directions by T: Take the Red Line to Kendall. Building E51 is right around the corner from the T stop. From the Inbound side, facing into Main Street, turn right (toward Boston) and walk down the block. Turn right on Wadsworth Street and walk to the corner of Amherst Street. Building E51 is the building across the street directly in front of you with the metal canopy. Directions by Car: General directions provided by MIT: http://whereis.mit.edu/map-jpg?section=directions The Boston Linux and Unix user group also meets at E51, so you may find their directions helpful as well (keeping in mind that we will be meeting in room 376, not room 315): http://www.blu.org/directions/mit/e51-315.php Parking Information: MIT's Amherst Street Lot is adjacent to the building: http://whereis.mit.edu/map-jpg?selection=P4Parking=go Officially, a sticker is required to park in the lot. However, we've been told unofficially that there is no enforcement after 3pm weekdays, nor on the weekends. Chances are very slim that cars will be ticketed. Nonetheless, parking in the lot is at your own risk. ___ Boston-pm mailing list Boston-pm@mail.pm.org http://mail.pm.org/mailman/listinfo/boston-pm
Re: [Boston.pm] Tech Meeting Tuesday, April 11, at MIT
I forgot to mention that Boston.pm member Greg London has offered to provided the refreshments for this month's meeting. Greg recently wrote a new book, Bounty Hunters: Metaphors for Fair Intellectual Property Laws. http://www.greglondon.com/bountyhunters/ Ronald ___ Boston-pm mailing list Boston-pm@mail.pm.org http://mail.pm.org/mailman/listinfo/boston-pm
