Hacker News new | comments | show | ask | jobs | submit login

I think python is a terrible language. It has so little syntax you can't tell the difference between various things. A variable declaration, a reassignment, a keyword, a whatever else, they don't have any visual distinction from each other.

I also find that python has reserved a whole bunch of keywords that I can't use as function names, making APIs hard to create with appropriate names. You also have to pollute your code with self everywhere.

It is also really slow, has no where near the number of libraries on github as javascript, is not a client-side language, doesn't have anything like babel, which can allow you to do a lot more than reflection/introspection (but not the same things exactly), etc.




> I also find that python has reserved a whole bunch of keywords that I can't use as function names, making APIs hard to create with appropriate names.

Python is one of the imperative languages with fewer number keywords in existence. Compare for example the number of keywords in Python[1] with Javascript[2].

Maybe you're confusing the built-in functions in Python language, like len() or str(), however since they're functions you can reassign them (not a good idea, however in a limited scope it works).

[1]: https://en.wikipedia.org/wiki/Python_syntax_and_semantics#Ke... [2]: https://www.w3schools.com/js/js_reserved.asp

> It has so little syntax you can't tell the difference between various things. A variable declaration, a reassignment, a keyword, a whatever else, they don't have any visual distinction from each other.

The fact that you don't know the difference between keywords and built-in functions makes your argument weak. But I will bite, if you're having difficult to make the distinction between a keyword and a variable you probably have a very bad editor. Syntax highlighting helps a lot here (like in almost every other language).

> You also have to pollute your code with self everywhere.

I really like the fact that self is explicit in Python. It makes OO patterns more explicit (there is no magic variable like self or this, just a parameter that is passed as the first argument in any Class method) and it helps making a distinction between attributes and local variables. Really, I would go even further and make super() a method from Object, so instead of calling a magic method super() I would call:

    class Test:
        def __init__(self):
            self.super().__init__(self)
Ugly? Maybe, however it is so much easier to understand what is happening.

> has no where near the number of libraries on github as javascript

Most JavaScript libraries in GitHub are pure toys/garbage, though. Python has a number of useful libraries and if you don't concur with me, please give examples of areas where Python is lacking a good library (I can easily give an example for JavaScript: ML and scientifc computing).


> It is also really slow

1) In scientific/ML CPython libraries, most critical parts are compiled anyway, and the core language is fast and expressive enough to provide a nice and fast interface to it; so your statement makes little sense without more context

2) Python != CPython


While I use Python for ML myself, I find it weird to say that a language isn't slow because you don't really use it anyway. It's true that Scripts in Python can be fast if 99% of the executed logic is in C anyway but that doesn't mean the language isn't slow. As soon as your Python script needs to do anything not available in a library you'll notice how slow it really is.

Python is really neat to quickly experiment platform independent but it's definitely extremely slow.


As parent mentioned, python!=cpython. You've got pypy, cython, typed cython, nuitka, and probably some others I forgot about. Without knowing what you're trying to achieve and what you've tried, "extremely slow" is pretty hard to accept.


Cython is a subset of Python, while PyPy has shitty C interop if nothing changed from the last time that I checked. Ergo in a general sense Python = CPython. If you have specific needs you may want to consider the alternatives, but saying that Cython is Python is at least shady if not completely deceptive.


That python is slow is utterly irrelevant. You would never deploy an unoptimized Python codebase into production if you cared about performance. You would profile the code and optimize the hot paths with the appropriate technology, be it numba-jit, cython, numpy, cffi, or any of the other many ways you can easily optimize Python


I wouldn't but I've seen a lot of people who will. If you have code that runs, why spend extra money to optimise it? Hardware is cheap and the cloud allow to scale as much as you want (not my opinion obviously but I've heard that more than once and I'm not even directly involved in these kind of decisions).


Clearly if there is no incentive to spend money to optimize it then it is fast enough.


Python environments and versioning are a PITA too. That's my main beef with it. Getting anyone else's Python code to run is a nightmare if they haven't documented everything; most other languages I use feel like they have some sort of default versioning built in when you start including other packages.

The difference between 'npm install' (and even an added 'gulp') and the chickens I've had to sacrifice at crossroads to get Python packages working is notable.

Oblig XKCD - https://imgs.xkcd.com/comics/python_environment.png


It's funny you should say the same issues aren't as bad with Node and NPM. Node's versioning is a sliding window. I tried compiling Bootstrap recently and it simply wouldn't compile because there was some dependency error that didn't make sense. Apparently Node breaks things too frequently and you can't `npm install` anything if it's half a year behind the newest version. I've never had that problem with Python.


'Node breaks things too frequently' - Python 2.7 -> 3.0.

Yes, you need to get the right version of Node, just like you need the right version of Python. I've had both largely just work with directions of "Version Y.X", where Y is defined. I've also had the occasion where it still broke with a specific version where both Y and X were defined.

