Comment by mdasen | Hacker News Reader

Comment by mdasen | Hacker News Reader

Java: The fact that I have to manually cast Arrays to a template. Everything else allows me to template nicely except arrays.

Python: The error message passed when you call a method with the wrong number of arguments. It's just off since the method "def apple(self, steve, new_product)" has three args, but you'll call it with two "apple(steve, new_product)". So, the message that gets passed back if I pass in one or three arguments is just wrong. I actually like the explicit self in the definition, but the error message needs to say something like "method given the wrong number of args. 1 argument passed when there are 2 arguments plus implicitly passed self."

Python: The functions that should be methods. len(list) just doesn't rub me as well as list.len(). It's such a stupid criticism that I'm hesitant to post it, but whatever, it bothers me. Likewise, Ruby's int.to_f seems much nicer than a built-in function float(int). Same with int and str.

PHP: The fact that 0 == "apple". Yeah, integer 0 is equal to any string. That means: $a = 0; $b = "apple" $c = "ms" $a == $b $b != $c $a == $c

Yeah, a == b, a == c and b != c. Um? Heck, integer 0 is equal to an uninitialized variable. It just makes bugs that are so hard to find. Yeah, it stops you from having to cast in certain situations, but for the little time it takes to cast, you end up with horrible bugs.

Java: The fact that I can't do if(a) { return true } else { return false } in a method. The Java compiler will say that I don't have a return in that method because all of my returns are within a conditional even though it will always hit one of the return statements. if the Java compiler is going to check that I have an appropriate return, be smart enough to figure out that I do.

Python: "Ruby's int.to_f seems much nicer than a built-in function float(int)."

    >>> print float.__class__.__name___
    type

See, "float" is a type. float(int) is a constructor for a floating point number. It's not a magic built-in function, it's just a constructor for type float. Same with int and str. I can't say there's anything wrong with Ruby's int.to_f, but I actually like the Python design better.

Now, as far as len() goes, I agree. It's easy to forget about such troubles, but I definitely wasted a good 10 minutes when I was learning Python trying to figure out what property or method of type list (or str--I don't remember) I should use to get its length.

The C code for Fixnum#to_f is quite literally

  fix_to_f(VALUE num) {
    double val;
    val = (double)FIX2LONG(num); //RSHIFTs sign
    return DBL2NUM(val); //Ruby float constructor of C double value
  }

It does the same thing. Ruby, by design, flows left to right instead of nested params. This way you don't have float(user.timestamp) but instead user.timestamp.to_f.

Your two Java points - the first one: Amen. The latter - not true:

public static String foo(final boolean b) { if( b ) { return "Yes"; } else { return "No"; } }

Compiles just fine.

> Ruby's int.to_f seems much nicer than a built-in function float(int)

I multiply by 1.0 to turn an int into a float:

   Python 2.5.1 (r251:54863, Jul 31 2008, 23:17:40)
   >>> 3/2
   1
   >>> 3*1.0/2
   1.5
   >>> float(3)/2
   1.5

About your last point: You can get around it by typing return (a);

or...

if (a) { return true; } return false;

agreed, if (a) then just return a;

if (a) { return true; } is just as redundant as an if (a == true) statement.

Hmm... not sure what justified the -1 on this. Perhaps that in some languages if (a) can be used as a shortcut for if (a != null), where a is an object and not a boolean. So, as a correction to my previous comment. If (typeof a == "Boolean" || a instanceof boolean), I still stand by reducing redundancy, but if a is an object, then fine, if (a) return true;

I should have used a better example, but there are a good number of cases where the Java compiler complains about missing return statements that just don't need to be there. It's a wart in the language.

Can you cite a specific example where the condition is NOT ambiguous and the Java compiler WILL produce an error? The example you cite is incorrect (see my post later) - you can compile code of this form just fine.

I'm not aware of unambiguous situations where the compiler will complain; if you see an error it's usually pebkac!

It isn't always that straightforward. For example:

  if (a)
    return (some && complicated || boolean && calculation);
  else
    return (some || other && boolean || calculation);

edit: I suppose you can get rid of the "else", but you shouldn't have to sacrifice readability for a compiler shortcoming. I'm with mdasen; the compiler should figure it out.

Readability is improved by not having the else clause. It makes it clear that the return in the then-block is there and the code won't continue after the end-if.

You (and some posters below you) missed the point. It's just an example. Think of the more general case.

About your last point: return (a ? ... : ... );

Reply on news.ycombinator.com