Yes. Ruby is beautiful when you come from PHP or Java or C++. If you come from Python it's meh because it's a very similar language (though the community is different and a number of recipes/best practices are very different) at the syntactic and at the semantic levels, and if you come from Lisps, from Smalltalk, from ML or Haskell, etc… then it's not "meh" it's "ugh", because the language is far more complex less orthogonal and far more full of weird corner-cases than what you come from.
TFAA came to Ruby from Java, so Ruby was like seeing the Sistine Chapel for the first time.
Likewise (and this is just a throwaway argument, not the general point I'm trying to make), Lisp may be more elegant conceptually than Ruby, but when trying to find an individual incorrect line of code to make a change, Lisp's "elegant" uniformity actually hinders scanning, whereas Ruby's bumpy, "inelegant" syntax gives your eyes regularized shapes to abstract sections of code into, and thus visually skip them without having to read into their contents.
However, as the mouse's elegance matches well with a paint program, Lisp matches well with Turing-complete data-specifications ("code as data.") Usability is not a one-dimensional spectrum, like your partial ordering of "beauty" above, but rather a consideration made separately for each task an interface is used for.
What's the last useful LISP program you have used? What proportion does it consist among the other useful programs you use?
Was that a subtle dig at those who spend too much time on HN?
Given that close to 100% of my time is spent in XMonad, and >50% of my time is spent in Emacs, and every session involves at least some interaction with my collection of scripts... I'd say I use quite a lot of useful programs written in those fanfare-laden languages.
It's just a personal preference, but I find anonymous code blocks to be a lot more elegant and intuitive than decorators + with statements + for comprehensions. I also like that classes are open, and that you can execute code inside the declaration of a class and that self is implicit ... making tasks suited for the __metaclass__ concept in Python trivial.
I also find Lisp / Haskell and ML to be really ugly ... as in, I could never look over a piece of code and understand what it is doing without learning the language first (with the learning curve being as steep as it gets).
the language is far more complex less orthogonal and far
more full of weird corner-cases than what you come from
E.g. I don't appreciate that ML doesn't have a simple concept like operator overloading, or that in LISP every DSL still looks like LISP. I don't like that a Smalltalk application is not portable between implementations or that applications are big, monolithic images of the virtual machine with everything included, even the IDE.
It's easy to get into these mine-is-bigger-than-yours contests, especially with languages, but you know what works better than formulating half-baked opinions?
Results. It's a lot better to shut up and show me some code ;)
2. The learning curve of those languages is not bigger then the learning curve of other languages. Time time I spend with making pretty OO designs in school was way bigger then the time it took me to learn clojure and FP in general but this of course is a issue we can not solve. I just don't like it if people say something as if it is a fact.
3. Is it more convenient to do this array.select &:even? better then (filter even? array)
The later seams more intuitive to me and I didn't have to learn more syntax.
4. In Lisp not every DSL looks like Lisp.
If only it wasn't for the fact that reality and history has proven otherwise...
Most programmers went form basic (lack of alternative) to C then C++ and now Java thats a path of simularity. Most where never exposed to functional programming and now the all have a hard time to switching there OO brain off.
The only proof we have of something being easier to learn, beside anecdotal evidence ("oh, I tried it and it was easy") is statistical empirical evidence, i.e people actually learning it. Well, people are not actually learning those languages. They are learning the "other ones".
(Where by people, I mean: a significant percentage of people, > 1%. I'm sure me, you and that "professional programmer who gives a shit about Haskell" do not a significant percentage make).
Even in universities, students find functional languages difficult, and opt-out of those classes.
Wow.
> I don't appreciate that ML doesn't have a simple concept like operator overloading
ML operators are nothing more than functions. The issue of "operator overloading" comes from the type system and the simplicity of the language.
> or that in LISP every DSL still looks like LISP
You might want to read on Scheme reader macros.
> I don't like that a Smalltalk application is not portable between implementations
It's true that you don't have this issue in Ruby as the "standard" is simply the original implementation (aka there is no standard at all, and not really any competing implementation).
> or that applications are big, monolithic images of the virtual machine with everything included, even the IDE.
That definitely isn't the case. That's not the case in GNU Smalltalk, and most commercial smalltalk let you create a stripped production image which contains only the necessary code.
Check out https://github.com/rubyspec/rubyspec.
And there are plenty of competing implementations: JRuby, Rubinius, MagLev, etc.
In fact, can you mention a single language with a standard that doesn't brake compatibility with its standard?
And yet the point is moot, because compatibility between implementations is manageable for popular languages like Javascript, C++ and yes, Ruby (JRuby, Rubinius). That's not the case for Smaltalk.
<bait>When your language is already at the top of the beauty chart, why would you write a DSL that is not also beautiful?</bait>
It is really a programmer choice. Lisp programmers generally love the way Lisp looks because of the advantages awarded by those looks (check Myth #7 here: http://www.algo.be/cl/myths.htm). But you can certainly create a DSL that requires more extensive string parsing, and CL provides a lot of help towards that end, including native translations of strings to Lisp objects where your parser needs them.
I'd like to see more effort put toward creating programming environments that provide clean abstractions that span entire multi-process distributed applications.
# Ruby
string.reverse()
# Python
string[::-1]
Which looks better?
Edit: I'm not sure why this is being down voted. It's a true statement.
Edit2: With all the down voting on Hacker News recently, I'm about to quit sharing my knowledge here. Maybe pg will do something about this. It needs to change otherwise good people will stop posting here.
Edit3:
irb(main):002:0> x = "hacker"
irb(main):003:0> puts x.reverse()
rekcah
>>> x = "hacker"
>>> print x[::-1]
rekcah
But yeah, I hear you on the downvoting.
It's all subjective, but I prefer concise, exact non ambiguous readable code.
From a google for 'ruby sample code'...
http://www.fincher.org/tips/Languages/Ruby/
print " with no line breaks."
printf("\n\nprintf ... %7.2f,... %s.",3.14156,"me")
def welcome(name)
puts "howdy #{name}"
end
"hello".upcase() => "HELLO"
"hello".upcase => "HELLO"
balance = -10.0
puts "Bankrupt" unless balance > 0.0
Java code has a very exact, easy to parse syntax. We all know it, and it's easy to learn - {} for code blocks, () for method invocations, etc
That's just for starters.
-
a
b
c
d
end
end
end
end
a {
b {
c {
d {
}
}
}
}
-
-
puts "Bankrupt" if balance <= 0.0
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
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)I'm inclined to agree. I think the following also pretty closely matches the english requirements.
(with-open [rdr (reader "customers.txt")]
(->> (line-seq rdr)
(map #(second (.split % ",")))
(group-by identity)
(map (fn [[age coll]] [age (count coll)]))
(sort-by second (comparator >))
(map first)
(take 3)))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
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 ;) ;)
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.
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.
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
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.
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.
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:] from operator import itemgetter
I would point out, however, that printf is fairly rarely used and that I am not familiar with fincher.org in the context of sites to recommend newbs to learn Ruby from.
Removing the difference between accessing an attribute (variable) and invoking a method is a solid OO principle. You, as a client of the API, should not care how obj.foo is implemented.
It's called the Uniform Access Principle[1] and the languages that don't take advantage of it often suffer from a getter/setter hell.
Hey presto! Now you have the best of both worlds.
I disagree. Code execution is not data access. They are very separate concepts.
Whether you like that or not is immaterial. You are free to avoid that aspect of OOP or the paradigm altogether.
For example,
class flower
property color
property numberOfPetals
method pluckPetal()
method water()
Could you give some pointers to the OOP principle that blurs the line between these two?
There are languages where UAP is enforced by the syntax (eg. Eiffel, Smalltalk, Ruby) and languages where it's a matter of convention. But even in the latter it's considered a good practice to keep properties private and encapsulate them with accessors. Some even have dedicated features that help with that (auto-properties in C#, properties in Python).
There is absolutely no reason for that, and the grandparent of all things object-oriented (Smalltalk) very strongly disagrees with you: everything is a message, and there are no properties.
> A property defines data about an object, and a method defines something you can 'do' with the object.
A getter method is a property and a method. Properties are irrelevant, access should be uniform, the implementation details of an object (whether a "property" provides direct access to internal data or not) is of no concern to the user of the object.
A property is nothing more than a method whose contract is "give me some data"
However, for me, and the CPU, we treat code execution differently to data access.
1. It's not ugly
2. It's how CPUs work
3. It's how most people think
2. If you want a programming language that maps closely to how CPU's work, Ruby's definitely not for you. Assembly and C are for you.
3. I can't speak for most people. What I can say is that I can think in C and I can think in Ruby, and it doesn't seem difficult for me.
"public static final" is not particularly verbose. It's a one time upfront cost which defines a few flags. It's error free, since a typo in any of those keywords will be picked up.
It can also be automated easily etc.
But Ruby using 'end' etc instead of curly braces, that's going to add up to a lot of verbosity.
Furthermore, variables can't be called. If you have a proc object in a variable, you use "myproc.call" to invoke it. The only ambiguity is between methods call within the same 'self' and local variables:
def foo
42
end
def bar
puts foo #=> 42
foo = 30
puts foo #=> 30
puts self.foo #=> 42
end
class Foo
attr_reader :bar
def initialize (num)
@bar = num
end
end
puts Foo.new(42).bar
public class Foo
int bar;
public Foo(int bar) {
this.bar = bar;
}
public int getBar() {
return bar;
}
public static void main(String[] args) {
System.out.println(new Foo(42).getBar());
}
}You should make bar private, and add a setter. After all, we might want to change the rules on setting bar sometime, and you wouldn't want to have to go back and change everywhere that accesses it...
It's package-access by default, that's enough to hide it from the third-party users of the class.
> and add a setter
The original code uses `attr_reader` which defines a readonly "property". The Java translation is a single getter, with no way to set the value from outside the class.
public class Foo
int bar;
public Foo(int initBar) {
bar = initBar;
}
public static void main(String[] args) {
System.out.println(new Foo(42).bar);
}
}2. let's say you solve this conundrum by making the field public
2.1. This piece of code is now frozen solid, you will not be able to ever refactor it (where refactoring is defined as changing implementation without changing behavior) since you can not transparently swap fields and methods in Java
2.2. This piece of code is dead to abstract types, as fields can not be part of interfaces in Java.
2.3. This piece of code is incompatible with Java Beans and will therefore be unusable in e.g. JSP taglibs
and your other points don't really make any sense at all. There is no such thing as 'fozen solid code'. Unless you're interfacing to external libraries etc and have agreed on a specific API, which is unlikely to include "yeah just reference 'bar' directly" unless you're insane.
I can't count the amount of time I wasted typing things like
LongVariableName longVariableName = new LongVariableNameImpl();
Your comment comes across as someone who is either trolling or has no real experience in a language outside of java.
def some_method { ... }
def some_method; ... end
obj.something # "something" is allways a method
# never a var, say accessor (getter, setter &c ...)I'm just more at home with exact, specific concise well structured syntax.
I know it's an extremely unpopular opinion to hold, especially round these parts, but I don't see any beauty in Ruby syntax. Same with Python...
{} or do/end work for blocks, however.
There is nothing infamous about it. It's a multimethod, the designers of Python decided that mandating the same function for everything (via a common protocol under the covers) was better than risking people implementing a thousand different method names. They did the same with the iterator protocol.
What is not true of every function?
That said, I think Ruby is beautiful for a few reasons, but they mostly stem from the fact that Ruby strikes the perfect balance between Lisp and Other Languages: it's taken just enough of the good parts of Lisp and grafted them onto a more 'usual' language. Maybe 'grafted' is too harsh, it's Lisp _from the perspective of the rest of the world_. It's taking Lisp's ideas through a slightly different lens.
Whatever, I'm almost rambling. You get the idea. Some people think Java is beautiful, too...
Ruby doesn't have Lisp-style lambdas, or macros, or conses, it has blocks and messages (it tries to anyway) and classes. That's the Smalltalk recipe book. Ruby uses `select` and `reject`, `collect` and `inject`. Those come from Smalltalk's collections.
You're speaking of Lisp's _features_, I'm talking about Lisp's _ideas_. It may not have 'Lisp macros,' but it does embrace metaprogramming, for example.
Are you reminding yourself of that issue?
> but matz has specifically said Lisp influenced him, as well.
He might have said that, but I don't see it. Then again, considering what he did to Smalltalk it might be very, very well hidden. And in a pretty sad shape.
> You're speaking of Lisp's _features_, I'm talking about Lisp's _ideas_
They're in the same state.
> It may not have 'Lisp macros,' but it does embrace metaprogramming, for example.
Lisp metaprogramming is macro-based, unless you're getting into CLOS.
Smalltalk's metaprogramming is based on metaclasses and "unhandled message" forwarding.
Guess which one Ruby has?
Both of us, yes. My original comment was painting with a broad brush, and your follow-up is too.
> Guess which one Ruby has?
You're still speaking around me. The implementation of Ruby's metaprogramming is irrelevant, it's the place of prominence it's been given in the design and culture.
The rest of the language is definitely more about pragmatism. How could it not be with the Perl legacy?
For example:
array.select &:even?
array.select{|n| n.even?}
filter even xs
filter (\x -> even x) xsThe latter is readable.
I want to note that the &:even? idiom is only used in the simplest cases.