4 ms·

> That's the cost of being a dynamic language. No, this is a cost of this particular style of dynamic object model. Not all dynamic languages are dynamic in th

> That's the cost of being a dynamic language. No, this is a cost of this particular style of dynamic object model. Not all dynamic languages are dynamic in this way. > Those objects are not enhance-able any more. I don't see any reason why Python can't do what Clojure's defrecord does: Provide fixed fields for pre-declared slots, while still using a dictionary for extensions. It has been a while since I've used python, but I'm almost certain that there is some __special__ magic that can make this work with relative ease. It's also worth pointing out that most modern JITs, like V8 or PyPy, can automatically detect "hidden classes" like this and optimize these objects to pack such static fields.

gsnedders 13y ago
"modern JITs" aren't so modern at all. All that work was originally done on Smalltalk in the 1980s — it's also entirely tangential to JITing compilers, as it can easily be done with interpreters too, so it's not even a cost of this particular style of dynamic object model — it's a cost of this implementation strategy of this particular style of dynamic object model. The fact that PyPy manages fine shows it is not the language, or any model to which it subscribes, that is at fault.
PythonicAlpha 13y ago
I did not say, that every dynamic language has to implement it this way, but Python does. And Python was not intended to be a language for building up huge data masses in memory, though it does not so bad in most cases (leaving out the mentioned ones). Pythons style has some advantages though. Simplicity and really a huge quantity of flexibility are two of them. (Traditional) Python normally is not a truly compiled language -- it is just a rather simple precompilation step that makes life easier for the interpreter. When you compile or "JIT" the code, you have more options. You see the whole program. The precompiler of Python does not! It just sees the local module. So, it can not find all classes that might enhance a base class. If you have any ideas, how to implement a better language, why don't you implement your own? It's up to you! (I guess, creating new (more or less useful) programming languages is the hobby of computer scientists anyhow)

gsnedders 13y ago

"modern JITs" aren't so modern at all. All that work was originally done on Smalltalk in the 1980s — it's also entirely tangential to JITing compilers, as it can easily be done with interpreters too, so it's not even a cost of this particular style of dynamic object model — it's a cost of this implementation strategy of this particular style of dynamic object model. The fact that PyPy manages fine shows it is not the language, or any model to which it subscribes, that is at fault.

PythonicAlpha 13y ago

I did not say, that every dynamic language has to implement it this way, but Python does. And Python was not intended to be a language for building up huge data masses in memory, though it does not so bad in most cases (leaving out the mentioned ones). Pythons style has some advantages though. Simplicity and really a huge quantity of flexibility are two of them. (Traditional) Python normally is not a truly compiled language -- it is just a rather simple precompilation step that makes life easier for the interpreter. When you compile or "JIT" the code, you have more options. You see the whole program. The precompiler of Python does not! It just sees the local module. So, it can not find all classes that might enhance a base class. If you have any ideas, how to implement a better language, why don't you implement your own? It's up to you! (I guess, creating new (more or less useful) programming languages is the hobby of computer scientists anyhow)