No Fluff Just Stuff

Live Service Reloading in Tapestry 5.2

Howard Lewis Ship — Mon, 15 Mar 2010 13:13:00 CDT

A common question I get during Tapestry training sessions is: Why can't Tapestry reload my services as well as my pages and components?. It does seem odd that I talk about how agile Tapestry is, with the live class reloading, and how nicely OO it is, what with services ... but when you move common logic to a service, you lose the agility because services do not live reload.

This came up yet again, during my latest training session, in London.

I've considered this before, and I've been opposed to live service reloading for a couple of reasons. First, live reloading requires creating new class loaders, and that causes conflicts with other frameworks and libraries. You get those crazy ClassCastExceptions even though the class name is correct (same name, different class loader, different class). Further, in Tapestry IoC, services can be utilized to make contributions to other services ... changing one service implementation, or one module, can cause a ripple effect across an untraceable number of other services. How do you know what needs to be reloaded or re-initialized?

When I last really considered this, back in the HiveMind days, my conclusion was that it was not possible to create a perfect reloading process: one that would ensure that the live-reloaded Registry (and all of its services with all their internal state) would be an exact match for what configuration you'd get by doing a cold restart.

So I shelved the idea, thinking that simply redeploying the WAR containing the application (and the services and modules) would accomplish the desired effect.

But as they say, The Perfect Is The Enemy Of The Good. One very sharp student, Andreas Pardeike, asked: Why not just reload the service implementations?.

Why not indeed? Why not limit the behavior to something understandable, trackable, and not very expensive. Most of the infrastructure was already present, used for reloading of component classes. What about ClassCastExceptions? In Tapestry, service implementations are already buried under multiple layers of dynamically generated proxies that implement the service interface. The underlying service implementation is never automatically exposed.

A few hours of work later ... and we have live service reloading. Each reloadable service gets its own class loader, just to load the service implementation class. When Tapestry is periodically checking for updated files, it checks each reloadable service. If necessary, the existing instance, class and class loader is discarded and a new class loader created for the updated .class file.

This is going to make a big difference for me, and for most Tapestry developers. Both applications I'm working on have enough Hibernate entities and other clutter to take some time (20 - 30 seconds) to restart, and most functionality is hidden past a login page. Being able to change a service, for example to tweak a Hibernate query, with the same speed with which I can tweak a template or component class, is just one more thing to keep me in the flow and super productive.

Give it a try ... it's one more step towards making Tapestry so compelling, you wouldn't think of using anything else!

Procrastination and JavaOne 2010: See you in 2011!

Howard Lewis Ship — Mon, 15 Mar 2010 10:30:23 CDT

Well, that's what I get for waiting until the last day ... by the time I had a chance to put together a submission or two for JavaOne 2010, the site was down (from about 10pm on). Kind of frustrating, I was looking forward to talking about Tapestry and Clojure (my main speaking staples) in front of another big crowd.

Open Source Update: jQuery PeriodicalUpdater, TestingLabs, GPars, etc.

Robert Fischer — Fri, 12 Mar 2010 12:28:00 CST

I’ve done a fair bit of fairly small open source updates recently.

jQuery PeriodicalUpdater: The main function now returns a handle that can be used to call stop(), thereby ignoring any updates that may come back and preventing future updates from being sent.
TestingLabs: I released TestingLabs 0.4 to work with Grails 1.2.0. Had a bug with versioning under Grails: More info on JIRA.
Presentations: I’m now storing the slides for my presentations on GitHub. They’re under a Creative Commons License.
ClosureBridge: This is a tiny library (up on the repo.smokejumperit.com Maven repo) that provides a link between Groovy’s Closures and Callable/Runnable/Java code.
Fun with GPars: A small library where I was experimenting with GPars
GPars: Submitted a fix and generally been discussing things with the GPars community (and by that, I mean Vacalv Pech)

See my GitHub page for more info.

This post was by Robert Fischer, written on March 12, 2010.
Comment on this post: http://enfranchisedmind.com/blog/posts/os-update-march2010/#respond
Public Permalink: http://enfranchisedmind.com/blog/posts/os-update-march2010/

This article was a post on the EnfranchisedMind blog. EnfranchisedMind Blog by Robert Fischer, Brian Hurt, and Other Authors is licensed under a Creative Commons Attribution-Share Alike 3.0 United States License.

Live Service Reloading in Tapestry 5.2

Howard Lewis Ship — Fri, 12 Mar 2010 12:00:35 CST

This came up yet again, during my latest training session, in London.

So I shelved the idea, thinking that simply redeploying the WAR containing the application (and the services and modules) would accomplish the desired effect.

But as they say, The Perfect Is The Enemy Of The Good. One very sharp student, Andreas Pardeike, asked: Why not just reload the service implementations?.

A few hours of work later ... and we have live service reloading. Each reloadable service gets its own class loader, just to load the service interface class. When Tapestry is periodically checking for updated files, it checks each reloadable service. If necessary, the existing instance, class and class loader is discarded and a new class loader created for the updated .class file.

Give it a try ... it's one more step towards making Tapestry so compelling, you wouldn't think of using anything else!

Why Eclipse leaves me wanting

Howard Lewis Ship — Thu, 11 Mar 2010 18:41:15 CST

I think I've come to understand why Eclipse leaves me always feeling a bit frustrated. Yes, it is more stable than IDEA, uses less memory, has some documentation, and a lot of acceptance ... but even so, it just leaves me cold (and I was an early adopter, signed up for the beta way back in 2000!).

Keystrokes are not modal

The fact that I can type a common keystroke into an Eclipse window and not know what it will do is painful. How a keystroke is interpreted depends on what perspective is active, what view or editor has focus, and what kind of data is being edited in the editor. That's dead wrong; keystrokes are about muscle memory, and muscle memory remembers motion, not context. The end result is that I get frustrated hitting keystrokes and seeing nothing happening. It doesn't help that I cycle between Mac and a PC on most days.

You can't have it your way

A tool as powerful and extensible as Eclipse walks the tightrope of offering lots of features and customizations without overwhelming the user. Alas, Eclipse is lying in a broken heap fifty feet below that tightrope. Eclipse has an unending set of options and defaults for things I don't care about, but anything I do care about seems to never be presents. Here's a few ideas of the top of my head:

Stop running launches when I close the project (I often have to kill them from the command line)
Give me a quick way to stop all running launches
Why so many steps to implement an interface? It's the second most common thing I do!
How about a button to quickly relaunch the current running launch?
Why are the available refactorings so paltry and where are the 3rd party ones?

Who's eating their own dog food?

When I used IDEA, I was constantly struck by little details that showed that the IDE developers were also its prime users. For example, it has open-type and open-resource dialogs much like Eclipse ... but each recognizes the keystroke for the other, so that if you mistakenly activate the open-type dialog, you just hit the normal keystroke to switch over to open-resource. Eclipse makes you cancel the dialog first.

Another example: in IDEA if you rename a field, it notices the getter and setter and will offer to rename those as well.

IDEA also has lots of quick fixes everywhere, such as "implement this interface" and lots of other tiny, cool things I miss every single day I use Eclipse. It's been about a year since I gave up on IDEA and I still miss it.

Is it cultural or organizational? Eclipse gives me the impression that day-to-day developers either have no concept of how the IDE gets used (and what rough spots are causing some serious chafing) OR they are somehow prohibited from fixing things that are obviously wrong.

If you love IDEA so much why don't you marry it?

So why don't I use IDEA anymore? Two main reasons: first, it's become very bloated, to the point that unless you go in and shut off a ton of features, it's unusable on my hardware. Merlyn has the same problem doing GWT work on his MacBook Pro ... all the help it gives you comes at a cost in terms of CPU and memory utilization and some instability.

Secondly, I tried (even before IDEA went open source) to use IDEA in my training labs and I hit a stone wall of non-acceptance. Switching to Eclipse was a benefit to my students since, even running in Ubuntu instead of Windows, it was familiar and easy to navigate. It also out-performs IDEA inside my Ubuntu Virtual Machine. I simply lack the ability to switch between the two on a constant basis without getting completely confused and frustrated. I had to choose one, and I chose Eclipse: stable and accepted, even if it is brain dead.

Why call it Ugly?

One thing I don't get is how many people claim Eclipse is "ugly" and IDEA "beautiful". I found IDEA to be overly chock-full of modal dialogs and a number of improperly resized (or non-resizable) dialogs and windows. It's a real dog's breakfast in terms of UI, and has the classically ugly Swing look and feel.

I've always found Eclipse to look sharp and somewhat elegant. You can have a debate about the technical merits of SWT vs. AWT and Swing, or the ability to tune Swing to look like SWT ... but SWT out of the box is simply a better L&F visually.

On a Mac they both suck at keyboard navigation, though.

There, I've vented. See what going cold-turkey from Twitter can do?

Actor style messaging and honey do lists

Andrew Glover — Wed, 10 Mar 2010 09:56:00 CST

As I previously mentioned in “Free lunches, mousetraps and the Actor model“, Edward A. Lee wrote an interesting article entitled “The Problem with Threads” in which he advocates leveraging the actor model in popular languages (such as in Java) as opposed to adopting an entire new paradigm (like Erlang). He states:

We should not replace established languages. We should instead build on them.

It appears that more than a few hip people agree with his line of thinking. It turns out there are quite a few options available for leveraging the actor model in Java. That is, aside from alternative languages like Scala, which supports actors and Groovy with GPars, there’s framework’s like Kilim, ActorFoundry, Actors Guild, and jetlang.

I ended up employing Kilim at a client side over a year ago to replace a thread based computational model. At the time, GPars was in its early stages and I was specifically looking for a speed up in application performance. The multi-threaded application was taking roughly 5 hours to complete.

In the end, the speed up attributed to Kilim (or indirectly leveraging its actor model) was hardly noticeable (some aspects of Kilim were noticeably faster though — such as spawning a task was quite fast as opposed to spawning a normal threads) as the real performance gain was leveraged by reducing and improving database queries (as usual, performance issues were essentially IO bound); nevertheless, the prime benefit of Kilim, which at the time I had overlooked, was the notion of a mailbox. That is, in the actor model, processes can share data more safely.

