Hacker News Reader

Funny, for about every point I feel the opposite way :-). Python is an elegant language that hits the sweet spot where it is very expressive, and easy to do what you want, and at the same time has enough structure so you don't produce a mess all the time.

The libraries are very powerful, but a lot of them are hacks. Numpy and Pandas totally rely on magic and overloading the array indexing operator. You can't express a problem the natural way or it will be slow, you have to think the numpy way. I find it especially confusing if you create expressions with numpy arrays. Am I operating on them element wise, or creating a "cross product", or am I creating some kind of magic indexing object? Matplotlib is also annoying, there are so many ways to do things and half of it is object oriented, while half of it uses global state.

One thing I like about Python are the web frameworks (Django, Flask). Async is also good, although it took almost 10 years for vanilla Python to catch up with what Twisted already had.

About code breaking I also have the opposite experience. I wrote a little Gtk app in the late 2000s and it worked with little or no changes for many Python and Gtk versions, thanks to the dynamism of Python. That would be completely impossible with a compiled language.

Interesting, and nice to have a contrasting datapoint.

I do think that "The libraries are very powerful, but a lot of them are hacks. Numpy and Pandas totally rely on magic and overloading the array indexing operator. You can't express a problem the natural way or it will be slow, you have to think the numpy way. I find it especially confusing if you create expressions with numpy arrays. Am I operating on them element wise, or creating a "cross product", or am I creating some kind of magic indexing object? Matplotlib is also annoying, there are so many ways to do things and half of it is object oriented, while half of it uses global state." is an illustration of my point: the language itself isn't powerful enough to do the job so you rely on a lot of libraries written in different languages to glue it all together.

An 'elegant' language would provide a way to do so without all of these leaky abstractions.

To me Clojure is such a language, but it doesn't nearly have the kind of ease of use that Python has.

> is an illustration of my point: the language itself isn't powerful enough to do the job so you rely on a lot of libraries written in different languages to glue it all together.

The language is 100% capable. Matplotlib's API is horrible and confusing because one of their design goals was/is to be similar to matlab (that's where the "mat" in it's name comes from) to allow people who are comfortable with matlab to switch more easily.

Matlab's plotting facilities are a mess of global state, so matplotlib has copied it.

> An 'elegant' language would provide a way to do so without all of these leaky abstractions.

It would have to do something else, first: Exist.

In 10+ years of programming, I've yet to ever see a implementation of a complex abstraction that was comprehensive and complete enough that I didn't find a corner case requiring me to reach through it and deal with platform specific something-or-other.

You are right, you can't separate the language and the libraries, and a language would profit if it had a way to express these abstractions better. But if you'd that kind of syntax the Python language I think it would become bloated.

I think I like Python, because coming from C, a lot of things that are tedious there are effortless in Python (Strings! Lists and dicts, libraries, and so on.)

I came from C as well and even though Python does make strings, dicts and so on easier the main difference between the two (compiled vs interpreted) is exactly why you get all those libraries in the first place: it is super hard to get good performance out of an interpreted language if you want to crunch numbers.

That's why each and every number crunching problem will eventually make use of the various escape hatches to call libraries written in a language that is performant.

As for strings: BASIC also had strings. That doesn't mean that having strings (or even dicts) is what makes a language elegant.

The problem really is that there are only so many sweet spots for programming languages and usually those come with limitations with respect to the domain you want to use them for. Pick any two: expressive, fast, easy to use.

NumPy/matplotlib make perfect sense for Matlab users (it's basically a port of Matlab semantics). If Matlab were free and didn't suck so much as a general purpose language, I wonder to what extent Python would have been adopted in scientific computing (Matlab is still pretty strong in some communities, to be fair).

Very strange, about the whitespace. I write C++ most of the time and I love significant whitespace. I like the combination of power and (...these days, relative...) simplicity of the language for all kinds of helper tools. Probably wouldn't want to use it to write something that is large and / or needs to run fast.

Ive always found whitespace to be like variable names, restriction coming from the language always seems to make it harder to use them to convey things to the next person who comes along.

The code typesetting is for the humans not the machines.

The best thing about significant whitespace is the reduction in pernickety code review comments about it compared to other languages. If you also agree to "just run black" to format code then that kind of bullshit drops to almost 0 in a team.

But if you agree on a certain formatting tool anyway, then you don't need significant whitespace to get that. That's one of the things I like most about Go. It shipped with gofmt from day one, so literally no one ever argues about coding style.

People totally do argue about go coding style. Since gofmt doesn’t do line breaks, where to break long lines is a constant struggle. You also have stricter formatters like gofumpt addressing certain problems not handled by gofmt, but the long line problem is still up in the air AFAIK.

The bad thing about significant whitespace is it breaks copy-pasteability of code, with no way to get broken formatting back without understanding what the code does.

That is a lot worse than formatting squabbles, especially for a glue language where you are expected to be able to copy snippets for short scripts all the time.

That and even with version control you will always have to keep an eye out for accidental deletion of the last bit of whitespace on any code block. It's a pretty easy mistake to overlook without context.

My biggest pain point with Python is C / Rust dependencies. So, not really Python per se, as I suspect any language relying on C ABIs will hit the same issues.

> there isn't a single piece of code that I ever put together that worked longer than a few years out of the box without some breaking change

The best practice, which prevents this issue, is to use envs, (as well as pinning your dependencies for any given project in a committable artifact).

(Seems like a lot of people are using system Python, which isn't really recommended.)

I started a project in 2016 and used pipenv to freeze all the dependencies. A few weeks ago, I could not get it working on a new machine. Apparently the new system python broke some of the libraries. I had also pinned the python version in pipenv, but it seems like pipenv can only install python versions that are not too old.

I really like the language, but all the tooling is seriously broken.

If you upgrade the runtime / compiler, you'll run into changes of behaviour. This really applies to almost every implementation out there. This applies across the board with large enough codebase.

pyenv will make your life easier in this regard. that is all.

Pipenv has pyenv integration. It just doesn't work with python 3.6 on my machine. My guess is that it tries running pipenv itself with the old interpreter and is no longer compatible. In any case, faffing around with 25 different third-party solutions is a horrible developer experience.

I feel you.

Fwiw what I've settled on that seems the most stable is to use pyenv as the "outer layer", as it shims the python interpreter along with any venvs so you don't get conflicts / heisen-incompatibility. Lets you use anaconda envs as children as well. The real trick, I think, is to pick one system as the canonical master env controller and don't deviate.

Yeah, I have no problem running stuff from a decade ago because of virtual env and pip freeze (even across diff oses).

I have no problem running stuff from a decade ago either on the same box and installation that it was on a decade ago. But virtual environments and pip freeze are closer to mothballing an old box than displaying long term code compatibility and functionality. Their main reason to exist is as a workaround precisely because there are such issues.

The whole idea that you need a multitude of environments to support applications written in the same interpreted language is where it breaks, that should not have been necessary if backwards compatibility had not been an issue.