| Cassius Rosenthal on 21 Apr 2006 14:36:41 -0000 |
|
Hello Obie, My impression of DSLs has been that, as I develop a specific type of application for years -- say an online CMS -- a form of DSL evolves on its own. My (or my team's) object abstractions become convention and eventually take on a life of their own, with an associated mini-API. At that point, creating a new application reusing the same code, or the same mini-API at least, is a productive leap. Making that happen in reverse strikes me as terribly difficult, because it requires so much domain-specific knowledge that a programmer might not have prior to getting his/her hands dirty within the domain. It's a chicken~egg problem for me. So in your talk, I'll be looking for advice on design as much as on implementation. The sales commission example sounds complex enough to be interesting. In the interest of getting the online discussion going, maybe we could also look at some sort of system queue. This could apply to anything from kernel task execution to a retail cashier check-out simulation. We could look at a general case, like G/G/3/infinite/fifo/infinite in Kendall notation <http://en.wikipedia.org/wiki/Queuing_theory>. Let's take the retail check-out example. Roughly, this would be a system where customers arrived in a general distributed arrival times, say 10 customers per hour; the service time is generally distributed, say 4 minutes per customer; there are three cashiers; there is infinite space for a waiting line; customers are served on a first-in/first-out basis; and the number of potential customers is infinite. For those who don't work with simulations, there are many, many simulation DSLs. The more well-known ones: <http://en.wikipedia.org/wiki/Simulation_language> I'll be interested to see how the list responds. Thanks! -Cassius _______________________________________________ talk mailing list talk@phillyonrails.org http://lists.phillyonrails.org/mailman/listinfo/talk
|
|