Hacker News Reader

Comment by lioning | Hacker News Reader

Python has always been sort of an odd language to me. Its syntax has always had a certain strong appeal to a large number of people, but there have always been these underlying performance issues that have been swept under the rug. I was surprised when it started being adopted so much in AI research because of the performance issues (I understand it's really C and other things doing the performing, but at some point you have to do something other than call C, otherwise you might as well just use C).

I do understand the appeal; I think its ergonomics are exemplary and worth being studied by language designers as a success case (if not a perfect or unique one).

Going forward, though, I'd like to see more adoption of languages like Nim, Kotlin, or Julia, that have similar levels of expressiveness but are more performant. The issues discussed in the article aren't really growing pains; they've been there from the beginning.

View on HN

I’ve personally never understood the appeal of Python’s syntax or other language details. The inconsistency over postfix method calls versus builtin or root level functions (like ‘len’) has always been totally inscrutable to me. The weird and unexpected rules about how to interact with multiple kinds of strings (what?). The special self param you are forced to add to method specs so that they don’t match how they are called. And the whitespace rules always struck me as heretical and in practice they just make me feel constantly confused about where to put what. For a long time I thought it was just a matter of working through the learning curve. But I’ve never felt comfortable with it.

All that said, lots of people I deeply respect love the language and I think it ultimately just comes down to some different wiring in our brains about what intuitively makes sense or doesn’t.

> The inconsistency over postfix method calls versus builtin or root level functions (like ‘len’)

Interesting, what inconsistency? My understanding is that the main interfaces the language provides (Sized, Iterable, Container, etc.) are defined in terms of dunder methods that are used by top level functions (len, iter, sorted/reversed). Granted, the python-of-1995 decision that objects like dict or list shouldn't have chainable methods is weird compared to modern ergonomics (like streams), but that decision predates a lot of those practices by decades.

> The special self param you are forced to add to method specs so that they don’t match how they are called.

Is this more, or less magical than a `this` param that is magically accessible in method bodies and references something, though it's not always clear what, especially in the case of nested classes/scopes (Java/JS)?

> The weird and unexpected rules about how to interact with multiple kinds of strings (what?)

Huh? Do you mean unicode/bytes? This isn't really hard. Just use unicode everywhere unless you're dealing with something that is conceptually either a bitstring you're going to do bit-twiddly things to, or an opaque blob of bytes.

E.g. "".upper() vs len("")

Len works on any Sized. Upper only works on strings. There are lots of Sized, there's only one string.

I believe that was a reply to your question:

> Interesting, what inconsistency?

And my point is that there isn't an obvious inconsistency there.

Sized is an interface, exposed via a function. String is a type, which has methods. Now yes, you can make an argument that everything is an interface ("upper-able"). But bleh, and this avoided problems like "is it .length or .length() or .size or .size()" as happened in some other languages.

This appears to be 2 different languages:

"".upper() vs len("")

The first appears to be an object oriented language such as Ruby or Javascript.

The second appears to be some language with plenty of static or built-in functions, such as PHP or C.

This is clearly inconsistent under any definition of inconsistent.

So which would you prefer:

upper([1,2]) (so `upper` is a static builtin) or being unclear on whether its "".len or "".length or "".size or "".size()

Like I said, there is consistency: interfaces are given top level things (builtin functions, operators, language features/keywords), while object methods don't.

To give a recent anecdote, Rust's `x.await`, which is more "consistent", but everyone is complaining because in most languages async interfaces are exposed via something like `await x` instead of an attribute/method-y thing.

I think there's a lot of worth using a high level language and integrating with C. It depends on the interface of course, XS (Perl) isn't too user friendly, but actually just using the Python C APIs is straightforward, rather than say Cython for example. I think you get the best of both worlds, but really it depends on what you are trying to achieve. If you want more type safety, then OK maybe not but if you want to interface with some low level components, or want to write a faster algorithm. Basically you can be more focused and granular with the unsafe and more error prone C side and tame it with a higher level language. Anyway, this is just my opinion but I've enjoyed this area very much and it has worked well for me.

> I think there's a lot of worth using a high level language and integrating with C.

I agree.

Python is an awesome high level interface to low level libraries and algorithms. As which it became even more appealing since you can write your low level code in Rust and call it from Python via PyO3 [0].

[0]: https://github.com/PyO3/pyo3

Why the downvote? This is just my opinion. I wasn't saying the parent was wrong, this is just my take on it. I'd like to hear some thoughts on people's experience in this area rather than just be downvoted.

Many/most AI/quant/data science people aren't exactly the best developers. Often these kinds of people only know one or two different languages and aren't really interested in programming "correctly" in the first place.

In quant finance, for example, once the research quants have developed a strategy (in python or matlab usually), the professional developers have the thankless job of actually implementing it in C++ or whatever.

Reply on news.ycombinator.com