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

Why Python Is Terrible

josvisser.substack.com

Post reply on HN
Print view View original

111–120 of 125 posts

Re: Why Python Is Terrible

#111

Post by rvieira »

kaba0 wrote: post #104
rvieira wrote: post #67

Earlier quoted context omitted.

I really think that Python is not a good language for ML, it just got "there" first. The ecosystem is the real plus, of course. But the language is a headache for this. I agree with the "false economy" angle. I would happily trade the "agility" of dynamic "gluing" with some kind of real type safety, human-readable error messages and performance[0]. [0] - hiding C in Python's clothes doesn't count :)

Python is the de facto glue language with one of the biggest ecosystems out there, that makes it possible to use any kind of over-the-top library that does 1093 things after a single `import antigravity`. Also, ML absolutely makes sense for python, it’s not like most PLs have actual support for video cards — ML is very specifically about manipulating data (a fundamentally dynamic task) and calling out to specific lib…

> Python is the de facto glue language with one of the biggest ecosystems out there

I never contested that.

> ML is very specifically about manipulating data (a fundamentally dynamic task)

I disagree strongly with using dynamic languages for data. Data has dimensions, units, types. You need to know that you're not adding coats to horses or USD to EUR. You need to know that you didn't silently sliced by the wrong axis. You may want formal verifications. You may to transform data without worrying about silent errors.

All the "metadata" and wrapper classes ML in Python are just trying to give you what the language can't.

> a very glue-task. Give me any language better than python for that

That's my point exactly. ML has evolved beyond glueing a few C libraries. It needs complex, big programs, which is an area where Python is terrible. Also the different nature of the "glued" components (each with its own data formats, protocols and calling conventions) makes the glue a mish-mash of untyped mixed magic idioms.

Re: Why Python Is Terrible

#112

Post by kaba0 »

rvieira wrote: post #111
kaba0 wrote: post #104

Earlier quoted context omitted.

Python is the de facto glue language with one of the biggest ecosystems out there, that makes it possible to use any kind of over-the-top library that does 1093 things after a single `import antigravity`. Also, ML absolutely makes sense for python, it’s not like most PLs have actual support for video cards — ML is very specifically about manipulating data (a fundamentally dynamic task) and calling out to specific lib…

> Python is the de facto glue language with one of the biggest ecosystems out there I never contested that. > ML is very specifically about manipulating data (a fundamentally dynamic task) I disagree strongly with using dynamic languages for data. Data has dimensions, units, types. You need to know that you're not adding coats to horses or USD to EUR. You need to know that you didn't silently sliced by the wrong axis…

Training and using ML is different. It has been relatively common to bundle the trained weights with a different programming language system - but training can be a more exploratory phase, so python is not a bad fit for that.

Re: Why Python Is Terrible

#113

Post by Rochus »

> Using Python for a large application is like building a nuclear reactor using Lego bricks

I like this comparison. Anyway, it's interesting to note that it took the author "many years of experience running large applications written in Python" to come to his conclusions. The advantages of static typing and the disadvantages of dynamic or duck typing are well known since decades. The problem is less Python as a language, but the fly-by-night decisions to just use it for anything. To stick with the example: what prevents people from using "Lego bricks" (or a high-temperature proof version thereof) to build a reactor? Sound engineering decisions and, most importantly, safety regulations.

Re: Why Python Is Terrible

#114

Post by IOT_Apprentice »

timbit42 wrote: post #68
IOT_Apprentice wrote: post #39

Earlier quoted context omitted.

Let me ask the obvious question. Why hasn’t the go community, of professional software engineers built an even richer ecosystem of libraries? Is it ennui, incompetence, or attitude? As Go came from Google, is that the attitude was, “I am a professional I’ll just write my own code to solve X”, rather than considering building a library that others can use? Are libraries harder to build in Go? Is adoption of libraries…

It hasn't been around as long as Python.

That is true, but where are the go libraries for machine learning, tensors, LLMs, equivalents to PyTorch that I see bandied about?

Others have stated that they don’t need such libraries in Go, or that Python just has a glut of libraries that are a sort of detritus obsolete or language version specific.

Why isn’t Go then, THE language of choice for machine learning, analytics, fast prototyping, data conversion, ETL, etc.

What I’ve heard of Rust in comparison is that the syntax of the language & the learning curve is counterintuitive for engagement by non-computer scientists or systems programmers.

Seems expected then that, non comp-sci folks will choose a language that is more accessible, with an ecosystem that lets them get things done in a short period of time.

I would wonder if it it that the experts & heavy users of Go or language architects moving Go forward see any need for a parallel course of engagement to bring Pythonists into the fold or to allow Go to become the language people choose over Python or TypeScript, et al, by providing a best of class approach to quickly prototyping and extending into well architected systems as an underlying function.

Re: Why Python Is Terrible

#115

Post by IOT_Apprentice »

dafhagionio wrote: post #73
IOT_Apprentice wrote: post #39

Earlier quoted context omitted.

