Domain Specific Languages: Molding Ruby

Ruby

Joe O'Brien

3 talks

#domain-specific-language-dsl

#ruby

#meta-programming

#software-development

#programming-languages

#ruby-on-rails

Domain Specific Languages: Molding Ruby

by Joe O'Brien

The video titled "Domain Specific Languages: Molding Ruby," presented by Joe O'Brien at the MountainWest RubyConf 2008, explores the concept and practical application of Domain-Specific Languages (DSLs) within the Ruby programming language. O'Brien shares his passion for Ruby while encouraging both Ruby developers and those contemplating it to leverage its unique capabilities in crafting DSLs that cater specifically to business needs.

Key points discussed include:

Purpose of the Talk: Aimed at Ruby developers and others interested in Ruby, O'Brien explains why Ruby is a preferable choice for software development.
Personal Background: O'Brien shares his journey as a developer and his enthusiasm for Ruby, influenced by his desire to create expressive and readable code.
Productivity in Programming: Emphasizing the need for higher productivity, he notes how domain-specific languages can help developers address particular problems more efficiently.
Concept of DSLs: O'Brien defines DSLs as specialized programming languages tailored to specific problem domains, highlighting their value in software development.
Success of DSLs: Examples such as Microsoft Excel and Starbucks' ordering system underscore the significance of a tailored vocabulary fostering efficiency and clarity in software applications.
Two Types of DSLs: Internal DSLs and external DSLs are explained, but the focus remains on the simpler internal DSLs that enhance Ruby development.
Challenges and Solutions: O'Brien discusses common pitfalls and strategies, such as spillover context and declarative programming styles, that make implementing DSLs in Ruby more manageable.
Case Studies: He shares anecdotes about the development of Rake, demonstrating how DSLs can emerge organically through addressing real-world programming challenges.
Building DSLs in Ruby: O'Brien suggests starting with small DSLs and evolving them as the problem becomes clearer, emphasizing the importance of context to shape the language.
Conclusion: The talk culminates with a call for creativity in crafting DSLs and encourages developers to explore language design as a way to better address the nuances of their specific domains.

In summary, O'Brien's insights present DSLs as powerful tools in Ruby that can enhance clarity, productivity, and communication in software development, ultimately empowering developers to solve complex problems effectively.

00:00:17.199 So I'm giving a talk about three or four months ago. I left my backpack in the back of the room and forgot to turn my phone off. It starts ringing halfway through my talk, and everybody's looking around, like, okay, who's the culprit? Finally, I'm like, yeah, that's me. I can't do anything about it. So let's talk about domain-specific languages. It's late at night, which at first, I was kind of like, you know, what's going on? But I think it's going to be good because this talk is a little bit more hand-wavy.

00:00:39.920 This talk is designed as much for Ruby developers as it is for other developers who want to understand why they should use Ruby. It's kind of my argument as to why I absolutely love this language and why I like to use it. It will pull on some of the stuff that Giles talked about and some of the stuff that Jeremy talked about. In fact, Jeremy's comment caused me to add in five slides, so my rhythm is a little off. Forgive me, but hopefully, you won't notice. So, like I said, this is kind of the why I love Ruby. What are my goals? First of all, why you should look at Ruby. Most of you are already here; most of you have already looked at it.

00:01:15.600 I have spoken to some people who this is kind of an evaluation period, so this is yet another reason for you to consider diving into Ruby. Also, what else you can do with Ruby? A lot of us come in through Rails, which is a favorite quote of the day from Ezra: a lot of people come from Rails and stay for Ruby. This is kind of a demonstration of what else you can do with it. And then, of course, why I personally can't shut up about Ruby.

00:01:46.240 When I was growing up, my dad was one of those guys who loved to make a bunch of goofy stuff. He was a pilot in the army, and everywhere they went, they’d give him a bunch of maps. His proudest moment was making this map book that he had. He would spend all this time putting them together and creating this big book. The problem was the outside cover was always duct tape. You know, as a teenager, your dad walking around with this thing was just so embarrassing. He would never buy things; he would always just make the things he needed because, just give him some wood and some duct tape, and he'd come up with some weird solution. After a while, I began to discover that, as I became a developer, I am very much like my father.