In general, if I have the right version of Node (and I agree, I'd prefer package.json to also indicate the version of Node that was used to initialize it), things work when installing from package.json. Things also generally just work with Python if I have the right major version of Python, and an environment file. My issue is more that the 'simple' steps a lot of people do when creating Python projects -don't- use an environment. They just use whatever is installed globally on their computer, and they pip install any dependencies, then write a readme to pip install things with, rather than lock it down with a virtual environment.


I don't know, getting people to run my Python code currently consists of "make sure you have Python 3, run `pipenv install`, run the code".


And if every Python developer, researcher using Python, etc, did that, it would be much less of a problem. The reality is, many, many don't.

It's kind of ironic, really. With the Zen of Python stating "There should be one-- and preferably only one --obvious way to do it" why is it that it's so common for people to not do the thing that makes it reasonably portable?

I mean, I currently am working with some code that, as part of its readme, has a pip install of a lib -off of master-, and yes, obviously that caused problems. Is the author not a Python developer? Well, he's a researcher. Why is the obvious thing for someone coming naively to develop in the language not building a portable environment?


> Is the author not a Python developer? Well, he's a researcher.

I think this is why the situation is bad in Python: we have too many non-programmers in the community, that simply want something to work and get on with theirs life. If they can get by it by installing a bunch of libraries by running some command incantations as root, they're happy enough.

You don't have this problem with Node because the only niche that Node really matters is Web, and WEB DEVELOPERS know that their environment should be reproducible.

*: Even in Node this isn't really true, since we have yarn vs npm. Ruby is way more stable thanks to bundler.


> we have too many non-programmers in the community, that simply want something to work and get on with theirs life

The impact of those people in the ecosystem is zero, though. They don't inconvenience anyone by producing badly-written libraries, they literally do their job, produce what they want to produce and everyone is happy. I'm not sure why they get lumped in with "this problem".

I don't know why I hear this a lot, it certainly doesn't echo my experience. I've rarely had dependency problems, even the regular requirements.txt (without pinning to specific versions) tends to work well enough on reasonably current code. Pipenv pretty much solves the problem by introducing a lockfile.


Well, it impacts those people who needs their work, for example for validation of scientific experiments.

It doesn't impact the ecosystem very much for sure, however I wouldn't say that the impact is zero.


The Zen of Python does not extend past the language itself, unfortunately.


My main problem with Python: passing a temporary closure to a function is very messy. You can't do functional programming well in Python.

Also, I think scoping rules in Python are terrible. I always end up with a namespace that is a mess. And you can't do something like this in a clean way:

    counter = 0

    def add(n):
      counter += n

    add(1)
    add(2)
    add(3)


> And you can't do something like this in a clean way:

That's what nonlocal is for: https://docs.python.org/3/reference/simple_stmts.html#the-no... Just stick "nonlocal counter" in your function and it works.


True. But nonlocal is relatively new.

Also nonlocal implies that other variables are local, which is not true. E.g., the following works without "nonlocal" keyword:

    counter = [0]

    def add(n):
      counter[0] += n

    add(1)
    add(2)
(This used to be my workaround.)


Yup, relatively new. Only around since python 3.0, for the last 12 years ;-)


nonlocal implies that you are reassigning a variable outside of the local scope.

Your example works because you are mutating an existing object, not reassigning a new one.

It's a disingenuous comparison IMO.


> My main problem with Python: passing a temporary closure to a function is very messy.

What's messy about it?


Python syntax is built around indentation. Try to properly indent a function that you pass to another function. And what if you have to pass two such functions? Where do you place the comma that separates both arguments?


You can't define a function via 'def' and pass it as an argument at the same time. You can do it via 'lambda' though (which doesn't require any indentation since it's just an expression), what's the problem with it?

    >>> (lambda f: lambda x: f(x) * 2)(lambda x: x + 1)(100)
    202


So the problem is that you can only inline expressions; you can't inline let-blocks (assignments), or multiple statements. The usefulness is very limited.


You pass functions just like any other argument.

clos = 42

def foo(x): return x + clos

def bar(y): return y * clos

higher_order(foo, bar)

What's so hard about that?


Here's a challenge: try inlining the foo and bar in the call (because this is how functions are typically composed in functional programming)

You could do this with a lambda construct in Python; but this only works if the function has a single expression-statement; it doesn't work e.g. when you have a bunch of assignments inside the function you are inlining.


>Here's a challenge: try inlining the foo and bar in the call (because this is how functions are typically composed in functional programming)

Sure, it's ugly but I think it's a silly challenge. Complex functions defined in the function call are un-maintainable anyway IMO.


Explain how you can't tell the difference between a variable assignment and a keyword.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: