Tuesday, June 24, 2008

Glimmer Introductory Tutorial

A Glimmer introductory tutorial has been posted on Eclipse Zone (and Java Lobby):

The article includes a brief introduction to Eclipse SWT concepts for both Java and Ruby developers who are not familiar with SWT desktop development. Additionally, the article maps Java conventions to Ruby convensions to facilitate learning Glimmer for Java developers who have not had any Ruby experience.

Feedback and feature requests are welcome.

Thursday, June 12, 2008

Glimmer Eclipse Project is Created


Not much to see yet, but it's finally done.

Expect Glimmer's files to move sometime soon from RubyForge to the Eclipse repositories.

For more information about Glimmer, check out the original Eclipse project proposal.

Tuesday, June 03, 2008

Internal DSLs: Part 1

Ruby as a language helps rapid application development by facilitating composition and use of internal DSLs (domain specific languages) without the need to write complex parsers and compilers.

Rails, a popular Ruby web framework, benefits quite a bit from that fact as it has a DSL for specifying object model relationships, a DSL for naming pluralization rules, and a DSL for routing of web URLs to actions.

RSpec, a very popular Ruby testing library, allows developers to write unit-tests and functional tests with a syntax that is very close to plain English, making test code easy to maintain and useful as specifications of the software.

So, DSLs help developers raise the level of abstraction and reduce the input needed from users/developers to the absolute minimum necessary for getting the job done.

As an example from Glimmer, a new Eclipse Technology Project for SWT GUI development, here is how a UI author would create a shell with a label:

shell {
  label {text "Welcome!"}

As you can see, this is the bare minimum needed to visually represent a shell containing a label.

Coding the same example in plain Java yields the following:

Shell shell = new Shell(Display.getDefault());
Label label = new Label(shell, SWT.NONE);

With the Java API, the developer has to be concerned with lower-level details, such as object assembly mechanisms and setting values following the JavaBeans standard, neither of which are truly UI authoring concerns.

Here is another example taken from Rake, a popular Ruby make-like build tool:

task :generate do
  # code generation logic

task :load => :generate do
  # database data loading logic

task :test => [:generate, :load] do
  # test running logic

What is noteworthy about the Rake DSL is the visual factor of the syntax. Arrows are used to indicate dependency in a similar fashion to how one might use arrows in a hand-drawn diagram.

Without a DSL, the tasks could have been written as:

def generate
  # generate running logic

def load
  generate unless generate_ran
  # load running logic

def test
  generate unless generate_ran
  load unless load_ran
  # test running logic

As you can see, with purely imperative logic, the developer works at a lower abstraction level by having to manage the task run-order dependencies. While it may seem simple in that example, that can bloat to pages of code with enterprise Rake scripts, increasing the code surface and probability of making mistakes.

Therefore, not only does relying on internal DSLs help developers raise the level of abstraction, but it also minimizes the amount of code needed, thus reducing the probability of making mistakes and increasing productivity further.

Nonetheless, with all the excitement about internal DSLs, people may wonder... How do they compare to external DSLs? Where does their use really fit in? Can they be used by stakeholders or are they limited to developers only? Are there other alternatives?

Stay tuned for answers to these questions in future blog posts.