Live data from Hacker News

Python is 1.3x faster by just adjusting some compiling options for libpython

bugs.python.org

41–50 of 105 posts

Re: Python is 1.3x faster by just adjusting some compiling options for libpython

#41
post #11

There’s nothing wrong with this post factually, but the tone sucks. It has an immensely combative energy for what is not really a charged subject matter. Like sure. Today, a lot of the historical reasons for things seem silly and irrelevant. At one point, they did not seem silly and irrelevant. For compatibility with stuff sticking around from those days, we get some performance penalties that are not strictly necess…

The OP was writing about a 29 year old design decision, and he wasn’t writing about a person. Design decisions don’t have feelings. I found his no holds barred clarity about something as obscure as dynamic linking namespaces made for an easier if still not easy read. But that said, I don’t think dynamic linking is in the ELF spec. I believe that’s a de facto OS + dev tools thing rather than an ELF spec de jure thing.…

> no holds barred clarity

There's a big difference between 'clarity' and confrontational, negative language.

Re: Python is 1.3x faster by just adjusting some compiling options for libpython

#42

Anyone got an archive link? I can't read this without making a Facebook account and signing in

I think I get to see the full text in iOS private mode without logging in. Didn’t have to click away anything, either.

Re: Python is 1.3x faster by just adjusting some compiling options for libpython

#43
post #36

Earlier quoted context omitted.

> I found his no holds barred clarity Being right is no excuse for being an asshole. The attitude will appeal to some. It will strike many others in the wrong way and put them on the defensive. There's no reason to write this way. A concise, well-articulated, non-combative post will appeal to everyone and still convey the same information.

I don’t think it’s possible to be an asshole to an inanimate object.

Even though the vitriol may be directed at an inanimate object, it may be distracting and obnoxious to the person who is reading.

Re: Python is 1.3x faster by just adjusting some compiling options for libpython

#44
post #36

Earlier quoted context omitted.

> I found his no holds barred clarity Being right is no excuse for being an asshole. The attitude will appeal to some. It will strike many others in the wrong way and put them on the defensive. There's no reason to write this way. A concise, well-articulated, non-combative post will appeal to everyone and still convey the same information.

I don’t think it’s possible to be an asshole to an inanimate object.

Someone wrote that inanimate object. Someone likes that inanimate object. Someone thinks that inanimate object has reasons to be the way it is.

Attacking that inanimate object is not without emotional repercussions to those related to that object.

Re: Python is 1.3x faster by just adjusting some compiling options for libpython

#45
post #36

Earlier quoted context omitted.

> I found his no holds barred clarity Being right is no excuse for being an asshole. The attitude will appeal to some. It will strike many others in the wrong way and put them on the defensive. There's no reason to write this way. A concise, well-articulated, non-combative post will appeal to everyone and still convey the same information.

I don’t think it’s possible to be an asshole to an inanimate object.

Unless that inanimate object was invented by a person or a group of people, in which case you are indirectly insulting those people.

Re: Python is 1.3x faster by just adjusting some compiling options for libpython

#46
post #11

There’s nothing wrong with this post factually, but the tone sucks. It has an immensely combative energy for what is not really a charged subject matter. Like sure. Today, a lot of the historical reasons for things seem silly and irrelevant. At one point, they did not seem silly and irrelevant. For compatibility with stuff sticking around from those days, we get some performance penalties that are not strictly necess…

The OP was writing about a 29 year old design decision, and he wasn’t writing about a person. Design decisions don’t have feelings. I found his no holds barred clarity about something as obscure as dynamic linking namespaces made for an easier if still not easy read. But that said, I don’t think dynamic linking is in the ELF spec. I believe that’s a de facto OS + dev tools thing rather than an ELF spec de jure thing.…

This is recalling the old Linus debates, but the aggressiveness _doesn't improve the clarity_, and is basically upping the word count.

I'm not tone policing but contesting the premise that "aggressive tone" = "direct". For example

>(Windows took a different approach and got it right. In Windows, it's okay for multiple DLLs to provide the same symbol, and there's no sad and desperate effort to pretend that a single namespace is still cool.)

>(Windows got this right, where multiple DLLs can provide the same symbol)

There you go. Shorter, and not wasting 3 lines to express your feelings, and _you can still say Windows got it right_.

