Hacker News Reader

My cranky old age is going to show here, but... Python or Perl, all the way.

Both have a long history of "standard" modules for common cases and well-maintained (if not "standard") modules for alternative approaches to the common cases, or for the uncommon cases.

More importantly, both languages have a well-established culture of boringness. This is a quality I actively look for, because it tells me someone wrote code to solve a problem, not because it was the hip thing to do.

There's still room for improvement in both of them, too. If you want to have a lot of connections open, you have to choose between lots of threads with blocking I/O, or using event-driven I/O, or using some kind of magical light-weight cooperatively multitasked greenlet/fiber thing.

As Erlang and Haskell show, it's totally possible to combine an event-driven I/O subsystem with lightweight user-space preemptive multithreading that supports a huge number of threads, takes advantage of multiple cores, and doesn't need to worry about blocking-vs-nonblocking magic. I would love to see that in a more mainstream language.

Deep integration with JavaScript (ExecJS and TheRubyRacer are way ahead of what is available in Python, Perl, and PHP)

There are a lot of libraries to check out on each language before you can make that claim!

Here for example are just some of the Javascript libraries on CPAN:

* JavaScript (SpiderMonkey) - https://metacpan.org/module/JavaScript

* JavaScript::SpiderMonkey - https://metacpan.org/module/JavaScript::SpiderMonkey

* JavaScript::V8 - https://metacpan.org/module/JavaScript::V8

* JE (Pure Perl JS engine)- https://metacpan.org/module/JE

* JSPL (SpiderMonkey) - https://metacpan.org/module/JSPL

It also depends on what you need to do with the web. Perl is currently the best language for interacting with Unicode, for example. If you web needs include Unicode, you might have trouble with Ruby or Python, unless you're willing to accept half-ass, partial, or just plain wrong Unicode implementations.

I agree, I love Python but I've spent untold hours dealing with its unicode issues.

Everything unencoded is unicode in 3 isn't it?

Strings are unicode. Bytes are encoded data.

With Python 2 strings you have to be proactive about it and - always use u"" unless you know what you're doing - segregate non-unicode data to boundaries by decode()ing early and encode()ing late, or you're guaranteed to shoot yourself in the foot sooner or later

but if you do it it's quite smooth sailing.

Also,

    #/usr/bin/env python
    # -*- encoding: utf-8 -*-

helps a lot.

All that just brings you closer to Python 3 anyway and really helps when using 2to3.

Agreed, however I've run in to compatibility issues with 3 a few times and so resolved to stick w/ 2, deal with the text parsing issues myself, keep the libraries I like and leave the ops team alone.

As someone building websites using ruby & dealing with Japanese, I have to agree..

    incompatible character encodings: UTF-8 and ASCII-8BIT

gets pretty tiresome! Using 1.9.2 at least you have .force_encoding ... feels pretty wrong but sometimes it's just needed to get the job done..

Ruby's character encoding and Unicode support is pretty strong. I'm intrigued how you think it's half-ass, partial or just plain wrong (Really! If there's something really borked with it, it's in my interest to know :-)). Every string has full encoding support and it's baked right in to the language.

tchrist's OSCON Unicode talks:

http://98.245.80.27/tcpc/OSCON2011/index.html

Specifically the third talk:

http://98.245.80.27/tcpc/OSCON2011/gbu.html http://98.245.80.27/tcpc/OSCON2011/gbu.pdf

Excerpts:

  Its String functions like upcase or capitalize won’t even look at
  anything but ASCII. 

  It’s completely missing a whole lot of critical Unicode
  functionality:

    casemapping & -folding
    grapheme support
    normalization
    collation
    text segmentation, &c &c &c. 


  Every Ruby string carries around its encoding, instead of sanely
  unifying into Unicode internally like nearly everything else does.

Also:

  > baked right in to the language

is not synonymous with "intelligently implemented"

Note that I wasn't implying that "half-ass," "partial," and "just plain wrong" necessarily all apply to Python and/or Ruby's implementations. Some may apply to some areas while others may not, and really this extends outside of just Python and Ruby, but I'm trying to stay in context here.

This is interesting stuff - thanks for sharing, I'll be checking it out. The upcase/downcase stuff definitely checks out so far :-)

require 'net/http'

Net::HTTP.get_print 'www.gun.io', '/'

That's it! In only two lines of ruby, you can grab a whole webpage and print it to the screen. Awesome! - and it's in the standard lib ;)

I agree, when I left PHPland I chose Ruby over Python because the (web) community was larger, there were just more books, blogs, screencasts, etc for Ruby/Rails.

There seems to be more ideas generated out of the Ruby community, I'd add Sinatra and HAML to the list above, like Rails they've both been ported to other languages.

OF course Heroku was Ruby first and it's so good that my PHP/Java/Python friends jumped for joy when their language became supported.

arguably, in PHP

    echo file_get_contents('http://www.gun.io')

you lose even more of the line noise of the other languages.

