Call Hierarchy for Ruby, Finally!!

I updated my installation of Aptana today after reading that RadRails milestone 7 had this feature. I have been waiting a long time for this.

In case you don't know what Call Hierarchy is or why you should care. It allows you to see every place in your code that is calling a particular method. This is indispensable when you are trying to refactor and can't remember everywhere you used this method.

JBoss Seam

After searching for a Java web framework that comes as close to Ruby on Rails as possible I've settled on JBoss Seam. It is still more complex than I would like since right now the applications I need to deliver in the coming months are very simple.

The appeal of Seam (for me anyway)

• Annotation on the model for O/R mapping. No more hibernate XML mappings.
• Generates the DB from the model. The reverse of how Rails does it but it's still DRY so I'm happy.
• Annotations on the model for form validation. They don't seem as flexible as the Rails validations, e.g. I can't find a way to do the equivalent of validates_uniqueness_of or other complex validations using model annotations in Seam.
• Testable. Hopefully unit testing the applications will now painless enough that I can get into the habit of doing it.
• Automated builds out of the box. Comes with ant build script for common tasks.
  

New Job

Starting new job today to do Java web development at a local Telecoms provider.

The Bad

• Their web framework stack is a little stale i.e. ibatis/J2EE/struts/jsp/tiles
• They are primarily using IBM tools Websphere Developer, Rational, WAS
• They aren't open to using dynamic languages (Ruby) or the frameworks built on them (Rails)

The Good

