Aaron Blohowiak on 25 Apr 2006 13:42:10 -0000

[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]

[PhillyOnRails] Notes from DSL talk

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.

Change of mindset to escape above. Them, you must understand the domain.

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.

            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

You could even, with simple heuristics, spit out human-readable code

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