Home > Archive > Extreme Programming > September 2007 > Pragmatic Programmer - DRY - Orthogonal - Code Generation
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Pragmatic Programmer - DRY - Orthogonal - Code Generation
|
|
| www.gerardvignes.com 2007-08-10, 7:03 pm |
| If there is a better forum for this article, please tell me. If this
is a rehash of old stuff, please forgive and ignore me.
I have been reading Dave Thomas' interviews, where he discusses DRY
(don't repeat yourself), orthogonality (perpendicular, independent
axes) and the usefulness of writing code generators (that run only
during the build).
I understand that the code generation he speaks of occurs as part of
the build process. This build process begins with an orthogonal set of
source files (no duplication of information).
What he describes is neither a wizard nor a model-driven programming
tool (e.g., a tool that generates code from UML). It is more like a
collection of scripts (which might be Ant tasks?) that de-normalize
(my terminology) the orthogonal sources to produce the files needed
for conventional build tools.
My curiosity has been piqued. This is code generation I can see the
potential value of. I don't like wizards and I really don't like most
CASE tools.
Has anyone actually followed Dave's advice and written their own code
generators to achieve dry (orthagonal) sources and further automate
the build process?
If so, how do you feel about this approach?
Thanks,
Gerard Vignes
| |
|
|
| Phlip 2007-08-15, 10:06 pm |
| www.gerardvignes.com wrote:
> If there is a better forum for this article, please tell me.
No.
> If this is a rehash of old stuff,
No.
> please forgive and ignore me.
No!
(-;
> I have been reading Dave Thomas' interviews, where he discusses DRY
> (don't repeat yourself), orthogonality (perpendicular, independent
> axes) and the usefulness of writing code generators (that run only
> during the build).
>
> I understand that the code generation he speaks of occurs as part of
> the build process. This build process begins with an orthogonal set of
> source files (no duplication of information).
"Orthogonal", in this context, means that two low-dimension manifolds bound
a high-dimension space. You write the manifolds, and the build process
populates the space.
(This is easiest to visualize as two perpendicular line segments defining a
rectangular area ;-)
> What he describes is neither a wizard nor a model-driven programming
> tool (e.g., a tool that generates code from UML). It is more like a
> collection of scripts (which might be Ant tasks?) that de-normalize
> (my terminology) the orthogonal sources to produce the files needed
> for conventional build tools.
A much better term for it these days is a Domain Specific Language; DSL. And
if you can't write one directly inside your home language, then get another
language. Seriously.
Here's from my post today to the Ruby newsgroup:
----8<------------------------------------------
> DSL is a state of mind, not a language inside a string inside a language.
>
> The state of mind is that you intend to write in one language style,
> inside another language. For example, Rake is a _light_ form of rule
> solver, so you can write it in a format paralleling a Makefile:
>
> task :rule_1 => [:rule_2, :rule_C] do
> evaluate_rule_1
> end
>
> To write in a declarative mode, write object methods with store their
> commands in an engine, and then process the engine. Here's a little
> Flea script to draw a spiral:
>
> egg = startOvum(18, 45, 100)
> ax = egg.newRootAxiom('A')
> b = egg.newAxiom('B')
>
> ax.longer(6).right.color(1).gosub(b)
> b.tube.shorter(0.8).left.link(b)
> render egg
>
> The commands like longer, right, color, etc are turtle graphics
> describing a shape. render then outputs the shape.
>
> All the ActiveRecord association commands - has_many, belongs_to, etc
> - qualify as DSLs too. The goal is to give your user-programmer a
> clear but deep interface, so they can write the command they need, in
> the relevant context they need, and the engine on the inside hides the
> complexity.
----8<------------------------------------------
That's what he means. You write code that doesn't execute, but secretly
arranges operations as an object model. Then an engine operates on the
model, and extrudes a result. We see this pattern everywhere - when the
coding language is a specialty language, such as Flex or Lua, and when the
coding language and engine language are the same. These topics can be called
"code generation", "metadata", or "Domain Specific Language".
> My curiosity has been piqued. This is code generation I can see the
> potential value of. I don't like wizards and I really don't like most
> CASE tools.
Someone else wrote those, with limitations. You need a language that makes
DSLs easy to write, even emerge. Another example here is C++ Boost Spirit.
> Has anyone actually followed Dave's advice and written their own code
> generators to achieve dry (orthagonal) sources and further automate
> the build process?
No. We are not advising spending time in a project writing a toy language
and running it. We _are_ advising practicing as much emergent design as
possible, using languages and techniques that _encourage_ DSLs to emerge.
This is essentially how one Dave HH wrote Rails.
He now writes with Dave Thomas...
--
Phlip
http://www.oreilly.com/catalog/9780596510657/
"Test Driven Ajax (on Rails)"
assert_xpath, assert_javascript, & assert_ajax
| |
| www.gerardvignes.com 2007-08-17, 7:06 pm |
| On Aug 15, 7:02 pm, "Phlip" <phlip...@yahoo.com> wrote:
....
> No. We are not advising spending time in a project writing a toy language
> and running it. We _are_ advising practicing as much emergent design as
> possible, using languages and techniques that _encourage_ DSLs to emerge.
> This is essentially how one Dave HH wrote Rails.
>
> He now writes with Dave Thomas...
>
> --
> Phlip
> http://www.oreilly.com/catalog/9780596510657/
> "Test Driven Ajax (on Rails)"
> assert_xpath, assert_javascript, & assert_ajax
Thanks Philip,
You post really helps clarify some things I've been wondering about.
I haven't heard the phrase "emergent design" before. I found a few
links, but I don't think it's the same thing:
http://en.wikipedia.org/wiki/Emergent_Design
http://www.research.ibm.com/journal...t2/cavallo.html
Where can I go to find out about the Emergent Design you are speaking
of?
Thanks Again,
Gerard
| |
| Jim Kingdon 2007-08-17, 7:06 pm |
| > I found a few links [to Cavallo], but I don't think it's the same
> thing
Might be related, but Cavallo is writing much more generally than
software development in particular.
> Where can I go to find out about the Emergent Design you are speaking
> of?
There must be something in print about it (I partially gave up reading
XP books when the number of them exploded, so I'm not sure what to
point to), but the first thing which springs to mind is to read the
(in)famous bowling score example
http://www.objectmentor.com/resourc...s/xpepisode.htm and
notice the way the Throw and Frame objects went away, and the Scorer
object got introduced. Throughout that example, there is lots of talk
of design, but it is concurrent with coding or refactoring.
| |
| www.gerardvignes.com 2007-08-17, 7:06 pm |
| On Aug 17, 10:15 am, Jim Kingdon <king...@panix.com> wrote:
....
> There must be something in print about it (I partially gave up reading
> XP books when the number of them exploded, so I'm not sure what to
> point to), but the first thing which springs to mind is to read the
> (in)famous bowling score examplehttp://www.objectmentor.com/resources/articles/xpepisode.htmand
> notice the way the Throw and Frame objects went away, and the Scorer
> object got introduced. Throughout that example, there is lots of talk
> of design, but it is concurrent with coding or refactoring.
I did run across one online source that I am fairly certain is the
correct topic:
http://luxagile.blogspot.com/2007/0...-on-design.html
I will try to find more and post them.
Gerard
| |
| Phlip 2007-08-17, 10:03 pm |
| www.gerardvignes.com wrote:
> I haven't heard the phrase "emergent design" before.
That one you must learn by doing. I could write a 1,500 work WikiPedia entry
on eating a chocolate soufflé, but if you haven't actually eaten one the
entry won't make your mouth water.
Do it by looking up any of the Test Driven Development tutorials, including
Kent Beck's book, or Dave Astel's book, or including any of the "bowling
game" examples on the 'net, and follow along with it. By alternating writing
simple tests, writing simple code, and refactoring, you can coach a nice
design to emerge. The design will be adequate for your tests and problem.
Maybe you had a good design idea when you started, maybe you had no idea, or
maybe you had a very bad idea. The resulting code will be good.
--
Phlip
http://www.oreilly.com/catalog/9780596510657/
"Test Driven Ajax (on Rails)"
assert_xpath, assert_javascript, & assert_ajax
| |
|
|
|
|
|