00:02:30.560 So who am I? My name is Joe O'Brien. I founded a company called Edge Case in Columbus, Ohio. I was a former ThoughtWorker. I realized that a 7-7-47 for a commute kind of sucked, so I started my own company near my house. I founded the Columbus Ruby Brigade because I got tired of going to my wife and showing her really cool things Ruby could do and having her roll her eyes at me. We have about 300 people strong on the list, and we get about 50 to 60 people regularly attending, which for Columbus, Ohio is absolutely mind-boggling because that's not exactly the capital mecca of the world.

00:03:10.720 I have a very large .NET and J2EE background; my specialty was enterprise application integration, SOA, those kinds of things. I love the big hairy balls of mud that you have to join with some other big hairy ball of mud because you've got 16 years of really stupid technical decisions. I find those really interesting. One of my passions, thanks to my mentor, was XP and Agile. I spent a lot of time selling into enterprises a better way of doing things. While I was doing that, along came Ruby, and it was kind of this interesting fit because we were preaching that better people and better process make better software. Then all of a sudden, we said better people, better process, and a better tool make perfect software.

00:03:56.960 With that being said, the biggest reason I have this slide up is not because I'm arrogant, as Evan said, but because I want to tell you I’m not a Rails guy. We mainly do Rails development right now because it’s hot, it’s selling, and I like to get paid for what I do at times. But I’m not here to tell you about Rails; I’m here to talk about why people stay, like Evan or Ezra said. Also, I love Emacs. Allen Perlis has a very famous statement: "A language that doesn’t affect the way you think about programming is not worth knowing." We all love to throw out the fact that, in Prague, they say that every year we should learn a new programming language.

00:04:49.599 But a lot of us, when we make the choice of what programming language to use, tend to go for the safe features. In programming, we decide, 'I need to know JavaScript a little bit better.' Not just on JavaScript; there's a real language in there, but we always tend to go for those safe options, and Ruby is a really interesting one, if you haven’t already learned it, because it's really going to affect the way you think about programming. Yes, you can write Java code in Ruby. I recently found an old backup disk of mine, and I was going through it and found some Perl code, and I thought, 'Wow, this is really interesting.' Back when I was doing Perl, I remembered the time frame, so I dug a little deeper and found my original Ruby scripts. It was really cool because there was Java code with Ruby syntax; I just hadn’t understood what you could do and understood those concepts.

00:05:52.560 This is what happens late at night: I completely lose my train of thought. That thread's gone. Let's move on. We’ve all heard of The Mythical Man-Month, I hope. If you haven’t read it, put it on your list. Fred Brooks talks about the fact that, through study after study, they discovered that every programmer can produce about 1,400 lines of productive code per year. The number's not important, but what's important is we discovered that there is a finite number of lines of code each one of us can produce per year. Unless you're Evan Phoenix or Ryan Davis, that’s pretty much a standard number that's going to stay there.

00:06:19.680 So what we need to do is start figuring out how to be more productive with that code and how to produce more. This is not news to any of us; we’ve been doing this for a long time. We all started off in base assembler, and apparently, poor Josh Wulf actually wrote in that for quite some time, as I discovered this morning. Then we discovered that we wanted to abstract it, make it more portable, so we went to C. That eventually compiled down, and then we found languages that produced more. But we were still missing another step. We've also discovered what’s really cool about this language: it's very expressive, but we're trying to do the same thing again that people have done time and time again, and that's this bridge between Ruby and C.

00:07:07.759 So we are now presented with even better options, which include harnessing existing knowledge that's already been gained in the industry and looking at the JVM, CLR, or with DLR edition, or even Rubinius, which I find absolutely fascinating. For quite some time, people have said, 'Okay, let's not worry about speed; let's see what we can do with this language, and somebody will solve it.' And sure enough, somebody did, and that’s what’s been fascinating. But we still want to find how we can be more productive with the code we have, and we can do even more than we’re currently doing.

