Hacker News Reader

Comment by raymondh | Hacker News Reader

This is a wonderful recap of the different ways of expressing the same idea in different languages. It is a fine Rosetta Stone.

That being said, it would also be useful to characterize features that are completely unique to a given language. For example, Python has 1) a unique and powerful version of super() for working with multiple inheritance; 2) it has generators (the yield statement) that allows state to be suspended and restarted (and allows data and/or exceptions to be passed back in to the generator); 3) the with-statement for managing contexts and for providing a new way to factor code; 4) easy-to-write class and function decorators; 5) metaclass support that provides full control over the creation of classes; 6) and descriptors for fine-control over attribute/method binding behavior.

Collectively, these capabilities make the language more than just another syntax for expressing the same ideas as other languages.

View on HN

That being said, it would also be useful to characterize features that are completely unique to a given language.

Perl has all these features.

1) a unique and powerful version of super() for working with multiple inheritance

Perl (with Moose) has before, after, around, override, and augment in addition to super. And, it has "Roles" so you don't have to resort to hacks like multiple inheritance to implement mixins or interfaces.

2) it has generators (the yield statement) that allows state to be suspended and restarted (and allows data and/or exceptions to be passed back in to the generator)

Perl has the library Coro, which allows multiple Perl and C stacks. With this coroutine and call-with-current-continuation are implemented.

3) the with-statement for managing contexts and for providing a new way to factor code

Perl has scope a few implementations of scope guards; Guard and Scope::Guard. It's not quite the same as with, because with's semantics around:

   with open_file('foo') as f:
       return f

are unclear (f is closed but the object still exists). Perl mixes

   sub x {
      my $f = file('foo')->openr;
      return $f; # $f is still open and ready for reading by the caller
   }

Emulating Python is still possible, however:

   sub x {
       my $f = file('foo')->openr;
       scope_guard { $f->close }
       return $f; # caller gets a closed file object
   }

4) easy-to-write class and function decorators

This you don't really get, though you do get all of the things I've seen them used for in Python. You can even hack Perl syntax in a lexical scope, but that's evil so I will pretend it's impossible :)

5) metaclass support that provides full control over the creation of classes; 6) and descriptors for fine-control over attribute/method binding behavior

Moose. And unlike Python, there are libraries that take advantage of this to provide tiny bits of OO functionality that you can pick and choose from. Look on CPAN for a MooseX:: module, and chances are that the set of libraries you choose to use to augment a class will all work together.

The difference between Perl and Python is that Perl's features are implemented as modules, while Python's features are implemented in the core. That means that if you come up with a good idea, you can start using (and sharing) it immediately, while with Python, you have to wait until the next major release.

It also means you have to stumble upon Moose to start using objects in a reasonably sane way. The average new Perl programmer is not going to go looking for a library that does object-oriented behavior until it's too late. They'll probably have some crazy idea that the language should be doing OO for them.

If you were to navigate a largish Perl codebase today, you'd encounter the old-school bless, Moose trickiness, and all kinds of variants on these themes. Extremely clever stuff that Damian Conway would give you a gold star for.

As usual Perl gives you everything you want, unless what you wanted was simplicity or standardization.

I used to work on an old perl code base that was written by well meaning new programmers. I know work on an old python code base written by well meaning new programmers.

Both projects suck equally. The python project is much newer (~4 years instead of 12), but the smell is about the same. The problem with new programmers isn't that they pick the wrong object creation patterns, but that they reinvent the wheel and write long stupid functions with horrible nested if/else statements. A former google employee worked on one of the projects, and wrote her own python to json function.

I like python, and I like perl, but the python culture sucks. It has this weird superiority complex where it rejects any external ideas. If I am talking to perl people, and I mention some kick ass python feature that I miss, I either get information as to how it can be done in perl, or interest into why I like it. Around python people, I generally get something like, "well, none of us know perl. Have you tried doing it the python way?"

Moose is awesome, perlbrew is awesome, perl's module culture is awesome. The module culture is the one that annoys me most often. Python programmers don't write as good of tests, or nearly as good of documentation. We still have to run a lot of python 2.4, and a lot of modules claim 2.4 support and then use 2.6+ syntax.