There are quite a few different implementations and ways to facilitate message passing in various languages and platforms, but to me, the actor model’s mailbox notion is quite intuitive. In Kilim’s actor model, messages are passed between processes via a Mailbox — in many ways, you can think of it as a queue. Processes can put items into a mailbox and also pull items from a mailbox in both a blocking and non-blocking manner (blocking of the underlying process not a thread).

As an example of leveraging mailboxes in Kilim, I wrote two actors (a Husband and a Wife) that extend from Kilim’s Task type. Previous versions of Kilim had an Actor type; however, as of version 0.6, Task is the way to go.

import kilim.Mailbox;
import kilim.Pausable;
import kilim.Task;

public class Husband extends Task {
 private Mailbox<Message> mailbox;

 public Husband(Mailbox<Message> mailbox) {
  super();
  this.mailbox = mailbox;
 }

 @Override
 public void execute() throws Pausable, Exception {
  while (true) {
   System.out.println("Husband listening...");
   Message msg = mailbox.get(); // blocks
   if (msg.getReceipient() == Message.HUSBAND) {
    System.out.println("Husband hears: " + msg.getMessage());
    Message reply = new Message(Message.WIFE, "Yes, dear");
    mailbox.putnb(reply);
   }
   Task.sleep(1000);
  }
 }
}

Under the covers, Kilim works by weaving bytecode so as to control Task types and facilitate their safe interaction — specifically, Kilim’s weaver is looking for methods that throw the Pausable type (previous versions used the @Pausable annotation).

In the Husband class, a few things are going on — first, the instance waits for a message from a shared mailbox. In this case, I used a blocking get call (as in reality, a husband really doesn’t do anything else but waits for orders (I mean requests) from his wife). When a message is picked up, the instance checks to see if it was intended for it (in many cases, wife instances can communicate with children types sending messages like “clean your room” or “brush your hair”).

Once a Message type (which, in this case, is not a Kilim type) is determined to be sent to a Husband instance, the Husband type replies appropriately by creating a Message and placing it into the mailbox instance. Finally, the sleep call is just placed to facilitate reading console output.

The Wife class is similar (expect that she doesn’t wait to listen…). Like the Husband instance, this class creates a Message (in the form of a Honey Do) and sends it off via the shared MailBox; however, she doesn’t wait around — that is, the instance uses the putnb call, which is non-blocking. What’s more, she’ll also attempt to see if anything is in the mailbox for her, but in her case, she also uses a non-blocking call (getnb) like so:

import kilim.Mailbox;
import kilim.Pausable;
import kilim.Task;

public class Wife extends Task {

 private Mailbox<Message> mailbox;

 public Wife(Mailbox<Message> mailbox) {
  super();
  this.mailbox = mailbox;
 }

 @Override
 public void execute() throws Pausable, Exception {
  while (true) {
   Message request = new Message(Message.HUSBAND,
    "Please do x, y, and z today, husband.");

   mailbox.putnb(request);
   Task.sleep(1000);
   Message msg = mailbox.getnb(); // no block

   if (msg != null && msg.getReceipient() == Message.WIFE) {
    System.out.println("Wife hears: " + msg.getMessage());
   }
  }
 }
}

As you can see, if there is a message waiting for her, she’ll hear it, otherwise, she moves on and requests her husband to do something else.

Lastly, everything is coordinated by a simple driver class containing a main method like so:

import kilim.Mailbox;
import kilim.Task;

public class HoneyDo {

 public static void main(String[] args) {

  Mailbox<Message> sharedMailbox = new Mailbox<Message>();

  Task wife = new Wife(sharedMailbox);
  Task husband = new Husband(sharedMailbox);

  husband.start();
  wife.start();
 }
}

Note how a Mailbox instance is created for my custom Message type; what’s more, the sharedMailbox is then shared between both the wife and husband instances. Lastly, things are started via the start method.

Running this hip example yields the following output (remember, your exact output will most likely look different; however, the logic sequence of activities will line up. That is, the wife requests things be done and the husband responds with “yes, dear”, which the wife hears).

 Husband listening...
 Husband hears: Please do x, y, and z today, husband.
 Husband says: Yes, dear
 Husband listening...
 Wife hears: Yes, dear
 Husband hears: Please do x, y, and z today, husband.
 Husband says: Yes, dear
 Husband listening...
 Wife hears: Yes, dear
 Husband hears: Please do x, y, and z today, husband.
 Husband says: Yes, dear
 Wife hears: Yes, dear
 Husband listening...
 Husband hears: Please do x, y, and z today, husband.
 Husband says: Yes, dear
 Husband listening...
 Wife hears: Yes, dear
 Husband hears: Please do x, y, and z today, husband.
 Husband says: Yes, dear
 Wife hears: Yes, dear
 Husband listening...
 Husband hears: Please do x, y, and z today, husband.
 Husband says: Yes, dear

The actor model facilitates concurrent programming by allowing a safer mechanism for message passing between processes (or actors). Implementations of this model vary between languages and frameworks — I suggest checking out Erlang’s actors followed by Scala’s as each implementation is quite neat given their respective syntax.

In the end, if you want to leverage plain Jane Java actors, then have a look at Kilim (or one of the other frameworks available) — just make sure you’ve finished your honey do list first, man.

Looking to spin up Continuous Integration quickly? Check out www.ciinabox.com.

Another Good Tidbit from GOOSGBT

James Carr — Tue, 09 Mar 2010 08:37:00 CST

I’m currently in chapter 12 of Growing Object Oriented Software Guided By Tests and thought I’d share another good tidbit from one of the asides:

Put Tests in a Different Package

We’ve adopted a habit of putting tests in a different package from the code they’re exercising. We want to make sure we’re driving the code through its public interfaces, like any other client, rather than opening up a package-scoped back door for testing.

Good point! Almost everytime I’ve found my self expose a method that should be private as protected or default it’s been because that method was really in gross violation of Single Responsibility Principle and I’ve often taken such code and extracted it to a separate object.

Thoughts?

Java Champion

Howard Lewis Ship — Mon, 08 Mar 2010 18:39:48 CST

You might call it petty, you might call it vain, but I've aspired to be recognized as a Java Champion for the last couple of years. The process by which you are selected for this is a bit secretive, but I've finally gotten the nod and joined the roster.

My larger goal for Tapestry has always been to create a web application platform so compelling that it would draw developers to the Java programming language, just to be able to use it. Of course, that's not so much a goal as it is a journey. Technologically, I think Tapestry has the chops to embrace that goal (or journey) ... and looking at current discussions and developments in the Tapestry world, I think the other critical areas where Tapestry is lagging (namely, Documentation and Marketing) may come around.

Want to do your part? Blog about Tapestry ... what you like, what you don't like, what's missing, and what's hidden.

ESDC 2010 resources

Andrew Glover — Mon, 08 Mar 2010 12:48:00 CST

I recently had the opportunity to present four different talks at the Enterprise Software Development Conference (or ESDC) in San Mateo, California. In an effort to provide additional data points and information, I created individual resource pages for each talk. These pages (hosted at my company’s site — beacon50.com) provide links to articles, blog entries, tutorials, and a copy of each presentation. If you’re curious to see what you missed at ESDC, then have a look, man:

Thanks to everyone who came to ESDC and attended my talks — I had a great time discussing these topics (and more!) with you!

Looking to spin up Continuous Integration quickly? Check out www.ciinabox.com.

Mockito 1.8.3 Released

James Carr — Sun, 07 Mar 2010 22:14:00 CST

Szczepan has announced on the Mockito user mailing list that 1.8.3 of Mockito has been released. This released includes several small (but useful) additions as well as bug fixes.

The two parts of this release I like are the new annotations @Spy, @Captor, and @injectMocks. These add to the already useful @Mock annotation to simplify test setup tremendously. Additionally, the @Mock annotation is now configurable so you can add different Mock/Stub styles; previously @Mock only supported the default mock behavior, now you can configure it to RETURNS_MOCKS, CALLS_REAL_METHODS, etc.

This release also includes a feature I requested that can be useful when trying to get legacy code under test, something I call deep stubs. Ever been in the situation where you have code with something like this in the middle of it:

someCollaborator.getFoo().doBarThings().getBaz().execute().processResult();

Normally to stub this call, you’ll have to mock every object returned by each method call, and then stub the last one. Examples for code like this can be a little verbose, but now you can just @Mock the aggregate root and do something like:

given(someColllaborator.getFoo().doBarThings().getBaz().execute().processResult).willReturn(resultObject);

Just remember friends, this is only good for legacy code… if you are already writing your code exemplar first to drive your design, you should know better than to make your object know too many details about it’s neighbors.

This release also includes a patch I submitted to stop having all of the examples in a test run when trying to run a single one in eclipse and intelliJ when using MockitoJunitRunner.

For a complete list of features/fixes, see the release notes.

Scala: Post-Functional, Post-Modern, or Just Perl++?

Robert Fischer — Sat, 06 Mar 2010 21:30:00 CST

Let’s start with some background.

I complained that Scala did not seem to be very functional to me, but I didn’t really know how best to express what was fundamentally wrong with it. I did know that if “functional languages have a fixed set of features” like Scala’s creator, Odersky, claims, then it wasn’t simply “first-class functions in there, function literals, closures”, “types, generics, [and] pattern matching”. Scala has missed the functional boat in some basic way.

After a kerfuffle in the comments, Brian enlightened us all by telling us what is a functional programming language. His explanation (while being a self-admitted generalization) is summarized as follows:

So, what is it that differentiates the functional programming languages from all the other programming languages? It is simply this: the functional programming languages use, as their fundamental model of computation, the lambda calculus, while all the other programming languages use the Turing machine as their fundamental model of computation.

Six months later, Odersky responds with a very interesting post, which actually agrees that Scala is not a functional language in Brian’s sense, but instead argues that any language is functional if it “makes programming centered around functions easy and natural”. He then runs through a list of features which is in common with functional languages, noting that Scala has them within handwave enough (more on that later). He ends wishing that people would “stop thinking of functional programming as a different, novel, or exotic way to code”. Even more, though, Scala is apparently “an early example of a new breed of postfunctional languages”.

And that gets us to this blog post.

