Thursday, September 27, 2007

Omaha Dynamic Language Group

Erlang is the hottest new language in the land to learn. It's what on the tip of everyone's tongue. Why is it so hot? What makes it so special? I am proud to have Erlang guru Sam Tesla presenting to answer all our questions. He will be displaying why Erlang scales so well and it's many unique features. This will be one meeting that should not be missed!

And if that wasn't enough, we have none other than Tek Systems providing all of the pop and pizza that our bellies can take. Prepare to have your mind and stomach stuffed!

Come out and join us for the best user group in the land (In my opinion, of course).






TopicA Gentle Introduction to Erlang
SpeakerSam Tesla
TimeOctober 2, 7-9pm
LocationUNO's Peter Kiewit Institute (PKI) building
1110 South 67th Street
Omaha, NE

Monday, September 24, 2007

Good Design

I love Alex Ruiz's post on named parameters in Java. Why? For one, it shows how he got around Java's lack of named parameters. He then goes on to explain why he made the design choices he made. Pros and cons are then listed for the approach. But, the part that I loved is that he sided on the side of the API user. It made his life as the API designer harder and cost him more code to write. The result was something that allowed for more readable code for the client. I love it! I tend to design with making the client's life easier instead of mine. This article is excellent for outlining the design choices and not being dogmatic. Everything is logical and well laid out. Another reason I loved the article is that the lack of a language feature inspired him to work harder to get the same result. A post that inspires us to push for better solutions no matter the constraints.

Sunday, September 23, 2007

I'm embarrassed

I can't believe what gets passed off as humor these days. I'm embarrassed to be part of a community where one of the main evangelists of the community post such bile and garbage. It was meant to be funny. But, calling developers outside your community "morons" even in jest is not cool. It certainly doesn't breed communication and good will. And if you were interested in "making the world of software development a more enjoyable, productive place", then name calling is not the way to do it. I understand it was done in humor and I know you are writing off my serious reply as "dumb" because of your debate killing "if you didn't get the humor, then you're dumb" post. But, if you wanted to be funny, you went about it the wrong way. All you displayed was a level of immaturity that should be unacceptable in our community. It wasn't witty.

And to end I will add, yes, Ruby does need tools. It needs tools badly. I would love to have refactoring support (that works) and a good debugger. I can't imagine doing a project of any size without those tools. Not every one is a great developer and eventually you will step into some unsavory code. Tools are for helping with those unsavory pieces of code and even to gain understanding on a large system. This is where learning comes in. Instead of writing the developer off as a "moron", I use unsavory code and tools to teach how to do it better. So, who's really "making the world of software development a more enjoyable, productive place"?

Sunday, September 16, 2007

A Sorting Language

Inspired by Neal Ford's post on patterns and sorting in Ruby:

class Comparator
def initialize(&default)
if (defined? default)
@compare_block=default
else
@compare_block=lambda { |a,b| a <=> b }
end
end

def compare(a,b)
@compare_block.call(a,b)
end

def to_proc
method(:compare).to_proc
end

def to_comparator
self
end

def then_by(next_aspect)
next_comparator=next_aspect.to_comparator
self.class.new do |a,b|
comparison=compare(a,b)
if (comparison == 0)
next_comparator.compare(a,b)
else
comparison
end
end
end

def reverse
self.class.new do |a,b|
comparison=compare(a,b)
if (comparison == 1)
-1
elsif (comparison == -1)
1
else
0
end
end
end
end


def by(aspect_to_compare)
aspect_to_compare.to_comparator
end

class Symbol
def to_comparator
Comparator.new { |a,b| a.send(self) <=> b.send(self) }
end
end

module Enumerable
def to_comparator
inject do |thus_far, every|
thus_far.to_comparator.then_by(every.to_comparator)
end
end
end

require 'rubyunit'
class SortTest < Test::Unit::TestCase
def test_simple
a=Person.new("blaine", 36)
b=Person.new("blaine", 12)

result=[a,b].sort(&by(:name).then_by(:age))
assert_equal([b,a], result)
end

def test_array
a=Person.new("blaine", 12)
b=Person.new("alice", 12)

