link

A friend emailed me asking what I thought about Ruby. I've only recently picked up a book on Ruby and am charmed by its comprehensive non-annoyingness. Here's what I wrote back to him. What do you think?

Will it take off? I doubt it. I think it has been steadily gaining over
the past few years, but there isn't anything so revolutionary about its
design or its culture that I think will let it dethrone Perl, PHP, and
Python (perhaps it's the lack of a letter P). At least not in the US. Ruby
originated in Japan, and may well be a leading scripting language there.
It's well-enough known, it has its O'Reilly books, but I don't see it
becoming THE HOT THING. It certainly has little traction in big software
companies.

There is a web application framework for Ruby called Rails [here's a promising recent article], which is rumored
to be a very lightweight, easy-to-start-with framework. Their website has a
10 minute video where someone installs it and builds a sample site. This
is highly laudable in a world where suits insist on web applications written
in J2EE, a framework so byzantine that it makes Software Architects
confident they cannot understand the details of programming, while making Programmers confident they cannot understand the scope of design.

link

This is what I did my undergraduate thesis (2003) on, and now it's showing up in trade publications. I don't think the author, Ramnivas Laddad, knew about my thesis, but perhaps he'd be interested in its large catalog of aspect-oriented refactorings.

link

I've posted my undergraduate computer science thesis on the web, finally. It's on refactoring AspectJ programs. Here's the abstract:

This thesis extends the state of the art in refactoring to Aspect-Oriented Programming. Refactorings are specific code transformations that improve the design of existing code without changing its observable behavior. Aspect-Oriented Programming (AOP) offers a new approach to software design by encapsulating crosscutting concerns. The novel contributions of this thesis are a recasting of existing refactorings to preserve program behavior in aspect-oriented code, and several new refactorings that can improve the design of code by deploying AOP techniques. The refactorings are described in reference to AspectJ, an AOP extension of Java, and are amenable to partial or full automation.

It is necessary to reevaluate existing OO refactorings because the constructs of AOP programming languages significantly affect what changes can be meaning-preserving. To this end, new preconditions and steps are introduced to about 20 fundamental refactorings (from Opdyke, 1992) such as renaming a class and inlining a method. These extended refactorings can form the basis for an AOP-aware refactoring tool.

About thirty new AOP-specific refactorings are proposed. These refactorings include both fundamental refactorings and more complex refactorings built from these that address specific design problems. For example, a simple refactoring possible in AOP is to move the definition of a method from within a class to an aspect. A more complex refactoring that includes this is moving all code responsible for implementing a particular interface into an aspect. The focus is primarily on accomplishing the desired changes once the involved program parts are identified. These new refactorings can form the basis for a truly AOP-focused refactoring tool.

link

Awesome tool that records a complete trace of your (Java) program's actions, allowing you to debug by finding where something went wrong, then stepping backwards in your program to figure out why.

It's like a pause-and-rewind button for the world.

link

you had me at "we believe J2EE should be easier to use"

Update 4/6/04: Holy shit, this is easier to use?

link

Rick Ross responds to the results of this study:

It would be my preference to point out the silver lining in all of this, but I don't see a silver lining here. I believe the folks at Wily Technology have done a genuine service to our Java community, even though the findings of their survey are stark and disturbing. We all need to do a better job, from start to finish, in the process of building, deploying and maintaining high performance J2EE applications. "Five eights" won't cut the mustard, it's just plain lousy.

link