Maybe this is old news to some, but I recently discovered that there’s a complete recording (audio at iTunes, audio and video on the web) of an MIT lecture by Prof. Charles E. Leiserson using “The Big Book” Introduction to Algorithms (which he co-wrote) as textbook. I just listened to the first of 25 lectures and liked it as a refresher course on the stuff I learned at university years ago. Lecture notes are available online as well.
Posts Tagged: learning
7
Jul 07
Quite Groovy
In the recent weeks, both of my co-bloggers told me independently of each other about Groovy, the new hipster language which brings the scripting goodness of dynamic languages like Ruby and Smalltalk to the JVM Sweet JVM, so I finally couldn’t resist but take a look at it. To be honest, I didn’t like its Java-like syntax from the beginning, with all the parentheses, lowerCamelCaseIdentifiers and such, but that was just because I prefer Ruby’s very lean syntax. Its concepts are very close to Ruby (modification of objects and classes at runtime, blocks/closures, etc.) and of course it integrates well with the Java platform and its rich libraries, since this is the purpose for which it was created, to add a scripting facility to the Java platform. Groovy scripts are compiled into bytecode before execution and thus run on a normal JVM.
A crucial part for dynamic languages today (at least in my eyes) is the creation of domain-specific language, which Groovy also supports. Gant, for example, is a Groovy DSL for Ant scripts. Another example (take from the Tutorial Domain-Specific Languages in Groovy, PDF) I find very practical is a DSL for creating query criteria for Hibernate in the Grails framework (formerly known as Groovy on Rails, so its purpose should be clear):
def c = Account.createCriteria()
def results = c {
like("holderFirstName", "Fred%")
and {
between("balance", 500, 1000)
eq("branch", "London")
}
maxResults(10)
order("holderLastName", "desc")
}
A good thing, but looks too java-y for my taste, I miss the feeling I get when using a Ruby DSL, such as SQL-DSL, for example:
statement = Select[:column1, 'book', 10].from[:table1, :table2].where do equal :column1, 99 not_equal :column1, 100 less_than :column2, 'foo' less_than_or_equal :column3, :column4 greater_than :column1, 0 greater_than_or_equal :column2, 'bar' like :column1, 'any' is_not_null :column1 is_in :column1, [1,2] is_not_in :column2, [3, 4] exists 0 not_exists 0 end
But maybe that’s just personal preference.
From a few first glance I get the impression, that Groovy is quite successful as a scripting sidekick to Java and I’m curious to learn more about it.
22
May 07
Learning by Testing
A while ago, Mike Clark wrote two blog postings on how to learn Ruby by writing tests (#1, #2). He explains that he wrote a test for each bit he learned about the language, over the years collecting a set of more than 200 tests which act as his personal knowledge base on the Ruby language:
Through trial and error they taught me how Ruby and its rich set of libraries really work. Not surprisingly, typing in code and running it makes you remember. Indeed, writing learning tests is a fun way to poke and prod any new language or API. And with every test you write you’re investing in an executable knowledge base.
Unfortunately I never tried this myself, but I like the idea. According to him, the benefit is twofold: The tests assist in acquiring and checking knowledge (by what he calls “asking Ruby”) and act as a knowledge base that manifests itself in code (and some documentation, where needed, I’d like to add).
Yet I am a little bit skeptical about “asking Ruby”. In his second posting, he suggests to “make a guess” in a particular case where he doesn’t know the result of a method invocation ("Rick".index('t')). Maybe I’m a bit hypersensitive here, but I have some reservations when it gets to using tests to find out how things (could or should) work. I’d think it would it be better to just look it up in a reference and write the test afterwards. The main reason is that using one test case (or a few) will give you one (or few) results, from which you will have to draw conclusions and generalize—the semantics of the index method in this case. What if your conclusions are wrong for some exceptional cases? Is it possible/feasible/desirable to write tests for each and every combination of parameters for a method? Why not trying a “read first” approach?
Nevertheless, the basic idea of using test cases for playing around with a language and collecting them as a reference is a nice idea. I’ll almost certainly try this the next time want to learn something about Ruby or a different language.