I'd call it "Subjective-C", it would be a language open up to interpretation...

:D

"Dream no more"

Just because it would be so strong, and so efficient it would make dreams come true in moments of coding.

hmm... there seems to be enough general interest in VM managed C to almost make me think that it might be worthwhile to go implement it...

likely architecture:

compiler: prior C frontend -> FRBC -> 'EXE' (package, *1)

interpreter: 'EXE' -> FRIR / JIT

(where FRBC is essentially a Dalvik-like Register IR).

luckily I already have most of the major parts...

using plain C though would likely require a wrapper layer to try to gloss over things like MSVCRT vs Newlib vs Glibc and similar though, though I already partly have this part as well in the form of a modified/expanded PDPCLIB + POSIX-like API wrappers. partly as a lot of "detail issues", like values of various #define's, struct layouts, ... tend to vary from one C runtime and another, so it is needed to provide a consistent C runtime to avoid stuff blowing up... (and to provide consistent DLLs to link against, ...). (note that the VM and library wrappers would still need to be ported to each target...).

*1: probably one of raw PE/COFF, PE/COFF+ExWAD (my current VM works this way), or raw ExWAD. (ExWAD is a WAD based format, initially based on the Quake WAD2 format... things like bytecode and metadata and so on are stored in various "lumps", more-or-less...).

hmm... "FRBC" -> "FurbyC"... seems to be available...

I'd combine the best of Lisp and Erlang and call it Erlisp or Lilang.

Offtopic: Can being too expressive actually cause you to not be able to express yourself?

What, exactly, does "VM managed C" even mean?

the language is still C, and still behaves pretty much like plain old C and can use native-compiled libraries and so on, but rather than being compiled directly to native code, is compiled first to a bytecode format, and possibly compiled to native code for each target (such as via a JIT compiler, or maybe an AOT compiler), allowing an increased range of portability (no need to recompile a "reasonably written" application to run on various targets, provided the VM is available).

granted, there are a few technical hurdles which would be involved with making something like this "work reasonably well" and "not suck too badly".

for example, ideally:

requirements should be small, and it should not require a heavyweight VM runtime;

performance shouldn't be too awful (not drastically slower than direct native compilation);

ideally it shouldn't get in the way of utilizing platform-specific functionality (as-needed), and should be "reasonably transparent" (allowing direct calling and data-sharing between natively-compiled and VM managed code, IOW: ABI compatible with native code);

ideally the bytecode should be reasonably agnostic to the particular backend used (IOW: not LLVM bitcode or similar);

...

IOW: where it ideally still retains a lot of the relative merits of developing natively-compiled apps, while at the same time lessening the need to recompile all the code for each target.

possible secondary sub-goals:

ideally, provide some some semblance of memory protection (while using pointers), and possibly access-rights validation;

provide an "easier" target for dynamically compiled code (API functionality similar to the JVM ClassLoader facilities, *1);

provide an API for dynamic compilation ("load from source", etc...);

...

*1: while there would still be the option of getting RWX memory from the OS, writing into it, and then calling it, this would be CPU-architecture specific, whereas ideally the program should be able to compose its own bytecode and feed it into the Loader API, and then fetch back a compiled function-pointer or similar.

partly unresolved issues:

library / versioning issues (where different targets have different libraries or library versions, which can't really easily addressed within the confines of standard C or C++, hence why some wrapping of core APIs would be needed);

good handling of target-specific code (*2);

...

*2: traditional #ifdef would no longer be a particularly effective portability mechanism (due to it being handled too early in the compilation process), likely requiring a new mechanism to address a similar use-case. one possible option here would be introducing a construct for JIT time conditionals, for example: "_Ifdef(VAR) { ... }", which would be evaluated at JIT-time (as opposed to during preprocessing or at run-time). however, this mechanism would itself introduce a few new ugly problems (related to the use of OS-specific headers on other targets).

likely, a "simpler" solution of marking individual compilation-units as belonging to particular architectures and compiling them as-if they were running under the target in question, then the loader will skip versions of compilation units compiled for an incompatible architecture:

#pragma CompileAsIfOS(linux, WIN32, default)

#pragma CompileAsIfCPU(X86, X86_64, AArch64:linux, default)

...

or such...

I would name my language AWESOME.

the language is still C, and still behaves pretty much like plain old C and can use native-compiled libraries and so on, but rather than being compiled directly to native code, is compiled first to a bytecode format, and possibly compiled to native code for each target (such as via a JIT compiler, or maybe an AOT compiler), allowing an increased range of portability (no need to recompile a "reasonably written" application to run on various targets, provided the VM is available).

who came up with the name of C(or C++) anyway?

Ken Thompson and/or Dennis Ritchie. C is named as such because apparently it was heavily influenced by the programming language B.

C++ was an expansion on C, and I'm assuming named because it is an incremental expansion over C instead of something designed completely from the ground up.

Pretty much.

C was named like that because it was based on B, which in turn got its name from Bell (since it was a language developed there). As for C++, it was an extension of C, so they used the increment operator to show that (but originally it was called C with classes, back when classes were the only addition to the language - thereby why some C++ source files have .cc as the filename extension).