Capturing Output from PUTS in Ruby
When writing unit tests for my simplesem interpreter, one test in particular was problematic. In simplesem, the set write instruction prints output to the screen.
// place Hello World! on the 'write' buffer set write, "Hello World!"
Internally, the interpreter is just passing the second parameter, “Hello World!”, to the puts method in Ruby. This makes it difficult to use traditional test/unit assertions to check that the simplesem instruction is working.
I eventually found two solutions for this. The first, suggested by David Stevenson at Pivotal Labs, is to use mocha to check that puts was called on the object.
require 'test/unit' require 'rubygems' require 'mocha' class SimpleSemParserTest < Test::Unit::TestCase def test_set_stmt_write parser = SimpleSemParser.new parser.expects(:puts).with("Hello World!") parser.parse('set write, "Hello World!"').execute end end
This solution is fine for most situations; Mocha will throw an exception if puts is not called. However in my case, it was unsuitable because puts was not being called on the SimpleSemParser object but instead on a Treetop syntax node that I did not easily have access to within the unit test.
I knew that if I could capture the output from the puts method into a variable I would be able write the test using a standard assert_equal. After some googling I discovered that this functionality is built into the ZenTest gem. After rewriting the test looked like this.
require 'test/zentest_assertions' class SimpleSemParserTest < Test::Unit::TestCase def test_set_stmt_write out, err = util_capture do parser = SimpleSemParser.new parser.parse('set write, "Hello World!"').execute end assert_equal "Hello World!\n", out.string end end
This works great. However, should we decided that we do not want to use an external gem, with a little effort we can bypass ZenTest and implement util_capture ourselves.
Automate Updating Your Git Repositories
I have a half dozen TextMate bundles that I am grabbing the latest versions from GitHub instead of from the main TextMate subversion repository. For a long time I have been updating each of the bundles’ Git repositories by cd’ing into each directory and running git pull. Doing this over and over became silly and I was annoyed from doing all that typing.
Today, I finally wrote a basic bash script that automates updating each of the repositories. Sometimes it is surprising how simple an automated solution turns out to be.
A SIMPLESEM Interpreter
In my Programming Languages course, taught by Shannon Tauro we have been using a fake assembly language of sorts called SIMPLESEM to gain experience translating the semantics of a high level programming language, to a simple processor.
Since SIMPLESEM is a made up language that was created just for our textbook, there was no way for me to execute the SIMPLESEM programs that I was writing for the homework assignments. This was annoying because SIMPLESEM is a low level language which makes it hard to notice mistakes. Of course, it is very easy to make a mistake any time you are programming but it is even harder to catch those mistakes if you are working at close to assembly level.
As a fun exercise I implemented an interpreter for SIMPLESEM using Ruby and published it as a RubyGem. Fortunately, I choose to use Nathan Sobo’s Treetop gem to aide in the development. Using Treetop, I wrote a parsing expression grammar to parse SIMPLESEM commands. This resulted in my SIMPLESEM interpreter being a lot more flexible than I had originally anticipated. After I familiarized myself with the basics of writing Treetop grammars I found it very easy to make changes to my grammar definitions to add language features one by one.
Since When Did A Nice Case Cost $300?
This jumped out at me while browsing the Apple Store today. The two 13″ Macbooks are practically identical on the inside. The new aluminum version’s hard drive is 40GB larger and it contains the newer DDR3 memory. However they have the same video card and the same CPU. These changes may seem of consequence, but with the falling price of memory components Apple is likely paying the same price or less for the DDR3 memory and 160GB hard drive than they were for the corresponding parts in the white Macbook a year ago. Making the internal enhancements essentially a free upgrade for Apple.
All that remains is the case. Which means buyers are paying $300 for the upgrade from plastic to aluminum. That unibody case is nice but that is outrageous! It is easy to see where Apple’s high profit margins are. And I thought it was bad when they put a $150 premium on the black macbook casing two years ago.
The Case For Replacing Java With Python In Education
Around 2003 all of the colleges and high schools in the United States switched from teaching Computer Science courses in C++ to teaching them in Java. The intention was to make it easier for students to pick up programming. Schools were finding that many students were struggling to cope with low level tasks in C++ like manual memory management and pointer references. Instead of learning algorithms, data structures and object oriented programming, students were stuck for hours trying to track down incorrect pointer references.
About four years after the education system made the switch to Java from C++, the whole software industry started complaining about the degrading quality of the Computer Science graduates in the US; which is a topic I explored recently. Ultimately, schools have made the switch away from C++, and they are unlikely to go back, nor do I think they should. Instead, what I want to discuss is why did we have to replace C++ with Java? I can see that at the time, it may have seemed the obvious choice, but looking around the language landscape now there are several choices that I think are better suited for the task. Namely, Python.
Java > Python How???
First, I want to really think about what advantage does learning programming with Java have over using a modern scripting language like Python? Python equally hides the things that make programming in C++ laborious and has many of the nice features that the JVM provides like garbage collection, unicode strings, and threads. The difference is Java is miserable for web programming (Java EE) and equally overly complex for building GUIs (Swing). As a scripting language, Python is far easier to pick and learn.
What CS students would lose from switching from Java to Python
- Static Typing - The difference between an Integer and a Float is harder to understand when you do not have to declare variable types.
- Compilation - In my opinion this is not a big deal. They are still going to learn how to debug runtime errors which is where the substance is. Advanced IDEs like Eclipse are making dealing with compiler errors almost a thing of the past in Java. Additionally, the upper division compilers class will still be there to teach them the ins and outs of compilers.
- Performance - This is a moot point. I only put it down because it is what most people think of first but very rarely do the projects assigned in a classroom require serious computation. I would also wager that even the ones that do can be solved in a satisfactory manor with Python. If anything it will force students to be more creative about their solutions instead of just relying on brute force.
What CS students will gain from switching from Java to Python
- Dynamic Typing - There are tradeoffs to both approaches but as nearly everyone who programs dynamically typed language for a while finds out that the type safety provided by static typing is unnecessary and more often gets in your way than it helps you (ex. Casting).
- Interpretation - Becoming familiar with interpretation is just as important as compilation. Interpretation opens several doors for you when programming and is becoming more common. In addition it gives you helpful tools like an interactive console.
Overall, there is no big loss in Computer Science concepts when moving from Java to Python like there was when we moved away from C++. You trade static typing for dynamic typing and compilation for interpretation but everything else is just about the same and you gain Python’s simplicity.
One of the real problems with Java is that many students do not like to use it when programming for fun. Since the majority of students only become competent in Java, they only code they write is for their homework assignments. These are type A CS students. There is a second, type B, group of CS students. Type B students pick up another language like PHP, Python, Ruby, Clojure, etc. and are ones who spend time coding and creating cool things outside of their schoolwork. These students find programming on the side to be the most enriching and also the most educational. Employers often cite type B students, the self starters, as the ones they are most interested in hiring. If the only programming a student does while attending school is for their class projects, it is more than likely that they will continue this practice once leaving school, only writing code for their job. By making the switch away from Java in education, more type B CS students would emerge from American universities; enormously benefiting the software industry.
