Live data from Hacker News

Why Python Is Terrible

josvisser.substack.com

101–110 of 125 posts

Re: Why Python Is Terrible

#101

Earlier quoted context omitted.

And now, of course, it's deprecated because you wrote it in a version of Python that's no longer in support or used a library that hasn't been (or maybe won't be) ported to 3.11.

I did 2 to 3 migrations. It was fine. I would rather deal with these types of issues once in a while than work everyday with Java.

Yeah. I did 90kloc of python porting. Twice. Never working for a company that allows developers to use python again.

I'm glad you were able to port your scripts, but python is absolutely not appropriate for mission critical software.

Re: Why Python Is Terrible

#102

Python is a horrible language, but not for the reasons the author gives. Just because range() returns a generator doesn't mean the whole language is lazy. Several Lisps allow something like duck typing and they're not horrible. It is possible to reason about program behaviour in dynamic languages, but JavaScript certainly makes it hard. Python is a horrible language because it is not a language. It is a family of lan…

I've been programming in Python for most of the past 10 years, and I've never experienced a regression in backwards-compatibility between minor releases. What problems have you had?

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 originally wrote that code.

Though I did write some code that used package variables. And then the syntax for package variables changed, but that was an easy fix. And then the scope of package variables changed to be class variables, which is totally fine, but harder to find. Then the syntax changed again, but in a way that made it harder to fine. And then the debugger stopped working if you enabled async io for a few versions.

Python is for total amateur code fluffers.

Re: Why Python Is Terrible

#103

Earlier quoted context omitted.

> The standard way of error handling in python appears to be to present the user with a stack trace. What do you expect it to do? Silently fail and move on?

No. How about something that is neither "silently fail" or "print a stack trace"? How about something that lets the programmer handle the error?

Python has proper error-handling since 20+ years.

Re: Why Python Is Terrible

#104
post #67
post #24

I wish people could be honest and say they don't care for some language or framework or OS for personal or aesthetic reasons, rather than having to round it up to being objectively bad, but then I suppose nobody probably would click on "I don't like Python and have got some nits to pick". Oh and he just says what is supposed to be quiet part at the end: >And, not to put too fine a point on it, but if you can code Pyt…

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 libraries for training, a very glue-task. Give me any language better than python for that.

Quoting Brooks (butchered): “the only significant productivity improvement comes from relying on code that is already written”. Your fancy “better” language has not even 1/10th of what python has, it won’t replace it.

Re: Why Python Is Terrible

#105
post #12

> And, not to put too fine a point on it, but if you can code Python but not Go (or another decent programming language), you probably have no business writing software for a living. I know it sounds harsh and I apologize for that, but writing software is a profession and hence you should have the knowledge, skill, and experience to use professional tools. Part of the profession of software engineering is maintaining…

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.

Re: Why Python Is Terrible

#106
post #26

Every single "This language is good" or "This language is bad" take really needs to always come with a "for what, exactly." "This wrench is really bad for hammering nails!"

The author of this article does highlight the cases where using Python didn't work out well for them, in fact multiple times.

The context the author was working in was a large corporation with a demanding collection of services that needed to be managed. Many of the tools to manage those servers were written in Python, since many people know it, it was already widely used at the org, it had good support for C++ interop (also widely used at the org), and Java was found to be really clunky for sysadmin tooling.

I've seen both sides of it- I worked in the same sub-org as Jos, and my very first job was cleaning up a large pile of incredibly important and variable-quality Python code used to manage a fleet of database servers. the code was tools to do useful things like implement failover of the replication master (across ~90-120 shards) from one region to another for maintainence. Or apply schema changes across all those master shards. Or monitor the shards at runtime.

At times, the code would Exception (literally, crash with a Python exception) during the middle of an important but routine maintainence, and the migration would be half-done. I was hired- literally, this was my job- to add tests to the code until it was much more reliable. Working on that convinced me that rather than type-safety (which is nice, and can be used optionally in python), high test quality and high test coverage of paths used in production were more important to keep the code running smoothly.

I just wish Python hadn't made strings a sequence type, as one of the most common errors at the org was accidentally e m a i l i n g e v e r y s i n g l e letter in a To: string. IE, if it was "To: bore-sre@stoogle.com", then b@, o@, r@, e@, etc, would all get an email saying "Process failed..." And r@ would reply (because he's rob pike) saying "your python program has a bug...."

Re: Why Python Is Terrible

#107
post #6

Yes, pretty much agree with this word for word. It is very, very difficult to refactor a python application in any sort of reliable way. The standard way of error handling in python appears to be to present the user with a stack trace. Very user friendly (not!). Now people will say that, for instance, mypy can help with this. That is true but since projects can be started without type checking chances are that your p…

I couldn’t (and still can’t) believe that non-exceptional situations are considered exceptional. Such as, there not being a way to parse a string into a number and return a value indicating if it was successful or not. With Python everything is an exception. Messy and inelegant. Of course this mess is called “pythonic” so everything is fine… https://blog.codinghorror.com/exception-driven-development/a... https://stac…

What? You can return Exceptions instead of raising them. Since the language is dynamic, the caller can introspect.

Personally, from the perspective of a number parsing function, I think being passed an unparseable number counts as an "exceptional" situation- InvalidArgumentError- and I don't care which way it's returned- as an raised exception, or as an error object- as long as it's clearly documented, and the use matches the semantics of the function (NetworkNotAvailable is a better example of an exception where you're want to put something in the exception block)

Re: Why Python Is Terrible

#108

A few weeks ago I was working on a small wildfire smoke and fire perimeter API, and I hit a few annoying snags due to tooling issues. I needed to process a lot of different formats of layered geographic datasets, and converting one thing to another, processing the data into various buckets, cleaning, aggregating, etc. all wound up being extremely cumbersome and verbose. I write a lot of Go and I’m used to that. But w…

By the way, another nice thing about python is that you can force your program to drop into a debugger with an interactive shell at runtime- and inspect/print objects. In today's complex world of generic types, it can often be hard to see exactly which method is handling your data.

Re: Why Python Is Terrible

#109

Earlier quoted context omitted.

I've been programming in Python for most of the past 10 years, and I've never experienced a regression in backwards-compatibility between minor releases. What problems have you had?

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.
Post reply on HN