1) If you're reading bad code, that could be a problem. But 99% of Ruby code I read has been written by people who know when they need parentheses/brackets to make the code readable (e.g. when it's not the only code on the line.) But there are tons of times when it's wonderful to be able to leave out the parentheses.
-
2) It might be because I spend a lot of time with Ruby, but I much prefer `end`s to curly brackets, they're just easier on the eyes, especially when they're going to take up the entire line anyway:
a
b
c
d
end
end
end
end
a {
b {
c {
d {
}
}
}
}
Of course, at times I wish Ruby used indentation to declare structure, like Python.
-
3) I don't think I've ever had that problem. If I'm calling `person.full_name`, I don't care if that's a variable, or a method joining first_name and last_name. And if I it was a method, ideally I'd have a corresponding `full_name=(str)` method defined too, so `person.full_name = "Joe Bloggs"` would work, and split the string into the first, last, and optional middle names.
-
4) Why? Why not? What makes this easier to read?
puts "Bankrupt" if balance <= 0.0
Ruby is a lot like the English language; when you're learning it as a second language, you're constantly confused and frustrated by it's weird syntax, but once you get past those initial hurdles, it just clicks. I love Ruby because I never feel like I'm programming in it, it almost feels like pseudo code that's not going to actually execute.
Essentially you could get any non-programmer to solve a problem on paper, and turn it into Ruby code which, without too much fuss, describes their process.
# get the customers text file
# each customer is on their own line, w/ their name and age separated by a comma
# group the customers by age
# show me the top 3 most common ages
file = File.open('customers.txt')
customers = []
file.each_line do |line|
name, age = line.split(",")
customers << {:name => name, :age => age.to_i}
end
grouped_ages = customers \
.group_by{ |c| c[:age] } \
.map{ |c| [c[0], c[1].size] } \
.sort_by(&:last) \
.reverse
grouped_ages.first(3).each do |age, size|
puts "#{age} years old: #{size} customers"
end
Four blocks of reasonably clean code (except the 3rd, that could be cleaned up a bit), which implement the four lines of plain english instructions.
>I love Ruby because I never feel like I'm programming in it, it almost feels like pseudo code that's not going to actually execute.
Uh, you realise that describes any high level language, right? Ruby scores pretty low on the readability scale, about halfway between Perl and Python, but I find it's more familiarity with a particular language that determines how readable people find things.
Here's a quick Python version. The main thing to notice is that while the overall flow/structure is similar, I don't have a lot of { } << \ characters hanging around, and I don't have to chain blocks together since I have list comprehensions.
from collections import defaultdict
customer_file = (line.strip().split(',') for line in file('customers.txt'))
grouped_ages = defaultdict(list)
for name, age in customer_file:
grouped_ages[age].append(name)
age_lengths = sorted( [(len(names), age) for age, names in grouped_ages.items()], reverse=True )
for length, age in age_lengths[:3]:
print "%s years old: %s customers" % (age, length)
Looks kinda nasty to me, but then I'm not too familiar with Clojure/Lisp/whatever-the-hell-that-is ;)
I think one of the side effects of learning a Lisp is that you get a bit blasé about using map. Do you find list comprehensions easier than map/filter? Is there a list comprehension equivalent in Lisp, or would you have to write your own?
As for preference, given that map, filter, etc., are lazy, I like the clear visibility of each step working on each element of the sequence.
Clojure has a list comprehension, for, though using it here is more trouble than it's worth since you have to group and sort, both of which require you to step outside the comprehension and work on the whole list; that's why your code has multiple sections.
Instead, I see the example as just a selection/transformation process on sequences of data. Each step in the clojure code takes and returns a sequence of values (the ->> macro weaves them together):
0. a sequence of lines from a file
1. a sequence of age strings
2. a sequence of [age, [ages...]] tuples
3. a sequence of [age, count] tuples
4. a sequence of [age, count] tuples sorted by count desc
5. a sequence of age strings
6. a sequence of up to 3 age strings
Fun detail: The with-open macro is akin to python's with statement, supports arbitrary number of items, is closed in reverse order of their appearance, and didn't require a change to the language to implement ;)
I wanted to reply to anthonyb's comment about macro use changing the language in the clojure example but couldn't, I guess because it's too deeply nested.
Anyway, ataggart didn't write a macro he just used one that's already part of the language. Using a macro does not count as changing the language.
He was talking about with-open not needing a change to the language to implement. In other words, Python's with statement did need a change to the language, but then Python is a (semi-)interpreted language written in C, so it's a cheap shot - just what I'd expect from a dirty Lisp hacker ;)
Well, you need to sort by occurrences, so you have to work with the whole list in this particular case. I also don't think that having two sections is a particularly big deal, since semantically you're working with two separate things too (the list of people+ages, and the aggregated list of names+a count). If you wanted to do something else too (say, list the names as well) then having an intermediate form can come in handy.
Also, I'm pretty sure that writing a macro counts as 'changing the language', although that line's a bit blurred when you're talking about lisps ;) ;)
Note, I wasn't criticizing the python implementation. It's a perfectly reasonable way to model the problem.
You brought up list comprehensions, and something about being "blasé about using map". I wanted to show how a different way of modeling the problem yields a different structure to the code (namely, as a chain of transformations on sequences).
One is not better or worse than another. One of the things I enjoyed most about learning clojure was forcing myself to think in these different ways.
Well, I was comparing it to something like Java. Though Python still scores far lower on my readability scale. It's seems like it's halfway to being minified, the lines are chock-a-block.
Also, this is a better version in Ruby:
file = File.open('customers.txt')
customers = {}
file.each_line do |line|
name, age = line.split(",")
customers[age.to_i] ||= []
customers[age.to_i] << name
end
grouped = customers.sort_by{|age, names| names.count}.reverse
grouped.first(3).each do |age, customers|
puts "#{age} years old: #{customers.count} customers"
end
…not sure what I was thinking before, it was late.
> Python still scores far lower on my readability scale. It's seems like it's halfway to being minified, the lines are chock-a-block.
That's likely because you're not used to reading Python. For me, Ruby seems unreadable - you have all these weird << and ||= assignments, {||} blocks, etc. I don't parse those as well, because I don't program much Ruby. I'm sure if I did, it'd make a lot more 'intuitive' sense - ditto for you and Python's list comprehensions.
<< and >> are rudimentary it's almost always exactly the same as unix dated from 1970's redirection. e.g: $ echo 'crap' >> somefile.txt. ||= reads as 'or equal', simple.
Yeah, I know what they do - eg. ||= being a Ruby idiom for 'set if this currently evaluates as false'. The point is that because I don't often program in Ruby, it's less readable (for me). Similarly, if you're not used to list comprehensions they'll seem opaque - but I use them all the time, and find them far more readable than equivalent expressions using map/filter.
That said, I do find the more "squiggly" languages (Perl, Ruby, C) to be less readable than the equivalent Scheme or Python, and I suspect that it's because there are fewer weird characters, so it's closer to English.
The groupby, if done using itertools, will cut some code.
from itertools import groupby
customer_data = (line.strip().split(',') for line in file('customer.txt'))
grouped_ages = groupby(customer_data, key=itemgetter(1))
print sorted((len(list(g)), k) for k, g in grouped_ages)[-3:]
A meta-question: why do people keep downvoting this comment? It's been up and down ever since I posted it. Is it that I'm critical of Ruby? I would've thought that if I take the time to write some code and respond in a rational way, then it should be worth at least a couple of karma. What gives?
Trying to make a programming language modeled on plain english instructions is a recipe for disaster. Perhaps that's why I find your example at the end pretty ugly code.
Essentially you could get any non-programmer to solve a problem on paper, and turn it into Ruby code which, without too much fuss, describes their process.
Four blocks of reasonably clean code (except the 3rd, that could be cleaned up a bit), which implement the four lines of plain english instructions.