00:07:58.400 A couple of years ago with his OMG, it came out and said, 'I’ve got an idea! Let’s all draw pretty pictures!' We’re going to draw pretty pictures that represent our domain, and we’re going to generate code from that. As my mentor likes to say, 'Hieroglyphics worked really well for the Egyptians, but only to a certain point in time; eventually, they had to go to a real language too.' So we get our languages, and we’re told that everything's a tree. Life is like a tree; we can put everything in these nice structures.

00:08:47.200 We start programming and doing that, and that’s one of the places where I love Jeremy’s talk because he said these languages we’ve been using, Java, C#, are like Lego blocks. I think that's a really cool analogy because you can do a lot with Legos. I had my big bucket of Legos at home, and I still have it. The cool thing about having kids is you get to play with this stuff again, and it’s not considered stupid. You could make different things; you could make robots, dogs, computers – not a working computer, but you could build these structures up from those blocks. But you still had to use a little bit of your imagination to figure out what was going on because you didn't have exact rounded corners, or the ability to go that extra little step.

00:09:28.720 We’re also told that everything’s a tree, but what they don’t tell us is what the forest actually looks like. You get into your first big company job, and you start looking around, and there are dead trees everywhere. There’s moss growing on things, things are crossing each other, and things are growing off one another. This is what reality becomes. On another note, I’ve had several career paths, and one of them was at a small company that made culinary artwork. Talk about a niche market! It turns out that chefs like to be decorative; they like to be expressive and artistic, and it’s amazing what they are able to do.

00:10:37.040 They have one rule: it has to be done with food because it’s 'cheating' if you bring in a Picasso and shove it on a buffet. You have to create it with the food that you’re delivering. I worked for a guy who found a way to purify something called tallow, which became really popular with chefs in the 60s. They would make these sculptures with it, but the problem was that it went rancid, and the FDA eventually said this was not a good thing. However, Dominic figured out a way to purify it so it didn’t go rancid anymore and got a good business going, with all these sculptures to sell.

00:11:17.760 The most popular item we sold was bulk tallow, available in three grades: casting tallow, which was really hard and you poured it into molds; carving tallow, which worked very much like ice except it didn’t melt; and molding tallow. Chefs could take this product and mix it, and we sold it in plain, cheddar, or chocolate flavors. This was a huge hit with cruise lines because they could create extravagant buffets and reuse the products without tossing the food overboard, which usually made things a little risky.

00:12:02.640 What was particularly interesting was the variety of tallow being used. We got into a culinary write-up once that detailed the chef’s Olympics that occurred once a year. A chef I got to know well used all three varieties of tallow because certain things needed to be cast, certain things needed to be carved, and some just had to be molded by hand. If you’re making a life-size tree standing so tall, you can't do that with modeling clay.

00:12:39.840 We’ve discovered that drawing pretty pictures and all these different things is interesting, but we’re attacking the wrong side of the problem. Gartner did a research study years ago, talking about the total cost of software and took a software project over its lifespan, say five years, and documented what the total cost was. They came up with a figure: 85% of the software lifecycle and maintenance costs account for 85% of the cost of software development. So, all these technologies we’re trying to develop to make software development faster, we are only attacking 15% of the problem. This is where I really dive into software because I am not the math guy. I am not the smartest developer, and Jim will attest to that.

00:13:39.840 I don’t look at cute little tricks and things and get it right away. I like readable software; it should be expressive. Those five cycles it takes me to figure out what someone was doing, I don’t like, so I tend to focus more on reading rather than writing.

00:14:15.360 So what do we do? I am personally a business software developer, so we create software for businesses, and all these businesses have established vocabularies and established languages they use. Who knows what this one is from? Someone? Thank you! Waffle House. I gave my first ever DSL talk out in California. I put this slide up and there was silence, so I had to create this one.

00:14:40.160 What's interesting about Starbucks is they really do have a DSL. Yes, part of it is somewhat pretentious, especially with the venti and grande terms. I really want to get next to Chad Fowler one day and whisper in his ear 'venti' because I know it bugs him. But they operate within a distinct order and vocabulary, and if you ever wonder why they do this, it’s because it provides a consistent experience. You can walk into a Starbucks at 8 a.m. in downtown Chicago, and there’s a line out the door, yet that line is moving efficiently.