• They are interested in improving their web framework stack (as long as it's Java)
• There is some interest in XP/Agile (don't scoff. This is pretty rare in Jamaica, in fact I don't think there is a single development shop in the entire country that is doing it)
• They have the infrastructure to support telecommuting and they allow it! (Again very rare here)

Exciting times ahead, look for future posts related to the work I'm doing here.

DSLs and Computer Graphics

The use of Domain Specific Languages in Teaching Computer Graphics Courses

Gordon DuQuesnay
ID#9613644





Analysis of Programming Languages, Assignment 1
Wessel Thomas
February, 2007

Abstract:

Domain Specific Languages (DSLs) are limited forms of computer language designed for a specific class of problems. This approach to programming has been used for some time, for instance, it is very common among LISP and Smalltalk programmers. In spite of their having been around since the dawn of programming they have only recently become a hot topic for discussion in the industry. In this paper I will examine a particular a subset of DSLs referred to as Internal DSLs (Fowler 2006), and how they can be implemented in the Ruby language. I will further show how they could be used in computer science courses such as the "Computer Graphics" course as taught at the University of Technology's School of Computing and Information Technology.

Problem Statement:

Computer Science courses often attempt to deliver very challenging, technically complex content. While some complexity is unavoidable the level of complexity in a course is often compounded by the need to also teach topics that introduce incidental complexity along with the core topic. For example consider the Computer Graphics course, the core complexity of this course involves the various algorithms for producing complex shapes in two and three dimensions by building upon graphic primitives, the most basic being the displaying of a single pixel. However, in addition to this the students must also master C++ and OpenGL, each of which introduce additional incidental complexity. The use of a DSL for graphics could allow the course to focus on the essentials of graphics without having to also concurrently deal with the complexities of C++ and OpenGL.

Research Questions:

• How can DSLs help to reduce complexity?
• What type of DSL would be best suited for use in the compter graphics course?
• What language would be best for writing the DSL?

Literature Review:

How can DSLs help to reduce complexity?
In his paper No Silver Bullet, Brooks explains why he feels the software industry is unlikely to experience orders or magnitude increases in productivity. At the core of his argument is the idea that the complexity of any system can be divided into two parts, the essential and the accidental or incidental. The essential complexity is that which is inherent in the problem. The incidental complexity on the other hand is a function of the difficulty of adapting a general purpose language and platform to be able to solve that problem. Vanderburg asserts a third kind of complexity that arising from the dissonance due to mixing code addressing incidental and essential complexity and suggests DSLs as a way of minimizing this complexity.

What type of DSL would be best suited for use in the Compter Graphics course?
According to Freeze there are two ways to create a DSL. One is to invent a syntax from scratch, and build an interpreter or compiler (External DSL). The other is to tailor an existing general-purpose language by adding or changing methods, operators, and default actions (Internal DSL). The advantages of Internal DSLs as opposed to External make them well suited for use in computer science courses. In particular the speed of development would allow the lecturer to develop and modify the language as the course progresses tailoring the DSL as needed. The main disadvantage of Internal DSLs, that their syntax is constrained by the language they are written in(Fowler), is not insurmountable since the target users are programmers.

What language would be best for writing the DSL?
Internal DSLs, since they are limited by the syntax of their host language are best expressed in languages that have terse, flexible but expressive syntax. This makes dynamic, interpreted languages such as Ruby ideal (Fowler).

Conclusion:

To illustrate the advantage of using a DSL for teaching graphics consider the following OpenGL program in c++:

#include <gl/glut.h>

const int width=640;
const int height=480;

void display(void)
{
	glClear(GL_COLOR_BUFFER_BIT);
	glBegin(GL_LINE_STRIP);
		glVertex2f(50,50);
		glVertex2f(50,-50);
		glVertex2f(-50,-50);
		glVertex2f(-50,50);
	glEnd();	
	glFlush();
}

void reshape(int w, int h)
{
	glOrtho(-300.0, 300.0, -200.0, 200.0, -1.0, 1.0);
}

void main(int argc, char **argv)
{
	glutInitWindowSize(width, height);
	glutCreateWindow("Graphics Programming Basics");
	glutDisplayFunc(display);
	glutReshapeFunc(reshape);
	glutMainLoop();
}

Notice the complexity of even this simple program, also notice the mixing of the essential and incidental complexity. With words and symbols like "void", "int", "**", "}" and ";" which really have little to do with graphics sprinkled throughout the code. An internal DSL written in Ruby could reduce this complexity allowing the same program to be written like this:

window :title=>"Graphics Programming Basics", :width=>640, :height=>480

Ortho(-300, 300, -200, 200)

lineStrip do
point(50,50)
point(50,-50)
point(-50,-50)
point(-50,50)
end


References:

Brooks, F (1986) No Silver Bullet: Essence and Accidents of Software Engineering. Retrieved February 7, 2007

from http://www-inst.eecs.berkeley.edu/~maratb/readings/NoSilverBullet.html

Buck, J (2006) Writing Domain Specific Languages. Retrieved February 7, 2007

Web Site: http://weblog.jamisbuck.org/2006/4/20/writing-domain-specific-languages

Deursen , A., Klint , P., Visser, J. (1998)Domain-Specific Languages:An Annotated Bibliography.

Retrieved February 7, 2007

from: http://homepages.cwi.nl/~arie/papers/dslbib/

Fowler, M. (2006). Introduction to Domain Specific Languages.
Retrieved February 4, 2007, from InfoQ Web Site:
http://www.infoq.com/presentations/domain-specific-languages

Fowler, M. (2005). Language Workbenches: The Killer-App for Domain Specific Languages?

Retrieved Februery 7, 2007, from Martin Fowler's Bliki

Web Site: http://martinfowler.com/articles/languageWorkbench.html

Frecho, J. (2003) Domain-Specific Languages - An Overview. Retrieved February 7, 2007

from: http://compose.labri.fr/documentation/dsl/dsl_overview.php3

Freeze, J (2006) Creating DSLs with Ruby. Retrieved February 7, 2007
from http://www.artima.com/rubycs/articles/ruby_as_dsl.html

Graham, P (1993) Programming Bottom Up. Retrieved February 7, 2007

from http://www.paulgraham.com/progbot.html

Olsen, R (2006). Building a DSL in Ruby. Retrieved February 4, 2007,
from Russ Olsen's Weblog
Web Site: http://jroller.com/page/rolsen?entry=building_a_dsl_in_ruby

Vanderburg, G (2006) Interviewed by Geoffrey Grosenbach. Retrieved February 7, 2007
from Rails Podcast
Web Site: http://podcast.rubyonrails.org/programs/1/episodes/glenn_vanderburg_mp3

Wikipedia Article (2007) No Silver Bullet. Retrieved February 7, 2007

from http://en.wikipedia.org/wiki/No_Silver_Bullet

Ruby and DSLs

I recently got an assignment for my Analysis of Programing Languages course. Since I've been getting into Ruby I chose a topic that would allow me to delve into some of the areas that, as a Java programmer, I've been finding more mystifying. I also had a Computer Graphics assignment given out at around the same time so I combined the two. It is published using Google documents at http://docs.google.com/View?docid=ddqzx3ws_6frhjrv.