First of all, Odersky is still missing the point. It’s not about whether you use fold, map, and iter, or whether you can write closures easily. It’s not even really about pure functions vs. side-effects. To code in a functional style is a fundamentally different way of thinking about problems: instead of thinking about problems as nouns that are doing things, functional programming views a problem as a series of transformations to the world which results in an answer. This is why functional programming is considered “a different, novel, or exotic way to code”: it is a different, novel, and (as of yet) exotic way to code. It’s as different, novel, and exotic from OO as OO was from procedural. It’s a different way of thinking about the entire issue. You can check out this snippet of an IRC conversation from #ocaml for more on that.

The paragon of this way of programming is point-free programming, where you are quite literally building up a mega-function that describes how your program works, and then executing that one, single function when you run that program. If your language doesn’t lead people to re-discover point free programming at least in the small, then the language really isn’t taking function manipulation and functional language type conceptions seriously. And that’s the case with Scala: even Odersky admits that in Scala, “currying is more verbose and much less used than in other functional languages”. (Protip to Scala people: If one of the fundamental stunts of a style is pervasive in all the code but yours, you’re not in the same style of programming.)

What really gets me, though, is the claim that Scala is “an early example of a new breed of postfunctional languages”, because aside from the static typing, all the language features that Odersky trots out already exist in Perl. It’s hard to be a vanguard of a new breed of programming languages when there’s prior art from the 1980s.

Don’t believe me? The existence of a book on the topic unconvincing? Then let’s run the list of functional language features from Odersky.

Functions as first class values: check.

sub apply(&$) { # Take a function as an argument no problem $_[0]->($_[1]);
}
 
sub times2($) { # Create a function to take print $_[0]*2 . "\n";
}
 
apply(\&times2, 3);

Convenient closure syntax: check

my $x = 2;
apply { print $_[0]*$x . "\n" } 3;
 
my $times_x = sub($) { print $_[0]*$x . "\n";
};
$times_x->(3);

List comprehensions: check. (See perlfunc on list data.)
“Curried” function definitions and applications: check-ish.
Okay, so calling this a “check” on Scala is a bit of a reach (cite, cite, cite, although note this—here is a more sympathetic run-down on Scala currying). Ignoring the foo(2,_:Int) syntax for a moment, we can implement basically the same style of “‘curried’ function definitions” such as Scala’s List#foldLeft.
```
sub add { my $x = shift; return sub { $x + shift };
}
add(2)->(3); # Okay, so you do need an extra ->
```
In the case of our apply function above (where we take a function as the first argument), it’s even easier.
```
apply { print $_[0]*$x . "\n" } 8;
```
Now, there isn’t really argument skipping (i.e.: foo(_:Int,3)) as a syntax feature, and there isn’t a built-in curry function, but if you want Scala’s Function.curried in perl, here it is:
```
# This code released under Creative Commons 0 and WTFPL.
sub curry(&@) { my($f,@args) = @_; return sub { $f->(@args, @_); };
}
 
sub add($$) { return $_[0] + $_[1];
}
 
my $curried = curry(\&add, 2); print $curried->(3) . "\n";
```
Lazy evaluation: check. See Scalar::Defer for lazy val equivalents and Tie::LazyList for lazy seq equivalents. People generally use a double-return approach for generators (which I realize are different than lazy seqs and only kinda-sorta lazy).
Pattern matching: check (okay, check-ish). See Switch. The decomposition isn’t there, which is the biggest weakness. But the general cumbersomeness and lack of real algebraic data types hamstrings the coolest parts of pattern matching anyway, so I’m calling it a draw. (This should be read as a generous and sympathetic ruling for Scala: Cedric Beust, for instance, rails against pattern matching/case classes and says “it’s hard for me to see case classes as anything but a failure“.)

In addition, perl’s got a few features in its favor for functional programming, like more flexible arguments, autovificiation, list/argument coercion, and dynamic symbol table mangling. Since perl also has OO capabilities, perl is at least as convincing a “post-functional language” as Scala. But there’s even more in common between the two than that.

Odersky’s “post-functional language” is really a subtype of Larry Wall’s “post-modern language”: it’s an attempt to create a language that is a grab-bag of multiple paradigms. And when you do that, you’re just begging for the complaints that you hear leveled against both perl and Scala: it’s too complicated, its syntax is weird, it’s too magical, people write in entirely distinct subsets of the language, etc. (cite, cite, cite) Now, those who master the language (or master their favorite subset of it) love the TIMTOWTDI aspect. But it also means that the language is left as a jack-of-all-trades, master of none. Yes, Scala and perl integrate a lot of powerful tools from functional languages—but learning OCaml still blew my mind, despite knowing perl for years. As I started off saying, Scala is not a functional programming language. It is a statically typed object oriented language with closures.

Now, there is a sense in which Odersky is really onto something. The world of programming is forever transformed with closures and list comprehensions as being mandatory for new high-level languages, even if they’re otherwise object oriented. And software developers are going to need how to work with them effectively if they want to read code moving forward. Yes, after 20+ years, the rest of the programming world finally caught up to one of perl’s fundamental insights.

Comments

