Live data from Hacker News

Hyperpolyglot: PHP, Perl, Python, Ruby

hyperpolyglot.org

31–40 of 58 posts

Re: Hyperpolyglot: PHP, Perl, Python, Ruby

#31
post #12

Neat, ridiculously comprehensive table. A few "warnings" I found in the first 10%: > Python: Statement separator: ; or sometimes newline More like newline or sometimes ; . When was the last time you saw a Python script with a semicolon? > Python: Multiline comment: '''comment line\nanother line''' That's a multiline string.

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 That's just bizarre.

Yeah I came here to point this out. I'd understand if pip weren't mentioned, but easy_install has been the standard for many years.

Re: Hyperpolyglot: PHP, Perl, Python, Ruby

#32

Earlier quoted context omitted.

Go to http://hyperpolyglot.org/ directly. Included there: Scripting Languages: PHP, Perl, Python, Ruby Embeddable Languages: Tcl, Lua, JavaScript, Io Shell Languages: Bash, Zsh, AppleScript, PowerShell C Style Languages: C, C++, Objective C, Java, C# Pascal Style Languages: Pascal, Ada, PL/SQL, SQL/PSM Lisp Dialects: Common Lisp, Scheme, Clojure, Emacs Lisp Type Inference Languages: Standard ML, OCaml, Scala, Haskell…

I would have liked for Go to have been included, (C style languages) not to mention Smalltalk.

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.

Re: Hyperpolyglot: PHP, Perl, Python, Ruby

#33
post #13

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($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.

Re: Hyperpolyglot: PHP, Perl, Python, Ruby

#34
post #2

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.

Go to http://hyperpolyglot.org/ directly. Included there: Scripting Languages: PHP, Perl, Python, Ruby Embeddable Languages: Tcl, Lua, JavaScript, Io Shell Languages: Bash, Zsh, AppleScript, PowerShell C Style Languages: C, C++, Objective C, Java, C# Pascal Style Languages: Pascal, Ada, PL/SQL, SQL/PSM Lisp Dialects: Common Lisp, Scheme, Clojure, Emacs Lisp Type Inference Languages: Standard ML, OCaml, Scala, Haskell…

Ah didn't notice that. This site suddenly got a whole lot more awesome :)

Re: Hyperpolyglot: PHP, Perl, Python, Ruby

#35

Earlier quoted context omitted.

Go to http://hyperpolyglot.org/ directly. Included there: Scripting Languages: PHP, Perl, Python, Ruby Embeddable Languages: Tcl, Lua, JavaScript, Io Shell Languages: Bash, Zsh, AppleScript, PowerShell C Style Languages: C, C++, Objective C, Java, C# Pascal Style Languages: Pascal, Ada, PL/SQL, SQL/PSM Lisp Dialects: Common Lisp, Scheme, Clojure, Emacs Lisp Type Inference Languages: Standard ML, OCaml, Scala, Haskell…

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).

Re: Hyperpolyglot: PHP, Perl, Python, Ruby

#36

Earlier 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).

> 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 believe io does this as well.

Re: Hyperpolyglot: PHP, Perl, Python, Ruby

#37
post #27

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.

As a Ruby noob and without researching too much, here's my question: would x.succ! do it?

Not if x were a regular old Fixnum.

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™ :-)

Re: Hyperpolyglot: PHP, Perl, Python, Ruby

#38
post #13

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($in…

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.

Post reply on HN