Hacker News Reader

Comment by karterk | Hacker News Reader

> you are writing javascript, which is a pretty shitty language in which to develop apps these days.

Woah. I do both Python and JS, and guess what - there are a fair number of people who hate Python's significant whitespace. And to them, it's also a "hacky" language (with all kinds of __foo__ stuff). So, shitty-ness is in the eyes of the beholder.

> It's for fad chasers who have no idea how real servers manage to serve volume.

There are real world apps like Trello, which is on Node, and are scaling well. Get your facts right, or stop trolling.

View on HN

I'm not going to argue too much between JS and Python.

But whitespace as debate topic over corner cases in JS language? really?

And also Trello is just launched and suddenly it scales off miles away? really?

The have pagerank 6 and they "just launch"? ... that is weird.

They launched mid September 2011. 3 months and they are what people considered web-scale?

Pagerank 6 == webscale?

Those facts are weird...

Yup, shitty-ness is in the eye of the beholder. I wish that every time a discussion of syntax came up, we'd be as quick to make reference to Wadler's law as we are to make reference to Godwin, when Nazi's are brought into the picture.

http://www.haskell.org/haskellwiki/Wadlers_Law

Arguing syntax is more often then not pretty absurd, unless you are arguing how the syntax actually changes semantics (like with S-expressions and overloaded parens).

I think it's amusing that when I claim that javascript is a shitty language, instead of trying to claim that javascript isn't shitty, you point out the shittier attributes of the language I was comparing it to.

Regardless of whether you like python or not, javascript pretty much sucks. Coffeescript helps a bit, but if you aren't running in browser, why hobble yourself like that?

The "Javascript is a shitty language" argument is getting old. I feel like you're only admitting that you're too lazy to learn how to program with a prototype-based language. You even suggest Coffeescript which is big on making Javascript like an OOP language when it's really not.

As far as a reason why you might "hobble" yourself is because Javascript is great at asynchronous design. You should try checking it out for real instead of jumping on the opinion bandwagon.

Oh man oh man.

    > You even suggest Coffeescript which is big on making
    > Javascript like an OOP language when it's really not.

JavaScript is deeply object-oriented.

> argument is getting old.

How does the age of the argument impact its validity.

> you're only admitting that you're too lazy to learn how to program with a prototype-based language.

If you don't like Erlang you are just admitting you are too lazy to learn the actor model. See I'll just call you "lazy" it will validate my argument.

> because Javascript is great at asynchronous design.

Not disagreeing with you here, but it would help if you'd actually mention why. You said something about it being a prototype based language. Is that why you think it is great at asynchronous design?

You expected a nuanced refutation when you yourself offered nothing of substance?

At least Javascript isn't having problems with incompatible language versions

The language is limited by IE dragging their feet on unbreaking their implementation or advancing standards, Webkit and V8 staying at a very conservative middle ground (Google pushing Dart and compilation as substitutes), and Mozilla being the only engine developer showing willingness to evolve the language, because they are the only ones using it to implement the rest of their browser. Node.js is held back by a language implementation they don't control and feels underpowered in the language department, indirectly being a victim of resistance to change in the browser landscape.

Python and other non-browser languages are far more powerful and expressive, and — since you refer to Python 3 — willing to further improve.

What __foo__ stuff?

__call__; __new__; __getattr__ and __getattribute__; and __metaclass__ - you can do some black magic in Python straight out of the box that takes a lot more work in statically typed languages.

Those are used for hacking, though, or for more advanced usage. The syntax is to discourage trivial use.

I'm not the author, but I believe the classic example is:

if __name__ == "__main__":

Or methods like __init__, __str__, __cmp__, etc. I know they are part of Python's protocols, which are basically a form of the template method pattern, and that they do make sense. But to some people they feel hackish; they woud prefer to have "normal" name methods for these protocols instead.

If they were normal they'd eat up your namespace.

Yes. But, it that a bad thing?

For example, I think if you'd have to explain how to change the string representation of some kind of object, saying "just define the 'str' method and then call it, like 'something.str()'" is simpler than "define a '__str__' method -- don't worry about all the underscores -- but then don't call it directly; instead of that, use the global 'str' function".

I don't know if that extra indirection (i.e. calling 'str', which, in turn, calls '__str__'; or 'next', that calls '__next__' in Python 3) adds more value than the simplicity of not having that extra indirection in the first place.

If it used normal names, Python couldn't evolve new methods for its protocols with language support. It would need some kind of annotation saying “yes I really mean to get this method called by the language and didn't just happen to use the same name by coincidence”.

You don't actually need that though - there is a completely obvious way to write stuff without having to use that line.

Just about the only underscore that you can't really avoid is the constructor syntax, "def __init__()". Which I guess is tolerable.

> You don't actually need that though - there is a completely obvious way to write stuff without having to use that line.

Can you elaborate on that point? I thought that was the canonical way to do exactly that... http://docs.python.org/library/__main__.html. If there's an easier/less verbose method (pun not intended) I'd love to know about it.

From your link:

It is this environment in which the idiomatic “conditional script” stanza causes a script to run

The conditional script stanza is optional, and intended to make a .py file function as both a script and a module (i.e. be importable). To me, it's unclear why you would want to do that. The only thing you have to do to avoid using __main__ is not require any file to be both a script and a module/library. Then just put any entry-point code at the top level of whatever script invokes your program. Unfortunately the __main__ stanza is pretty widely used though.

On the topic of modules, there is a wrinkle in requiring __init__.py to be present in any library subdirectory that you want to be part of the namespace. It would be nice to have a more intuitive way for that.

Oh, I do it all the time. It allows me to write a script that I can just run from the command line when I want, like 'fetch_new_images'.

I especially love it when I'm first coding, cause I like to test as I go. That allows me to run it to see what works and what doesn't.

When I'm finished, I know that I can just plop that file into a directory and use it as a library afterward. The majority of the code that I write implements that, and I find it a godsend, personally.

> fair number of people who hate Python's significant whitespace

if that is their only reason to claim JS is a better language, i wouldn't bother listening to their opinion too much.

Reply on news.ycombinator.com