Python dosen't have NULL/NIL?
Python has "None".
Hyperpolyglot: PHP, Perl, Python, Ruby
41–50 of 58 posts
Re: Hyperpolyglot: PHP, Perl, Python, Ruby
#42Neat table, one thing about PHP's member variables compared to Python/Ruby seems inaccurate though. In the example "define class", the member variable $value is declared private and then accessed through a getter and a setter, while the corresponding Python and Ruby examples use a public variable and hence look cleaner. The equivalent PHP version should be more along the lines of: class Int { function __construct($in…
The Ruby example actually involves generating the getter and setter at runtime via attr_accessor. In contrast to Python, in Ruby all instance member variables are private.
Yes, but functionally the Ruby example is the equivalent of a public member variable. Since those are public by default in PHP, there is no need to complicate the code by first making it private and then implementing a getter and a setter.
Re: Hyperpolyglot: PHP, Perl, Python, Ruby
#43python, statement separator: not "sometimes", but "usually"
python, multiline comment: not quite. print '''foo''' outputs "foo". This is a string literal, and """foo""" is more popular.
Re: Hyperpolyglot: PHP, Perl, Python, Ruby
#44python, statement separator: not "sometimes", but "usually" python, multiline comment: not quite. print '''foo''' outputs "foo". This is a string literal, and """foo""" is more popular.
Under variable interpolation, there is nothing listed for python, but the equivalent is this:
count = 3
item = "ball"
print('%(count)s %(item)ss' % locals())Re: Hyperpolyglot: PHP, Perl, Python, Ruby
#45Re: Hyperpolyglot: PHP, Perl, Python, Ruby
#46Earlier quoted context omitted.
I would have liked for Go to have been included, (C style languages) not to mention Smalltalk.
Smalltalk definitely belongs on the list, it's the only one that takes "object-oriented" to its logical conclusion (dispatch can replace control structures). I'd suggest omitting Elisp and ObjC—they're both lackluster imitations of better languages that will do far more for the way you think, unless you happen to be developing for their captive platform (Emacs and iOS, respectively).
> "it's the only one that takes object-oriented to its logical conclusion"...
Can you elaborate more on what you mean by that?
Re: Hyperpolyglot: PHP, Perl, Python, Ruby
#47Earlier quoted context omitted.
The Ruby example actually involves generating the getter and setter at runtime via attr_accessor. In contrast to Python, in Ruby all instance member variables are private.
Yes, but functionally the Ruby example is the equivalent of a public member variable. Since those are public by default in PHP, there is no need to complicate the code by first making it private and then implementing a getter and a setter.
This is a kind of a semantic game. You might say they're "equivalent," but you're still doing different things — and different is very rarely truly equal. For example, the Ruby accessors could be hooked or altered later without changing the interface. Not so if you use a public variable (which Ruby doesn't have, for this very reason). The only language I know of where public variables and accessors are truly interchangeable is Scala.
Re: Hyperpolyglot: PHP, Perl, Python, Ruby
#48Some of the PHP stuff, as others have noted with Python, etc., is misleading or outdated. Backticks work: echo `ls`; Constants can be declared globally: const PI = 3.14; Anonymous functions can be declared without create_function: $f = function($x) { return $x*$x; } I'm sure there are more. That said, I love these sorts of side-by-side comparisons.
There is a lot of non-idiomatic Ruby as well
Also it doesn't tell you that 'and' and 'or' are not equal to && and || in Ruby. http://hyperpolyglot.org/scripting#logical-operators
Re: Hyperpolyglot: PHP, Perl, Python, Ruby
#49Some of the PHP stuff, as others have noted with Python, etc., is misleading or outdated. Backticks work: echo `ls`; Constants can be declared globally: const PI = 3.14; Anonymous functions can be declared without create_function: $f = function($x) { return $x*$x; } I'm sure there are more. That said, I love these sorts of side-by-side comparisons.
I've been developing with PHP for 2 years now and I didn't ever notice that we can make anonymous functions with PHP like that!! From where did you get that man??!! :D
Re: Hyperpolyglot: PHP, Perl, Python, Ruby
#50Earlier quoted context omitted.
Yes, but functionally the Ruby example is the equivalent of a public member variable. Since those are public by default in PHP, there is no need to complicate the code by first making it private and then implementing a getter and a setter.
This is a kind of a semantic game. You might say they're "equivalent," but you're still doing different things — and different is very rarely truly equal. For example, the Ruby accessors could be hooked or altered later without changing the interface. Not so if you use a public variable (which Ruby doesn't have, for this very reason). The only language I know of where public variables and accessors are truly intercha…
Everything is a semantics game: meaning matters. This is not about playing "gotcha" with trivialities. I'd like to convince you that there is a significant difference or bias about the way those languages are being showcased.
Isn't the whole point of this table to compare equivalent snippets of code? You're right, those languages do things very differently from one another - especially when it comes to OO. In this case, the stated goal was to define a class that exposes a public property. In this I believe PHP and probably Perl were represented badly.
If you don't believe me, look at the Python example: it's the exact same implementation I translated into PHP syntax above. So my terse implementation is an exact match for the Python example and it's a functional match for the Ruby example. Hence, I can't help but think that PHP and Perl were misrepresented by making them jump through unnecessary hoops that do nothing but make the language look more complicated.