Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Python Paradox (2004)

paulgraham.com

Post reply on HN
Print view View original

121–130 of 275 posts

Re: The Python Paradox (2004)

#121

Post by knighthack »

roenxi wrote: post #118
omershapira wrote: post #52

Funny how emergence works with tools. Give a language too few tools but viral circumstances - the ecosystem diverges (Lisps, Javascript). Give it too long an iteration time but killer guarantees, you end up with committees. Python not falling into either of these traps should be understood as nothing short of magic in emergence. I only recently discovered that python's reference typechecker, mypy, has a small side pr…

> Imagine reading the C++wg release notes in the same mood that you would the python release notes. Which mood are we talking about here? Mild dread? They keep adding new features to the language. The Python programming language is around 30. The release notes at this point should be "wow, we found a bug this year! Didn't expect to see one of those!". The secret of Python is it is actually a large community all learn…

My mood when reading the PEPs is of excitement.

While I'm not too keen on hardcore feature divergences, most of the new features have been really nice things to have, and which are never imposed. (E.g. the walrus operator, type hints, dataclasses, etc). I don't see the need to be so outright hostile to changes, unless they were clearly breaking features.

Re: The Python Paradox (2004)

#122

Post by dragonwriter »

zo1 wrote: post #100
aabhay wrote: post #44

Typed python is extremely ugly and frustrating. Does anyone have any good advice on doing it well? It seems like every library has their own system and doing any kind of casting just to make the linter be quiet is such a chore.

If you're doing casting its probably a code smell and good indicator of something being off, or you're doing something too exotic. I'd say this applies a good amount to normal compiled languages too. To do types well, I'd recommend constraining as much as possible. E.g. if a library gives you a union of 5 possible return types, just type it as one of them that you know you'll get and don't let that "complexity" propa…

> Or any other type checker for that matter other than Pycharms built-in one and mypy. Don’t faff about with vscode either.

Eh, I’m not getting different editors for different languages (coding, documentation, and otherwise) used in the same project, and IntelliJ doesn’t have nice tooling for everything I need that VSCode does. Not sure how good Pycharm’s typechecking is, but pyright is, IME, usually better than mypy, and VSCode lets me belt-and-suspenders both of those if I choose (I did for a while, between being pure mypy and being pure pyright).

Re: The Python Paradox (2004)

#123

Post by zmmmmm »

xhevahir wrote: post #58
treeform wrote: post #19

Earlier quoted context omitted.

My vote is on Nim. Python like syntax with C++ speed. Unknown enough, but still not too new or obscure.

The community gives me pause. Nim's BDFL seems to have a habit of driving away prominent users of the language. Programmers who had contributed to the compiler have made their own hostile fork, and two of the three people who have written book-length introductions to the language have either given up on Nim or been tempted to do so. (The third is the BDFL himself.) If anyone cares, here's some comments from one of th…

Interesting. I saw shades of this when I tried porting a tool over to Nim, found it was much slower than trivial code in Python and Groovy, then stumbled into this discussion:

https://github.com/nim-lang/Nim/issues/9026

Nothing as strong as the above but it definitely rubbed me the wrong way. So much advertising about Nim being efficient/fast and the default way to read a file is incredibly slow and inefficient .... and they don't care.

Re: The Python Paradox (2004)

#124

Post by college_physics »

> You push blobs of source code around the way a sculptor does blobs of clay

Love this sentence. Python is a success precisely because it enabled a lot more people to be sculptors. Ofcourse this means you see a lot ugly, unfinished pieces. And indeed bronze or iron sculptures may require a slightly different workflow and skillset.

Not clear for how long Python will retain this advantage. People parlay lists of technical reasons but most likely the new hot language will be one that makes it even easier and fun to push around blobs of code.

Re: The Python Paradox (2004)

#125

Post by zmmmmm »

PHP dominated the internet and then eventually became shunned with people embarrassed to admit they use it. I sometimes wonder if Python is on this trajectory but much slower or not. We are already at the point where there are very clearly better alternatives from nearly every technical perspective, so it's carried primarily by momentum and ecosystem. Can that last forever?

Re: The Python Paradox (2004)

#126

Post by ReflectedImage »

aabhay wrote: post #44

Typed python is extremely ugly and frustrating. Does anyone have any good advice on doing it well? It seems like every library has their own system and doing any kind of casting just to make the linter be quiet is such a chore.

There is no point in statically typed Python, it's useless.

Just a lot of people from other programming languages coming in and trying to make the language more familiar to them.

Re: The Python Paradox (2004)

#127

Post by ReflectedImage »

LudwigNagasena wrote: post #90
cabalamat wrote: post #40

Earlier quoted context omitted.

> Python is great for small scripts or explorations. I've used Python on program with >30000 LOC without any problems.

Do you really have no problems? I find the lack of proper type support and proper variable scoping to be a huge issue.

Lack of typing support is a major advantage. If you don't have types you don't need interfaces, generics, etc. The resulting code is shorter and less bug prone.

Re: The Python Paradox (2004)

#128

Post by stefncb »

klyrs wrote: post #82
arthurcolle wrote: post #30

Earlier quoted context omitted.

Post a pic

A random file in the standard library: https://gcc.gnu.org/onlinedocs/gcc-4.6.3/libstdc++/api/a0109... Honestly I don't think it's that bad if you can look past all the underscores. I looked around for something worse but maybe I'm just accustomed to the eyebleed that C++ has to offer. To me, Rust is uglier, but that's because it's been around a quarter of the time that I've been using C++ and I don't know what all t…

If you want ugly look at the MSVC std.

Re: The Python Paradox (2004)

#129

Post by signaru »

> People don't learn Python because it will get them a job; they learn it because they genuinely like to program and aren't satisfied with the languages they already know.

At least in my area, these days there are many programmers who know Python because that's the only language they have been taught. And there are many job opportunities specifically looking for Python.

Re: The Python Paradox (2004)

#130

Post by rullopat »

signaru wrote: post #129

> People don't learn Python because it will get them a job; they learn it because they genuinely like to program and aren't satisfied with the languages they already know. At least in my area, these days there are many programmers who know Python because that's the only language they have been taught. And there are many job opportunities specifically looking for Python.

You have to put this essay in the context of year 2004. Python was not used as much as today, it was an emerging language.
Post reply on HN