Live data from Hacker News

Python's pre-declared constants are kinda weird

sebsite.pw

31–40 of 234 posts

Re: Python's pre-declared constants are kinda weird

#31
post #8
post #5

Earlier quoted context omitted.

It is 30+ years old with all the baggage you would expect. It’s very much a product of its time.

It’s not like that cannot be changed. Look at PHP, which managed to evolve brilliantly over the last decade and gets tons of things right now.

I keep on hearing people be excited about PHP. Having first attempted to use PHP in early 00s, I simply cannot bring myself to attempt it again. I once had to rewrite large chunks of a site because it simply couldn't deal with the fact that a string had an apostrophe in it.

Re: Python's pre-declared constants are kinda weird

#32

I remember reading that in early versions of Python there was no built in True and False. Each user would implement this themselves as True = 1 False = 0 then later these got added to the language. In Python 2 you could still reassign and swap them so that 'if False' was actually true! True, False = False, True Python 3 you could no longer reassign them.

Misery is trying to retrofit "bool", True/False, and nil/null to a language. C had to do that. Python had to do that. Getting those wrong is one of the classic language design mistakes. It seems like treating "True" as a value that equates to 1 will work, but then the special cases get you. Like being able to perform arithmetic on True.

Common language design boners:

- Not building in strings. That's now in the past. Everybody has strings. (Well, C...)

- Not building in multidimensional arrays of the numeric types. Everything that number-crunches needs them, and having multiple definitions is Not Fun and may lead to expensive re-copying between different libraries. This is an enormous blind spot in language design. It's one of the reasons FORTRAN, which has good multidimensional numeric arrays, is still often used for number-crunching.

- Not standardizing the small vectors (vec2, vec3, vec4) and their matrix friends. Graphics code depends on these, and it's really annoying if there are multiple slightly incompatible implementations. Especially since GPUs have hardware for those types, and you want CPU and GPU to use the same representations.

- Not having arrays of bits. Pascal had PACKED ARRAY[0..N] of BOOLEAN but that was lost in later languages. It's useful to have that as a language construct, because most modern CPUs have good hardware for dealing with bit strings, and you'd like the compiler to use it.

Most useful languages acquire these features, but, when they come in late, there are multiple similar implementations, and libraries made incompatible by depending on different implementations.

(Amusingly, when Second Life switched from Linden Scripting Language to Luau, they initially had True, TRUE, and true all in use, as different types with different semantics. I was able to persuade the devs to unify the boolean types.)

Re: Python's pre-declared constants are kinda weird

#33
post #28

just my 2c but py is honestly one of the worst languages and ecosystems i’ve used in my life. for all the hate js used to get, py is at least a few magnitudes worse. my opinion ofc. don’t get mad xD

I'm not mad, but curious - I use Python for years and only dabbled with JS. Could you elaborate what makes Python magnitide worse than JavaScript?

Don't mind the web designers calling themselves engineers.

There's a lot of annoying issues with Python, but compared to the billions of dollars and thousands of man hours that has been spent trying to fix Javascript and how horrible it still is, it's a perfectly cromulent language.

Re: Python's pre-declared constants are kinda weird

#34
Python is awful. There are so many one offs in libraries, none agree on a style, it’s slow, and it’s way too easy to do the wrong thing. I often work with data scientists and have to productionize their jupyter notebooks which is pure suboptimal hell. I guess it must be a good easy learning curve for research/scratchpad

Re: Python's pre-declared constants are kinda weird

#35
post #28

just my 2c but py is honestly one of the worst languages and ecosystems i’ve used in my life. for all the hate js used to get, py is at least a few magnitudes worse. my opinion ofc. don’t get mad xD

I'm not mad, but curious - I use Python for years and only dabbled with JS. Could you elaborate what makes Python magnitide worse than JavaScript?

Not OP, but dependency management, for one.

Re: Python's pre-declared constants are kinda weird

#36

Python is awful. There are so many one offs in libraries, none agree on a style, it’s slow, and it’s way too easy to do the wrong thing. I often work with data scientists and have to productionize their jupyter notebooks which is pure suboptimal hell. I guess it must be a good easy learning curve for research/scratchpad

Seems like an excellent user for LLMs

Re: Python's pre-declared constants are kinda weird

#37

just my 2c but py is honestly one of the worst languages and ecosystems i’ve used in my life. for all the hate js used to get, py is at least a few magnitudes worse. my opinion ofc. don’t get mad xD

JavaScript has its share of wtfs, so I wonder how much of it is which one someone experienced during some formative window in their learning.

Did you encounter JS first?

Re: Python's pre-declared constants are kinda weird

#38
post #8
post #5

Earlier quoted context omitted.

It is 30+ years old with all the baggage you would expect. It’s very much a product of its time.

It’s not like that cannot be changed. Look at PHP, which managed to evolve brilliantly over the last decade and gets tons of things right now.

PHP has evolved a lot, but it also still has a lot of cruft from its earlier days. And it has made breaking changes on a scale python probably couldn't get away with.

Re: Python's pre-declared constants are kinda weird

#39
post #9

Earlier quoted context omitted.

Python certainly has some baggage, especially the typing system (which is still not finished, if you're looking at static typing and so is implemented differently by type checkers) and pip's safety, or lack thereof. But comparing it to PHP or Perl is rhetoric leading you one step too far.

Comparing it with PHP is unfair… to PHP. The amount of hard work that the PHP community has done to advance and keep their language relevant is impressive and admirable, and Python is perhaps the most extreme counterexample there is. The Python community has spent the last 15 years refusing to improve in any meaningful way, or to learn anything from their peers. As someone who used to choose only jobs that would let…

Most of the time downvoters don't explain their downvote, but I'll explain mine. I voted this comment down because it's just plain incorrect.I worked with PHP for nearly ten years (and I never want to go back). Maybe PHP has improved since I worked with it (PHP 7.4 was the most recent version when I last worked with it, I have never used PHP 8), but I doubt it.

But to describe the Python community as "spen[ding] the last 15 years refusing to improve in any meaningful way" is just laughably wrong. I can't give details as I haven't been doing much Python work, but even so I know of multiple changes, such as the typing system, or packaging improvements, which have significantly improved the language AFAICT. If there's a reason why you would not consider those to be "improv[ing] in any meaningful way", please enlighten me.

Re: Python's pre-declared constants are kinda weird

#40
post #32

I remember reading that in early versions of Python there was no built in True and False. Each user would implement this themselves as True = 1 False = 0 then later these got added to the language. In Python 2 you could still reassign and swap them so that 'if False' was actually true! True, False = False, True Python 3 you could no longer reassign them.

Misery is trying to retrofit "bool", True/False, and nil/null to a language. C had to do that. Python had to do that. Getting those wrong is one of the classic language design mistakes. It seems like treating "True" as a value that equates to 1 will work, but then the special cases get you. Like being able to perform arithmetic on True. Common language design boners: - Not building in strings. That's now in the past.…

> Not having arrays of bits. Pascal had PACKED ARRAY[0..N] of BOOLEAN but that was lost in later languages. It's useful to have that as a language construct, because most modern CPUs have good hardware for dealing with bit strings, and you'd like the compiler to use it.

I'm not sure exactly which features are responsible (I'm inclined to blame templates), but C++'s std::vector is a rough edge. For those unfamiliar, the standard specifies this vector template in a way that's not compatible with other vectors.

Post reply on HN