result=[a,b].sort(&by([:age, :name]))
assert_equal([b,a], result)
end

def test_reverse
a=Person.new("grue", 123)
b=Person.new("thief", 34)

result=[a,b].sort(&by(:name).reverse)
assert_equal([b,a], result)

result=[a,b].sort(&by(:age).reverse)
assert_equal([a,b], result)
end
end

class Person
attr_reader :name, :age

def initialize(name, age)
@name=name
@age=age
end
end

I loved Neal's post, but it got me thinking that sometimes I need to sort beyond one field. How could I go about that? I whipped up this example really quick. The function :by is simply syntactic sugar for converting to a comparator. I thought it read better. Neal's solution is the way to go if you need to sort on a single field. But when you need more, the above will work too. This is another one of my little late night coding thoughts. Enjoy.

Saturday, September 15, 2007

Duh....

pdcawley wrote the following comment to my previous "reduce" post:
[1,2,3,4].inject() {|a,b| a + b} # 10

So, I looked it up in ri and got this entry:
------------------------------------------------------ Enumerable#inject
enum.inject(initial) {| memo, obj | block } => obj
enum.inject {| memo, obj | block } => obj
------------------------------------------------------------------------
Combines the elements of _enum_ by applying the block to an
accumulator value (_memo_) and each element in turn. At each step,
_memo_ is set to the value returned by the block. The first form
lets you supply an initial value for _memo_. The second form uses
the first element of the collection as a the initial value (and
skips that element while iterating).

# Sum some numbers
(5..10).inject {|sum, n| sum + n } #=> 45
# Multiply some numbers
(5..10).inject(1) {|product, n| product * n } #=> 151200
javascript:void(0)
# find the longest word
longest = %w{ cat sheep bear }.inject do |memo,word|
memo.length > word.length ? memo : word
end
longest #=> "sheep"

# find the length of the longest word
longest = %w{ cat sheep bear }.inject(0) do |memo,word|
memo >= word.length ? memo : word.length
end
longest #=> 5

Ouch. All that coding for nothing (well, I did get to play around with some stuff). Next time, I will consult the documentation before I post. Duh...Good call.

P.S. It seems Rails implements the Symbol extension of #to_proc already. It's in the activesupport stuff. Their implementation is similiar to mind. But, I found one implementation better than mine. I love reading other people's code because it always shows me things I didn't think of. For your reading pleasure:

class Symbol
def to_proc
lambda do |this, *arguments|
this.send(*arguments)
end
end
end

This is better than using shift and cleaner. I got this from one of the comments off of Neal Ford's blog. Great stuff.

Friday, September 14, 2007

More Functional Fun In Ruby

I have no clue whenever this will be useful, but it was a fun exercise. Hope you enjoy it as well. It's an implementation of Lisp's cons, car, and cdr.

def pair(left,right)
lambda do |dyadic|
dyadic.call(left,right)
end
end

def left(pair)
pair.call(lambda {|left,right| left})
end

def right(pair)
pair.call(lambda {|left,right| right})
end

require 'rubyunit'

class WorkspaceTest < Test::Unit::TestCase
def test_simple
a_b=pair('a','b')
assert_equal('a',left(a_b))
assert_equal('b',right(a_b))
end

def test_again
a_b=pair('a', 'b')
c_a_b=pair('c', a_b)
assert_equal('c', left(c_a_b))
assert_equal('a', left(right(c_a_b)))
end
end

Python's Reduce, (Fun)ctional Programming, and Ruby

Mike Hostetler blogged about Python's reduce. He said he never had a use for it until recently. I looked at his example and I thought that looks a lot like inject, but it uses the first element in the collection as the seed instead of it being given. I thought what mad fun would it be to write one in Ruby? Exactly. Here's my implementation:

module Enumerable
def reduce(empty_return=nil, &dyadic)
to_execute=lambda do |thus_far,every|
to_execute=dyadic
every
end
inject(empty_return) do |thus_far, every|
to_execute.call(thus_far,every)
end
end
end

require 'rubyunit'