00:15:47.200 If you take this vocabulary away, mistakes can happen, and things start breaking down. This is how they get around that. We also look at very successful DSLs and very successful models that have been used. Microsoft Excel is another one; as much as most of us may hate it, if there were one piece of software we'd take out that would take down 85% of the economy, it's Excel! When it first came out, it was successful because it matched the mental model of what people were doing. It was columns and math and accounting, and you could sum them up. Oh my God, it just made sense!

00:16:52.000 Domain-specific languages, just like their name suggests, are languages that are very specific for particular domains. The domain can be really small or it can be really large. This is some of the things I hope to discuss today. Eventually, Jim might start chatting at me at the end of this, because he and I currently disagree on it.

00:17:32.400 I mentioned that I love Emacs. I absolutely love Martin Fowler, because he's not one of those guys out there trying to forecast what will happen next year. He works for ThoughtWorks and is very much the chief scientist; he observes what people do in software and watches trends and takes a step back. More importantly, he provides us with language we can use to identify certain things. All of us love to scream and moan about design patterns. What they were supposed to do was give us a vocabulary we could harness to better communicate what we were doing. 'I did this cool hacky thing!' It created names for things, so Martin is working on this for DSLs.

00:18:30.960 Thank goodness he has his work published in DSLs work in progress. I highly recommend you go take a look at it; it’s language agnostic and very interesting. He defines DSLs as a computer language aimed at a particular kind of problem rather than a general-purpose language meant for any software problem. What I’m not up here telling you is to write your own version of Scheme or write your own version of JavaScript; what I’m saying is that we’re discussing very specific problem sets we're trying to solve.

00:19:26.240 By definition, this also means they’re not going to work in general scenarios, and that’s very important. The metaphor of craftsman has been overused, but it’s really good. If anyone watches PBS and sees Norm Abram, please tell me you know who Norm is. Despite having the world’s biggest budget for any carpenter and being able to pull out a new router every time he wants, Norm has a lot of jigs set up, feather boards and other special setups for certain scenarios, because you can't buy every tool.

00:19:55.760 This is what we'll start talking about: building these sets of jigs and evolving what we're doing. Eventually, you get an entire collection, and when you go to make a window, you already know what to grab; to build a desk, you know what you’re going to do; to build a model bridge, you know what to use. These can be small or large. There’s scaffolding out there that helps us achieve these targets.

00:20:17.680 This is also not a new concept. There will always be someone in the audience who talks about how they've been programming longer than I've been alive and says, 'Yeah, we've been doing this forever.' You’re right. In the Unix world, they call it mini-languages. If you haven’t read 'The Art of Unix Programming' by Eric Raymond, I highly recommend it; it discusses a lot of the fish and ideas. I notice very few Dells and IBM computers; there are many Macs. All of us are running on Unix.

00:20:58.240 If you want to understand what's going on and why, read that book. Off that soapbox. Eric Raymond discusses many languages and this tradition in Unix, where it makes sense to have your own language. It’s not always ugly, but send mail config comes to mind – the one that everybody uses. You sit there and use it for the first time, stand back, grab a beer, and wonder who the hell in their right mind came up with this solution. In reality, it's years of stupidity and not really planning ahead.

00:21:38.560 He uses that as an example to look towards what you're doing. Don't just map out a language from the beginning, but also observe it. We also need to classify things into two categories, and here's another piece where I enjoyed what Martin did. He gave us two definitions: external and internal DSLs. We're speaking about languages; we're talking about mini-languages, but two different ways of doing them.

00:22:13.840 Who here has used Lex and Yacc? Keep your hands up if you enjoyed that experience. Antler? What I’m going to be discussing mainly are internal DSLs. I’m not going to cover Lex, Yacc, or Antler. These are very planned-out; what I’m discussing is a style of development. And we’re going to talk about internal DSLs.