March 7, 2010, Barry Kelly wrote: Functional programming optimizes for different things than OO does. That means for different problems, you want to take different approaches, depending on your level of familiarity with the problem domain and the solution strategies. And thus for a language that supports both paradigms, different people will often end up using different subsets of the language. But I don't think this is necessarily a damning criticism. Our problems are bigger and more compositional. We need languages that have the semantic richness to support different solution strategies. An example. There's an isomorphism between OO polymorphism / dynamic dispatch, and algebraic data types / pattern matching and destructuring. OO lets you add subclasses as late as dynamically at runtime. ADT lets you add functions freely, and such functions are more composable that they're dealing with well-defined quantities. More generally, OO is about defining loosely bound protocols, while FP is more about flexibly defining transformations over tightly defined structures. But if you want to write a solution that's natural for one paradigm in the other, you end up re-inventing and poorly reinventing the other paradigm. In a comment somewhere else out in the ether, I made an argument that getting FP to work as well as a dynamically typed late bound language like Ruby for fast-iterating web solutions that join together multiple independently developed and fast-iterating modules, you'd end up writing what amounted to a dynamic language just to avoid the brittleness that comes from the over-specification that naturally falls out of static typing. I will agree that e.g. currying is useful, as it decomposes the concept of functions of arbitrary arity into what amounts to a linked list of unary functions; and this is particularly handy for programming in a point-free style. But point-free mostly helps (I would assert) on problems where what you need to do is create an algorithm, where little helpers like fold, map, memoize etc. are your bread and butter. But not all problems are like that, not by a long shot.
March 7, 2010, Ittay wrote: "because aside from the static typing, all the language features that Odersky trots out already exist in Perl" That is a big 'aside'. You also forgot that Scala runs on the JVM and Perl not. Not to mention that I think it is common consensus that Perl code is very unreadable. So Scala is a language that combines some FP characteristics with OO, running on the JVM and with a readable (and scalable) syntax. That's a big win for me.
March 7, 2010, Robert Fischer wrote: I will freely grant that there's a lot to be gained by having some flexibility, but languages that end up trying to play in multiple sandboxes end up either doing one part badly (e.g. OCaml and OO, Scala and functional). The answer seems to be using multiple languages for different contexts, not trying to create the One True Language with all the features of the world in it. That's why when I encounter a programming problem, I will generally reach for perl, Groovy, or OCaml/F#: which one I go for depends on the nature of the problem. But I don't long for a day when there's a language that has all the features of perl, Groovy, and OCaml, because they're fundamentally incompatible takes on the process of programming. The strongly opinionated natures of these languages is precisely what makes them so good. Scala's lack of strong opinions is what's frustrating me. Well, that and having to explain to Java devs over and over again at No Fluff events that learning Scala does not mean learning to program in a functional style. I mean, you can code Scala in a functional style, but I can code Java in a functional style. And yes, it's a bit easier to code in a functional style in Scala, but learning Scala is no more learning functional programming than learning perl is learning functional programming.
March 7, 2010, Robert Fischer wrote: The "readable (and scalable) syntax" bit is a big assumption—at least to my ear, there's as much concern about the readability of Scala code as there is about perl code. And how much Scala's static typing really helps vs. how much it gets in the way is a matter of contention. But both of those are an aside. The purpose of this post was not to say that people should stop coding Scala and start coding perl: if you're still futzing around in Java-land, Scala (like Groovy and JRuby) is a productivity huge win that can leverage your existing infrastructure. Groovy's probably the semantically closest, JRuby's the conceptually cleanest, and Scala keeps the fetishized complexity and the BDSM aspects of Java. No, this wasn't a call to go back to perl. The purpose of this post is to show that the idea of merging closures with imperative isn't a new idea, and that Scala is no more a functional language than those languages (like perl) which merged the concepts beforehand.
March 7, 2010, Richard Vowles wrote: I've been saying this for 6 months at least now - Scala and Perl have way more in common than Scala has in common with any other language. Including a tendency towards unreadability.
March 7, 2010, Marc wrote: "It’s as different, novel, and exotic from OO as OO was from imperative." OO is as imperative, if not more so, than C. I assume you meant procedural? Also, there is nothing new in programming languages, period. Everything you see in "new" languages was figured out at least 20 years ago. So, all language designers are just mixing and matching as they see fit. So it's unfair to single out Scala in this regard. While you're at it, go after Groovy, Clojure, Boo, F#, etc.
March 7, 2010, Nick Bauman wrote: I find the description "combines some FP characteristics with OO" problematic when discussing hybrid Functional / OO languages. The more I use one of my favorites of these languages, Python, the more I find the OO aspects receding into the background and the functional ones coming to the fore. It seems to me that Functional is OO "done right" where when I do use OO in them, it's not as heavyweight and seems more natural. I think the key is that in most traditional OO languages the concept of what a type is tends to be much narrower. Can you confirm this in your experience?
March 7, 2010, Thomas Heywood wrote: Robert, I admire your ability to "professionally blog." You delivered no useful content, but you did it with inspiring attention to page hits and comment controversy. Yes, Scala is a multiparadigm language. Yes, Perl is one too. Yes, they both share features from Common Lisp. That's not really worth my or your time. But you cleverly used the confrontational tone to make the blatant non-issue into a controversial issue. You cleverly used Blogosphere's beloved "Scala" and "Perl" tags in a single article. You nagged about a minor syntax issue like it was life-or-death as only a true master-of-functional-programming-who-blogs-more-than-he-actually-programs can. Bob, you're my hero - a true Dilbert's Wally in flesh. A guy without any real code to show - but who "realigns the tone of existing projects" and whose "technical leadership focuses on pragmatic communication" like there's no tomorrow. Wally - sorry, Robert - do you think you could write some posts on how to professionally sell bull and call it "technical accomplishments?" Many of us CompSci majors would like to get in on this money for nothing scheme. Unless, of course, you're not comfortable writing about things you actually do know a little about.
March 7, 2010, Nilanjan Raychaudhuri wrote: Well I believe it is possible to write unreadable code in any language and I am not sure blaming any programming language for that is a good idea.
March 7, 2010, Daniel Spiewak wrote: Throwing out static typing fundamentally changes what Scala has to offer. In a sense, I agree with you that if we completely threw out Scala's type system (and all that it entails), then we would end up with a language which improves very little (if at all) over languages like Perl or Ruby. However, that first step is a doozy and not really fair. Consider a snippet like this:
```
"123".to[Int] // => 123
".+".to[Regexp] // => /.+/
true.to[Regexp] // compile error!
```
There's a lot of magic going on here, all of which is made possible by the static type system. In fact, while this sort of thing is *possible* in a dynamic language with open classes (like Ruby), the implementation will be ugly, unscoped, brittle and difficult to extend. In Scala, the implementation looks something like this:
```
trait Converter[-A, +B] { def apply(a: A): B
} implicit object StringToInt extends Converter[String, Int] { def apply(str: String) = str.toInt
} implicit object StringToRegexp extends Converter[String, Regexp] { def apply(str: String) = Regexp(str)
} implicit def toSyntax[A](a: A)= new { def to[B](implicit conv: Converter[A, B]) = conv(a)
}
```
This is taking advantage of a feature which Scala inherits from Haskell called typeclasses. This is an feature which is inherently tied to static typing and is often very difficult to emulate in dynamic, so-called "more flexible" languages. The real magic of this is two-fold. First, it's scoped, and so we actually have to import these members before they start messing with our objects. It's hard to over-state how important this is to keeping such extensions from devolving into intractable monkey-patching. Second, it's extremely extensible. What if we want to add another conversion from Foo to Bar? Just define it ourselves as an implicit value in scope! Or, if we don't want the implicit syntax, we can always specify the conversion explicitly:
```
// off in *our* code, separate from the converter lib
implicit object StringToBool extends Converter[String, Boolean] { def apply(str: String) = str.toBoolean
} "true".to[Boolean] // => true
"false".to(StringToBool) // => false
```
I'm not even going to try to imagine how to do this sort of thing in Perl. Even in Ruby, which usually makes monkey-patching quite simple, the implementation still ends up extremely nasty:
```
class Object def to(target) case target when :fixnum if self.class == String self.to_i else raise "Unknown conversion: String -> :fixnum" end # ... end end
end
```
...and, you get the picture. You could probably do this in a nicer way, but it would still end up being fragile, unscoped and virtually impossible to extend. This is what you're throwing away when you discard the type system, not some unreliable correctness "guarantee". And if I can throw together an example like this in a blog comment in just a few lines of Scala, imagine what can be done in a non-trivial system with real requirements. The type system is an intrinsic part of Scala's power and expresivity. Remove it and you're not even looking at the same language.
March 7, 2010, Daniel Spiewak wrote: While currying and point-free aren't as syntactically clean as they could be in Scala, they are certainly still used (I use those features all the time). Does this make Scala less "functional" than Haskell or ML? Yeah, probably (I've made that argument in the past). Does it mean that Scala is no more functional than Perl? Absolutely not. Theoretically speaking, currying is possible in any language which supports closures (alblue, if you're reading, yes I do mean "closure" and not "lambda"). You can even define a curry function in C++, though the obfuscated template mess it entails makes it nigh unreadable. Lambdas ("closures" if you will) and function values do not a functional language make. C has function values, and I don't think anyone who understands the debate will argue that it is "functional". Ruby has function values and lambdas, but they are fundamentally different constructs and produce different values (just like in Perl). Again, not a functional language (though you can use many patterns which find their roots in FP, like map and fold). My point is this: you can't go out of your way to link FP to point-free and lambda calculus and then turn right around and claim that Perl and Scala are in the same league. Scala's unified functions and function values alone should be sufficient to overturn that one.
March 7, 2010, Robert Fischer wrote: Yes, I meant procedural.
March 7, 2010, Martin wrote: You really can't claim "perl has had _____ since the 80's" and then point to books about Perl 5. Perl 25 years ago is *very* different than it is now. Your point that Scala and perl are similar is well taken, but I'm not totally clear why this is bad for Scala or Perl. The way Perl 6 is going towards a virtual machine, I wouldn't be surprised to see Perl and Scala and Java running together on a JVM sometime soon.
March 7, 2010, Robert Fischer wrote: I'm not saying it's bad for either Scala or perl to be similar to each other — on the point of similarity, I'm simply saying that in the ways Odersky argues Scala is "functional", perl is just as functional, and so I'm still unconvinced that Scala deserves to be called a "functional language". You don't hear people listing off the functional languages like: "Haskell, OCaml, perl, Lisp...". So to hear people say "Haskell, OCaml, Scala, Clojure" just gets my goat. I'm also saying that on the point of similarity, it shouldn't be a surprise that we're getting similar unreadability/complexity complaints about Scala as we got about perl, since they are so similar. I heard something about perl getting onto the JVM for AppEngine, but can't find additional info on it.
March 7, 2010, Robert Fischer wrote: In what ways do Scala's unififed functions and function values outperform perl?
March 7, 2010, Robert Fischer wrote: Note the point I'm arguing: I'm arguing that Scala is no more a functional language than perl is. Functional languages can be dynamic (e.g. Clojure), so static vs. dynamic typing is irrelevant to the point I'm trying to make.
March 7, 2010, Robert Fischer wrote: You've earned a special spot in my heart: this is my new favorite flame of all time. I mean, the fact that you say I don't have "any real code to show" just goes to show that you're not paying attention, because you've somehow managed to miss my long trail of open source projects. And you kinda missed the boat on the entire fundamental question: "Is Scala a functional programming language?" But still, the Dilbert references, the accidentally-on-purpose "slip of the keyboard", and the general long-suffering tone is really nicely done. A+
March 7, 2010, Robert Fischer wrote: Oh, and you're fair on the dating thing. It's hyperbolic to conflate Perl 1 with Perl 5, although I honestly have no idea how far back I can go in perl and still have my code samples work. If you find out, let me know.
March 7, 2010, Robert Fischer wrote: Brian Hurt, the co-blogger here on EnfranchisedMind, is theoretically working on a post about how OO is fundamentally broken. I'll leave that to him. My experience has been that many of the Gang of Four design patterns just aren't relevant anymore, and inheritance is something I'm extremely reluctant to use and much more aware of its difficulties. I'm not sure exactly what it would mean to say that "the concept of what a type is tends to be much narrower", but I certainly have a much thinner type hierarchies in the world of functional programming.
March 7, 2010, Robert Fischer wrote: Oh, not to mention the cite of enterprise-ese from SmokejumperIT.com. I mean, that's some real attention to detail for the zingers. In all seriousness, this is my favorite flame of me of all time. Thanks!
March 7, 2010, Dave wrote: FWIW, I really dug this post. As to the topic at hand, I'm not even sure what point there is to saying Scala is or isn't "functional". The only real purpose seems to be to make it easy to show how awesome Haskell is by point out Scala's perceived shortcomings as a functional language. For my money, Scala is simply "Java: The Next Generation". A general-purpose, statically-typed, object-oriented language that has broad applicability to many problem domains. Arguing "what is functional" might be a fun exercise, but it's not really going to lead us anywhere; look at most n-tier Java applications: to say they are object oriented would be a vast overstatement. Java is object-oriented in that it's main means of organizing code are around classes and objects (which is exactly the same as in Scala), but most systems still end up using OO only when it helps, and throwing it for imperative/procedural stuff when it makes sense to do so. I would be willing to bet that Scala will be much the same way; the code inside our classes might be much more functional (simply because its' simply worth-it to do in Scala, whereas it's not terribly so in Java), but I don't see it ushering in some functional utopia (LISP has had, oh, I don't know, the entire history of the field of computer science to usher this in and largely failed [no offense to LISP]). Scala is an escape route from Java's cruftiness without having to bend your mind or prejudices too much. Much as Java was to C++.
March 7, 2010, Tracy Harms wrote: The most interesting sentence in your post, to me, was this: If your language doesn’t lead people to re-discover point free programming at least in the small, then the language really isn’t taking function manipulation and functional language type conceptions seriously. This has me wondering, though, about your agreement with Brian that the key quality is reliance on lambda calculus as the model of computation. Not that I'm convinced we need a "key quality." It just looks to me that the range of languages you have in mind would not be identified through this criterion.
March 8, 2010, joe poki wrote: what's up with these groovy people nowadays? groovy++ is 10 trillion times faster than scala actors, now this piece. your rant could be summarized like I Do Not Like Scala. Look, I get that. But I must say it's funny that you use this patronizing tone with Odersky as he was a n00b who has no idea about languages and then once you get a trollish comment, you go on and post it everywhere: OMG somebody was responding to my trollish post in a trollish manner, what a surprise? as for your post: just because a language can be used in a certain way (or certain language toolsets can be simulated in that language) that does not mean that the users will find that specific style idiomatic. What matters is the style you will meet the most while reading or writing code in that specific language (hack, even java has various functional libraries: lambdaj, functionaljava etc. but how many people would consider code written with these library java-like?). When people say that scala is "kinda functional", what they really mean is that the language is nudging you into that direction (preference for pattern matching, option type, final variables, map, foreach,closures, partial functions etc.). And this nudging towards the functional style is what makes scala "postfunctional". (other features responsible for the "scala feel" but not directly related to the functional thing: static typing w/ type inference, a powerful type system, xml literals, implicit converions, case classes, mixins + various actor libs etc.)
March 8, 2010, Robert Fischer wrote: My issue isn't with people saying Scala is "kinda functional". It's saying it's a "functional language". I've heard people say they want to learn Scala b/c then they'll know functional programming, and that's just wrong. Worse, I've heard people write off functional programming because they didn't like Scala. This means that the misconception that Scala is a functional language is hurting real functional language adoption and hindering people's advancement as software developers by making them think they know functional when they don't. So I'm trying to reinforce the barrier between real functional languages and languages with closures. I'm not particularly knocking Odersky here: what he's done with Scala is pretty impressive. But he's clinging to a title that Scala doesn't deserve. While I appreciate the move with "postfunctional", I'd be a big fan if it also meant he'd give up "functional" — but he's just taking both titles on. In so doing, he's diluting what we mean by a "functional language", and that's just not helpful to anyone involved. The evidence does seem to be that Odersky doesn't really know functional languages. Or, if he does know them, he knows them academically or intellectually, and doesn't really grok them. But you can't be an expert on everything, and I get that. This whole conversation is really kind of sad. There's such an extreme dichotomy here: the assumption seems to be that if you criticize a language, you must hate it. I don't hate Scala: Scala is what Java should be. It's finally a competitor to C# on the JVM — the advanced capabilities of C# have been downright embarrassing for a long time, and Scala evens the playing field. I'm just criticizing the way we talk about this language, and providing counter-evidence to some of the claims made about it.
March 8, 2010, Robert Fischer wrote: Which languages do you see as missing one of the two qualities?
March 8, 2010, Robert Fischer wrote: As I will say below, my issue is mainly one of vocabulary and pedagogy, because I'm frustrated with the murky waters that such marketing-speak has created.
March 8, 2010, Robert Fischer wrote: PS: From someone who has been there (remember: I'm a static typing fan, too): If you want to debate static typing usefulness vs. dynamic typing usefulness, don't argue that it's hard to implement type safety in a dynamically typed language. It doesn't win you any points with the dynamic language crowd, because they've already accepted they don't need it.
March 8, 2010, Peter Lewerin wrote: Daedalus and his son Icarus were imprisoned by King Minos, and made themselves wings out of wax and feathers to escape. Before they took off from the island, Daedalus warned his son not to fly too close to the sun. The sensation of flying made Icarus forget the warning and he soared higher and higher. Eventually the wax melted and he fell into the sea. A programmer can escape the prison of procedural programming using functional programming, but going for the purest form of FP isn't really a sustainable goal. Most likely, these wonktional programmers will melt their wings by straying too close to the realm of mathematics and plunge to their deaths.
March 8, 2010, Thomas Heywood wrote: And you kinda missed the boat on the entire fundamental question: “Is Scala a functional programming language?" Scala is a multiparadigm language that supports procedural, functional and object-oriented programming. We've had that since 1950s and Lisp. Now, what was the fundamental question again?
March 8, 2010, Thomas Heywood wrote: (Mea culpa: we've only really had it supplied with the language since 70s, when Lisp machines took off. Still, a blatant fact is blatant, no matter how much you blog it into shape.)
March 8, 2010, Vassil Dichev wrote: Robert, if you like Perl, that's nothing to be ashamed of :-) Seriously, I think your article is thought-provoking, if a little controversial. Still, there are several things I disagree with. First of all, I have interpreted Odersky's article in the spirit of: "OK, I don't insist on calling Scala a functional language". One important piece you didn't mention was immutable data structures. Perl doesn't scale very favorably here. Was this on purpose? I find it important not just what a language *can* do, but also what it *cannot* (easily) do. Mutation and scoping are some of the things Scala restricts rather successfully. I also don't find how the fact that Perl has flexible arguments, autovivificiation, list/argument coercion, and dynamic symbol table mangling makes it more functional. Does Haskell have these? Do you consider Haskell functional? Then I also don't see many people argue that Java is object-oriented. By the same reasoning, it's not- it certainly has types that are not objects, and you can certainly write in a procedural style in Java (unfortunately some people really do). Also, I don't see you arguing that OCaml is not object-oriented, because it's also considered a multi-paradigm language. I see that in one of your comments you agree that OO is poor in OCaml, which is fair enough, but I think some OCaml users wouldn't agree with you on this count either. I most emphatically agree that if you "know" how to write working Scala code, this doesn't mean you know all about functional programming. But I disagree that this harms "real" (read purer) functional languages any more than Java harms "real" object-oriented languages (whatever they are). In the end, I'm also fine with the definition of "statically typed object oriented language with closures".
March 8, 2010, Vassil Dichev wrote: I've just read some of the blog posts you've linked to, and it's quite telling that two of them complain that Scala is too functional, while you complain that it's not functional enough. I think this is the problem with Scala: you can't appease everybody without any mental effort on their part to get used to the new style of programming. And I think the same can be said of OCaml. I also think OCaml would be a wonderful language to learn (and I might try it soon).
March 8, 2010, Paul Kaletta wrote: All of your examples should work with any version of Perl 5, which came out in 1994.
March 8, 2010, Martin Odersky wrote: Robert: Your blog and even more so your comments make it sound as if I have no clue about what functional programming is. So, it must be because of a series of freak accidents that I organized ICFP, am a member of the IFIP working group on functional programming and am a member of the editorial board of the Journal of Functional Programming. And I even published quite a bit on lambda calculus, too :-). Seriously, I stand completely by my article on postfunctional programming. I believe your post here has added nothing of substance to the discussion. http://www.scala-lang.org/node/4960
March 8, 2010, joe poki wrote: if you cite every single well-known post that dismisses scala one way or another and you go on and say "it’s too complicated, its syntax is weird, it’s too magical, people write in entirely distinct subsets of the language", then people will rightly assume you do not like scala, I do not get it why you are surprised (notice, I did not say you hate it, just that you dislike it). see, the patronizing stuff again "Odersky doesn’t really know functional languages". As I tried to point out: what matters is how a language is used and what's considered idiomatic and in that sense scala definitely has some functional feel to it (and no, it's not just about closures or foreach, but preference for pattern matching, option types, final variables, map, foreach,closures, partial functions etc. etc.).
March 8, 2010, Tracy Harms wrote: To the best of my knowledge, Factor, Joy, FL, and J are languages that favor anonymous arguments (and/or emphasize composition of functions) while lacking reliance on lambda expressions.
March 8, 2010, Robert Fischer wrote: If you're up for not calling Scala a "functional programming language", tell Odersky.
March 8, 2010, Robert Fischer wrote: It's not patronizing to say someone doesn't know something, or to disagree with the way someone is using language. That's just not what patronizing speech is. It'd be patronizing if I started explaining to Odersky what closures are and how they're supposed to work, or if I sent you off to look at this link. That would be patronizing.
March 8, 2010, Thomas Heywood wrote: Your blog and even more so your comments make it sound as if I have no clue about what functional programming is. Martin, hate to break it to you, but all you ever did was bring effective functional programming to a mainstream platform for the benefit of industry and academia. Call me back when you write a wrapper library or two, learn the persistence API of a web framework, or realign the tone of existing projects.
March 8, 2010, Robert Fischer wrote: That's cool that you're so involved. Ultimately, though, our problem is boiling down to one of language. If Scala and perl are functional languages, how do we differentiate them from languages like Haskell, OCaml, and Lisp, where the fundamental way of tackling problems is different? I'd like to use the term "functional programming language" for the latter, and I'm more than happy to stick to "postfunctional programming language" or "multi-paradigm programming language" for the former. But that means we stop calling Scala a functional programming language, as most of the commenters here on the post already have. Deal?
March 8, 2010, Robert Fischer wrote: Yeah, that's the general issue with these multiparadigm languages like Scala and perl. If OCaml narrowly avoided that fate (and I think it has), it was by completely subjugating the OO aspect to the functional aspect, and not really using the OO aspect much.
March 8, 2010, joe poki wrote: If you think saying somebody does not know squat about a subject while that person is supposed to be some sort of an expert on the topic is not condescending, then I do not know what is. By the way, it seems I was not alone, see Odersky's comment above.
March 8, 2010, Robert Fischer wrote: The immutability is a good point, and it's an area where Scala certainly pulls ahead. Actually, the Ruby (and, to a lesser extent, C#) people regularly say that Java isn't really OO, because a lot of things in Java weren't either objects or messages. I think Ruby inherited that criticism from the old SmallTalk people. And I'll happily argue that OCaml isn't object oriented: while it has objects, it's certainly not oriented towards them. What harms functional programming languages is when Java people learn Scala and then think they know functional programming languages. Or, worse, when they decide they don't like Scala and then conclude they don't like functional programming. This happens a lot because Scala was lauded as a functional programming language on the JVM which was comfortable for Java people. It's the murkiness in the water that's the issue.
March 8, 2010, Daniel Spiewak wrote: In Perl, functions and lambdas are fundamentally different. If nothing else, this can be seen by the different invocation syntax. You can convert between functions and lambdas (just like in Ruby and Groovy), but they are very different constructs as far as the language is concerned. To me, one of the essentials of a functional language is that functions are merely lambdas which have been assigned to a named value. OCaml and Haskell encourage this notion with their syntax for function declaration (in fact, Haskell's function decl syntax is exactly the same as its value decl syntax). Perl doesn't even come close to meeting this qualification. Scala does substantially better, though I'll admit that it does have its gotchas (methods are sometimes tricky).
March 8, 2010, Robert Fischer wrote: While that's a bit hardcore of a comparison (and somewhat damning on people's ability to learn), I definitely agree with your point. And Scala's great in this regard—as I said a number of times, I think Scala is where Java should be if Java's growth hadn't been stunted. If you look at how C# has evolved, Scala's basically right in line with that kind of development. And so a Java developer learning Scala in order to push their way of thinking about types and functions is a great move.
March 8, 2010, Robert Fischer wrote: True — I'm oversimplifying the world into imperative and functional. There are other paradigms out there (e.g. Factor's stack-based approach) which also can lead to point free programming.
March 8, 2010, Robert Fischer wrote: Do they work before that? (Or, rather, would they work before that if I dumped the prototypes?)
March 8, 2010, Robert Fischer wrote: True: there are conversions that need to be made between functions and lambdas in perl. This suggests for Scala (as a multiparadigm language) having a somewhat stronger functional aspect than perl, but it still doesn't make it a functional programming language a la OCaml and Haskell.
March 8, 2010, Alicia wrote: Wouldn't it be awesome if you really could make money writing b.s.? People won't even donate a dollar towards valuable open source projects...the suggestion that you could make money for being good at b.s. is hilarious.
March 8, 2010, Robert Fischer wrote: Amen.
March 8, 2010, Robert Fischer wrote: True enough. I'm just trying to wrap my head around how Odersky can really grok functional programming and then assert that it's simply bolt-on features of a language. The difference between Haskell and Java is not simply one of syntactic sugar. Claiming he's mistaken about how FP works is actually a generous take—claiming he's clinging to the FP title for Scala for some ulterior reason when he should know better is much less generous. I was trying to give him the benefit of the doubt.
March 8, 2010, James Iry wrote: Robert Fischer Finally Admits That Scala Is Functional (http://james-iry.blogspot.com/2010/03/robert-fischer-finally-admits-that.html)
March 8, 2010, Martin Odersky wrote: Robert, please, read my post again: http://www.scala-lang.org/node/4960 Nowhere did I define functional programming exclusively by a list of features. Instead I had as my central definition: "A functional language makes programming centered around functions easy and natural." A good test of this would be: is it common to write functional programs in the language in question? It's usually far easier to tell whether a program is functional than whether a programming language is functional. By that standard Scala is clearly functional; many of the classes and modules written in it are purely functional and every cool idea from Haskell seems to be implemented sooner or later in Scala (not that we don't invent some cool ideas of our own as well). I don't know Perl well enough to be able to tell whether there are many functional programs written in it, and whether the expression of such programs is easy and natural.

Free lunches, mousetraps and the Actor model

Andrew Glover — Tue, 02 Mar 2010 18:01:00 CST

A politician once mused

A free lunch is only found in mousetraps.

While this quote is amusing, it’s painfully true. In fact, the whole notion of a free lunch and its consequences was copacetically captured by Herb Sutter in an article entitled “The Free Lunch is Over: A Fundamental Turn Toward Concurrency in Software” that was published in Dr Dobb’s Journal back in 2005. In this well crafted masterpiece, Mr Sutter tore apart the misplaced belief that Moore’s Law would continue to unleash higher and higher CPU clock speeds and thus he predicted an end of the “free lunch” that we’ve had when it comes to increasing the performance of software applications. That is, clock speeds have roughly stabilized around 3GHz — and they’ve held there for a few years now.

As Mr. Sutter points out

the growth [in chip speeds speeds] will come mostly in directions that do not take most current applications along for their customary free ride.

Thus, obtaining an appreciable speed up in application performance requires taking advantage of multi-core chip architectures (where Moore’s Law has been realized). And to do this, of course, Mr. Sutter advocates concurrent programming:

applications will increasingly need to be concurrent if they want to fully exploit CPU throughput gains

Interestingly, the author concludes with a few points, one of which hits the nail on the head with respect to where the majority of mind share around this subject is focused:

we desperately need a higher-level programming model for concurrency than languages offer today

Indeed, the basic programming model of hip languages like Java is thread based. And while multi-threaded applications aren’t terribly hard to write — there are challenging to write correctly.

In a paper published in 2006 by Edward A. Lee entitled “The Problem with Threads“, the author argues that concurrent programming isn’t all that hard. In his view, the problem isn’t with concurrency — it’s with the prevailing model: threads.

As he states:

The problem is that we have chosen concurrent abstractions that do not even vaguely resemble the concurrency of the physical world

The author goes on to point out that the inherent non deterministic nature of threads presents a conundrum for developers:

a folk definition of insanity is to do the same thing over and over again and to expect the results to be different. By this definition, we in fact require that programmers of multithreaded systems be insane.

Mr. Lee provides an interesting story regarding the challenges and hidden dangers of concurrent programming. He relates an experience where a multi-threaded application that had a strict code review policy in place along with 100% code coverage (note, what type of coverage or how it was obtained wasn’t disclosed) ran for 4 years without error. Nevertheless, finally the code deadlocked. He goes on to speculate that many

multi-threaded general-purpose applications are, in fact, so full of concurrency bugs that as multi-core architectures become commonplace, these bugs will begin to show up as system failures

As such, Mr. Lee espouses an alternative to threads: actors. He’s quick to note that actor-oriented models aren’t new, but what he does suggest is interesting. He notes that languages that have actors, such as Erlang, weren’t taking root (at the time); thus, he submits:

We should not replace established languages. We should instead build on them.

Fast forward to today. Java the platform isn’t dead. It’s thriving with a multitude of alternate JVM languages — a few of which embed the actor model (namely Scala). What’s more, libraries written in Java and for Java are available, which enable the actor model (such as Kilim). Plus, the Java language itself has started to add more complex features to enable easier concurrent programming.

So what’s the lesson in all of this? First, the evolutionary instinct to throw more hardware at a performance problem is now extinct. Programs written today will need to be designed with concurrency in mind. Second, doing this with normal threads is challenging at best. A better, more understandable way is via the actor model, which is available in a number of frameworks and alternate languages. Therefore, learn them today, lest you find yourself snagged by a mousetrap, man.

Looking to spin up Continuous Integration quickly? Check out www.ciinabox.com.

Presenting at Lambda Lounge This Thursday

James Carr — Mon, 01 Mar 2010 11:49:00 CST

I’ll be giving a presentation at Lambda Lounge this Thursday on Behavior Driven Development With Jspec. If you’re in the St.Louis area come on by and learn about BDD and how you can use it to drive your design. I’ll be using jspec to demonstrate how to build a functioning feature for a javascript library driven by small, iterative examples.

Retrospective Rules

James Carr — Sun, 28 Feb 2010 10:36:00 CST

I’m gearing up to put together a retrospective for my team at my current client site, and I’ve been both thinking about and reading over notes from previous retrospectives I’ve either sat in or facilitated. Looking over a lot of these notes, especially from the worst ones, I’ve noticed an emerging pattern of behavior that can either make or break a retrospective. Here’s a few that I think are the most important.

Retrospective Belongs to the Team
This is possibly the most important observance I’ve noticed… retrospectives are only effective if they truely belong to the team. This means that it should only be attended by the team and only the team can pick a goal and how they’re going to follow up on them. Management shouldn’t attend the retrospective imho as they can cause interference, step in, or require metrics to be collected. Several retrospectives I participated in at my previous client had the manager constantly cut people off or tell them that the goal they’re proposing won’t work and refuse to let it be considered. These retrospectives were the most useless in my opinion and we never accomplished anything.
Don’t Let It Become a Whine-fest
Retrospecting is about inspect and adapt… about looking at our experiences over the past and using root cause analysis to find causes and how we can improve in the future. However, if there is plenty of negativity in the past, it can be easy to succumb to “crying over spilt milk” without coming up with any real solutions. And nothing is worse for a team then to spend an hour in a room listening to each other bicker without any from of constructive activity… it will leave the team feeling down rather than up. Therefore aim to keep the retrospective on track to discuss the facts and observances and put emphasis that the past is only for concrete experience to draw ideas from. Problem solving activiities should be given more focus than pouring over historical data.
Activities Are Better

I’ve sat in on hundreds of retrospectives, both with activities and without. On the outset, the no-nonsense, just talk about “what worked, what didn’t, what to improve” sounds good, simple, and to the point. However, my experience indicates these were amongst the lowest in terms of effectiveness. For starters I think it keeps people locked into a “this is a meeting” mentality and prevents thoughtful activity. Hell, one place I was at just put a word document up with headings titled “What Worked, What Didn’t Work, Action Items” in which Action Items were items the manager would enter into Rally Project Management and assign to people to work on.

I’ve found that activities often keep people engaged. In a meeting someone can get by by sitting in front of their laptop staring at the projector, with activities they’re constantly involved and not given time to disconnect. Additionally, I find the care freeness (or even fun) of activities helps break down some subtle communication barriers and makes people feel more free to speak their minds.
Pick Only One Goal

In theory picking multiple goals sounds great right? We’ve identified all these impedments and road blocks in our team,process, or environment that really need to be addressed. Why don’t we just tackle ALL of them rather than ignore them so we can work on removing all of them? This is long the same lines of the theory that maximizing Work-in-Progress maximizes effeciency and we all know that this often fails. LIkewise, by maximizing the number of goals that you have for an iteration you run the risk of context switching too much (not to mention all the focus you’ll already have towards the work you’re doing during the iteration) that the team will lose track and quite possibly not make any headway towards any of the goals listed.

Therefore, limit your Work-in-Progress as a team by selecting one (and only one) goal for the team to work towards during the next iteration. Maybe you’ll complete it in one day. Maybe you’ll complete it by the end of the iteration. Maybe you’ll make progress on it and discover in the next iteration that you uncovered deeper issues that need to be addressed.
Follow Up

One of my biggest mistakes I ever made as a facilitator was failing to help the team follow up on goals… I assumed you could just let the team form a goal, work out how they would accomplish it, then just let them leave the room with it to schedule into their iteration and complete. Boy was I wrong. Working towards that goal can possibly even grow future retrospective topics, or like I mentioned previously uncover more serious or deeper issues the team needs to address. Failing to follow up can leave the team with a slew of goals they never complete or superficial goals that only kick some dirt over the issue. So it’s good to recap on the goal that was formed as part of establishing historical data near the beginning of the retrospective and let it help drive new ideas or delve deeper if it wasn’t completed. Often times you can find incomplete goals correlate to the iteration… for example if it wasn’t reached because there wasn’t enough time to work on it, maybe there’s not enough slack in the iteration?

Again, out of all these, I’d have to say the most important is number one: the retrospective belongs to the team. This is an activity for the team by the team to help them inspect and adapt their process and shouldn’t be something enforced upon them or led by their manager. I ask all ScrumMasters out there to take special care if you facilitate the retrospective… in my opinion you really shouldn’t, but if there’s an absence of facilitation skills you might need to. If this is the case, remember your position… you are not a manager and therefore should not use this to dictate goals to the team. Stay as neutral as possible and at all costs do not allow yourself to become the owner of a solution, it needs to belong to the team and the team needs to make whatever needs to happen happen. If they need to schedule a task into the iteration, let them do it rather than do it for them.

Likewise, as a facilitator it is of utmost importance to remain neutral. When I facilitate teams I am on I try to refrain altogether from involvment. Also remember as facilitator it’s your job to facilitate the discussion, not drive it or offer solutions. I’ve facilitated a retrospective once where someone called on my expertese with fitnesse to help them solve a recurring fitnesse problem they were having. Sadly, I offered solutions. Looking back, I should have suggested that they come up with a goal, and if they needed help they could come seek me out when I had my developer hat on out on the floor. Further, I often find that when a facilitator from the team participates, they often drive the entire retrospective. Either their ideas lead for the rest to follow (even if they participate last) or the teams participation might fall on deaf ears. I once watched a friend of mine facilitate a retro for our team and draw out a huge value map… at each time two or three pople would say what they thought the cause was, then he’d say “well, I think it’s really this…” and write out his own idea in the map without taking into account what the team said. When I called him out on this he couldn’t believe he did that.

Overall, keep in mind the retrrospective is for finding solutions, not problems. Keep it on track, listen, and help guide the teams to introspect within themselves and find the solutions they need. Most importantly let them do the decision making and above all use the retrospective as their own activity to get better.

Scala specs + Mockito == Dead Sexy Examples

James Carr — Wed, 24 Feb 2010 21:51:00 CST

Been doing some fooling around with scala for a little bit tonight, and specifically been trying out the BDD framework specs. specs adds some nice stuff to mockito that makes it read like a natural language… and I like it!

Take this simple example of stubbing:

list.get(0) returns "yo"

Yep… that’s perfectly valid scala code… and totally awesome.

Want to verify that a method was invoked with a specific argument?

notifier.send(order) was called

And again yes, that is a real line of code pulled from one of my examples. Take a look at more here.

easyb will support behavior tagging

Andrew Glover — Mon, 22 Feb 2010 18:31:00 CST

Back in the Age of Aquarius, I wrote an article entitled “Use test categorization for agile builds” in which I attempted to delineate various types of tests and then went on to suggest how to categorize these various tests so as to get the most out of a build run (i.e make it fast and effective at providing meaningful feedback). Back then (and to an extent now) my concern was with test execution; that is, I like to categorize tests as fast and slow. Accordingly, I run the fast ones all the time, such as before I check-in (I prefer a fast build to be less than 3 minutes — longer and I get bored). What’s more, for the slow ones, I usually schedule a build (via Hudson, for instance) that runs them hourly, nightly, etc — it all depends on how slow they are, man!

As it turns out, unit-like tests are usually the fast ones and functional-like tests are the slow ones. This all makes sense as functional ones usually require a lot of test up, like seeding a database or firing up Selenium.

Categorizing tests by execution speed it helpful, but a bit broad in some cases. Thus, I often find myself grouping tests (or behaviors) by feature, behavior or goal. That is, there might be a macro-feature in development broken up by a series of stories (or tests) and I find it’s helpful to run those stories as a group in isolation for focus. Those behavior groups are then aggregated into iteration builds that correspondingly execute all targeted behaviors, for instance.

This exercise, combined with the influence of TestNG (which supported test groups long long ago) has lead to a new feature in easyb: tags. With the tags keyword, you can categorize a behavior and then exercise only those desired behaviors via the -tags command line option or via the tags attribute in easyb’s Ant task, for instance.

Thus, the following story is tagged as “23949314″ — this happens to be a Pivotal Tracker story ID and in the current iteration, there are 4 stories 23949314, 23949315, 23949316, 23949317.

tags "23949314"

scenario "AcmeFoo should support expired account deletions"
scenario "AcmeFoo should support child account deletions"

The beauty here is that when this particular story is run, its status is pending, thus providing some status as to a particular feature.

Going forward in this iteration, subsequent easyb stories are tagged with appropriate IDs (23949315, etc) and during this iteration, builds are run that exercise these particular tags in isolation. Of course, there are other builds that exercise all other existing stories (via a build pipeline) so as to perform a continuous regression.

The tags keyword is flexible too — you can add multiple tags by including the tag names in a List like so:

tags ["23949314", "functional"]

scenario "AcmeFoo should support expired account deletions"
scenario "AcmeFoo should support child account deletions"

In this case, this story is tagged as both 23949314 and functional — accordingly, a build can be configured to execute only functional behaviors and, of course, this one will be included. Conversely, if a build is run with a tag such as prototype, then this particular story won’t be executed.

This is an evolving feature in easyb. Right now, only story level tags are supported. Scenario tagging is planned. What’s more, tags are currently supported in the tip of easyb’s SVN repository — if you’re eager to start using them now, you’ll have to build your own version of easyb. Otherwise, a release is forthcoming, which will contain this feature. Can you dig it?

Looking to spin up Continuous Integration quickly? Check out www.ciinabox.com.

March of Progress

Howard Lewis Ship — Mon, 22 Feb 2010 12:15:20 CST

Or should that be "Late February of Progress". I have to say I'm a bit envious right now of Rich Hickey ... I can see that he's continuing on like a steam roller, extending and improving Clojure. I guess he's having some success in generating Research and Design budget from funding companies. I can see, following his threads, that he's working on yet more concurrency metaphors for Clojure, which is a good thing (though eventually there'll need to be a big book just to describe them all).

I'm on a different track, in that I fund Tapestry out of pocket while doing training and project work. In some cases, those merge, such as when I add specific features to Tapestry for a specific client.

I'm of two minds here: doing project work keeps me grounded in real requirements for Tapestry. I see what works really well, and what needs some polishing. On the other hand, I come up with ideas for new components, improvements, and integrations all the time and barely have enough free time (between clients, ordinary Tapestry maintenance, and this special project) to even document my ideas, never mind implement, test and distribute them.

So, should I set up a funding option like Rich's? Well, that wouldn't help my current clients (I'm committed to getting their apps into production), but it may change how I would look for future work.

Setting up Clojure 1.1.0 on Mac OSX

Ken Sipe — Sun, 21 Feb 2010 22:27:00 CST

As part of the Lambda Lounge, established by Alex Miller (Thanks!!), we have started a group to study the SICP. We just started and are going virtual... if you would like to participate, email or tweet me (@kensipe). In the process of studying SICP and LISP, I plan on focusing on Clojure. Clojure was previously on my machine as I was reading Stu's book Programming Clojure, however increased usage would require some maturing of my tools. This led to the discovery of Mark Reid's blog on Setting up Clojure for Mac OS X, however I assume based on updates and changes over the last year, it requires some updates.

Read Mark's blog first... getting clojure, the clojure-contrib and jline. Here are the differences:

Create an environment variable CLOJURE_HOME assigned to the directory for clojure
Create the /bin directory for the clj script included below
Add $CLOJURE_HOME/bin in the $PATH
Clojure is distributed with clojure.jar in the CLOJURE_HOME... so I maintain that. It is expected that contrib and jline are in the same directory.
Mark's clj script has been updated below... The previous script invokes classes which are depreciated.

Here is the updated script:


#!/bin/bash
# Runs Clojure using the classpath specified in the `.clojure` file of the
# current directory.
#
# Ken Sipe   2010-02-20
# Inspired by Mark Reid 
# original: http://github.com/mreid/clojure-framework/blob/e1c80cc650f448713243be8272dba1fa3c1a7cea/clj
#
# This scripts expects $JAVA_HOME and $CLOJURE_HOME to be defined for the system it is running on
# The clojure.jar is standardly in the clojure_home dir (and not in the lib directory), so
# the expectation is that clojure-contrib.jar and the jline.jar are placed in the same dir

CLJ_DIR=$CLOJURE_HOME
CLOJURE=$CLJ_DIR/clojure.jar
CONTRIB=$CLJ_DIR/clojure-contrib.jar
JLINE=$CLJ_DIR/jline-0_9_5.jar
CP=$PWD:$CLOJURE:$JLINE:$CONTRIB

# Add extra jars as specified by `.clojure` file
if [ -f .clojure ]
then
   CP=$CP:`cat .clojure`
fi

if [ -z "$1" ]; then
   java -server -cp $CP \
        jline.ConsoleRunner clojure.lang.Repl
else
   java -server -cp $CP clojure.main -i $*
fi

Love the TextMate support and the history support in JLine!

The Power of the Backchannel

Nathaniel Schutta — Sun, 21 Feb 2010 16:08:00 CST

Last week, I spoke at the New England Java Users Group, one of the biggest and best around. I had a rocking good time, the audience was outstanding and Dave Klein (author of the outstanding Grails: A Quick-Start Guide) was even there! Anyway, one of the attendees, Deborah Hamill (VP Engineering at Accordare, Inc.), was kind enough to collect up all the links I referenced during the talk – including ones that weren’t even on my slides! Many thanks Deborah, I appreciate it. By the way, said slides can be found here.

http://ntschutta.com/jat/
http://blog.objectmentor.com/articles/2009/02/26/10-papers-every-programmer-should-read-at-least-twice
http://jania.pe.kr/aw/moin.cgi/JSSpec
http://www.jsunit.net/
http://www.extjs.com/
http://en.wikipedia.org/wiki/Ext_(JavaScript_library)
http://developer.yahoo.com/yslow/
http://blog.inspired.no/google-releases-page-speed-for-firebug-665
http://www.prototypejs.org/
http://www.crockford.com/
http://developer.yahoo.com/yui/
http://github.com/
http://www.jslint.com/
http://code.google.com/closure/
http://www.paulgraham.com/pypar.html
http://steve-yegge.blogspot.com/2006/03/execution-in-kingdom-of-nouns.html
http://www.javascripter.net/faq/reserved.htm
http://www.joehewitt.com/
http://www.thefrontside.net/

Acronyms
http://en.wikipedia.org/wiki/Domain-specific_language
http://en.wikipedia.org/wiki/Behavior_Driven_Development
http://en.wikipedia.org/wiki/Continuous_integration

Others Deborah found while searching for my topics:
http://blog.inspired.no/javascript-error-logging-with-ajax-154
http://writecodeonline.com/javascript/
http://www.infoq.com/articles/javascript-tdd

DynamicDomainProperties and the AGPL

Robert Fischer — Sat, 20 Feb 2010 18:24:00 CST

I just released the DynamicDomainProperties plugin for Grails, which allows domain classes to have dynamic properties. It’s pretty nifty, if I do say so myself.

Based on my frustration with the Grails plugin culture because of differing cultural assumptions about open source works, and based on my lack of appreciation for the promises of indirect compensation offered to me as an open source developer, I’ve decided to release it under the GNU-Affero GPL 3.0, which is like the GPL but (among other things) requires the source to be available to the users of a web app that use this plugin.

I’m open to the idea of releasing it under the more “biz-friendly” BSD, but then I’m going to want a different form of compensation. So I’m putting up a bounty via Pledgie: if I was building this plugin as a consultant, it would have cost a client about $2500. So, if the commercial community contributes $2500, I’ll do a BSD release. Anyone who donates $250 or more gets a single-domain usage license right away.

For more information on the plugin, see the plugin page on grails.org. (I’ve had enough difficulty with GitHub’s wiki freaking out on me and would rather avoid that.)

Comments

February 22, 2010, Marc Palmer wrote: I'm interested to see how this pans out Robert - good luck!
March 4, 2010, Jeremy Flowers wrote: Way to go. This looks like the way forward to me. In the Microsoft' arena GUI component vendors started to sell there wares this way too, like Infragistics. I always thought plug-ins would have to go the same way to get support for your plug-ins. You have to put food on the table somehow..
March 5, 2010, Does Grails have a problem? « The MetaSieve Blog wrote: [...] I have time to, I can completely comprehend Robert’s point of view and his desire to get a different kind of compensation for his open source work. In fact, there should be plenty of space for both approaches (and [...]
March 18, 2010, Sakuraba wrote: What part of those profits will go back to the creators of the software you benefit from? What if you had to pay for using Grails source code? You basically take freedom, but you close down your extensions on top of that. How is that fair? In my mind, if you dont stand by your contributions and pass by the freedoms that you have received to others, you shouldnt release those contributions at all.
March 18, 2010, Robert Fischer wrote: The Grails source code developers aren't asking for AGPL freedom. They're apparently feeling sufficiently compensated with the Grails Apache license: indeed, they've done very well by it. And they've done very well by touting the number of (totally uncompensated) open source plugins which are available for the platform they built. My plugin makes their platform more valuable by its very existence. So they're certainly getting their compensation. I, on the other hand, am not sufficiently compensated by the Apache license, so I'm releasing it under the free-as-in-freedom AGPL as my compensation. Even more, I'm not "closing down" my extension, but actually asking for exactly the kind of freedom-in-kind that you're describing. You can use my plugin all you'd like: your web-app just has to be free-as-in-freedom, too. If Grails wanted that kind of license, they could have released under the AGPL.
March 18, 2010, Raphael Miranda wrote: I find awesome your endeavor. We all love open-source but monetizing from it is often really hard if you're not Jboss, Sun or Mozilla. I've made a donation. Not for this plugin especificaly but for this and all others that you have contributed and that make my job easier. Thanks Rob.

This post was by Robert Fischer, written on February 20, 2010.
Comment on this post: http://enfranchisedmind.com/blog/posts/dynamicdomainproperties-grails-plugin-agpl/#respond
Public Permalink: http://enfranchisedmind.com/blog/posts/dynamicdomainproperties-grails-plugin-agpl/

links for 2010-02-20

James Carr — Sat, 20 Feb 2010 07:01:00 CST

Functional Testing Swing Applications with Frankenstein

Evolving the Meta Programming in Tapestry 5

Howard Lewis Ship — Fri, 19 Feb 2010 19:57:16 CST

I've set a goal of removing Javassist from Tapestry 5 and I've made some nice advances on that front. Tapestry uses Javassist inside the web framework layer to load and transform component classes.

All that code is now rewritten to updated APIs that no longer directly expose Javassist technology. In other words, where in the past, the transformer code would write psuedo-Java and add it to a method using Javassist (for example adding value = null; to the containingPageDidDetach() method), Tapestry 5.2 will instead add advice to the (otherwise empty) containingPageDidDetach() method, and the advice will use a FieldAccess object to set the value field to null.

Basically, I've vastly reduced the number of operations possible using the ClassTransformation API. Before, it was pretty much unbounded due to the expressive power of Javassist. Now a small set of operations exist that can be combined into any number of desired behaviors:

Add new implemented interfaces to a component Class
Add new fields to a Class
Initialize the value of a field to a fixed value, or via a per-instance callback
Delegate read and write access to a field to a provided FieldValueConduit delegate
Add new methods to a component Class with empty implementations
Add advice to any method of a class
Create a MethodAccess object from a method, to allow a method to be invoked (regardless of visibility)
Create a FieldAccess object from a field, to allow the field to be read or updated (regardless of visibility)

What's amazing is that these few operations, combined in different ways, supports all the different meta-programming possible in Tapestry 5.1. There's costs and benefits to this new approach.

Costs

There will be many more objects associated with each component class: new objects to represent advice on methods, and new objects to provide access to private component fields and methods.

Javassist could be brutally efficient, the new approach adds several layers of method invocation that was not present in 5.1.

Incorrect use of method advice can corrupt or disable logic provided by the framework and is hard to debug.

Benefits

We can eventually switch out Javassist for a more stable, more mainstream, better supported framework such as ASM. ASM should have superior performance to Javassist (no tedious Java-ish parse and compile, just raw bytecode manipulation).

The amount of generated bytecode is lower is many cases. Fewer methods and fields to accomplish the same behavior.

The generated bytecode is more regular across different utilizations: fewer edge cases, less untested, generated bytecode

Key logic returns to "normal" code space, rather than being indirectly generated into "Javassist" code space ... this is easier to debug as there's some place to put your breakpoints!

Summary

Overall, I'm pretty happy with what's been put together so far. In the long run, we'll trade instantiation of long lived objects for dynamic bytecode generation. There's much more room to create ways to optimize memory utilization and overall resource utilization and the coding model is similar (closures and callbacks vs. indirect programming via Javassist script). I'm liking it!

Git SVN On Windows

James Carr — Fri, 19 Feb 2010 09:18:00 CST

At work we use svn and lately I’ve been trying git svn to maintain a local git repository that I can push to the svn server. So far, I love it! The best feature is being able to use git stash to “stash away” the current dirty workspace, work on something (say a defect), commit and then call git stash pop to return to what I was working on.

Setup is quite easy… on windows, you need to install Cygwin and under devel package select git and git-svn.

Once it’s installed, just follow the following steps to get started:

git svn init http://path/to/svn/project/trunk projectname
cd projectname
git svn fetch -rREVISION (most likely this will be git svn fetch -rHEAD
git svn rebase

That’s it… all the usual git commands will work, and when you’re ready to commit just type git svn dcommit

My only worry is that I have yet to have a conflict, and I’m afraid I’ll be hosed without my usual eclipse conflict compare.

Book Review: DSLs in Boo

Andrew Glover — Thu, 18 Feb 2010 17:34:00 CST

While I don’t spend a lot of time on the .NET platform anymore, I’m still a big fan of Boo. Having cut my teeth on Python many years ago, I’ve always enjoyed hip Pythonic languages and when Boo came out for the .NET platform way back when, I jumped on the opportunity to experiment with it and leverage it at client sites. What’s more, it’s no secret that I’m a fan of DSLs as I do find they can be quite powerful, for example, in leveraging natural language semantics that enhance the “user experience” such as with expressing intent.

Thus, when I had a chance to read Ayende Rahien’s “DSLs in Boo“, I jumped at the opportunity, baby! Ayende does a great job of of introducing the notion of DSLs (interestingly, there isn’t a ton of literature here specifically about DSLs alone other than Martin Fowler’s bliki and of course, Wikipedia) in the first chapter, specifically covering the various types of DSLs (i.e. internal, external, and he goes on to define graphical ones plus he reluctantly includes fluent interfaces). What’s more, he also explores why one would want to write an DSL. Here he covers a few reasons, but a quote stuck out regarding one particular reason, which is for expressing

rules and actions in a way that’s close to the domain and understandable to business people

This is, of course, the intent of easyb — that is, to express intentions in an easily understandable language that stakeholders can grasp.

After chapter 1, Ayende goes on to cover the basics of Boo, which, of course, would be needed should you want to actually create a DSL in Boo! It isn’t until chapter 4, however, that you start to get your hands dirty coding DSLs; nevertheless, I understand the need to introduce the various required concepts leading up to chapter 4. Thus, in chapter 4, a few high level examples are covered.

Later chapters go into some details about writing and maintaining DSL code; plus, in chapter 7, he unveils Rhino DSL, which is an open source project that facilitates authoring DSLs in Boo (Ayende, by the way, is a prolific coder — he’s all over the map in the .NET world). Chapter 8 finally covers testing a DSL, which I can attest as quite difficult but paramount to a DSL’s success and stability. He also goes on to cover versioning, which I found quite intriguing as backward compatibility is a double-edged sword.

What I find most interesting is the way in which a base language affects the resulting implementation of a DSL (i.e. the end result). That is, Pythonic DSLs still have the oft complained about “white-space issue.” For instance, here is a code snippet from the book for an order processing engine:

upon auth_denied:
  when preferred_customer:
       delay_order_until_payment_is_authorized "preferred customer benefit"
  when default_customer:
       cancel_order "no money, no order"

Note how the underlying language (Boo) forces the DSL to use spaces (rather than say brackets or def/do/end like calls), what’s more, underscores (i.e. _) are required so as to keep the compiler happy. It’s, in many ways, the same in something like easyb (which is, of course, backed by Groovy), which is essentially forced to use brackets and in one case, a comma like so:

given "a preferred customer", {
  //blah blah
}

Note how Groovy requires the DSL to include a comma between the description String and the Closure. Ruby, by the way, and in the case of something like RSpec, doesn’t have this requirement. For instance, in RSpec:

it "should return item enqueued" do
  @queue.enqueue("test")
  @queue.dequeue.should == "test"
end

Yet, notice the do and end! Needless to say, you can see similar influences in something like Scala too.

DSLs are interesting beasts and they’ve clearly affected productivity on various platforms (need I remind you that Rails is a DSL?). “DSLs in Boo” specifically explores DSLs on a specific platform, yet it’s still an interesting read. Because it’s my bag, I’m definitely looking forward to more books exploring DSLs as a main subject! All in all though, this is an interesting book regardless of your chosen platform. Can you dig it, man?

Looking to spin up Continuous Integration quickly? Check out www.ciinabox.com.