I've had a theory for a while that the best Rock song ever written is "Memphis, Egypt" by the Mekons. Trying to describe it in words is pointless, so go listen to it if you haven't heard it. It's on the album The Mekons Rock 'n Roll. I've had the privilege of hearing them play it live, and all I can say is, holy ****.
There are a few songs that I think are almost as good as "Memphis, Egypt". "Club Mekon", also by the Mekons, comes close, and actually follows immediately after "Memphis, Egypt" on the same album! This has to be the greatest two-song sequence ever recorded.
"The Headmaster Ritual" by The Smiths (on Meat is Murder) is possibly a better song than "Memphis, Egypt", but loses some points for the mechanical production that saps much of the energy from the track. (Aside: the best Smiths album is Hatful of Hollow because it is (mostly) a collection of tracks from radio shows, and captures the manic energy of the band much better than any of their studio output. But you knew that.)
I recently discovered on Pandora a song called "I Stare Out..." by The Verlaines which I think could be as good as all of the previously mentioned songs; at the moment, I consider it a major discovery. (Had you ever heard of The Verlaines? I hadn't.)
Wednesday, April 2, 2008
Thursday, March 13, 2008
Today's riddle: why does CUP emit the generated parser as TWO classes?
OK, so when you use CUP to generate a parser, it emits two classes: a parser class, and an action class (which contains the code generated for the semantic actions associated with the productions of your grammar). These are totally separate classes.
Today's riddle is this:
The action code can refer to the parser via a field called parser, but that's only useful for calling public methods on the parser object. But that means that any internal parser state/operations that the semantic actions want to access must be exposed as public, violating encapsulation.
Blech.
Today's riddle is this:
Why is the code for the semantic actions generated in a separate class?Here are some possible answers:
- Your guess is as good as mine.
- Look in the user manual to find out --- oh wait, the user manual doesn't explain this.
- To ensure that you must violate encapsulation in order to allow semantic actions to refer to internal parser operations?
The action code can refer to the parser via a field called parser, but that's only useful for calling public methods on the parser object. But that means that any internal parser state/operations that the semantic actions want to access must be exposed as public, violating encapsulation.
Blech.
Wednesday, March 12, 2008
GUI Builders for Eclipse
The time has come to talk about GUIs in the Software Engineering course I'm teaching currently, which led me to revisit using a GUI builder in Eclipse. (I will not hand-code a Swing GUI. I just won't.)
Previously I've used the Eclipse Visual Editor plugin, which, while not perfect, generally gets the job done. To my dismay, the current release of the VE does not work with the current stable release of Eclipse, and there has not been an official release of the VE since June 2006. (So sadly neglected / and often ignored / a far second to Belgium / when going abroad / Finland, Finland, Finland :-) I hope this project gets reinvigorated at some point, but I wasn't going to sit on my hands waiting for that to happen.
A quick google search turned up Jigloo, an Eclipse-based GUI builder which, while not free software, is gratis for non-commercial use. From my 10 minutes or so of using it, it appears to be very nice, quite a bit more polished than VE. We'll see how it goes, but I'm cautiously optimistic it will do what I need it to do.
Previously I've used the Eclipse Visual Editor plugin, which, while not perfect, generally gets the job done. To my dismay, the current release of the VE does not work with the current stable release of Eclipse, and there has not been an official release of the VE since June 2006. (So sadly neglected / and often ignored / a far second to Belgium / when going abroad / Finland, Finland, Finland :-) I hope this project gets reinvigorated at some point, but I wasn't going to sit on my hands waiting for that to happen.
A quick google search turned up Jigloo, an Eclipse-based GUI builder which, while not free software, is gratis for non-commercial use. From my 10 minutes or so of using it, it appears to be very nice, quite a bit more polished than VE. We'll see how it goes, but I'm cautiously optimistic it will do what I need it to do.
Tuesday, February 26, 2008
ArgoUML
In teaching a course on Software Engineering and Design this semester, I have rediscovered ArgoUML. Briefly, it's a UML design tool along the lines of Rational Rose or Visual Paradigm. I can briefly summarize its strengths:
ArgoUML's main drawback is the lack of an Undo feature, which is certainly a bit disconcerting. Web search hits of the ArgoUML development lists seem to indicate that this feature is in the works; if it gets done, then I my enthusiasm level would go from "pretty cool" to "KICK ASS". Even without Undo, it's still a good choice for occasional UML modeling needs.
- It works pretty well, especially for basic uses (creating UML class diagrams)
- It's free software (in the sense of both freedom and money)
- It's a pure Java application, and works well on any platform supported by Java
ArgoUML's main drawback is the lack of an Undo feature, which is certainly a bit disconcerting. Web search hits of the ArgoUML development lists seem to indicate that this feature is in the works; if it gets done, then I my enthusiasm level would go from "pretty cool" to "KICK ASS". Even without Undo, it's still a good choice for occasional UML modeling needs.
Wednesday, February 13, 2008
Tuesday, February 5, 2008
Java Software is a Good Thing
I'm teaching a course on Compiler Design, and I'm going to have students use JFlex and CUP as the scanner and parser generators.
I always dread asking students to use any software besides Visual Studio or Java/Eclipse, since it means I have to worry about whether or not
It occurred to me today that JFlex and CUP are both written in Java, so I could simply include them in the assignment skeleton! This took me all of about 5 minutes. Now I have a compiler assignment skeleton that requires only Java and Eclipse. In fact, it has an Ant script, so you don't even have to use Eclipse. So far I've only verified that it works on Linux, but I'm pretty confident that it will work on Windows, too.
JFlex and CUP are both free software, so there are no license issues to worry about.
I always dread asking students to use any software besides Visual Studio or Java/Eclipse, since it means I have to worry about whether or not
- they have it installed
- they have it installed correctly
- they have the right version
- etc.
It occurred to me today that JFlex and CUP are both written in Java, so I could simply include them in the assignment skeleton! This took me all of about 5 minutes. Now I have a compiler assignment skeleton that requires only Java and Eclipse. In fact, it has an Ant script, so you don't even have to use Eclipse. So far I've only verified that it works on Linux, but I'm pretty confident that it will work on Windows, too.
JFlex and CUP are both free software, so there are no license issues to worry about.
Monday, February 4, 2008
The Vague Syntax of Ruby and Ruby on Rails
I like the Ruby programming language a lot, and the Ruby on Rails web application framework is one of the best ones out there. One characteristic they share is an emphasis on writing concise code. Ruby pares down the syntax of writing object-oriented programs to a bare minimum. Rails emphasizes the use of a small number of conventions and idioms in order to avoid specification of all but the most essential details.
However, I think that both Ruby and Ruby on Rails take the principle of brevity to an unreasonable extreme. Here are a few examples.
First, Ruby (the language) does not require parentheses around conditions or method arguments. So, you can write
As an even simpler (and more ambiguous) example, say that you see this code in a Ruby method:
Rails code (at least in the books and on-line tutorials I have read) tends to opt for the same kind of extreme brevity. For example, consider the following code:
I guess that options hashes are good in the sense that unnecessary information can be omitted. However, I think options hashes are overused in Rails. An options hash is basically a "magic bag of goodies" that a method will use to carry out some behavior. However, the specification of the options hash at the call site does very little to inform the reader how the contents of the hash will influence the behavior of the called method. In the case above, it's reasonably clear that :action => :login will redirect to the login action. However, what is going on the :destination key? As far as I can tell, it simply puts request.request_uri in the query parameters of the redirected request, but I fail to see how that behavior is even hinted at in the text of the method call. Wouldn't something like the following be much clearer?
Sacrificing a bit of brevity in order to get self-documenting code seems like a good tradeoff to me.
However, I think that both Ruby and Ruby on Rails take the principle of brevity to an unreasonable extreme. Here are a few examples.
First, Ruby (the language) does not require parentheses around conditions or method arguments. So, you can write
instead offoo.bar baz, thud
In the second form, isn't it much more obvious that we're calling a method, and that baz and thud are the arguments?foo.bar( baz, thud )
As an even simpler (and more ambiguous) example, say that you see this code in a Ruby method:
A bare identifier does not really provide any clue that would suggest to the reader how the identifier is being used. In this case, it will be interpreted as a method call with no arguments. Wouldn't it be much more clear like this?blat
I think the general lack of visual cues in Ruby code makes it difficult to read.blat()
Rails code (at least in the books and on-line tutorials I have read) tends to opt for the same kind of extreme brevity. For example, consider the following code:
I found this code in an implementation of user authentication using something called Confluence4r. The code specifies what should happen when a privileged action is attempted without the proper credentials being present in the user's session. It's reasonably clear that a request is being redirected. However, an options hash is being used to specify the details of the redirection.redirect_to :action => :login, \
:destination => request.request_uri \
and return false
I guess that options hashes are good in the sense that unnecessary information can be omitted. However, I think options hashes are overused in Rails. An options hash is basically a "magic bag of goodies" that a method will use to carry out some behavior. However, the specification of the options hash at the call site does very little to inform the reader how the contents of the hash will influence the behavior of the called method. In the case above, it's reasonably clear that :action => :login will redirect to the login action. However, what is going on the :destination key? As far as I can tell, it simply puts request.request_uri in the query parameters of the redirected request, but I fail to see how that behavior is even hinted at in the text of the method call. Wouldn't something like the following be much clearer?
Sure, we replaced 1 line of code with 5, but the reader would have a much better chance of figuring out what is going on.next_request = Request.new()
next_request,set_action( :login )
next_request.add_param( :destination, request.request_uri() )
redirect_to( next_request )
return false
Sacrificing a bit of brevity in order to get self-documenting code seems like a good tradeoff to me.
Subscribe to:
Posts (Atom)