00:22:54.400 I’ll steal from a really good guy who made a lot of money from Yahoo and has been blogging about it ever since. Paul Graham talks a lot about Lisp programmers and the way they work. It’s really interesting because we shouldn’t blow off the fact that he’s using Lisp when he’s telling you to use Lisp for e-commerce. He’s genuinely trying to convey that point, but also look at the style of development he employs.

00:23:43.440 He states that Lisp programmers follow the principle of bottom-up design; they alter the language to suit the problem. I’m going to break every rule and presentation and give you this quote – in Lisp, you don’t just write your program toward the language, you also build the language up toward your program. Language and program evolve together. The border between language and program is redefined, until eventually it rests along the natural frontiers of your problem. In the end, your program will look as if the language were designed for it, and when language and program fit together, you end up with code that is clear, small, and efficient.

00:24:28.960 This is very interesting because, like two warring states, they go back and forth. There is a natural frontier for your problem you need to be aware of; you will backtrack and forth, and this is what we’re aiming for. So, why aren’t we using Lisp? Because it is the world’s most natural language, right? No.

00:25:05.520 I wanted to stress the fact that I'm really talking about Ruby, not Rails. I'm discussing what we can do in the language itself. Rails is interesting, though, because it serves as a good demonstration of this idea. If you look at the front of ruby-lang.org, Matt has a really powerful statement that reads, 'I’m trying to make Ruby natural, not simple.' This has an interesting implication: with this language we have, we all think of it as straightforward, but he’s not going for simple; he’s going for natural.

00:25:47.040 Additionally, it’s important to realize that programming languages should not just be designed by piling features on top of one another, but by removing the weaknesses and restrictions that necessitate additional features. This is from the revised report on Scheme, and it gives insight into why Matt chose to implement things in the specific ways he did. He did not set out to create a language you could mold and manipulate to develop DSLs, but he crafted the perfect storm and provided the right ingredients, and this exploded. What were those ingredients? Smalltalk, Lisp, Scheme, Python, Perl, and a good viewpoint that allowed us to see things in a natural light.

00:27:16.320 He took these and sprinkled them all together to create a language that’s really powerful for us to use, fairly simple to learn, and looks like a lifetime to master. One of the main features coming from these inspirations is interpreted code, which helps us write DSLs way more than if we were compiled. Another is that it’s purely object-oriented; numbers are objects; nil is an object. This feature gives us comfortable error handling and a graceful way of dealing with problems.

00:27:43.440 We also know about the flexible syntax; no end-of-line requirements; no extraneous, unnecessary parentheses. We have open classes, which we’ve discussed, where you can add the behavior where it should be in the context of what you’re working on. Unlike most languages that we know where they decided to name a class final, programmers often carry around utilities because they think of new features they need. The Smalltalk influence is that we’re passing messages to objects to see if they can deal with it. We’re not calling methods that are predefined; this has enormous implications.

00:29:00.640 This principle of code as data means we package code up and send it to parameters on a method. This imposes many possibilities, especially the idea of implicit self. Personally, my biggest reason to dislike Python is you constantly have to tell it who you are. So, one of the questions that always arises is what's that boundary between an API and a DSL? I’ve credited Neil Ford for this definition: the difference between an API and a DSL is context. Ruby is a very context-specific language.

00:29:44.960 In an API, you constantly have to inject context; with a DSL, you know where you are and just derive things from that. This brings me to why I love Emacs. I had a hard time grasping context until I started looking at the editor I was using. Emacs, dependent on the kind of file you’re in, changes some operations that happen. There’s an idea of context where it makes assumptions depending on where you are and what action you're taking.

00:30:31.440 In Ruby, we are using a very context-sensitive language. The ability to manipulate that context becomes essential if you want to mold the language. Active Record is a perfect example where this style works; we have a declarative style that only works in the context of where we are. We can assume a lot of things; convention over configuration is beneficial, but only because we are in that place and can make that assumption.

00:31:38.640 From Martin's work and much of that out there, we are starting to collect patterns on this. One of those we’ve all seen is the fluent interface, or as Martin calls it, an expression builder. It’s a nice way to add more options on, and sometimes the order matters or does not matter. This is something that other languages have as well as we do; we’ve seen this in JMock and Jim's FlexMock library, which is a great example.