class ReduceTest < Test::Unit::TestCase
def test_simple
result=[1,2,3,4,5].reduce {|thus_far,every| thus_far + every}
assert_equal(15, result)
end

def test_empty_nil
result=[].reduce {|result,every| thus_far + every}
assert_nil(result)
end

def test_empty_default
result=[].reduce(0) {|result,every| thus_far + every}
assert_equal(0, result)
end
end

It has a somewhat functional style in that instead of using a boolean to check for the first iteration, I just use a special lambda for the first pass and then it turns itself into the original one. There is some state (to_execute), but I'm still a functional newbie.

I do love inject, which has a lot of uses beyond aggregation, and this will reduce (no pun intended) code in some places where I use it.

Anyway, I couldn't stop myself. I thought wouldn't it be nice to just pass in a symbol instead of a block? I added the following method to Symbol and another test. Check it out:

class Symbol
def to_proc
lambda do |*arguments|
arguments.shift.send(self, *arguments)
end
end
end

class SymbolTest < Test::Unit::TestCase
def test_simple
result=[1,2,3,4,5].reduce &:+
assert_equal(15, result)
end
end

All I do is take a list of arguments. I make the first one the receiver and send the rest as it arguments. How cool is that? I get to cut down on the line noise. I still have to put up with &, but until they make blocks first class citizens...

What's the point of this post? Nothing. Just wanted to do a fun little exercise. I thought others might find the implementation fun as well. Now, about that name 'reduce'...I think maybe aggregate would be better? But, that doesn't express for all cases either. Hmmm...

Monday, September 10, 2007

Why Is Groovy So Slow?

Peter Knego wonders "Why Is Groovy So Slow?" and shows some evidence. I will admit I expected Groovy to be slower than Java because even though it does compile to Java byte codes. It has to perform various translations to satisfy the VM that expects a lot to be already typed. The Java VM is an ugly world for dynamic languages because of the early bind nature to gain performance. Some of his numbers were shocking. He also mentioned he was going to run numbers on jRuby as well. I'll be curious about that too. I'm expecting the numbers to tell a similar story.

But, that's not the point of this post. I'm worried with posts like the above because developers will use it as evidence that you shouldn't use dynamic languages. I never thought the arguments for not using dynamic languages would be played out again. Back in the 90's, it was Smalltalk vs. C/C++. I remember having many a debate how the productivity gains out weighed the small performance hit for late binding. I thought when Java won, I would never have to argue about performance ever again.

It's not that the above posts are bad. I think they are wonderful. It gives something that the Groovy guys can use to make their product better. And that's good for all of us wanting to be dynamic in a static world. But, those numbers will also be used to prove why you shouldn't use dynamic languages. And that's sad. It's all come full circle. I hope I am wrong, but I doubt it. The numbers are not bad because dynamic languages are slow, but because trying to get them run on an architecture not built with them in mind.

We Need Each Other: Ruby and Smalltalk

Neal Ford made a blog post on meta-programming, Ruby, and Smalltalk recently. It caused some discussion from long-time Smalltalker, James Robertson, and Rubyist, Glenn Vandenburg. Even Avi Bryant got in the discussion. There was a lot of talking past one another on the issues of code generation in Ruby and Smalltalk.

I'll start with a quote from Neal Ford:
the Smalltalk version is a great example of accidental complexity, not essential complexity.

There is no example given of what the "accidental complexity" was in Smalltalk. But, let's look at an example that Rubyists are familiar with and then I'll go forward:
class Person
attr_accessor :name
end

This will generate the accessors :name and :name= at run-time. It's a nice way to describe a public field. There's even read and write only variations. It allows you to describe your intent of the field. Now, in Smalltalk you could do the same thing with class-side methods. Like so:
attributeAccessors
^#(name)