My feeling is that you can go in and describe a thing succinctly and to the point, and actually get your opinion across! It will be more effective, shorter, and your opinions are backed up with fact! No fluff needed.

Re: Python is 1.3x faster by just adjusting some compiling options for libpython

#47

I'm confused. Is this about something I can do to speed up our 3.8 Python code, or about why Python 3.8 is faster than 3.7?

I think it was addressed by python already: Eventually, someone working on Python (ironically, of all things) noticed this waste of good performance But It would be good to know when & what versions. I'm also not sure why this is "ironic". Who else but the experts on python would be more likely to discover this & resolve the issue? Which basically makes the whole thing a non-issue: Python creators made a choice when…

> Python creators made a choice when creating python. The tone of the article makes it sound like this was an embarrassing mistake of massive proportions.

The article is talking about a bad decision in ELF and dynamic linking, not in Python specifically. The Python people just discovered that disabling that default behavior was useful.

Re: Python is 1.3x faster by just adjusting some compiling options for libpython

#48
Python is like the cockroach equivalent of those shell scripting languages that came out of the late 80s to early 90s.

Perl, Ruby, PHP, TCL, and Lua have definetly declined over the years. Python's biggest asset seems to be featured rich libraries, rather than the language itself.

Re: Python is 1.3x faster by just adjusting some compiling options for libpython

#49
post #11

There’s nothing wrong with this post factually, but the tone sucks. It has an immensely combative energy for what is not really a charged subject matter. Like sure. Today, a lot of the historical reasons for things seem silly and irrelevant. At one point, they did not seem silly and irrelevant. For compatibility with stuff sticking around from those days, we get some performance penalties that are not strictly necess…

The OP was writing about a 29 year old design decision, and he wasn’t writing about a person. Design decisions don’t have feelings. I found his no holds barred clarity about something as obscure as dynamic linking namespaces made for an easier if still not easy read. But that said, I don’t think dynamic linking is in the ELF spec. I believe that’s a de facto OS + dev tools thing rather than an ELF spec de jure thing.…

> The OP was writing about a 29 year old design decision, and he wasn’t writing about a person. Design decisions don’t have feelings. I found his no holds barred clarity about something as obscure as dynamic linking namespaces made for an easier if still not easy read.

I don't think that it would've been hard to maintain the exact same level of clarity regarding the subject matter. Perhaps the read was more entertaining due to the abrasive tone, but was it actually easier to read?

Ultimately, design decisions are made by people - if someone made such a takedown of ideas of mine, I would probably be somewhat discouraged, at least as long as I know they are being sincere and not just doing a bit. I don't think people should be flinching in their criticisms of ideas, but being fair to nuance and history really would be welcome too. It's one thing to point out dysfunctions in things, but it's different to pull out a sort of Angry Video Game Nerd-esque personality and drag how horrible things are through the mud.

Maybe this post is more in jest than not and I(/we?) simply did not pick up on the tone being purely for entertainment value. But that's the thing. When people read things like this, I think a lot of people take it too seriously and start to embody this attitude, and it leads to the kind of thought processes where things are either good, or stupid/evil/whatever, with no room for things that are just "not perfect, but overall fine."

Hell, I feel kind of bad due to how unnecessarily personal my comments regarding this feel. How would the author feel reading this? The fact that I may be right doesn't matter, because I'm not some kind of uncaring asshole, and I think most people are not if they are in the right mind.

> But that said, I don’t think dynamic linking is in the ELF spec. I believe that’s a de facto OS + dev tools thing rather than an ELF spec de jure thing. His points are still valid.

Like I had said initially, I do not take any issue with the factual content of the post, and agree that most people should be using these compiler flags. And yes, it is, however many years later from when this may have not been the norm, now clearly a good idea to make all of your symbols hidden by default. No disagreements from me. I just hope that people don't walk away with the idea that some morons from the past made some horribly stupid mistakes because they just had no idea what they were doing. I wasn't there, but it doesn't feel like that's what happened at all; it feels like as things panned out some things worked out well, and some things did not work out well. Some ideas are more clearly 'bad' ideas than they were. Even today, it would probably be unwise to assume we still know 100% what we're doing. Personally, I think it's hard to ever be absolutely sure you are taking the right lessons away from things that don't work out well.

Post reply on HN