Hacker News Reader

Comment by Rusky | Hacker News Reader

> Also a language is neither fast nor slow, the implementation of said language is.

I don't like how much this simplification gets used. Of course there is more than one way to implement a given language. But there is also more than one way to design a language, and that can have big effects on its implementation(s), and that's usually what people mean when they speak of "fast languages."

Not to mention that many languages only have one implementation, or else many that have all converged to the same performance characteristics.

And on top of that, it's rarely a question of how fast or slow an entire implementation is, either! Individual codebases or problem spaces need different things from their languages.

View on HN

It’s not a simplification, it’s observing a basic category error. It’s confusing the procedure and the process. Consider for example how the same procedure executing in the same runtime on different processor families will result in highly divergent executing processes. And practically speaking even then they may not even be equivalent up to the explicitly or implicitly specified behavior. Nevertheless ideally when we talk about a language we are talking about a set of semantics that is independent of whatever mechanism executes the processes specified by procedures written in that language.

Some semantics are inherently slow though. If you are allowed to add fields to a class at runtime, you have to box all your objects. If you can eval in local scopes, you need to check to make sure you're running the right code. There are many types of semantic decisions with inevitable performance impact.

> If you are allowed to add fields to a class at runtime, you have to box all your objects.

Do you? You could restructure your data in memory if you wanted to, at least if the assumption is that adding a field is a rare operation.

I would not expect that such features are added under the assumption that it is rarely used.

Common Lisp for example has the assumption in the standard, that the object system is fully dynamic and supports a wide variety of live changes (adding/removing/changing of methods, classes, slots, superclasses, ...).

"Rarely" meaning compared to other elementary operations, such as function or method calls. So it makes sense to make function or method calls faster at the expense of making restructuring slower. That's basically the same principle as with Smalltalk and Lisp structures/objects being vectors as opposed to hash tables (like in Ruby or Python), even if it means that adding a field necessitates having to change the layout of existing instances. This way you'd need to also change the layout of other types that use the unboxed representation of the type being altered but the basic principle is the same and you already have the mechanism for updating your existing heap anyway -- so it should be possible and mere possibility of altering a type shouldn't necessitate boxing everything. "If you are allowed to add fields to a class at runtime, you have to box all your objects" should be no more correct than "if you are allowed to add fields to a class at runtime, all your object instances have to be hash tables".

Reply on news.ycombinator.com