I like python, I think it is a much better matlab, but a lot of its syntax is unintuitive and stupid, and there are some serious cultural issues. Anyone who thinks that it is perfect, or better than another language in every way is holding it back.

I agree with another comment in reply to yours that this is a tired argument.

But ignoring that; someone who is new to programming is not going to understand the value of any of these concepts anyway, so it doesn't matter that they don't discover them immediately. At about the same time people figure out how to do OO cleanly, they will start hearing about libraries too.

I've worked on a number of post-Moose codebases, and most people did the conversion cleanly and all at once. (I can't explain it, I'm just reporting the facts. I was surprised too.) The biggest Moose-hacking pain point I've seen was someone trying to subclass DateTime with Moose. It just doesn't work very well; DateTime is werid and Moose is weird. (Of course, the solution is delegation rather than subclassing. Even in languages with real OO, you often want a "does X interface by delegating to Y class" rather than "isa Y".)

Fork Perl 5, package it so that Moose is default, and call it Perl 7.

If you want Python, just use Python ("There should be one-- and preferably only one --obvious way to do it." - PEP 20). Very central to the Perl philosophy is that TIMTOWTDI (though I'm not sure if this is canonized anywhere as clearly as for Python), so your suggestion is ridiculous. I for one found the bless mechanics extremely enlightening with regard to the semantics of object orientation. The feeling I had when I first got that was akin to when I first realized "to be" lumps together the semantics of identity and attribution in the english language.

I'm not a Perl programmer, but I'm aware of Moose. It's frequently mentioned in beginner tutorials on how to do OO.

You mean Moose being mentioned in Non-Perl beginner tutorials? That's interesting! Do you happen to have some links to those tutorials?

No, I mean Perl tutorials like Modern Perl.

>>The average new Perl programmer is not going to go looking for a library that does object-oriented behavior until it's too late.

Sigh, please don't start language wars by stuff like assuming new programmers sits alone in an ivory tower and don't talk to people, read blogs or browse a new book. (Modern Perl discuss Moose before the old standard, for instance.)

Edit: I'm just not going to touch where you assume all Perl teams that write large code bases are too stupid to agree on best practices. (I'll ask this back instead: Why are there so many language wars-lovers in some open source communities...?)

Why are there so many language wars-lovers in some open source communities...?

Probably the same reason the French don't like the English or the Indians don't like the Pakistanis. The closer two things are to each other, the more passionate people are about the differences.

My experience is that all the languages are identical. Python has a culture of cleanliness at the core, but there is a lot missing from the language that makes it unclean in practices. (See: the investment bank I worked where all new apps were written in a C#/C++/Python trialect, to coin a new word.) Perl is a very messy language, but the community has hyper-overreacted and have made a very clean set of "best practices". I haven't done much Ruby, but I can't say anything other than that it looks like a combination of Perl and Python, with a relatively new community around it.

These three languages are largely the same thing: they run slow and they're fun to write. Hence all the infighting.

Learning a language is an investment. People defend their investment strategies lest they be considered a fool. Attacking alternatives is a form of defense. I fear it's as simple as that.

The original question was -- why do some communities seem to be more oriented towards language wars than others?

Can't speak for all of them, but if a language has "there's more than one way to do it" as its main motto, I guess the people from the ecosystem are less likely to attack other languages.

>>Why are there so many language wars-lovers in some open source communities...?

Honestly, I think that the reason is simple: because it's entertaining. Yeah, sometimes I'm tired of reading the same arguments over, and over, and over again. But sometimes, an OP is particularly eloquent in his trashing a language, and I like that, even if the language he's trashing is my favorite.

The same goes with rants. I can't understand people debating over Linus Torvalds rant on C++. Honestly, I found it hilarious and well written. That's it, I'm looking no further because I know that this type of argument has no end.

I would certainly not care to debate the relative merit of my favorite language in one of those troll topics, but I do enjoy reading heated programmers exercising their writing skills against each other.

I'm pretty sure you can do the same generator does with iterators in PHP. Traits in PHP 5.4 probably cover most of use cases where you may want multiple inheritance. Decorators are superior in Python though, no real replacement for it in PHP.

Reply on news.ycombinator.com