Yesod Web Framework
Michael Snoyman presents Yesod, a web framework written in Haskell and containing a web server, templating, ORM, libraries (templating, gravatar, etc.).
The content has been bookmarked!
There was an error bookmarking this content! Please retry.
Posted by Werner Schuster on Jun 15, 2007
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.
Getting Started with Stratos - an Open Source Cloud Platform
Agile Maturity Model Applied to Building and Releasing Software
Agility at scale, become as agile as you can be
Agile Practices to Improve Project Management Organization (PMO) Effectiveness
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:
www.infoq.com/presentations/agile-dsl-developme...
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":
www.catb.org/~esr/writings/taoup/html/minilangu...
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:
www.pbell.com/index.cfm/2007/6/17/Why-You-Want-...
While we're posting quotes, there is Martin Fowlers great old piece on Language Workbenches:
www.martinfowler.com/articles/languageWorkbench...
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.
Do you know any repository for Domain Specific Language (DSL)? I want DSLs in XMI or Ecore format, as for example, the XMI related to the Ruby DSL. Does anyone can help-me, please?
Thanks a lot.
Michael Snoyman presents Yesod, a web framework written in Haskell and containing a web server, templating, ORM, libraries (templating, gravatar, etc.).
Richard Kreuter and Kyle Banker on how to avoid classical RDBMS transactional systems by using compensation mechanisms, transactional messaging or transactional procedures.
Attila Szegedi talks about performance tuning Java and Scala programs at Twitter: how to approach GC problems, the importance of asynchronous I/O, when to use MySQL/Cassandra/Redis, and much more.
One category of risk that project teams need to ensure they address is business value failure – delivering a product that fails to provide value for the business investor.
InfoQ spoke to the authors of Software Systems Architecture on a couple of new topics, the System Context viewpoint and Agile, which have been added to the second edition.
Alex Papadimoulis discusses ugly code, where it comes from, how to avoid it, and how to get rid of it.
John Davies examines Visa’s architecture and shows how enterprises have architected complex integrations incorporating Hadoop, memcached, Ruby on Rails, and others to deliver innovative solutions.
Sean Comerford unveils ESPN.com’s architecture, what components are used and why, and the current changes the website goes through.
10 comments
Watch Thread Reply