Agile Project Management: Lessons Learned at Google
In this presentation filmed during QCon 2007, Jeff Sutherland, the creator of Scrum, talks about his visit at Google to do an analysis of Google's first implementation of Scrum.
Tracking change and innovation in the enterprise software development community
Posted by Werner Schuster on Jun 15, 2007 07:00 PM
The term Domain Specific Language (DSL) has become very popular in the Ruby space. One popular example is the Make replacement Rake, particularly after an article by Martin Fowler about it. The term DSL is also used to describe some of the concepts in ActiveRecord, which is part of Ruby on Rails.task :codeGen doAs can be seen, the host language must be quite flexible to allow the DSL to have a distinct look.
# do the code generation
end
1. Have you ever programmed in a language other than Ruby? (PHP and HTML don’t count.) If not, it’s a DSL.#5 on chromatic's list is particularly telling:
2. Is the defining syntactic feature that you’ve cleverly left the parentheses off of a list of function arguments? If so, it’s a DSL.
3. Is the code primarily a list of key-value pairs? Welcome to DSL Town, population you!
5. Have you ever used the phrase “… and it reads just like English!” in seriousness? You’d better get to the hospital; you’re coming down with a case of the DSLs!This is a popular argument for creating DSLs: they allow to write code that is easy to read and understand and doesn't hide its meaning behind language constructs such as for loops, conditionals, etċ. However, David A. Black offers another view of this:
This:Using a domain specific vocabulary for naming code elements isn't a new concept, instead it should be an obvious choice for a designer.
with Employee "123-45-6789" do
dock_salary 1000
warn_about :misconduct
end
is not a domain specific language. It is, rather, domain specific language. Note the lack of the “a”. It’s domain specific, and it uses language-like constructs. But it isn’t a language. It’s Ruby, using expressive method names and cushy semantics and therefore facilitating the use of domain specific idioms.
I've always wondered what the big deal with DSLs was. Now, i'm not saying they are bad quite the contrary.But, I believe a DSL is a healthy bi-product of a good object-oriented design. So, I was a little annoyed with all of the talk and the tricks. I kept thingking to myself, "But, if you did a good design, you would have this!"Languages with syntax that can be twisted/bent to allow for more concise code are useful, but good design still depends on the developer.
But, I should really be kicking myself. I should be glad that good design is back in vogue. and you know what? I am. I'm not annoyed any long and I relish all of this new talk on DSLs. I even feel guilty. You see, DSLs have always been part of the Smalltalk farbic. It's natural to us because it's the way we have learned to code. I remember having the mantra "Code should read like a conversation" shoved down my throat until it became second nature. The cool thing is that there is a whole new generation finding out about this and doing it.
Hpricot(my_document)Basically, there's a function called Hpricot which creates a new object of the class Hpricot and parses my_document. Smalltalk blogger James Robertson, however, takes issue with that:
Urban Honking goes to great pains to explain why using syntax tricks in Ruby to get to something like this: Hpricot(my_document) Is a good thing. Here's a question - if you stumbled on that in code, would you have any idea what it did?After explaining how to improve the code, he continues:
I've out-clevered myself in Smalltalk many times; it's never a good idea.This view is also backed by Stuart Halloway:
If you are going to bend a language's idiomatic usage, you should have a compelling reason, and I share James' view that this example is not compelling.He goes on to give an interesting overview of the many different solutions to API design, and how to design an API to make it possible to write expressive code with it.
Ruby VMs, Scaling Rails, YellowPages.com on Rails, Merb @ QCon SF Nov 19-21
Hacking 101 -The Top 10 Attacks in Web Applications
Software Quality Survival Guide
IBM Web 2.0 Developer eKit: Free Tutorials, Webcasts, Whitepapers
Introducing Project Zero: Building RESTful services for your Web application
It's nice to see topics like this getting attention. One nit to pick: I'd agree with a commenter on Stuart Halloway's blog: Hpricot() is actually pretty classic Ruby if you've done much data-crunching with the language. (The most likely scenario in my experience to need/run-in-to Integer().)
Meaningful methods on objects and API's is simply a hallmark of good design, which seems to have become DSL branded ! However, I think DSL's become much more useful in the design and specification of the code (BDD and to an extent unit tests) where the impact of ambiguity can have far wider (and more expensive) consequences, than in the execution of the code itself.
"with Employee "123-45-6789" do dock_salary 1000 warn_about :misconduct end" I am not Ruby or DSL expert, but it looks like you are hardcoding an employee's SSN in a program here. Maybe I am being too literal ;) Seriously, in real programs, wouldn't most domain specific language not deal with any specific nouns? I ask because nearly every example I ever seen in an article about DSLs uses nouns (i.e., the person that SSN indicates, above) that refer to a hardcoded thing. It seems once you start placing symbols in where the proper nouns go, the code becomes less and less readable to non-programmer humans, and more like... computer language. Maybe I just don't get it. Seriously, this concept is new to me, and I may still be able to be convinced.
Aaron, InfoQ has a new presentation by Obie Fernandez on DSL design and the ideas behind it: http://www.infoq.com/presentations/agile-dsl-development-in-ruby As for the hardcoded values: I think the problem is that short examples just aren't perfectly representative - eg. when JSPs (Java Server Pages) were introduced in Java, every sample contained a page that did an SQL query .. obviously not good either. Another side to this is: DSLs can be used as a way to configure an application. So, instead of defining yet another XML format or some other ad hoc format, you do something with a DSL. Eric S. Raymonds' book "The Art of Unix Programming" has a great chapter where he looks at "Minilanguages": http://www.catb.org/~esr/writings/taoup/html/minilanguageschapter.html where he describes the spectrum of these formats or languages, from simple name/value pairs to full Turing complete languages.
The real value of the idea of DSLs is twofold. Firstly it makes explicit what great programmers have always known - they are in the business of language design (what else are class methods but carefully layers constructs for allowing your code to be more readable and to express intent). Secondly it reminds you that you have options. You aren't writing an API - you are designing a language. Depending on the use case you might want to write an API, extend the language, come up with an XSD to define an XML config file, read in statements from a database, allow users to describe intent using a formatted spreadsheet, build a content management system for expressing intent or implement some kind of "boxes and arrows". When you see all of these as possible concrete syntaxes for implementing your abstract grammar you are much more likely to use the right tool for the job depending on use case. I wrote something about this yesterday: http://www.pbell.com/index.cfm/2007/6/17/Why-You-Want-to-Learn-About-DSLs
While we're posting quotes, there is Martin Fowlers great old piece on Language Workbenches: http://www.martinfowler.com/articles/languageWorkbench.html
Something you may not know about chromatic is that he's a Perl 6 core developer. It's something to consider when reading his (now several) opinion pieces on Ruby, Rails and/or its users.
Actually, chromatic is a core *Parrot* designer. However, you're accusing him of lying about Ruby, Rails, and Ruby users. In the peice quoted here, he's merely showing that most people don't understand what a DSL actually is, and especially how it's not anything special to Ruby. So, what's your motive? Are you afraid that someone might find out that Ruby is just a programming language and not the cure for all the world's problems?
Actually, chromatic is a core *Parrot* designer.
Yeah. Ok. Right.
However, you're accusing him of lying about Ruby, Rails, and Ruby users.
I've made no such accusation. Strange comment really, since chromatic's article is just a sarcastic opinion piece. Accusing him of lying would be nonsensical.
In the peice [sic] quoted here, he's merely showing that most people don't understand what a DSL actually is, and especially how it's not anything special to Ruby.
It's external vs internal Brian. Mostly it seems to be a terminology issue.
So, what's your motive? Are you afraid that someone might find out that Ruby is just a programming language and not the cure for all the world's problems?
Yes, that's it Brian. You've found me out.
Thanks so much for this! This is exactly what I was looking for mirc mırc eski mirc script indir irc komutları mirc indir kameralı mirc sohbet mirc indir mırc indir mirc mırc mirc yükle mirc download islami sohbet dini sohbet islami site islami chat kelebek kelebek script kelebekscript kelebek.gen.tr kelebek.com kameralı mirc indir kameralı mirc kameralı sohbet chat chat yap chat sohbet chatsohbet çet çet sohbet çet odası sohbet kanalları izmir sohbet kanalları sohbet odaları aşk sohbet odaları chat odaları soru cevap sevgili sevgili bul arkadaş arkadaş ara arkadaş bul arkadaşlık bedava sohbet arkadaşlık sitesi arkadaşlık siteleri partner erkek arkadaş bayan arkadaş oto araba mp3 astroloji zoydak nedir cep telefonları gazete marifetname bedava domain ücretsiz domain bayii parça kontör bayiliği bayii online kontör
In this presentation filmed during QCon 2007, Jeff Sutherland, the creator of Scrum, talks about his visit at Google to do an analysis of Google's first implementation of Scrum.
In this article, Bryon Jacob and Chris Berry introduce AtomServer, their implementation of a full-fledged Atom Store based on Apache Abdera, which is now available as open source.
It is easy to think that virtualization applies only to servers. In reality the recent resurgence of the concept is also being applied to networking, storage, and application infrastructure.
In this article, Stefan Tilkov explains some of the most common anti-patterns found in applications that claim to follow a "RESTful" design and suggests ways to avoid them.
In this article, Adrien Louis and Marc Dutoo discuss the differences and relative merits of using orchestration vs. routing in a typical ESB setup, and discuss various implementation options.
Wayne Lund discusses batch processing, Spring Batch objectives and features, scenarios for usage, Spring Batch architecture, scaling, example code, failures and retrying, and the future roadmap.
Developer Jay Fields draws on his experiences as a ThoughtWorks consultant to describe effective user story estimation techniques.
In this talk from QCon SF 2007, Justin Gehtland explains two open solutions to distributed identity and their Rails integration components: OpenID (using ruby-openid) and CAS (using rubycas-client).
10 comments
Reply