3 ms·
The reference Python interpreter is implemented in C, does that invalidate the common sense observation that python is dynamic while C is static ? What counts i
by Banana699 5y ago
The reference Python interpreter is implemented in C, does that invalidate the common sense observation that python is dynamic while C is static ? What counts is the default zero-effort mode. Sliding into "All languages are turing complete so all distinctions are meaningless" territory is very rarely helpful for conversations.
Sure C++ offers you both stack and heap allocations, virtual and ordinary methods, static types and std::any for values of unknown/irrelevant runtime type. But the default zero-effort thing to do is to use statically-typed stack-allocated objects with non-virtual methods. Java only offers two of these things and one of them needs to be explicitly stated upfront. And, furthermore, Java's runtime still maintains the full machinery needed to do dynamic typing and dynamic method dispatch (the final modifier on methods is purely a promise to javac, the JVM has no concept of a method call that doesn't involve looking up the class it refers to and potentially all of its superclasses), it doesn't matter that you don't use it, your calling code or called code might, and the specification says that it can.
C++ objects compile to dumb bit buckets that contain exactly what's asked of them and nothing more. No matter what you do, you can never have all class types in C++ share a common ancestor, and the ones you can will know nothing about their parents unless specifically asked to with 'virtual', they can only remember this when allocated on the heap.
- pjmlp 5y agoYeah, because there isn't such thing as C++ language runtime, RTTI, dynamic_cast<>() and loading C++ classes via shared objects. /s
- Banana699 5y ago>RTTI, dynamic_cast<>() I don't get the snark, these things are only allowed for virtual-method-containing classes, something I explicitly mentioned and said it doesn't count because it's not on by default, not idiomatic to be on by default, doesn't exist in binaries or at runtime when not in the source, and is extremly limited compared to the rich metadata every java object hold no matter what you do or say (so even objects of final classes have it). >loading C++ classes via shared objects A capability of the underlying operating system, which _is_ a "runtime", just not a standard or required part of the language, and shared objects or dynamic libraries know a tiny drop of water about their source compared to the ocean of metadata in every .class file and the runtime representation of them. >C++ language runtime What does that even mean in this context ? I have heard it said to refer to the standard library, which is ridiculous in our context because it's neither required (let alone mandatory) part of the language nor carries information or controls execution of the calling code like the java runtime does. I have heard it being said to refer the variant of C++ that Microsoft runs on the CLR, which might as well be C# in this context. The closest thing would be the Exception Handling Mechanism and the runtime info it requires, but that's again extremely limited compared to what java does and a qualitatively different thing. Dumb tables of pointers or return addresses can never be comparable to the very rich representation of types and other metadata about code that the JVM or the CLR does.
- deleted 5y ago[deleted]
- pjmlp 5y agoFirst of all, an ISO C++ compliant implementation can run bare metal, there isn't any requirement that an OS must exist, that is the whole point of a systems programming language. Secondly a C++ runtime is responsible for running all global variable contructors and destructors, handling exceptions, soft floating operations, loading shared libraries on demand for dynamic linking (depending on OS capabilities or bare metal), how new/delete translation into the underlying OS/MMU. As for the metadata, so when I use static reflection in C++, either via template metaprogramming, or with the features that sadly will only come in C++26, then what? And really I just picked C++ as first example that came into my mind. We can also start discussing Eiffel, Delphi, Swift or Go for example, with their rich type information, dynamic dispatch, rich runtimes, and native compilation model, so they are also dynamic?
- Banana699 5y ago>an ISO C++ compliant implementation can run bare metal, there isn't any requirement that an OS must exist Ok? so This point contradicts you, the language defines no runtime support, so it's very difficult to do the things that a language with a runtime in its specification considers for-granted. >a C++ runtime is responsible for running all global variable contructors and destructors, handling exceptions, soft floating operations, loading shared libraries on demand for dynamic linking (depending on OS capabilities or bare metal), how new/delete translation into the underlying OS/MMU. This is a misuse of the term as used in our context, almost all of the above can be considered as simply linked/injected code. The global variable initialization is done by startup code injected by the linker, the construction and destruction code is routine boilerplate inserted by the compiler at specific fixed locations, the new/delete operators simply wrap calls to the underlying memory allocators to call constructors and destructors properly, etc... Nothing of these features knows anything of value about the source code it's injected into, they are just boilerplate function calls inserted for housekeeping. Only loading dynamic libraries can be considered as remotely "runtimey", and I have never heard of them done on anything without an OS. >so when I use static reflection in C++, either via template metaprogramming, This is compile-time reflection, it's neat but has nothing to do with dynamacity or runtime support. The original point was 'C++ is drastically less dynamic than Java because it's binaries are very thin and it's philosophy is that the compiler shaves as much of the high-level semantics as it can and leaves nothing but raw, dumb, optimized bits'. I don't see how compile-time metaprogramming contradicts this. >or with the features that sadly will only come in C++26, What are those features exactly? do they include, for example, that the compiler injects the name, fields and method signatures of every class into an inspectable object? If yes, then those features, when they come, _will_ make C++ significantly more dynamic. (and its binaries significantly fatter) >really I just picked C++ as first example that came into my mind A very bad example to say the least. >We can also start discussing Eiffel, Delphi, Swift or Go Let's do it indeed, I love discussing programming languages! What exact features or abstractions of each of those language that you think will classify it as dynamic? If they are similar in quantity or quality to what the JVM does it should indeed qualify as more dynamic than C/C++ (almost everything is). Dynamic-Static is a spectrum, not a binary category.