This could add the instance variable (if it didn't exist), and generate the getters and setters when the class is initialized. It is true in this case, we would use tools to do the generation and generate the code before hand. I think this is what Neal was talking about accidental complexity because we are adding methods that we later have to browse through. But, this is where they are mistaken.

Smalltalk has categories and usually, these code generated methods are placed in them. Accessors are generally placed in their own category so do not add to the cognitive friction. In fact, when I use code generation, I group the methods in a category with "AUTO" in it. This is so that I can later delete those methods and start over. Also, it allows me to not have to look at them when looking at the more important methods of the class.

There is one last way to do things like this in Smalltalk, but is rare. Classes are created in Smalltalk by sending messages. It's not some hard-coded construct in the language. It's a message. We can create our own messages to create our own classes. Here's what the example could look like in Squeak:
Object subclass: #Person
attributeAccessors: 'names'
classVariables: ''
poolDictionaries: ''
category: 'MetaExample'

And lastly, there is a initialize method for all Smalltalk classes that would give a more Ruby feel:
initialize
self attributeAccessors: 'name'

Now, with all of that said, these are just examples to show what is possible. It's all a matter of taste and what you are trying to accomplish to which method you choose.

finally, my mouth dropped when I saw this in the same blog post:
Smalltalk had (and has) an awesome environment, including incredible tool support. Because the tool is pervasive (literally part of the project itself), Smalltalkers generally shied away from the kind of meta-programming described above because you have to build tool support along with the meta-programmed code. This is a conscious trade off. One of the best things about the Ruby world (up until now) is the lack of tool support, meaning that the tools never constrained (either literally or influentially) what you can do. Fortunately, this level of power in Ruby is pretty ingrained (look at Rails for lots of examples), so even when the tools finally come out, they need to support the incredible things you can do in Ruby.

I will answer this as bluntly and respectively as I can. Smalltalkers have NEVER shied away from meta-programming because of having to build a tool. Most Smalltalkers have a bag of tools that they use and add to their environment. Tools are so easy to write in Smalltalk that most programmers in it have at some point written one or two to help them. It's trivial to add functionality to the browser and inspectors. Generally, Smalltalkers only stay away from things that are hard to debug (ala method_missing, doesNotUnderstand:), but do them when necessary. Readability is always the utmost importance to Smalltalkers. Abbreviations are generally frowned upon even.

The last thing I want to remark on is the quote in bold above. I'll repeat it here because it makes me both shocked and sad:
One of the best things about the Ruby world (up until now) is the lack of tool support

I hardly call that a strength. Really. Why would I want to go back to bear skin and stone development? I have finally become productive in Java because of Eclipse (code browsing, auto-format, code completion, refactoring, etc). Why would I want to go back to command line brute force methods? I keep hoping for a great Ruby IDE (some are close like Ruby's Eclipse plug-in, Arachno, etc). Besides, I think while tools like ri and rdoc are nice, I want to look at source code and it's difficult to find the definitions of methods (without using grep) when going through new source code. A friend once told me he never trusted a language you couldn't write an IDE for it. There's truth to that. I never got FreeRIDE to last longer than a few minutes of development. Tools and easy to read syntax are necessary.

Ruby has great potential, but the syntax needs to be heavily reafactored (%w while being nice shorthand is unreadable) and made more consistent (blocks do not take the same types of arguments as methods, I can not send a block with & into a block example, lambda {|&block| block.call } gives a compile error). But, those are my gripes and I do still like Ruby. I think boasting that your language has no tools is short sighted at best.

I think both Smalltalk and Ruby developers could learn a lot from one another. So, if any Ruby developer has questions about Smaltallk, please feel free to email me. I will even extend the same to Smalltalk developers curious about Ruby. The point of this post was mainly to educate and inspire both Rubyists and Smalltalkers to be better.

Saturday, September 01, 2007

Omaha Dynamic Language Group

Pinch me. Our speaker this month is none other than "Mister Groovy Eclipse Plug-In" Scott Hickey. He will be speaking about Rexx though. Rexx is a little known scripting languages with some unique features. This should be an incredible talk to make you think about Rexx in a totally different light. I can not wait.

I hope to see everyone there!





TopicRexx: The Little Known Scripting Language
SpeakerScott Hickey
TimeSeptember 4, 7-9pm
LocationUNO's Peter Kiewit Institute (PKI) building
1110 South 67th Street
Omaha, NE