Let me ask the obvious question. Why hasn’t the go community, of professional software engineers built an even richer ecosystem of libraries? Is it ennui, incompetence, or attitude? As Go came from Google, is that the attitude was, “I am a professional I’ll just write my own code to solve X”, rather than considering building a library that others can use? Are libraries harder to build in Go? Is adoption of libraries…

Why do people use Microsoft Windows on x86? The computer industry has a bizarre reputation for moving fast and breaking things. In fact the industry is shockingly conservative. You will encounter many, many programmers who flat-out refuse to learn new things.

Most companies & universities aren’t exposed to cutting edge or even modern technology. They stay in their bubble.

Leaving Silicon Valley, I’ve found the engineering management culture can be averse to training and allowing active skill building via development projects.

Just code that shit in Java or C++, doesn’t matter if you haven’t been trained in SQL properly or are even aware of best practices.

That culture leads to some gruesome product implementations & upgrade scenarios.

Hell, our IT department blocks this very website from being accessed.

I access it from my personal devices.

Re: Why Python Is Terrible

#116

Post by retrocryptid »

neoncontrails wrote: post #109
retrocryptid wrote: post #102

Earlier quoted context omitted.

The syntax of the language changes every version in non-backwards-compatible ways. If you have a couple scripts, sure, maybe you're not affected. But when you buy a company that shat out 90kloc of python and then all the employees quit, it's not a happy day. And sure... I shouldn't have used those features. I get it. I'm the one who's bad because I'm calling your baby ugly. Even though I wasn't the one that originall…

Which syntactic features have changed in ways that aren't backwards compatible? I've had some minor headaches, don't get me wrong, but in each case those headaches are a result of interface changes to common objects, like Exception-types. Python has added some syntactic sugar between minor releases, sure, but never at the expense of backwards compatibility.

Package variables. Class variables. Syntax changed between 2.3, 2.5 and 2.7. And the semantics changed somewhere between 2.3 and 2.7.

Re: Why Python Is Terrible

#117

Post by IOT_Apprentice »

kaba0 wrote: post #105
IOT_Apprentice wrote: post #39

Earlier quoted context omitted.

Let me ask the obvious question. Why hasn’t the go community, of professional software engineers built an even richer ecosystem of libraries? Is it ennui, incompetence, or attitude? As Go came from Google, is that the attitude was, “I am a professional I’ll just write my own code to solve X”, rather than considering building a library that others can use? Are libraries harder to build in Go? Is adoption of libraries…

Not sure if rhetoric question only, but Go has the expressivity of C. Let’s not compare it to python that is often textbook pseudo code like.

If the “expressivity of C was such a wonderful thing why was Go even needed? Why was Java & J2EE promoted to enterprise development?

Might it be that coding in C was and is hard and further that memory management pointer issues and more led to unstable code?

Re: Why Python Is Terrible

#118

Post by kaba0 »

IOT_Apprentice wrote: post #117
kaba0 wrote: post #105

Earlier quoted context omitted.

Not sure if rhetoric question only, but Go has the expressivity of C. Let’s not compare it to python that is often textbook pseudo code like.

If the “expressivity of C was such a wonderful thing why was Go even needed? Why was Java & J2EE promoted to enterprise development? Might it be that coding in C was and is hard and further that memory management pointer issues and more led to unstable code?

I wrote my comment as a negative — C is terribly inexpressive, just as Go.

Re: Why Python Is Terrible

#119

Post by Goofy_Coyote »

wrs wrote: post #82
Goofy_Coyote wrote: post #45

Can someone explain this part to me, please? I don't follow what's going on. > Python's use of reference counting defeated copy-on-write because even memory blocks holding variables that were read-only were actually written to in order to manipulate the reference counts, thereby blowing up the combined physical memory footprint of the workers. We solved this by smurfing the interpreter to use a magic reference count…

You have a program that for whatever reason (the Python runtime in this case) only works single-threaded, although its workload could be easily parallelized (say, it’s a web server where requests are processed independently). An old established way to accomplish this is to start a “master” process which forks N “worker” processes, each of which can happily run single-threaded. This would be a nonstarter if it require…

Thank you, this is a great explanation - much appreciated

Re: Why Python Is Terrible

#120

Post by neoncontrails »

retrocryptid wrote: post #116
neoncontrails wrote: post #109

Earlier quoted context omitted.

Which syntactic features have changed in ways that aren't backwards compatible? I've had some minor headaches, don't get me wrong, but in each case those headaches are a result of interface changes to common objects, like Exception-types. Python has added some syntactic sugar between minor releases, sure, but never at the expense of backwards compatibility.

Package variables. Class variables. Syntax changed between 2.3, 2.5 and 2.7. And the semantics changed somewhere between 2.3 and 2.7.

Wow, didn't realize folks were still actively developing on Python 2.x. FWIW, the Python steering committee takes backwards-compatibility pretty seriously these days. Here's a recent mailing list discussion on it's decision to reject a popular PEP on the grounds that it would have broken Pydantic: https://mail.python.org/archives/list/python-dev@python.org/...
Post reply on HN