9 ms·

FWIW, I come from Java and find Ruby to be fairly ugly. It's all subjective, but I prefer concise, exact non ambiguous readable code. From a google for 'ruby

• clyfe 16y ago
  Ruby can use both "{...}" and "do ... end", with a slight difference between the two (precedence): def some_method { ... } def some_method; ... end obj.something # "something" is allways a method # never a var, say accessor (getter, setter &c ...)
  • steveklabnik 16y ago
    def cannot have {}, it needs ;/end. {} or do/end work for blocks, however.
    • clyfe 16y ago
      indeed, you are right
  • axod 16y ago
    Having optional beauty isn't really any beauty at all though. 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...
• rue 16y ago
  It cannot please everyone so if you are happy with a less "conversational" language, stick with it. "Unless", for example, is what I think to myself so "if not" is a suboptimal translation thereof. 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.
  • axod 16y ago
    > "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." I disagree. Code execution is not data access. They are very separate concepts.
    • rue 16y ago
      Inasmuch this conversation is subjective, I just do not think that statement is objectively true. It is a basic OO principle that the outside world is not privy to the inner workings of an object (or class if you prefer). Whether you like that or not is immaterial. You are free to avoid that aspect of OOP or the paradigm altogether.
      • axod 16y ago
        I haven't studied OOP extensively in a strict setting, but I would have said that in the OO world, a property is completely separate to a method. For example, class flower property color property numberOfPetals method pluckPetal() method water() A property defines data about an object, and a method defines something you can 'do' with the object. Could you give some pointers to the OOP principle that blurs the line between these two?
        • adambyrtek 16y ago
          It's called the Uniform Access Principle, as I've already mentioned in a separate comment. Getting back to your example, it is not very useful without mentioning a language under examination. There is no single definition of OOP, and every language implements in a slightly different way. 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).
• deleted 16y ago
  [deleted]
• Twisol 16y ago
  With regards to differentiating methods, that's simple. "obj.name" calls a method. An object's variables are hidden inside the object, so the only way to access them is via methods anyways. 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 In practice this isn't a big problem.
  • axod 16y ago
    Ah I didn't realize Ruby does not have the ability to access properties of an object. That seems like a pretty big disadvantage.
    • Twisol 16y ago
      That's because methods effectively -are- properties. See: class Foo attr_reader :bar def initialize (num) @bar = num end end puts Foo.new(42).bar attr_reader is a class-level method that defines a getter method for the named variable. There's also attr_writer, for setting, and attr_accessor, for both at once.
      • axod 16y ago
        ... and people complain that Java is verbose???
        • ZitchDog 16y ago
          Here it is, converted to java. You tell me which is more verbose. 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()); } }
          • 16y ago
• drylight 16y ago
  A Java developer complaining about Ruby's supposed verbosity? What's the world coming to?! When one looks at Java code, 90% of it is just syntactic sugar, which doesn't add much to the actual working code. One has to filter through large amounts of white noise to get to the crux of the code. Not so with Ruby (and many other languages).
  • Twisol 16y ago
    This is exactly what the original article was saying. ;) The languages take very different mindsets though, so if someone is actually happy with Java, then it's very possible that they don't have (or want) the right mindset for using Ruby.
  • axod 16y ago
    Not really. "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.
• ashleyw 16y ago
  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.
  • anthonyb 16y ago
    >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)
• nimms 16y ago
  until java has a var keyword and closures, there is no way you can claim that it's less verbose than languages like ruby or python. I can't count the amount of time I wasted typing things like LongVariableName longVariableName = new LongVariableNameImpl(); as a java programmer. Also the amount of extra typing for creating anonymous inner classes made GUI coding a real chore. Sure your IDE can automate lots of it, but emacs automatically types end for me when I type def so it's not even a consideration. Your comment comes across as someone who is either trolling or has no real experience in a language outside of java.
• nwmcsween 16y ago
  There's ways to make anything look hideous, as for your points. * end vs {} is one more character, I can't believe I even typed this as it's so stupidly pedantic. * Keywords.