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

If we’re talking about “dynamic CRUD over socket abstracted to death”-style tasks, and not considering minor preferences like syntax, then python, lua, most of lisp/schemes, perl. All of these allow enough meta-anything to do:

  ./file.src:
  func api_foo()
    for x in objs
      x.a = fetch(x.b)
    ui.btnok.enabled = yes
    commit()
And have foo exported as api, and when called, all clients/servers, databases synced, validations passed, schemas updated, triggers and reactions done, errors handled, developer errors reported.



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.


Nothing is stopping you from generating JavaScript code to do what you want. You don't need reflection to do that.

I'd hate to see Python become as popular as JavaScript and to have it be used as the defacto standard in browsers because honestly, it's nowhere near as enjoyable to use as JS.


No, Python is much more enjoyable than JS (see what happens when you turn subjective statements into objective ones?).

It feels to me like JS is more for people who want to write "clever" code and Python is for people who want to write boring, more maintainable code. It doesn't help that JS has a gentler learning curve and attracts more people who just want to get things done without thinking whether those things should be done that way.


JavaScript is more enjoyable than Python to me. You can’t really say no to that.

IMO JavaScript is for people who want to get things done quickly and efficiently and have their program work everywhere. Python is for people who like to think they are doing things “the right way” as if there were such a thing.


> JavaScript is more enjoyable than Python to me. You can’t really say no to that.

Indeed I can't. I can say no to "JS is more enjoyable than Python", which is what you said in your upstream comment.

> JavaScript is for people who want to get things done quickly and efficiently and have their program work everywhere

If by "everywhere" you mean "in a browser", sure. I don't see how that's related to the common definition of "everywhere", though.

> Python is for people who like to think they are doing things “the right way” as if there were such a thing.

I don't know what you mean by that.


The criteria for this list of languages seems to have been "isn't JS". The story for metaprogramming in JS certainly is limited in some aspects; for example, there's no operator overloading and JS isn't homoiconic like lisps, but between dynamic inheritance in older JS and the newer additions like proxies, symbols, accessors, reflection API, protocols and being able to extend the 'exotic' behavior of arrays, JS can probably still do whatever the snippet you posted is supposed to illustrate.

As a concrete example, here's a library I made that relies on symbols and dynamic inheritance to extend the built-in data types: https://github.com/slikts/symbol-land


I tried to include all my rant points into this example. E.g. what if fetch() doesn't go async? Then we don't have to mark it like that and don't have to await. Where ui and commit lives? There should be a unique environment for this specific api call or a whole subsystem. objs is something both enumerable and proxied, etc. It can be done in JS, but IRL it will be:

  ./file.js:
  function foo(ctx) { // @export
    for (let x of ctx.objs.iterate()) {
      x.a = await fetch(ctx, x.b);
    }
    ctx.ui.btnok.enabled = true;
    ctx.commit();
  }
  autoexport(module, x => eval(x));
And more boilerplate, ceremony and fud down the way, if you go vanilla.

(Thank you and all commenters here for sharing your code and experience. In particular, symbol-land looks very interesting and haskell-y.)


Having to explicitly mark where the control flow goes to the event loop with `await` is a very small price to pay for making the code much more clear. This is why I don't recommend node-fibers or deep coroutines in general.

Destructuring would make your example look better: foo({ui, commit, objs}), and then there's no need for typing out ctx. Another thing that's not needed with for-of loops is .iterate().

Using eval() is a very strong anti-pattern, and it's not needed there anyway. JS has the `with` statement that allows running code with a specific context, but its use is discouraged as it's really bad for readability and hard to optimize.


I used eval as a workaround; autoexport does fs.readFile() on module’s filename and adds all lines marked with @export comment to exports. Eval is the only way to get a function value from other module, since functions are local to the context that is implicit and only accessible through eval-ing closure. That’s my code and my company, so I don’t push it to anyone now or in the future. I know how important antipatterns are in general.

Destructuring looks good here, you’re right. Actually, this thread somewhat relaxed my js hostility and I see it as an alternative that has reasonable tradeoffs (but still not as a friend though).


I have trouble picturing what advantage that setup would give over using ESM or node modules.

The Function constructor is a better alternative for eval(), but still only as a last resort. eval() itself has no use cases.

I find that most JS criticism is ill-informed, because people are too quick to jump to blaming the language due to its reputation. Not that I'd call JS a great language, but it has redeeming aspects.




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

Search: