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

91–100 of 275 posts

Re: The Python Paradox (2004)

#91

Post by ShredKazoo »

threeseed wrote: post #39
noobermin wrote: post #29

Earlier quoted context omitted.

Rust is "not as used" but it has a following who hype it to the point that I've avoided taking time to relearn it just due to the strange vibes I get from their community. These people once mentioned, on twitter, that people who hate systemd are like reactionaries (as in, politically far right), as if a choice of init is a correlative of political ideology. When you view others' preferences for fucking software as so…

The difference is that Java has alway been driven from the enterprise. And so there has been this long investment in frameworks, libraries etc that no one would ever otherwise write. Especially areas like governance, security, compliance, reliability etc. I think Rust is just going to end up just being a better C++ not a true mainstream language.

See this article: https://www.theregister.com/2022/09/20/rust_microsoft_c/

* Microsoft Azure's CTO says C and C++ are deprecated

* Most-loved language in StackOverflow dev survey for 7 years running

* Now in the Linux kernel

Sounds like success to me.

Re: The Python Paradox (2004)

#92

Post by cwalv »

VectorLock wrote: post #69
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.

Typically large code bases have problems that are more intrinsic to organization than what language its in. Huge code cases in any language are usually fine if discipline is exercised. And concurrency issues and memory overhead problem are from not knowing the right way to do it. Although I will concede that naive approach to both of those is sub-optimal.

> Although I will concede that naive approach to both of those is sub-optimal.

Paradoxically, this can actually lead to a better understanding of how to write performant code. When I first learned some of the be implementation details of python, I couldn't believe it was performant enough to work for anything ... after optimizing enough of it, I understand better what actually matters

Re: The Python Paradox (2004)

#93

Post by dietrichepp »

epgui wrote: post #43
cvccvroomvroom wrote: post #24

It was right then, but it's kind of dated and misses an evolutionary lesson: beautiful code isn't enough, it has to be safe, beautiful, maintainable, productive, understandable, and resource efficient. Ruby is still great for throwing something together fast and maintaining it until it runs into scale problems. It added gradual typing with sorbet and RBS. Crystal is a neat typed, compiled Ruby-alike but it's buggy. R…

> Haskell and Idris are beautiful and powerful, but inaccessible to most software engineers. I don't see any fundamental reason why that should be the case. It seems to me that while it's true that most engineers would have a hard time navigating these languages today, it's mostly due to socio-historical accident. It's not because the languages are particularly difficult or arcane, it's mainly because people don't al…

I do see fundamental reasons. Haskell was designed from conception to be a platform for research and education. I’d say it was a wild success at those two things. Certain decisions that made it successful as a platform for research and education make it less suitable for use writing applications in industry.

The main decision I am thinking about is lazy evaluation. Lazy evaluation forces authors to write pure code, which drove Haskell’s community to build libraries that expressed effects in the type system, which made things like STM possible. If I wanted to design a Haskell-like for industry use, I would give it non-lazy evaluation (I’m not gonna say “strict” because I think the compiler should be free to omit the evaluation of any expression, but it sure would be convenient if we had more predictable performance characteristics).

I’m also not saying that you can’t use Haskell in industry. Obviously, people do that.

Re: The Python Paradox (2004)

#94

Post by ShredKazoo »

d--b wrote: post #41

Yeah it is dated. Python got hyped and now people learn it because data science hires python people, and data science pays well, not because they care.

I used to interview people for data science roles. We let people use whatever language they wanted in the interview. I expected to see a split between Python and R, but the reality was that almost everyone used Python, which was a bit of a surprise.

It's even more surprising to me given that Pandas is such a poorly designed library. (Apparently the guy who developed it was learning Python while he was writing Pandas.) I saw candidates make mistakes due to quirks in Pandas often. And quirks can be extra deadly with data science code: https://news.ycombinator.com/item?id=33797339 So overall it's a weird situation. I think a big factor is that a lot of data scientists are newbie programmers who are just piling in to what's popular & established.

Re: The Python Paradox (2004)

#95