For a language that claims to be "batteries included" it amazes me how many Python tutorials begin with "go get and install this or that package..." How much of the Python standard library is no longer the "Pythonic" way of doing standard things? Why aren't APIs with more refined design, like Requests, pushed back into the standard library, and made the real one way to do it?

Well, OK, you'd have the problem of redundant libraries starting to stack up--it's already looking tiresome. For instance, Requests would have to be urllib3, since there is already a urllib2 and urllib. This article wants me to install simplejson, but there's already a Python json module: oh I see, it was merged in from simplejson, and now they are developed in parallel, so using simplejson may still be better, wtf? Why is there an htmllib in the standard library if I'm always going to use lxml instead? Let's not even discuss eyesores like the heritage of the subprocess and threading libraries...

To all your questions:

Because it takes time. It takes time to add things to the stdlib, especially if the are replacing "an old reliable." In the case of Requests, it is just a wrapper on the stdlib. There is nothing in Requests you can't do in the stdlib, ditto pretty much everything.

As far as lxml goes, there are a ton of XML parsing/query libraries out there. In lxml's case it is built on libxml2. I believe there is another library that is also build on libxml2, however lxml has better syntax for the most part. Should it be in the standard library? Probably not, it depends on a pretty heavy weight C library and most people don't really need it. When you do, you use it.

I have no idea what is going on with the simplejson business. I just use the json lib.

I don't see anything wrong with subprocess or the threading libraries. They do what they need to do. I use subprocess quite often, it works fine. It is way better than the actual legacy version (in the os library).

It seems performance issues with stdlib's json version are not in the past http://news.ycombinator.com/item?id=3128433

Good to know. When I said I don't know what is going on, I meant why the simplejson people are not focusing on the stdlib version. It seems strange to basically have a fork...

> arguably, in PHP

> echo file_get_contents('http://www.gun.io)

I thought it had to be "too good..." - links are broken. And since src links are broken, too, images do not display.

Of course, these are all examples of piping the body of an HTTP GET response. There is no parsing going on. You'd need to parse the HTML to translate the links, if this is being served from your own webserver. If you're trying to mirror actual content, wget -r might be a better tool (and can translate the URLs).

What? Both the Python and PHP samples output the same thing (bar one line) - images don't show because the pages contain relative paths (which only work if you have the images stored locally).

    (development)ross@debian:~/hntest$ python download.py > download.py.html
    (development)ross@debian:~/hntest$ php download.php > download.php.html
    (development)ross@debian:~/hntest$ diff download.py.html download.php.html
    242c242
    <             <div style='display:none'><input type='hidden' name='csrfmiddlewaretoken' value='b0c35970dfd374f2b138ed89a4f83a76' /></div>
    ---
    >             <div style='display:none'><input type='hidden' name='csrfmiddlewaretoken' value='018fe81570d710d88ca3f46d1db4c8b7' /></div>

303d302 <

urllib is in Python's standard library:

  import urllib
  the_page = urllib.urlopen("http://www.gun.io/")
  print ''.join( the_page.readlines() )

I could jam it all into one line, but in Python we prefer readable code ;) ;)

The Python community also tends to be quieter than those raving Ruby fanbois - if you'd said appeared to be larger, then I would have agreed with you...

Why don't you just use:

  print the_page.read()

Pythonistas should look at the "Requests"[1] lib for Python mentioned here on HN[2] a few days ago, too.

[1]: http://docs.python-requests.org/en/latest/ [2]: http://news.ycombinator.com/item?id=3094695

Explicit is better than implicit. I think keeping a bit of the verbose helps people know what's going on. That knowledge is infinitely valuable when debugging certain problems or creating solutions that work well.

Have you heard of something called Java? ;)

A good language, as a good anything, is a reasonable language. Giving extremes as arguments against sensible middle positions is the way of madness, paralysis, or extremism..

Thats what the post linked to talks about.

Sure, but good to repeat it in this case - Python's urllib/urllib2/etc. libraries are famously hard(er than necessary) to use.

I wouldn't count the need for a good JVM implementation as a plus mark in a Ruby vs Python comparison. Jython is used when you need to interact with Java libs, not because the C implementation of Python language is slower than the JVM one. The same does not apply for Ruby, you use JRuby because it's better than CRuby. If you want to compare speed you'd be up against pypy.

Your statement sounds like sour grapes to me.

When a language has multiple viable implementations, it means the language has a good specification. It also means that it doesn't depend too much on platform-specific characteristics. It means it is more portable. Python is both blessed and cursed with a couple of problems ... its behavior is sometimes related to the CPython implementation (e.g. reference counting, __del__), and also some libraries are too big and important to live without them.

One such library is NumPy. Currently you cannot talk about an alternative Python implementation if you don't have NumPy running on it, and that's a fact.

I'm a Python developer in my day job and I never used Pypy for anything. I only played with it and became frustrated that libraries I relied upon don't work on it.

Btw, if you're a fan of Pypy, checkout http://rubini.us/

Web developer here; I live without NumPy all the time. :)