Live data from Hacker News

The Python Paradox (2004)

paulgraham.com

61–70 of 275 posts

Re: The Python Paradox (2004)

#61
post #11

(2004) It calls Python "esoteric"! :-D I agree with the sentiment even if the example given hasn't aged well.

I too tend to agree with the sentiment. What isn't mentioned though is that is quite possible to run out of people to hire. Which mostly happened to us, where we had grown and everyone in the relatively small Python community who could and would work for us was working or had worked. We had to move on to another new language (Go), although that did rub a number of the Pythonistas the wrong way.

Can you hire people who know other languages and train them in python? Why would you need to change languages?

Re: The Python Paradox (2004)

#62
post #18

When organisations were asked "Which languages and platforms in your application portfolio have been the greatest source of risk or exposure to your organization?" in the SANS Institute "A SANS Survey: Rethiking the Sec in DevSecOps: Security as Code", security officers mention Python 29.4% of the time (first of the list - they can choose up to three languages - dated 2021). My question is: when will Python be seen a…

I'd be willing to wager that is because Python is simply highly represented in the workplaces of those interviewed. To think Python in and of itself is more risky or exposing than other languages, especially those like C/C++ where it's considered by some to be impossible to write safe programs, doesn't make much sense.

Re: The Python Paradox (2004)

#64

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…

Well, the mypyc was not a side project originally, as mypy was conceived to be a complete programming language with optional static typing (https://www.slideshare.net/jukkaleh/mypy-pyconfi2012), but still (almost) 100 % python compatible and that variant was supposed to be transpileable into C.

Re: The Python Paradox (2004)

#65

In my experience, programmers obsessed with unconventional programming languages are exactly the ones that prioritize (over) engineering over simply shipping things. If you think, writing your codebase in a funky functional language would bear fruits in the long turn, you're in for a surprise. The road is full of pitfalls. Here are a few I outlined in my essay[1]: 1. Hiring is harder: "When it comes to hiring people,…

Also I've found that teams that focus on easily understandable languages (Python I think is the best with its "executable pseudocode" syntax) are those that are placing value on teamwork rather than individual flexing.

FWIW I've had opposite experiences. :shrug: Each team is different, I guess :)

Re: The Python Paradox (2004)

#66

In my experience, programmers obsessed with unconventional programming languages are exactly the ones that prioritize (over) engineering over simply shipping things. If you think, writing your codebase in a funky functional language would bear fruits in the long turn, you're in for a surprise. The road is full of pitfalls. Here are a few I outlined in my essay[1]: 1. Hiring is harder: "When it comes to hiring people,…

[deleted]

Re: The Python Paradox (2004)

#68

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…

I haven't followed development of the Python language in a while but this article was featured last week [1] and it does feel like committees.

I have followed development of C++ and... yeah, committees and subcommittees.

[1] https://chriswarrick.com/blog/2023/01/15/how-to-improve-pyth...

Re: The Python Paradox (2004)

#69

Python is great for small scripts or explorations. You can't use it for anything serious that needs to scale due to the lack of concurrency and significant memory overhead. If you need something to scale you use something like C++, Java, Go, Rust, etc.

> 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.

Re: The Python Paradox (2004)

#70

(2004) It calls Python "esoteric"! :-D I agree with the sentiment even if the example given hasn't aged well.

Around that time it was hard to get people to learn Python because they were turned off over whitespace delineated blocks. You could have their curly braces and semicolons when you pried it from their cold dead fingers.
Post reply on HN