|Aaron Blohowiak on 25 Apr 2006 13:42:10 -0000|
Below are my notes from Obie's excellent talk.
DSLs and Ruby – Obie Fernandez
CRm / CRP / Automating batch jobs
Rails just makes the ruby easier – even if it is just a frunt end for more complex ruby scripts
DSL is a smaller part of a larger system – the stuff that changes, that models the particular business processes.
Other stuff – boring backend stuff
Dynamic languages should cover the dynamic aspects of the language.
Words in your dsl relate to the language of the business that you’re modeling
Html – DSL for web, et cetera
Context – a well written API would seem as a DSL.
Some call rails a DSL for web apps.
Object model first, then applying the DSL causes friction – it can be hard to map DSL onto traditional OOP methods.
Write a script that you want to work, then make that work!!!!
The object model should not be up-front design… the object model should EMERGE FROM the script.
You also have to have a language development expertise –
“DSLs become this thing you just do.”
You translate the human language into code.
Knowledge of implementation technology – ie: leveraging metaprogramming features.
External – write your own parser et al Internal dsl – hosted in general purpose language like ruby, like rake
Often implemented las an API –EX: fluent interfaces – changing method calls together
pay 5.dolars.times(number_of_transactions), explosives
An advantage of internal DSLs is that they preserve host language structures, methods and control
“How much ruby language do I want to use? How much ruby language do I not want to use?”
ie: pay 5.dollars * number_of_transactions, explosives
“You have a lot of freedom, so you have to learn how to use it.”
If English was executable, most of us would be out of work!
“Have you seen the writing skills of your average programmer?”
Code should read as closely as possible to what it does?
Who writes story cards or product specs? Customer or customer advocate.
If your code resembles the requirements, cool stuff happens (later)
Coding as a modeling excersize:
Taking real concepts and actions and expressing them in words
With a profusion of classes (like in java) the faithfulness of your code to real life can be obscured.
Sitting down with a non programmer, they should be able to understand your code.
STEPs 1) DEFINE SCRIPT LANGUAGE 2) Implement 3) make scripting language faithful to business process (about a month)
4) lay GUI over it – code generation
(about another month)
5) Visual view – source view – taking the WYSIWYG paradigm from web sites to business processes
For instance, instance_eval in different contexts to spit out different outputs
acts_as_state_machine – “best plugin ever”
* it is a DSL that represents a state machine
True bckend can be hardcore ruby programming – extending sql classes, et cetera, “behind the scenes”, test-driven.
During the implementation, we write the tests and implement
Key => value (implicit arrow) _______________________________________________ talk mailing list email@example.com http://lists.phillyonrails.org/mailman/listinfo/talk