00:32:22.120 Another idea is global scoping. One of the things Martin communicates in his work in progress is that we’ve been taught to fear globals. I vividly remember talking to Jim while developing a time DSL, where we utilized time. It was an amusing discussion whereby we realized that we kept getting confused over AM and PM, especially around noon.

00:32:51.680 We decided to create noon and midnight. Where should we put it? We placed it in kernel, and after developing unit tests and executing them, we found consistent results. It may be unclear here, but declarative programming refers to the notion where we specify what we want to happen. This recipe-like structure provides a set of instructions for what we aim to accomplish.

00:33:45.680 In Ruby, we don't have named parameters. To overcome this, we resort to language-level tricks. We utilize the ability to send whatever parameters we have into a hash, hash them up, and send them in, providing the semblance of named parameters. Spillover context was a coined term by Zach Thompson during a conversation about Rake.

00:34:25.040 Eventually, we will combine various DSL aspects, allowing us to enhance our development methodology. I must express, however, that I do not intend to suggest you write everything in a DSL. I’m merely advocating the notion that this is one of the tools available to you, something that will elevate your code to another level, but it won’t be the sole methodology employed.

00:35:01.280 One of my favorites is Capistrano. I like the idea because they label them recipes. With the declarative style and Rake-like syntax, it feels very much like a recipe; you have your ingredients and then the instructions on how to mix them. Let’s walk through a tale of three DSLs before I check on time.

00:35:58.480 Act One: 'Oops, I created a DSL.' This is one of my favorites. Sitting in the audience, Jim Wyrick was talking about how, depending on the situation, make can have its issues. Many of us familiar with making understand the problems associated, particularly dynamic dependency. He commented about how it would be much easier in Ruby, and his friend responded, 'Really? What would that look like?' Jim squiggled something on a napkin and mentioned that it could be done simply. Eventually, they brainstormed, recording with a whiteboard, but eventually returned to their tasks.

00:36:41.680 But not Jim! He fired up Emacs and 15 to 20 minutes later he was back with a prototype. Running it by his friend, he said, 'Look, this is really cool,' and both friends realized they had forgotten about dependencies as well. So Jim finished building Rake, and he would always open his presentations with a caveat: 'I’m sorry, the last thing we needed was yet another build language, but I created it by accident.'

00:37:28.520 Let’s look at the things he accomplished. Jim pointed out that Rake is really easy to create in Ruby, and if seen from an outsider’s perspective, it appears as though it is packed with language keywords. However, at its core, it’s a method where we send in the name of the task, along with task-related code. We’ve seen the code equals data principle emerge from this.

00:38:15.520 They spoke about dependencies and how, by leveraging Ruby’s flexibility, the code maintains a clean visual appeal. Only using parentheses where necessary promotes elegant syntax. However, the challenge Jim faced was ensuring that the methods are defined where necessary, allowing the evaluator to trust that the tasks were pre-defined.

00:39:12.960 It means the evaluator can securely ascertain that the task description exists. Understanding your audience becomes critical when building a DSL. Furthermore, Jim discovered that by setting a variable when defining the task, and checking that variable, the implementation works seamlessly. This is referred to as 'spillover context', where context is set in the description and rolls over to the next task.

00:40:06.320 As the audience expressed concerns over namespaces, Jim assured them that it is straight Ruby containing pretty-looking Rake files. Someone coming in from another language might look at it and think, 'My God, this is elegant!' Those who’ve used Ant may question the ease of using such a structured framework. The comparisons draw interesting insights.

00:41:04.640 Act Two: Consistency. Following Jeremy's talk, Mr. T is poised to come punch me. Let's get to the matter of associations in Rails. You’ve heard me mention this is not about Rails, but I'm going to use it for the example. I'm a staunch test-driven developer and enjoy the paired programming experience, especially during the 3 p.m. slump.

00:41:54.160 I want to tackle three questions when working with associations: First, I need to declare that an association exists. Second, is it correct? I've had instances where I've confused has many versus has one and belongs to. Lastly, I need to ensure I have the right column for the entitlements table. Convention over configuration exists, but as developers, certain responsibilities are ours.

