|
[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]
|
Re: [PhillyOnRails] help me customize my talk on DSLs in Ruby and Rails Enterprise adoption
|
Dear Aaron,
If we do decide to go with queueing theory, I think we should post
relevant links to the wiki immediately so we can all read up before
the next meeting.
This is a good suggestion, and perhaps it implies that a queue system
wouldn't be a good example. I don't suggest a detour into queue theory;
it's a matter in Statistics. I was only suggesting that queues are
interesting, have a proven track record with DSLs, multiple applications
(kernel programming, manufacturing, online commerce, etc.), and have
real world analogies that we can all readily relate to. Everyone
understands a line to the cashier at a store, and it's easy to
visualize. Sales commission might be a little more remote for some of
us lifelong programmers.
There wasn't much of a response from the list. I take that as a sign of
indifference to my suggestion. Perhaps that is also an indication that
a queue system wouldn't make a good example. Not exciting enough?
In this case, it's a question of what level of domain-specific knowledge
detail is appropriate for Obie's talk. I'm hoping that Obie will be
able to clear this up?
Thanks!
-Cassius
In light of Jamis Buck's recent post
(http://jamis.jamisbuck.org/articles/2006/04/20/writing-domain-specific-languages
) via weblog.rubyonrails.org, i'd like to focus on using ruby's great
language features as they pertain to creation of a DSL. Buck leaves
this as an excersize to the reader. I'd like to see some basic code as
examples of "proper use" of the following in DSLs:
procs, modules, eval, instance_eval and class_eval, define_method,
Module#included, and method_missing
Cool.
Aaron Blohowiak
On Apr 21, 2006, at 10:56 AM, Cassius Rosenthal wrote:
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
_______________________________________________
talk mailing list
talk@phillyonrails.org
http://lists.phillyonrails.org/mailman/listinfo/talk
_______________________________________________
talk mailing list
talk@phillyonrails.org
http://lists.phillyonrails.org/mailman/listinfo/talk
|
|