That these languages are so similar a table like this is possible leads one to think those programmers who consider themselves "polyglot" by programming in a subset of these aren't really "polyglot" at all.
I'd like to add Go, but I have a couple of reservations. First, I can't edit the page. Second, the list of features in each table is so specific. Go has a lot that the C-like languages in that table don't and vice versa. It seems there aren't enough axes along which to adequately compare.
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).
> Smalltalk definitely belongs on the list, it's the only one that takes "object-oriented" to its logical conclusion (dispatch can replace control structures).
As an aside, Haskell wouldn't need syntax for something like `if', but has it as a convenience. There's no syntax for looping, you can do that with higher-order functions.
You can't create 'idiomatic polyglots'. You just hack things together until they sorta work, for more than few languages this basically involves large strings and lots of backslashes, or base64 or something like that. (Writing a polyglot that does something more clever is obviously much better style, but it's incredibly hard.)
The site doesn't mention which meaning of "polyglot" the people behind it had in mind.
I assumed it was for people writing "polyglot" toy programs, because it'd be very useful resource.
I very rarely encounter uses of the term "polyglot" referring to people knowing large number of programming languages, so I didn't think of this use. Looking at it now, from this perspective, I have to say that I don't think it would be useful for these people, not enough depth.
Different definitions. You seem to be thinking of programs that are valid in multiple languages. The page is more of a dictionary of language constructs.
> The page is more of a dictionary of language constructs.
Which would come incredibly useful if you wanted to write a polyglot program.
Why else would you use a reference like this? If you wanted to learn a language, or had to hack something in a language you don't know, you'll be better off using resources specific to given language(s).
One would use this when writing a new program or modifying an existing one in a language one doesn't know, but when one does know another one well. Seems quite obvious.
(There's at least couple more errors on the Haskell column, a typo, and a missing idiom for their 'each' example, which would be 'mapM_ print', basically).
Neat 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($int = 0) {
$this->value = $int;
}
}
instead of the ridiculously verbose thing they posted there.
Speaking of ridiculously verbose, if they're going to pull in Moose to do OO in Perl they could at least use it's ability to provide default arguments instead of abusing BUILDARGS:
package Int;
use Moose;
has 'value' => ( is => 'rw', isa => 'Int', default => 0 );
no Moose;
Of course, Moose (while awesome) is hardly the only approach to OO in Perl:
package Int;
sub new {
my $cls = shift;
$cls = ref($cls) || $cls;
my $val = shift or 0;
bless \$val, $cls;
}
sub getValue { ${$_[0]} }
1;
Rather than wrapping the scalar int inside another data structure to be treated as an "object" it's possible to just take a reference and use that as our object. So in this case getValue is really just a verbose way to dereference ($int->getValue vs. $$int).
If you don't care about inheritance you could also take out the first two lines of ``new`` and just have:
package Int;
sub new { bless \($_[0] or 0) }
sub getValue { ${$_[0]} }
1;
Disclaimer: this kind of code is usually considered terrible Perl style and why people have such a hang up about the language, don't take this as idiomatic
Edit: Just noticed that they seem to think instance variables in Perl are private by default. Not sure where they got that idea? I guess Moose attributes are read-only by default, but that's hardly the same thing.
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.
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.
The Python bits do not seem to be written by a Python programmer, at least things like the above and this "package management" entry make little sense:
$ python
>>> help('modules')
download pkg with matching python version
$ tar xf libxml2-python-2.6.0.tar.gz
$ cd libxml2-python-2.6.0
$ sudo python setup.py install
x.succ is not the Ruby equivalent of ++$x in PHP (or Perl). x.succ returns x + 1 (by default, on integers) but does not increment x as ++$x does (since numbers are immutable and that's what "x" is giving us in Ruby). The closest match would be x += 1 (shorthand for x = x + 1). I don't see x = x.succ in common usage but that would work too.
I totally didn't notice that note but the page doesn't seem to have been updated since then :-)
I still don't see why it doesn't just use the common syntax though that does the same thing. It's intriguing that the Python one has no example for that row. Perhaps they are specifically looking for idiomatic techniques, even if they're not commonly used.
I note that the page is on a wiki so I could fix it, but given it's been there for years, I suspect there's a good reason no-one has already made the change.
The reason is that x would be referring to a number like 1, 42, or whatever, and numbers are immutable in Ruby. You can't "change" a number in-place. If you could change Ruby's concept of 1 into 2, then 1 would cease to exist and that would be a Bad Thing™ :-)
I think this shows that much of the time, the choice of open source scripting language isn't going to make or break a project. Ditto for well-maintained web frameworks.