00:42:38.560 When I sit down, I write a test first to verify the association's existence. If it's okay, I then verify the association’s correctness. Once that’s validated, I can check the primary key names against the dependencies, ensuring that the primary key is correct.

00:43:25.920 As I move on, I copy and paste and create custom assertions, refactoring as necessary until I attain the right flow. For one-liners, I want to define each association with clear syntax, again prompting those three essential questions: Is it there? Is it correct? Do I have the right column name? I built a consistency during coding.

00:44:12.160 Act Three: Business Language. This story has a humorous twist. Let’s imagine we’re working within a Just-in-Time inventory system, which requires strict adherence to delivery parameters. Jim and I work on this project together and discover that certain conditions enable us to define reusable code. If the definitions reflect combinations, we realize we can employ them in meaningful connections.

00:45:01.440 Gemini created a time DSL, optimizing code for finding durations rather fluidly. As detailed tests were written, edge cases presented themselves, manifesting throughout our code. We documented these edge cases within our framework to avoid confusion later.

00:46:00.240 After careful evaluation, it became clear that some ideas weren’t feasible algorithmically, leading us to reconsider the project’s entire scope. What was beneficial is that all edge cases discovered would be brought to the client’s attention for open dialogue.

00:46:51.200 In another project, the marketing department shared eccentric ideas for satisfying customers. In a hypothetical scenario with a video store, for example, a customer ordering specific items would have to navigate through curious conditions to receive free items. The ensuing rules organically led to excessive database calls, representing pure complexity without a clear direction.

00:47:40.320 Our team’s strategy involved consulting primarily with two professionals who struggled to communicate effectively—an accountant and a DBA. The language barrier between them created a significant bottleneck. To overcome this, the team devised a tailored ORM solution that mirrored the company's vocabulary, streamlining communication and decision-making.

00:48:32.640 A critical consideration was providing a human-readable language that allowed the DBA to interact directly with it. By doing so, the accountant could evaluate the code itself, enhancing the review process and mitigating potential redundancies associated with translating philosophy into words functionally.

00:50:23.040 This concept extends to considering the domain you are working in. One of the first resources I wish to point you to is an InfoQ article featuring Rich Kilmer. He presents a better explanation than most of us and discusses how he built a DSL with the Air Force. It’s a fascinating talk.

00:51:11.040 When I went to speak about DSLs in Silicon Valley, I was shocked when Rich demonstrated what he had accomplished. His success was deflating to me. This is a valuable video that needs to be watched.

00:51:53.840 Other recommended resources include Martin Fowler’s DSL work in progress and the Pragmatic Programmer's upcoming DSL book that is making progress. Reading 'The Art of Unix Programming' and 'Hackers and Painters' is also beneficial; they cover foundational ideas regarding programming.

00:52:37.680 In addition, they address many languages and discuss the challenges associated with them. Paul Graham even elaborates on why every language except Lisp has weaknesses because we should be able to mold and manipulate them effectively.

00:53:00.800 I would like to thank all those involved in this work: Jim Wyrick, who frequently debated and discussed these concepts, Paul Graham for his influential articles, and others from Thoughtworks who contributed to DSL understanding. I can’t neglect to mention my own conference in Columbus, Ohio, focusing on the future of enterprise Ruby. Everyone may be turning away from it in the Rails world, but I’m excited to delve into it and discuss what can be accomplished.

00:53:49.360 Find an opportunity for creativity; craft a DSL that you can utilize. Don't rush into production with it, but see how you can make a difference using it. It’s similar to learning a foreign language—exploring a new technology will help expand your understanding. I have a voice on Twitter and my blog, and I thank you for your time. Any questions?

00:54:31.920 Oh, I almost forgot, now that everyone’s trying to leave, any questions, comments, or tomatoes to throw? Jeremy, I really appreciated your comments on Rails testing, as people often chastise me for testing the framework. My goal is focused; I look at code in ways I create a structure around my fields. All the details align, and they're deployed.

MountainWest RubyConf 2008