Post by hgomersall »

threeseed wrote: post #39
noobermin wrote: post #29

Earlier quoted context omitted.

Rust is "not as used" but it has a following who hype it to the point that I've avoided taking time to relearn it just due to the strange vibes I get from their community. These people once mentioned, on twitter, that people who hate systemd are like reactionaries (as in, politically far right), as if a choice of init is a correlative of political ideology. When you view others' preferences for fucking software as so…

The difference is that Java has alway been driven from the enterprise. And so there has been this long investment in frameworks, libraries etc that no one would ever otherwise write. Especially areas like governance, security, compliance, reliability etc. I think Rust is just going to end up just being a better C++ not a true mainstream language.

What's a "true mainstream language"?

Re: The Python Paradox (2004)

#96

Post by ShredKazoo »

threeseed wrote: post #32
RomanPushkin wrote: post #6

It's called "anecdotal evidence", the only thing that makes this post credible(-ish) is that PG wrote it.

Since I have been following PG on Twitter I understand that the reason he has so many good takes is because he has so many takes in general. And most people tend to skip over the incoherent, offensive or just plain dumb ones. I wish more of those weren't flagged to death when people post them here.

PG's takes are pretty good by Twitter standards at least. Honestly his account is one of my favorites on Twitter. If you don't think his tweets are good, I'm genuinely curious whose tweets you actually like -- can you recommend any accounts?

Re: The Python Paradox (2004)

#97

Post by VectorLock »

cwalv wrote: post #92
VectorLock wrote: post #69

Earlier quoted context omitted.

Typically large code bases have problems that are more intrinsic to organization than what language its in. Huge code cases in any language are usually fine if discipline is exercised. And concurrency issues and memory overhead problem are from not knowing the right way to do it. Although I will concede that naive approach to both of those is sub-optimal.

> Although I will concede that naive approach to both of those is sub-optimal. Paradoxically, this can actually lead to a better understanding of how to write performant code. When I first learned some of the be implementation details of python, I couldn't believe it was performant enough to work for anything ... after optimizing enough of it, I understand better what actually matters

Also people seem to forget the rule of premature optimization. Worry about performance when performance starts to be a problem. You identify the area with performance is lacking and optimize that. Compute is cheap, manpower is expensive.

Re: The Python Paradox (2004)

#98

Post by ShredKazoo »

RomanPushkin wrote: post #6

It's called "anecdotal evidence", the only thing that makes this post credible(-ish) is that PG wrote it.

To be fair, blog posts based on anecdotal evidence hit the frontpage on HN all the time. I think you're implicitly holding PG to a higher standard.

Then again, maybe he's asking for it, given that he calls his blog posts "essays". Lol.

Re: The Python Paradox (2004)

#99

Post by ImaCake »

ShredKazoo wrote: post #94
d--b wrote: post #41

Yeah it is dated. Python got hyped and now people learn it because data science hires python people, and data science pays well, not because they care.

I used to interview people for data science roles. We let people use whatever language they wanted in the interview. I expected to see a split between Python and R, but the reality was that almost everyone used Python, which was a bit of a surprise. It's even more surprising to me given that Pandas is such a poorly designed library. (Apparently the guy who developed it was learning Python while he was writing Pandas.…

>Apparently the guy who developed it was learning Python while he was writing Pandas

This makes a lot of sense. I remember trying to learn Pandas before v0.24 and finding the syntax changing a lot between versions which just confused me even more. I later learnt some R and was blown away by how easy tidyverse, and even base R data.frames were to use.

Re: The Python Paradox (2004)

#100

Post by zo1 »

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" propagate further into your code base. Likewise if you're wrapping a lib function that can take 3 levels worth of complex union or umpteen varargs, don't let that bleed through in your function signature "just in case".

And most crucial advice. Don't use Google's type checker pytypes. Or any other type checker for that matter other than Pycharms built-in one and mypy. Don't faff about with vscode either. Pycharm will make your python type hinting journey a pleasant experience (barring some generics and OOP corner case scenarios.)

Post reply on HN