Interesting effort - another Rosetta-Stone kind of programming language site taking all the example code from the Perl Cookbook (vintage 2001) and asking people to submit the equivalent in their language of choice.
This is another source of something along the lines of "transaction patterns", that is, higher-level "things to do" that are implemented in lower-level code. A semantically oriented declarative language needs to be able to talk at that level. Maybe instead of "transaction patterns" they should be called "action patterns" or something. They're at a far lower level than architectural patterns.
Showing posts with label transaction patterns. Show all posts
Showing posts with label transaction patterns. Show all posts
Sunday, October 7, 2012
Wednesday, July 6, 2011
Transaction patterns
From February on "Web app design":
Oh, wait: a mother lode of so-called "transaction patterns" used in a toolkit for building database administration sites. It is incredibly detailed. These transaction patterns, by the way, constitute a language for user-level interaction with Websites that is not restricted to the Web domain - they'll work just fine in the Wx context as well. So they should definitely be analyzed, but they can't just be relegated to WWW::Publisher. I'm not really sure where they should go. Probably a new domain. Database::Declarative? I just don't know!
It took me a few minutes to find this post just now, as I hadn't really marked it very effectively. Now I'm doing so. The concept of the transaction pattern is a good one.
Saturday, February 26, 2011
"Base programs"
Grist for the mill of "types of program" here on HNN, ever the most interesting forum out there.
The list:
- basic form
- form with multi-valued lines
- form with data set (multi-valued parent/children)
- form with grid
- tabbed form
- form with skins
- batch (loop thru something)
- batch update selected records in a table
- batch dump table records --> .txt or .xml file
- batch .txt or .xml file --> update table records
- batch file --> create & populate database table
- cut an email
- traverse internal tree function
- traverse file index(es)
- build html from parameters
- build javascript from parameters
- build .pdf from parameters
- build hp esc sequences from parameters
- benchmark a process
- how does that syntax work?
- which way is faster?
- batch string parser
- batch source code search
- batch source code changer
- batch parse source code, identify routine for reuse
A follow-up comment mentions that these should be in a library - but I beg to differ. This is a higher level of organization than the library. This is where we talk about the semantic purpose of the program. It fits well with the Unix philosophy of many small utilities, actually.Food for thought!
Labels:
boilerplate,
macro,
patterns,
transaction patterns
Subscribe to:
Posts (Atom)